[cisco-voip] MGCP Audio Cut Through Delay

[c3voip]

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