Solved: Re: Call disconnects after 4 Seconds every time HELP!!

darren.frowen · ‎07-23-2004

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

jasyoung · ‎08-08-2004

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!

View solution in original post

jasyoung · ‎08-14-2004

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

View solution in original post

jtufail · ‎07-23-2004

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?

jasyoung · ‎07-23-2004

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.

darren.frowen · ‎07-23-2004

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

jasyoung · ‎07-24-2004

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".

darren.frowen · ‎07-25-2004

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

darren.frowen · ‎08-08-2004

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

jasyoung · ‎08-08-2004

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!

darren.frowen · ‎08-08-2004

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

darren.frowen · ‎08-14-2004

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

darren.frowen · ‎08-14-2004

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

jasyoung · ‎08-14-2004

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

darren.frowen · ‎08-14-2004

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