[cisco-voip] PBX-to-IPPBX calls

Fri Jun 5 12:51:06 EDT 2009

I have seen similar when you depend on the default dial-peers (undefined
incoming .)

debug voip ccapi inout will allow you to trace the call through peer
matching.

Best Regards,

Mike Lydick

On Fri, Jun 5, 2009 at 12:45 PM, Ratko Dodevski <rade239 at gmail.com> wrote:

> Hm... I was unaware of the loopback... but that still doesn't explain the
> normal GSM or PSTN calls and no calls for VoIP platform. As I already sad,
> on the SBC I see that call flow is right but after picking-up router
> immediately sends BYE. First I though it was codec mismatch but it's not. I
> tried with all of them.
>
> PS: I don't know what Applying typeplan for sw-type 0x16 is 0x0 0x0 is.
> PPS: Can you tell me what PI is?
>
> Ratko
>
>
> On Fri, Jun 5, 2009 at 6:13 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>
>> Here is where things start to go wrong:
>> *Jun  4 11:13:08.203: ISDN Se0/3/0:15 Q931: RX <- ALERTING pd = 8  callref
>> = 0x808D
>> *Jun  4 11:13:08.207: ISDN Se0/3/0:15 Q931: TX -> STATUS pd = 8  callref =
>> 0x008D
>>        Cause i = 0x80E018 - Mandatory information element missing
>>        Call State i = 0x01
>>
>> The pstn sends you an Alerting message to signal the far-end is ringing.
>>  Either your IPPBX or the router doesn't like the fact that this Alerting
>> doesn't have a PI and that's what the "Mandatory information element
>> missing" cause in the Status message means.  The pstn then sends you a
>> Status message indicating that the Status you sent isn't compatible with the
>> callstate it is in (this is most common with PRI protocol-type mismatches).
>>  You then send a Release to drop the call because obviously it's not going
>> anywhere.
>>
>> Are you aware that this call is looping back out to the pstn in the first
>> place?  You receive the call to 3141222 on 0/3/0:15 channel 1 and then send
>> it right back out on channel 2.
>>
>> *Jun  4 11:13:08.027: ISDN Se0/3/0:15 Q931: RX <- SETUP pd = 8  callref =
>> 0x000F
>>        Bearer Capability i = 0x8090A3
>>                Standard = CCITT
>>                Transfer Capability = Speech
>>                Transfer Mode = Circuit
>>                Transfer Rate = 64 kbit/s
>>        Called Party Number i = 0x80, '3141222'
>>                Plan:Unknown, Type:Unknown
>>        High Layer Compat i = 0x9181
>> *Jun  4 11:13:08.047: ISDN Se0/3/0:15 Q931: Applying typeplan for sw-type
>> 0x16 is 0x0 0x0, Called num 3141222
>> *Jun  4 11:13:08.047: ISDN Se0/3/0:15 Q931: TX -> CALL_PROC pd = 8
>>  callref = 0x800F
>>        Channel ID i = 0xA98381
>>                Exclusive, Channel 1
>> *Jun  4 11:13:08.047: ISDN Se0/3/0:15 Q931: TX -> SETUP pd = 8  callref =
>> 0x008D
>>        Bearer Capability i = 0x8090A3
>>                Standard = CCITT
>>                Transfer Capability = Speech
>>                Transfer Mode = Circuit
>>                Transfer Rate = 64 kbit/s
>>        Channel ID i = 0xA98382
>>                Exclusive, Channel 2
>>        Called Party Number i = 0x80, '3141222'
>>                Plan:Unknown, Type:Unknown
>>        High Layer Compat i = 0x9181
>>
>> There's also this line "*Jun  4 11:13:08.047: ISDN Se0/3/0:15 Q931:
>> Applying typeplan for sw-type 0x16 is 0x0 0x0, Called num 3141222".  I'm not
>> sure what's going on with that or what sw-type 0x16 is.
>>
>> -Ryan
>>
>>
>> On Jun 5, 2009, at 11:44 AM, Ratko Dodevski wrote:
>>
>> Hi Jason, I very much appreciate your help... I'm confused why would the
>> ISDN messages be OK for numbers that are on PSTN or GSM but not valid for
>> phones registered on AIRSPAN. Phones on AIRSPAN are working OK and are part
>> of the national network. Customer is the biggest telephone provider in
>> Macedonia and both platforms are working. I'will send you Q931 debug
>> messages and router config so please if you have time, maybe you can take a
>> glance.
>>
>> Thanks again
>> Ratko
>> __________________________________________
>>
>>
>>
>>
>> On Fri, Jun 5, 2009 at 5:07 PM, Jason Burns <burns.jason at gmail.com>
>> wrote:
>> Cause i = 0x80E018 - Mandatory information element missing
>> Cause i = 0x80E27D - Message not compatible with call state or not
>> implemented
>> Cause i = 0x82E5 - Message not compatible with call state
>>
>> Those messages indicate to me that you're sending q931 messages that the
>> far end switch doesn't like, or that youre getting messages that you don't
>> like. A sure fire indication at the far end isdn switch type is not
>> configured the same as your local isdn switch type.
>>
>> If you're set to primary-qsig, are you positive that your provider is also
>> set to primary-qsig?
>>
>> This may not be causing the problem you reported below, but I can only fix
>> the problems I see error messages for, and those errors tell me your switch
>> type is mismatched.
>>
>> For the problem with the call disconnect it would be helpful to get
>> relevant debugs (SIP, Q931) from each device involved.
>>
>>
>> On Fri, Jun 5, 2009 at 5:47 AM, Ratko Dodevski <rade239 at gmail.com> wrote:
>> Thanks for replying,
>> PRI switch-type is set as primary-qsig. I should mention that when i make
>> phone calls to PSTN or GSM network trough the IPPBX it works just fine, but
>> i can't make calls with phones that are registerd with the IPPBX (which i
>> think is some Israelian AIRSPAN).
>>
>>
>> Ratko
>>
>>
>> On Fri, Jun 5, 2009 at 4:58 AM, Jason Burns <burns.jason at gmail.com>
>> wrote:
>> It sounds like your PRI Switch Type is set incorrectly based on the type
>> of q931 errors you're getting. Is it NI2, 5ESS, DMS100?
>>
>> On Thu, Jun 4, 2009 at 6:30 PM, Ratko Dodevski <rade239 at gmail.com> wrote:
>> Hi, i have question (obviously :) )
>> I have big troubles connecting a TDM PBX to a IPPBX through SBC via SIP.
>> When I do debug isdn q931 I keep getting this massages:
>> Cause i = 0x80E018 - Mandatory information element missing
>> Cause i = 0x80E27D - Message not compatible with call state or not
>> implemented
>> Cause i = 0x82E5 - Message not compatible with call state
>>
>> Called number is ringing but when i pick-up it gives me busy dial and if i
>> hung-up it rings again. On the SBC I can see that after picking router sends
>> BYE signal with "Bearer capability not implemented" and instantly sending 2
>> more invites for call.
>> I tried with setting bearer-cap Speech and i use the command isdn
>> incoming-voice voice.
>>
>> Tried many combinations... Any ideas ????
>>
>> Thanks
>> --
>> Ratko
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>>
>>
>>
>> --
>> Ratko
>>
>>
>>
>>
>> --
>> Ratko
>> <config.log><to_mobile.log><to_voip.log>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
>
> --
> Ratko
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090605/bd55c1df/attachment.html>