[cisco-voip] MGCP Audio Cut Through Delay

Tue Jul 22 15:17:21 EDT 2008

So, do we want them bundled? I would think that TCP would get
retransmitted if lost (just cuz it is TCP)... so, how does bundling
fix my problem....

Jonathan

On Tue, Jul 22, 2008 at 12:08 PM, Wes Sisk <wsisk at cisco.com> wrote:
> 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.
>>>>>
>>>>>
>>>>>
>>>>>
>