[cisco-voip] PBX-to-IPPBX calls

Fri Jun 5 12:45:02 EDT 2009

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090605/58296ae5/attachment.html>