[cisco-voip] MGCP Audio Cut Through Delay

Fri Jul 18 13:06:35 EDT 2008

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.