[cisco-voip] Recovery on timer expiry QSIG
Ahmed Elnagar
ahmed_elnagar at hotmail.com
Thu Dec 20 15:31:16 EST 2012
Some of the calls works successfully Ryan "randomly" and I see in the
gateway debug the connect ACK received normally.
Regards,
Ahmed Elnagar | Unified Communication Team Leader | CCIE #24697, Voice
Description: Description: Description: MS Green
From: Ryan Ratliff [mailto:rratliff at cisco.com]
Sent: Thursday, December 20, 2012 10:26 PM
To: Ahmed Elnagar
Cc: 'Carlo Calabrese'; 'VOIP Group '
Subject: Re: [cisco-voip]RE: Recovery on timer expiry QSIG
Whether the connect_ack is required is going to be a byproduct of the PRI
protocol selection. Make sure this matches between the CUCM config and the
PBX and you should be good to go.
-Ryan
On Dec 20, 2012, at 2:59 PM, Ahmed Elnagar <ahmed_elnagar at hotmail.com>
wrote:
I found the issue "but not solved yet" the timer involved is the T313 which
by default is 4 secs and waits to have a connect ACK from the PBX side in
order not to disconnect the call "although the call works very normally for
the first 4 secs".the PBX is not sending the connect ACK before the 4 secs
and that is why the timer expires and its default behavior is to disconnect
the call.
I have PBX people working on this from their side, but my question is can I
disable this timer or at least disable its expiry action "send call
disconnect" until they solve this problem from PBX side?
Regards,
Ahmed Elnagar | Unified Communication Team Leader | CCIE #24697, Voice
<image001.jpg>
From: <mailto:cisco-voip-bounces at puck.nether.net>
cisco-voip-bounces at puck.nether.net [mailto:cisco-
<mailto:voip-bounces at puck.nether.net> voip-bounces at puck.nether.net] On
Behalf Of Ryan Ratliff
Sent: Thursday, December 20, 2012 4:44 PM
To: Carlo Calabrese
Cc: 'VOIP Group '
Subject: Re: [cisco-voip] [Bulk] RE: Recovery on timer expiry QSIG
T310 is used between call proceeding and alerting/progress/connect. Since
you are the one sending the call proceeding it's the other side that would
trip that timer. In this case you are the one disconnecting the call so you
are expecting some message from the other side that you aren't getting.
Since you are using MGCP check ccm traces for the call disconnect to see
what exact timer is getting tripped. That will tell you what to adjust.
-Ryan
On Dec 20, 2012, at 8:37 AM, Carlo Calabrese <
<mailto:carlo_calabrese2006 at yahoo.com> carlo_calabrese2006 at yahoo.com> wrote:
I think the default is 10000. I did a cut and paste from my router. I use a
2811.
From: Ahmed Elnagar [mailto:ahmed_elnagar@ <http://hotmail.com/>
hotmail.com]
Sent: Wednesday, December 19, 2012 11:30 PM
To: 'Carlo Calabrese'; 'VOIP Group '
Subject: [Bulk] RE: [cisco-voip] Recovery on timer expiry QSIG
Thanks a lot, but I think 120000 is the default for this timer, how do you
have it showing in the configuration?
Regards,
Ahmed Elnagar | Unified Communication Team Leader | CCIE #24697, Voice
<image001.jpg>
From: <mailto:cisco-voip-bounces at puck.nether.net>
cisco-voip-bounces at puck.nether.net [
<mailto:cisco-voip-bounces at puck.nether.net>
mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Carlo Calabrese
Sent: Thursday, December 20, 2012 8:18 AM
To: 'VOIP Group '
Subject: Re: [cisco-voip] Recovery on timer expiry QSIG
Here is what I have been using for my QSIG Connection. You will see it has
the T310 timer in it.
int ser 0/0/0:23
no ip address
encapsulation hdlc
isdn switch-type primary-qsig
isdn timer T310 120000
isdn protocol-emulate network
isdn incoming-voice voice
isdn bind-l3 ccm-manager
isdn outgoing ie facility
isdn outgoing ie notify-indicator
isdn outgoing display-ie
no cdp enable
!
I have had it running for about 5 years with no problems.
Carlo
From: <mailto:cisco-voip-bounces at puck.nether.net>
cisco-voip-bounces at puck.nether.net [
<mailto:cisco-voip-bounces at puck.nether.net>
mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ahmed Elnagar
Sent: Wednesday, December 19, 2012 2:16 PM
To: 'VOIP Group '
Subject: [cisco-voip] Recovery on timer expiry QSIG
Hi;
I have a PBX connected to CUCM using MGCP QSIG, some random calls "only from
PBX to IP Phones" is dropped after 4 or 5 seconds of the start of call to be
connected "both parties hear each other".
In debug isdn q931 I got the below
Dec 19 12:01:53.820: ISDN Se1/0:15 Q931: RX <- SETUP pd = 8 callref =
0x026D
Sending Complete
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA18382
Preferred, Channel 2
Facility i =
0x9FAA068001008201008B0100A1100201010201553008820301B850860101
Facility i =
0x9FAA068001008201008B0100A117020102020100800F49545353204D656574696E67205220
Progress Ind i = 0x8183 - Origination address is non-ISDN
Calling Party Number i = 0x0181, '55555'
Plan:ISDN, Type:Unknown
Called Party Number i = 0xC9, '66666'
Plan:Private, Type:Subscriber(local)
User-User i = 0x00FE, 'U', 0x0100, 'Y', 0x0100B00C07, 'I', 0x81,
'55555', 0x0F11828C82, 'Name01 ', 0x7F030F81000D05, 'I', 0x81, '30',
0xF2900E10818588, 'Name02'
Shift to Codeset 4
Codeset 4 IE 0x31 i = 0x80
Dec 19 12:01:53.828: ISDN Se1/0:15 Q931: TX -> CALL_PROC pd = 8 callref =
0x826D
Channel ID i = 0xA98382
Exclusive, Channel 2
Dec 19 12:01:53.828: ISDN Se1/0:15 Q931: TX -> ALERTING pd = 8 callref =
0x826D
Facility i =
0x9FAA06800100820100A117020101020101800F2A596F6E61732042656C6163686577
Progress Ind i = 0x8088 - In-band info or appropriate now available
Dec 19 12:01:53.828: ISDN Se1/0:15 Q931: TX -> FACILITY pd = 8 callref =
0x826D
Facility i =
0x9FAA068001008201008B0100A115020101020114300D0A01000A010280053333303332
Dec 19 12:01:55.444: ISDN Se1/0:15 Q931: TX -> CONNECT pd = 8 callref =
0x826D
Facility i =
0x9FAA068001008201008B0100A123020101020116301B0101FFA0168014596F6E6173204265
6C61636865772D3333303332
Facility i =
0x9FAA06800100820100A11C0201020201028014596F6E61732042656C61636865772D333330
3332
Connected Number i = 0x0081, '66666'
Dec 19 12:01:59.456: ISDN Se1/0:15 Q931: TX -> DISCONNECT pd = 8 callref =
0x826D
Cause i = 0x80E6 - Recovery on timer expiry
Do you think changing T310 timer will solve this or maybe it is another
issue?
Regards,
Ahmed Elnagar | Unified Communication Team Leader | CCIE #24697, Voice
<image001.jpg>
_______________________________________________
cisco-voip mailing list
<mailto:cisco-voip at puck.nether.net> cisco-voip at puck.nether.net
<https://puck.nether.net/mailman/listinfo/cisco-voip>
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20121220/edd524f1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2768 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20121220/edd524f1/attachment.jpg>
More information about the cisco-voip
mailing list