[cisco-voip] PBX-to-IPPBX calls
Ratko Dodevski
rade239 at gmail.com
Fri Jun 5 12:58:03 EDT 2009
I would be able to try this debug in Monday cos it's weekend. I send you an
incoming call from VoIP platform and it shows: ISDN Se0/3/0:15 **ERROR**:
call_cleared: VOICE ERROR: Bearer capability not available(0x3A): bchan -1,
call id 0x80B2 ... As you can see from the config I have set voice-port
0/3/0:15 bearer-cap Speech. This is very confusing for me.
On Fri, Jun 5, 2009 at 6:51 PM, Mike Lydick <mike.lydick at gmail.com> wrote:
> 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
>>
>>
>
--
Ratko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090605/fc11adf8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: call in.log
Type: application/octet-stream
Size: 5323 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090605/fc11adf8/attachment.obj>
More information about the cisco-voip
mailing list