[cisco-voip] PBX-to-IPPBX calls
Ryan Ratliff
rratliff at cisco.com
Fri Jun 5 13:52:07 EDT 2009
You need to look at the bearer-cap sent in the outbound Setup. For
the call earlier it is here:
*Jun 4 11:12:21.827: ISDN Se0/3/0:15 Q931: RX <- SETUP pd = 8
callref = 0x000E
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
-Ryan
On Jun 5, 2009, at 12:58 PM, Ratko Dodevski wrote:
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
<call in.log>
More information about the cisco-voip
mailing list