[cisco-voip] MGCP Audio Cut Through Delay

Jonathan Charles jonvoip at gmail.com
Tue Jul 22 11:43:42 EDT 2008 

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