Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Meeting Place Express 2.1.1.2 - FastBusy after disconnect

Dears,

I've got mpe 2.1.1.2 with ccm 7 integrated through h.323 as long as voice gateway. Voice Gateway accepts incoming calls through E1. When I disconnect from the meeting I joined before from PSTN to, other participants hears fast busy signal for a long time. What could be the trouble, please advice.

Cheers!)

4 REPLIES

Re: Meeting Place Express 2.1.1.2 - FastBusy after disconnect

Hi Ruslan,

The issue might be that PSTN is sending a disconnect message with PI=8. When we get DISCONNECT with PI=8, the caller may listen to the inband information: a busy tone or some other pre-recorded info.

This can be confirmed from "debug isdn q931". You will see something like this in the debugs:

Cause i = 0x8090 - Normal call clearing
Progress Ind i = 0x8288 - In-band info or appropriate now available

If this is the case, please configure "voice call disc-pi-off" in global configuration mode to resolve this problem.

HTH,

Natasa

New Member

Re: Meeting Place Express 2.1.1.2 - FastBusy after disconnect

Thank you for your reply, Natasa

As I figured out, this command was first introdused on IOS 12.3. I'm running 12.2. Is there simmilar command to disable pi withour reimaging router?

Cheers)

Update - I typed progress_ind disconnect disable command under outgoing dialpeer. As I understand it doesthe same thing you advised. It did not help. Here is debug output with pi disabled.

21w6d: ISDN Se4/0:15 Q931: TX -> SETUP pd = 8  callref = 0x299D
        Bearer Capability i = 0x8090A3
                Standard = CCITT
                Transer Capability = Speech 
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA9839E
                Exclusive, Channel 30
        Calling Party Number i = 0x0081, '******'
                Plan:Unknown, Type:Unknown
        Called Party Number i = 0x80, '***********'
                Plan:Unknown, Type:Unknown
21w6d: ISDN Se4/0:15 Q931: RX <- SETUP_ACK pd = 8  callref = 0xA99D
        Channel ID i = 0xA9839E
                Exclusive, Channel 30
21w6d: ISDN Se4/0:15 Q931: RX <- CALL_PROC pd = 8  callref = 0xA99D
21w6d: ISDN Se4/0:15 Q931: RX <- ALERTING pd = 8  callref = 0xA99D
        Display i = '*86*X#'
21w6d: ISDN Se4/0:15 Q931: RX <- CONNECT pd = 8  callref = 0xA99D
21w6d: ISDN Se4/0:15 Q931: TX -> CONNECT_ACK pd = 8  callref = 0x299Du all
21w6d: ISDN Se4/0:15 Q931: RX <- DISCONNECT pd = 8  callref = 0xA99D
        Cause i = 0x8290 - Normal call clearing
        Display i = '*AA*CLEARED#'
21w6d: ISDN Se4/0:15 Q931: TX -> RELEASE pd = 8  callref = 0x299D
21w6d: ISDN Se4/0:15 Q931: RX <- RELEASE_COMP pd = 8  callref = 0xA99D
        Cause i = 0x8290 - Normal call clearing
All possible debugging has been turned off

Re: Meeting Place Express 2.1.1.2 - FastBusy after disconnect

Hi Ruslan,

progress_ind disconnect disable is configured under the dial-peer and won't take the effect for incoming disconnect message. Also, the issue here is not with PI 8 as I thought initially.

Looking into the debugs, in Alerting PSTN is trying to send to the gateway Display IE "Display i = '*86*X#'" and the same in the Disconnect "Display i = '*AA*CLEARED#'". It looks like it's something that router can't decode and that's why we have this rubbish characters displayed in q931 debugs.

This looks like the issue on PSTN side, I would suggest to contact your PSTN provider so they can troubleshoot the issue on their side.

Thanks,

Natasa


New Member

Re: Meeting Place Express 2.1.1.2 - FastBusy after disconnect

I gave another customer with identical configuration on the voice gateway such as this. And he is using the same PSTN provider as the customer with the mentioned trouble. The main disfference between q931 debugs is that Display i of the client router without this issue is  Display i = '*AA*CLEARED#'. And the second - it uses 3.1Khz Audio as Transfer Capability. The router with the issue uses "Speech" one. Could it be the cause?

Thank you in advance, Natasa.

407
Views
0
Helpful
4
Replies