07-23-2004 09:56 AM - edited 03-13-2019 05:45 AM
Hi,
I am getting the folowing error when debugging on isdn Q931 on a cisco
7500 with a PA-VXC-2TE1 connected to a Ascom PBX:
**ERROR**: CCPRI_Go: call id 0x26 event 0x57 No ccb Source->HOST
Basically the problem is that call set-up appears to be fine, however
as soon as the Voice channel is cut into from the D channel set-up I
have 4 seconds of voice and the call disconnects. the following is a
debug:
Jul 22 18:43:27 bst: ISDN Se4/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x0005
Bearer Capability i = 0x8090A3
Standard = CCITT
Transer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA1838C
Preferred, Channel 12
Calling Party Number i = 0x80, '3020'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x81, '07989321115'
Plan:ISDN, Type:Unknown
High Layer Compat i = 0x9181
Jul 22 18:43:27 bst: ISDN Se4/0/0:15 Q931: TX -> CALL_PROC pd = 8
callref = 0x8005
Channel ID i = 0xA9838C
Exclusive, Channel 12
Jul 22 18:43:38 bst: ISDN Se4/0/0:15 Q931: TX -> ALERTING pd = 8 callref = 0x8005
Jul 22 18:43:38 bst: ISDN Se4/0/0:15 Q931: TX -> CONNECT pd = 8 callref = 0x8005
Jul 22 18:43:42 bst: ISDN Se4/0/0:15 Q931: TX -> DISCONNECT pd = 8
callref = 0x8005
Cause i = 0x80E6 - Recovery on timer expiry
Jul 22 18:43:42 bst: ISDN Se4/0/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x0005
Cause i = 0x809F - Normal, unspecified
Jul 22 18:43:42 bst: ISDN Se4/0/0:15 **ERROR**: CCPRI_Go: call id 0x26
event 0x57 No ccb Source->HOST
Jul 22 18:43:42 bst: ISDN Se4/0/0:15 Q931: TX -> RELEASE_COMP pd = 8
callref = 0x8005
Can anyone help me with this please?
Regards
Darren Frowen
Solved! Go to Solution.
08-08-2004 08:22 AM
That's a fairly common problem. Without a lot of q.931 debug outputs at both the 7200 and the 7500 I can't tell you exactly what to do, but your solution will more than likely be found here:
http://www.cisco.com/en/US/tech/tk652/tk701/technologies_tech_note09186a0080094c33.shtml
There's some progress_ind commands and other commands that you may have to apply at either the 7200 or 7500 or both. Go through that URL try a few things. If you don't have any success, capture the output of debug q.931 like you did in your first post, from both of your voice routers for the same call.
Also, please remember to use the rate/solve functions for posts that help you. Thanks!
08-14-2004 09:40 AM
It's your PBX's job to take the digits from the phone and convert them into out-of-band q.931 signaling. The router should never "hear" dialing on a PRI channel during the call setup phase, be it tone or pulse. It's all converted to data on the calling side and sent on the signaling channel. From the phone to PBX perspective, so long as the PBX understands tone and pulse, it can do that conversion.
This is just a guess, but perhaps your PBX wants to do overlap sending when you dial that way. This is uncommon in North America so I don't have much experience with it. Overlap sending is where the PBX sends a digit at a time, instead of sending them all at once. You have to enable overlap receiving on the router in order for that to work. You should just need to do it on the one connected to the PBX. Again, I'm not sure this is the fix, but it's my guess.
http://www.cisco.com/en/US/tech/tk652/tk653/technologies_tech_note09186a00800b48cb.shtml
07-23-2004 11:39 AM
I don't see a connect_ack coming from the PBX once the router sends the connect message. Can you check why we are not getting a connect_ack?
07-23-2004 11:43 AM
Your PBX failed to acknowledge the connection, so the 7500 correctly tore it down. I'm not sure what the CCPRI error is, but it comes after we started tearing down the call, so it's irrelevant. Here's what a proper call setup looks like:
Jul 23 15:36:36.565 EDT: ISDN Se2/1:23 Q931: RX <- SETUP pd = 8 callref = 0x038A
Bearer Capability i = 0x8090A2
Standard = CCITT
Transer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98382
Exclusive, Channel 2
Progress Ind i = 0x8283 - Origination address is non-ISDN
Calling Party Number i = 0x2183, '301963XXXX'
Plan:ISDN, Type:National
Called Party Number i = 0x80, '6400'
Plan:Unknown, Type:Unknown
Jul 23 15:36:36.809 EDT: ISDN Se2/1:23 Q931: TX -> CALL_PROC pd = 8 callref = 0x838A
Channel ID i = 0xA98382
Exclusive, Channel 2
Jul 23 15:36:36.825 EDT: ISDN Se2/1:23 Q931: TX -> ALERTING pd = 8 callref = 0x838A
Progress Ind i = 0x8088 - In-band info or appropriate now available
Jul 23 15:36:40.253 EDT: ISDN Se2/1:23 Q931: TX -> CONNECT pd = 8 callref = 0x838A
Progress Ind i = 0x8182 - Destination address is non-ISDN
Display i = '3620 Auto Atten'
Jul 23 15:36:40.321 EDT: ISDN Se2/1:23 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x038A
Check and make sure your switch types match up on both sides. Unsure what to advise you to do other than that, since it appears to be the PBX that's falling down on the job.
07-23-2004 11:25 PM
jasyoung Hi,
Thank you so much for your response. A fresh set of eyes is wonderful!
My problem is that I'm getting no help from our PBX manufacturer they simply dont want to know unless Im connecting to a BT ntu. Although they have confirmed that it is an ISDN DSS1 full etsi standard E1 I am connecting to, HDB3, CRC4 an I am taking clock from the line.
The PBX is our work PBX I have been given the task to migrate over to. Im wondering last year we dropped the 30 channels down to 12 channels due to cost, as you can see that the set-up has always a preffered channel of 12. On the terminating side a 7206 the preferred channel is channel 22. Could it be that the terminating is telling the originating to cut over to B channel 22 and it cant hence no Connect_ack and the channel is tore down ?????
Will configuring pri timeslots 1-12 overcome this you think???
Looking forward to your kind response!
Kindest Regards
Darren Frowen
07-24-2004 07:49 PM
I don't think it's a channel thing. If the channel were out of service, you shouldn't have been able to place a call over it, and if you tried, it should have been rejected, and you certainly shouldn't have been able to pass voice traffic over it for any length of time at all.
My guess is that you need to set "isdn protocol-emulate network" to emulate the Network side of the PRI. It's also worth making sure your switch type is "isdn switch-type primary-net5" (I'm guessing this switch-type based on your description of the environment).
I think the protocol-emulate network command could be the fix. One side has to be Network and one side has to be User; if we're in the default User mode, we expect the other side to play the Network role. I'm not sure if you could even get the PRI D-channel and B-channels to come into service if both sides are acting as the User side, however, it sounds like your PBX is in User mode. I base this on two things: one, it sounds like your PBX vendor doesn't know how to connect to anything but the PSTN. Second, sending CONNECT_ACK in response to CONNECT is optional and unnecessary from the User side, but mandatory from the Network side. This is exactly what we're not getting from the PBX. So, we probably need to shift the 7500 into the Network side mode if it's not there already, so that it can deal with the PBX being the User side.
You mention that you only have 12 channels on your PRI leading to the PSTN. I'm not sure where that PRI fits into this situation, since you say you're connecting to the PBX. Are you attempting to insert the 7500 inbetween the PSTN and the PBX, or are you "behind" the PBX and passing all of your calls through it? If you're behind the PBX, the details of its PSTN connectivity are irrelevant here.
If you're still having trouble, please post your config (without passwords) and the output of "show isdn status" and "show isdn service".
07-25-2004 06:15 AM
jasyoung Hi,
Thanks again for your time, much appreciated!!
I have the switch type set to "isdn switch-type primary-net5". The command sounds great, I have applied it to the Serial D channel and am looking forward to testing it. Unfortunately Im on my holidays break at the moment from www.sms-internet.net but Im itching to go back in to test it, which I might in the next couple of days! We have a 24Hr NOC so I have to notify customer's that we are taking the Phone system off line ;-)
Our setup is as follows:
Work users phones --> PBX --> PA-VXC-2TE1(7500) --> STM1Transport --> PA-VXC-2TE1(7200) --> TelcoSwitch Band-X --> (PSTN)
Ill update you on the outcome as soon as Ive tested.
Thanks again jasyoung!
Kindest Regards
Darren Frowen
08-08-2004 05:56 AM
jasyoung Hi,
Great news the command has worked perfectly! Thankyou so much for your time in this matter I really do appreciate it!
The command also had the effect that I now no longer need to go into the PBX and change to master clock as the the 7513 now provides the clock, which I could not find how to do before only line and internal!
Th only remaining problem I now have is that I am unable to hear any ringback with mobile destinations, do you know of any workarounds fro this this?
Kindest regards
Darren Frowen
08-08-2004 08:22 AM
That's a fairly common problem. Without a lot of q.931 debug outputs at both the 7200 and the 7500 I can't tell you exactly what to do, but your solution will more than likely be found here:
http://www.cisco.com/en/US/tech/tk652/tk701/technologies_tech_note09186a0080094c33.shtml
There's some progress_ind commands and other commands that you may have to apply at either the 7200 or 7500 or both. Go through that URL try a few things. If you don't have any success, capture the output of debug q.931 like you did in your first post, from both of your voice routers for the same call.
Also, please remember to use the rate/solve functions for posts that help you. Thanks!
08-08-2004 11:26 AM
jasyoung Hi,
My sincere apoligies for the unrated reply's which has now been corrected, ill let you know as soon as Ive had a chance to apply the various solutions in the document!
Thanks again!
Regards
Darren
08-14-2004 04:24 AM
jasyoung Hi,
Thanks again for the info, the command "progress_ind alert enable 8" appllied on the Terminating Gateway has enabled the ringback on Mobile's.
A further problem and final one I hope is that I can establish calls to destinations okay when I either pre-dial the destination whilst the phone is on hook or use the menu address book on the phone system. However if I take the phone off-hook and here the dial-tone generated by the local PBX and then dial 9 for an outside line for some reason the call fails. Basically using either DID or no DID the call fails. It appears for some reason that the router is not waiting for my dialled digit's it attempts to perform call set-up without any destination digits. Everything works fine when all digits are sent from the PBX imediately from pre-dialing or from the address book. But when manually attampting to dial it fails before I have chance to dial any digits. Please see below q931 output from the failed calls:
With no DID
===========
Aug 14 13:21:51 bst: ISDN Se4/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x002B
Bearer Capability i = 0x8090A3
Standard = CCITT
Transer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA1838C
Preferred, Channel 12
Calling Party Number i = 0x80, '3020'
Plan:Unknown, Type:Unknown
High Layer Compat i = 0x9181
Aug 14 13:21:51 bst: ISDN Se4/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x802B
Cause i = 0x8281 - Unallocated/unassigned number
With DID
========
Aug 14 13:23:25 bst: ISDN Se4/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x002C
Bearer Capability i = 0x8090A3
Standard = CCITT
Transer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA1838C
Preferred, Channel 12
Calling Party Number i = 0x80, '3020'
Plan:Unknown, Type:Unknown
High Layer Compat i = 0x9181
Aug 14 13:23:25 bst: ISDN Se4/0/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x802C
Channel ID i = 0xA9838C
Exclusive, Channel 12
Progress Ind i = 0x8188 - In-band info or appropriate now available
Aug 14 13:23:25 bst: ISDN Se4/0/0:15 Q931: TX -> CONNECT pd = 8 callref = 0x802C
Aug 14 13:23:31 bst: ISDN Se4/0/0:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x002C
Cause i = 0x8090 - Normal call clearing
Aug 14 13:23:31 bst: ISDN Se4/0/0:15 Q931: TX -> RELEASE pd = 8 callref = 0x802C
Aug 14 13:23:32 bst: ISDN Se4/0/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x002C
lh-gw1#
Looking forward to your kind response!
Regards
Darren Frowen
08-14-2004 04:37 AM
jasyoung Hi,
Ive figured it out. Basically our internal phone's when using the on-hook dialing or address book dialing uses DTMF signals. When off hook they use pulse dialing. Is there a way to configure the router to look for either or?
Regards
Darren
08-14-2004 09:40 AM
It's your PBX's job to take the digits from the phone and convert them into out-of-band q.931 signaling. The router should never "hear" dialing on a PRI channel during the call setup phase, be it tone or pulse. It's all converted to data on the calling side and sent on the signaling channel. From the phone to PBX perspective, so long as the PBX understands tone and pulse, it can do that conversion.
This is just a guess, but perhaps your PBX wants to do overlap sending when you dial that way. This is uncommon in North America so I don't have much experience with it. Overlap sending is where the PBX sends a digit at a time, instead of sending them all at once. You have to enable overlap receiving on the router in order for that to work. You should just need to do it on the one connected to the PBX. Again, I'm not sure this is the fix, but it's my guess.
http://www.cisco.com/en/US/tech/tk652/tk653/technologies_tech_note09186a00800b48cb.shtml
08-14-2004 11:17 AM
Jasyoung Hi,
You are an absolute genious, it works a gem:
Aug 14 20:14:38 bst: ISDN Se4/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x0024
Bearer Capability i = 0x8090A3
Standard = CCITT
Transer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA1838C
Preferred, Channel 12
Calling Party Number i = 0x80, '3034'
Plan:Unknown, Type:Unknown
High Layer Compat i = 0x9181
Aug 14 20:14:38 bst: ISDN Se4/0/0:15 Q931: TX -> SETUP_ACK pd = 8 callref = 0x8024
Channel ID i = 0xA9838C
Exclusive, Channel 12
Aug 14 20:14:40 bst: ISDN Se4/0/0:15 Q931: RX <- INFORMATION pd = 8 callref = 0x0024
Called Party Number i = 0x81, '0'
Plan:ISDN, Type:Unknown
Aug 14 20:14:41 bst: ISDN Se4/0/0:15 Q931: RX <- INFORMATION pd = 8 callref = 0x0024
Called Party Number i = 0x81, '2'
Plan:ISDN, Type:Unknown
Aug 14 20:14:41 bst: ISDN Se4/0/0:15 Q931: RX <- INFORMATION pd = 8 callref = 0x0024
Called Party Number i = 0x81, '4'
Plan:ISDN, Type:Unknown
Aug 14 20:14:42 bst: ISDN Se4/0/0:15 Q931: RX <- INFORMATION pd = 8 callref = 0x0024
Called Party Number i = 0x81, '7'
Plan:ISDN, Type:Unknown
Aug 14 20:14:42 bst: ISDN Se4/0/0:15 Q931: RX <- INFORMATION pd = 8 callref = 0x0024
Called Party Number i = 0x81, '6'
Plan:ISDN, Type:Unknown
Aug 14 20:14:42 bst: ISDN Se4/0/0:15 Q931: RX <- INFORMATION pd = 8 callref = 0x0024
Called Party Number i = 0x81, '6'
Plan:ISDN, Type:Unknown
Aug 14 20:14:43 bst: ISDN Se4/0/0:15 Q931: RX <- INFORMATION pd = 8 callref = 0x0024
Called Party Number i = 0x81, '4'
Plan:ISDN, Type:Unknown
Aug 14 20:14:43 bst: ISDN Se4/0/0:15 Q931: RX <- INFORMATION pd = 8 callref = 0x0024
Called Party Number i = 0x81, '1'
Plan:ISDN, Type:Unknown
Aug 14 20:14:43 bst: ISDN Se4/0/0:15 Q931: RX <- INFORMATION pd = 8 callref = 0x0024
Called Party Number i = 0x81, '1'
Plan:ISDN, Type:Unknown
Aug 14 20:14:44 bst: ISDN Se4/0/0:15 Q931: RX <- INFORMATION pd = 8 callref = 0x0024
Called Party Number i = 0x81, '5'
Plan:ISDN, Type:Unknown
Aug 14 20:14:44 bst: ISDN Se4/0/0:15 Q931: RX <- INFORMATION pd = 8 callref = 0x0024
Called Party Number i = 0x81, '7'
Plan:ISDN, Type:Unknown
Aug 14 20:14:46 bst: ISDN Se4/0/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x8024
Aug 14 20:14:48 bst: ISDN Se4/0/0:15 Q931: TX -> ALERTING pd = 8 callref = 0x8024
Progress Ind i = 0x8A82 - Destination address is non-ISDN
Aug 14 20:14:50 bst: ISDN Se4/0/0:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x0024
Cause i = 0x8090 - Normal call clearing
Aug 14 20:14:50 bst: ISDN Se4/0/0:15 Q931: TX -> RELEASE pd = 8 callref = 0x8024
Aug 14 20:14:50 bst: ISDN Se4/0/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x0024
Aug 14 20:15:11 bst: %CONTROLLER-5-UPDOWN: Controller E1 4/0/0, changed state to down
Aug 14 20:15:11 bst: ISDN Se4/0/0:15 Q931: L3_ShutDown: Shutting down ISDN Layer 3
lh-gw1#
So Grateful!
Kindest Regards
Darren
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide