[cisco-voip] MGCP Audio Cut Through Delay
Wes Sisk
wsisk at cisco.com
Tue Jul 22 13:08:36 EDT 2008
not usually. they are usually sent as individual TCP segments
immediately after generated. without this parameter the only way they
are bundled is if a retransmit happens.
Jonathan Charles wrote:
> I set it to 25 ms and it seems to have fixed it... How did this fix it
> tho.... are the SCCP messages packaged together and send it bulk?
>
>
>
> Jonathan
>
> On Tue, Jul 22, 2008 at 10:19 AM, Wes Sisk <wsisk at cisco.com> wrote:
>
>> The defect is only an attempt to help with a network limitation. Did you
>> enable the feature via advanced service parameter after upgrade?
>>
>> "Bundle Outbound SCCP Messages Timer" - This parameter specifies the number
>> of milliseconds that Cisco CallManager holds outbound Skinny Client Control
>> Protocol (SCCP) messages in order to bundle multiple SCCP messages into a
>> single TCP packet. Media-related outbound SCCP messages are exempt from
>> bundling and are always sent immediately. Specifying a value of zero
>> disables outbound SCCP bundling.
>>
>> Set this to a higher value.
>>
>> Otherwise, need to clarify network conditions where this happens. Does it
>> definitely happen on shared lines? Are all shared lines at the same remote
>> site? This came down to serialization delay on the interfaces. Bundling
>> messages reduced overhead bits in an effort to reduce total bits and
>> decrease delay.
>>
>> /Wes
>>
>> Jonathan Charles wrote:
>>
>>> Ok, the problem is back... This is growing unpleasant... the bugID was
>>> so on the money...
>>>
>>>
>>>
>>> Jonathan
>>>
>>> On Fri, Jul 18, 2008 at 12:32 PM, c3voip <c3voip at nc.rr.com> wrote:
>>>
>>>
>>>> I wish I had that "problem" :)
>>>>
>>>> Only two T-1's to each office for voice and data, but luckily not that
>>>> many
>>>> calls between offices. Have to rely strictly on QoS policy routing for
>>>> the
>>>> time being :(
>>>>
>>>> -C
>>>>
>>>> -----Original Message-----
>>>> From: Jason Aarons (US) [mailto:jason.aarons at us.didata.com]
>>>> Sent: Friday, July 18, 2008 1:07 PM
>>>> To: c3voip; Jonathan Charles; Wes Sisk
>>>> Cc: cisco-voip
>>>> Subject: RE: [cisco-voip] MGCP Audio Cut Through Delay
>>>>
>>>> I never understand why a remote site with 3 7960 Phones with
>>>> MetroEthernet type connectivity (10mbps or higher) would implement
>>>> Locations at 384k or anything other than unlimited. Yes a site with
>>>> 512K Frame Relay I could see locations, but I see customers with 150Mb
>>>> pipes and something like 786k in Locations with 10 phones. Doesn't make
>>>> sense but I see it often.
>>>>
>>>> -----Original Message-----
>>>> From: cisco-voip-bounces at puck.nether.net
>>>> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of c3voip
>>>> Sent: Friday, July 18, 2008 12:48 PM
>>>> To: 'Jonathan Charles'; 'Wes Sisk'
>>>> Cc: 'cisco-voip'
>>>> Subject: Re: [cisco-voip] MGCP Audio Cut Through Delay
>>>>
>>>> I had a problem going from 4.1(3)sr5b to 4.1(3)sr7 with Call Control.
>>>> So
>>>> just a warning make sure your Locations and Regions are working properly
>>>> after upgrading, if you use them.
>>>>
>>>> I'm still waiting for a patch, luckily we have enough bandwidth between
>>>> Locations to allow the unlimited workaround.
>>>>
>>>> -C
>>>>
>>>> -----Original Message-----
>>>> From: cisco-voip-bounces at puck.nether.net
>>>> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Jonathan
>>>> Charles
>>>> Sent: Friday, July 18, 2008 12:35 PM
>>>> To: Wes Sisk
>>>> Cc: cisco-voip
>>>> Subject: Re: [cisco-voip] MGCP Audio Cut Through Delay
>>>>
>>>> So, this turned out to be CSCsc06953...
>>>>
>>>> Patched em to 4.1(3)sr7 and it fixed it.
>>>>
>>>>
>>>>
>>>> Jonathan
>>>>
>>>> On Thu, Jul 10, 2008 at 9:48 AM, Wes Sisk <wsisk at cisco.com> wrote:
>>>>
>>>>
>>>>> need to check cm traces to see what happens between answer and audio
>>>>>
>>>>>
>>>> cut
>>>>
>>>>
>>>>> through.
>>>>> required CM SDI and SDL traces.
>>>>>
>>>>> /wes
>>>>>
>>>>> Jonathan Charles wrote:
>>>>>
>>>>>
>>>>>> So, is this a phone firmware issue? The PSTN caller (and the IP
>>>>>>
>>>>>>
>>>> Phone)
>>>>
>>>>
>>>>>> do NOT hear anything for about 4-5 seconds once the IP phone call is
>>>>>> answered.
>>>>>>
>>>>>> This is also inbound only.
>>>>>>
>>>>>> CCM is 4.1(3)sr5b and Gateway is a 2811 running 12.4(3g)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Jonathan
>>>>>>
>>>>>> On Wed, Jul 9, 2008 at 4:24 PM, Wes Sisk <wsisk at cisco.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> at the end the router reports call statistics:
>>>>>>> P: PS=978, OS=156480, PR=980, OR=156800, PL=0, JI=0, LA=0
>>>>>>> PS = packets sent
>>>>>>> PR = packets received
>>>>>>> 978 is close enough to 980. this means all RTP packets made it
>>>>>>>
>>>>>>>
>>>> through
>>>>
>>>>
>>>>>>> the
>>>>>>> network between the endpoints.
>>>>>>> 980 packets * 20msec/packet = 19,600msec of audio.
>>>>>>>
>>>>>>> Time from sendrecv to recvonly = 03:51:40.645 - 03:52:00.227 = 19.6
>>>>>>> seconds
>>>>>>> (approximately).
>>>>>>> 19.6 seconds connected and 19.6 seconds of RTP traffic. Thus audio
>>>>>>>
>>>>>>>
>>>> was
>>>>
>>>>
>>>>>>> successfully established and packets were sent and received
>>>>>>>
>>>>>>>
>>>> successfully
>>>>
>>>>
>>>>>>> for
>>>>>>> the duration of the connection.
>>>>>>>
>>>>>>> Router responded correctly and offered its ip address to receive RTP
>>>>>>> stream. the mgcp call agent (cm?) sent instruction to establish
>>>>>>> bidirectional audio full 15 seconds later. Need to see what took
>>>>>>>
>>>>>>>
>>>> the
>>>>
>>>>
>>>>>>> call
>>>>>>> agent(cm?) so long to obtain the media ip/port from the other
>>>>>>>
>>>>>>>
>>>> endpoint.
>>>>
>>>>
>>>>>>> debugs with comments:
>>>>>>> //create connection to setup new call
>>>>>>> Jul 10 03:51:25.534 CST: MGCP Packet received from
>>>>>>>
>>>>>>>
>>>> 10.1.1.10:2427--->
>>>>
>>>>
>>>>>>> CRCX 89768
>>>>>>>
>>>>>>> //router provides ip & port for RTP stream:
>>>>>>> Jul 10 03:51:25.550 CST: MGCP Packet sent to 10.1.1.10:2427--->
>>>>>>> 200 89768 OK
>>>>>>> I: 6
>>>>>>>
>>>>>>> // router receives instruction to change audio mode to sendrecv.
>>>>>>>
>>>>>>>
>>>> this is
>>>>
>>>>
>>>>>>> usually 2 way audio
>>>>>>> Jul 10 03:51:40.645 CST: MGCP Packet received from
>>>>>>>
>>>>>>>
>>>> 10.1.1.10:2427--->
>>>>
>>>>
>>>>>>> MDCX 89773 AALN/S0/SU1/3 at MC003776.mcenery.local MGCP 0.1
>>>>>>> C: A00000000200d51c000000F5
>>>>>>> I: 6
>>>>>>> X: 0
>>>>>>> L: p:20, a:PCMU, s:off, t:b8
>>>>>>> M: sendrecv
>>>>>>> R: L/hu, D/[0-9ABCD*#]
>>>>>>> S:
>>>>>>> Q: process,loop
>>>>>>>
>>>>>>> v=0
>>>>>>> o=- 6 0 IN EPN AALN/S0/SU1/3 at MC003776.mcenery.local
>>>>>>> s=Cisco SDP 0
>>>>>>> t=0 0
>>>>>>> m=audio 18840 RTP/AVP 0
>>>>>>> c=IN IP4 172.20.113.10
>>>>>>> <---
>>>>>>>
>>>>>>> //router receives instruction to stop transmitting audio
>>>>>>> Jul 10 03:52:00.227 CST: MGCP Packet received from
>>>>>>>
>>>>>>>
>>>> 10.1.1.10:2427--->
>>>>
>>>>
>>>>>>> MDCX 89775 AALN/S0/SU1/3 at MC003776.mcenery.local MGCP 0.1
>>>>>>> C: A00000000200d51c000000F5
>>>>>>> I: 6
>>>>>>> X: 0
>>>>>>> M: recvonly
>>>>>>>
>>>>>>> // router reports call statistics:
>>>>>>> Jul 10 03:52:00.287 CST: MGCP Packet sent to 10.1.1.10:2427--->
>>>>>>> 250 89776 OK
>>>>>>> P: PS=978, OS=156480, PR=980, OR=156800, PL=0, JI=0, LA=0
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> v=0
>>>>>>> c=IN IP4 172.20.115.254
>>>>>>> m=audio 17344 RTP/AVP 0 100
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> /Wes
>>>>>>>
>>>>>>>
>>>>>>> Jonathan Charles wrote:
>>>>>>>
>>>>>>> Here you go... no obvious errors...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Jonathan
>>>>>>>
>>>>>>> On Wed, Jul 9, 2008 at 2:42 PM, Wes Sisk <wsisk at cisco.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> yep
>>>>>>>
>>>>>>> Jonathan Charles wrote:
>>>>>>>
>>>>>>>
>>>>>>> The MGCP packet debug?
>>>>>>>
>>>>>>>
>>>>>>> J
>>>>>>>
>>>>>>> On Wed, Jul 9, 2008 at 1:02 PM, Wes Sisk <wsisk at cisco.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> can you share the debug (blank out the actual phone numbers) with
>>>>>>>
>>>>>>>
>>>> debug
>>>>
>>>>
>>>>>>> datetime msec?
>>>>>>>
>>>>>>> /wes
>>>>>>>
>>>>>>> Jonathan Charles wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> We have a remote site via a VPN tunnel (over MPLS), and we are
>>>>>>>
>>>>>>>
>>>> seeing
>>>>
>>>>
>>>>>>> significant audio cut through delays.
>>>>>>>
>>>>>>> We did a debug mgcp packet and saw no retries.
>>>>>>>
>>>>>>> We can also see the problem when PSTN callers are placed on hold and
>>>>>>> retrieved.
>>>>>>>
>>>>>>> Delay lasts between 3 to 4 seconds...
>>>>>>>
>>>>>>> Any ideas?
>>>>>>>
>>>>>>> MGCP config is the default (no special packages enabled/disabled)...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Jonathan
>>>>>>> _______________________________________________
>>>>>>> cisco-voip mailing list
>>>>>>> cisco-voip at puck.nether.net
>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>> -----------------------------------------
>>>> Disclaimer:
>>>>
>>>> This e-mail communication and any attachments may contain
>>>> confidential and privileged information and is for use by the
>>>> designated addressee(s) named above only. If you are not the
>>>> intended addressee, you are hereby notified that you have received
>>>> this communication in error and that any use or reproduction of
>>>> this email or its contents is strictly prohibited and may be
>>>> unlawful. If you have received this communication in error, please
>>>> notify us immediately by replying to this message and deleting it
>>>> from your computer. Thank you.
>>>>
>>>>
>>>>
>>>>
More information about the cisco-voip
mailing list