I have seen similar when you depend on the default dial-peers (undefined incoming .)<br><br>debug voip ccapi inout will allow you to trace the call through peer matching.<br><br><br clear="all">Best Regards,<br><br>Mike Lydick<br>
<br>
<br><br><div class="gmail_quote">On Fri, Jun 5, 2009 at 12:45 PM, Ratko Dodevski <span dir="ltr"><<a href="mailto:rade239@gmail.com">rade239@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
<br>PS: I don't know what Applying typeplan for sw-type 0x16 is 0x0 0x0 is.<br>PPS: Can you tell me what PI is?<br><br>Ratko<div><div></div><div class="h5"><br><br><div class="gmail_quote">On Fri, Jun 5, 2009 at 6:13 PM, Ryan Ratliff <span dir="ltr"><<a href="mailto:rratliff@cisco.com" target="_blank">rratliff@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Here is where things start to go wrong:<br>
*Jun 4 11:13:08.203: ISDN Se0/3/0:15 Q931: RX <- ALERTING pd = 8 callref = 0x808D<br>
*Jun 4 11:13:08.207: ISDN Se0/3/0:15 Q931: TX -> STATUS pd = 8 callref = 0x008D<div><br>
Cause i = 0x80E018 - Mandatory information element missing<br></div>
Call State i = 0x01<br>
<br>
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.<br>
<br>
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.<br>
<br>
*Jun 4 11:13:08.027: ISDN Se0/3/0:15 Q931: RX <- SETUP pd = 8 callref = 0x000F<br>
Bearer Capability i = 0x8090A3<br>
Standard = CCITT<br>
Transfer Capability = Speech<br>
Transfer Mode = Circuit<br>
Transfer Rate = 64 kbit/s<br>
Called Party Number i = 0x80, '3141222'<br>
Plan:Unknown, Type:Unknown<br>
High Layer Compat i = 0x9181<br>
*Jun 4 11:13:08.047: ISDN Se0/3/0:15 Q931: Applying typeplan for sw-type 0x16 is 0x0 0x0, Called num 3141222<br>
*Jun 4 11:13:08.047: ISDN Se0/3/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x800F<br>
Channel ID i = 0xA98381<br>
Exclusive, Channel 1<br>
*Jun 4 11:13:08.047: ISDN Se0/3/0:15 Q931: TX -> SETUP pd = 8 callref = 0x008D<br>
Bearer Capability i = 0x8090A3<br>
Standard = CCITT<br>
Transfer Capability = Speech<br>
Transfer Mode = Circuit<br>
Transfer Rate = 64 kbit/s<br>
Channel ID i = 0xA98382<br>
Exclusive, Channel 2<br>
Called Party Number i = 0x80, '3141222'<br>
Plan:Unknown, Type:Unknown<br>
High Layer Compat i = 0x9181<br>
<br>
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.<br>
<br>
-Ryan<div><div></div><div><br>
<br>
On Jun 5, 2009, at 11:44 AM, Ratko Dodevski wrote:<br>
<br>
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.<br>
<br>
Thanks again<br>
Ratko<br>
__________________________________________<br>
<br>
<br>
<br>
<br>
On Fri, Jun 5, 2009 at 5:07 PM, Jason Burns <<a href="mailto:burns.jason@gmail.com" target="_blank">burns.jason@gmail.com</a>> wrote:<br>
Cause i = 0x80E018 - Mandatory information element missing<br>
Cause i = 0x80E27D - Message not compatible with call state or not implemented<br>
Cause i = 0x82E5 - Message not compatible with call state<br>
<br>
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.<br>
<br>
If you're set to primary-qsig, are you positive that your provider is also set to primary-qsig?<br>
<br>
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.<br>
<br>
For the problem with the call disconnect it would be helpful to get relevant debugs (SIP, Q931) from each device involved.<br>
<br>
<br>
On Fri, Jun 5, 2009 at 5:47 AM, Ratko Dodevski <<a href="mailto:rade239@gmail.com" target="_blank">rade239@gmail.com</a>> wrote:<br>
Thanks for replying,<br>
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).<br>
<br>
<br>
Ratko<br>
<br>
<br>
On Fri, Jun 5, 2009 at 4:58 AM, Jason Burns <<a href="mailto:burns.jason@gmail.com" target="_blank">burns.jason@gmail.com</a>> wrote:<br>
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?<br>
<br>
On Thu, Jun 4, 2009 at 6:30 PM, Ratko Dodevski <<a href="mailto:rade239@gmail.com" target="_blank">rade239@gmail.com</a>> wrote:<br>
Hi, i have question (obviously :) )<br>
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:<br>
Cause i = 0x80E018 - Mandatory information element missing<br>
Cause i = 0x80E27D - Message not compatible with call state or not implemented<br>
Cause i = 0x82E5 - Message not compatible with call state<br>
<br>
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.<br>
I tried with setting bearer-cap Speech and i use the command isdn incoming-voice voice.<br>
<br>
Tried many combinations... Any ideas ????<br>
<br>
Thanks<br>
-- <br>
Ratko<br>
<br>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br>
<br>
<br>
<br>
<br>
-- <br>
Ratko<br>
<br>
<br>
<br>
<br>
-- <br>
Ratko<br></div></div>
<config.log><to_mobile.log><to_voip.log><div><div></div><div><br>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br></div></div>-- <br><font color="#888888">Ratko<br>
</font><br>_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br></blockquote></div><br>