[cisco-voip] MGCP Audio Cut Through Delay
Peter Slow
peter.slow at gmail.com
Fri Jul 18 13:31:00 EDT 2008
there's the potential to use that feature to find call leaks early
(albeit in a somewhat disruptive manner) before they become a bigger
problem. if you've identified a problem such as a leaking callflow,
you could then turn off locations for that site until you are able to
address the issue. I'd rather have that happen than not know what was
going on inside of CM. CM is usually pretty obvious about what it's
doing and why when it thinks you're out of bandwidth so you could turn
it off quickly if necessary.
just a thought =)
-Pete
On Fri, Jul 18, 2008 at 1:06 PM, Jason Aarons (US)
<jason.aarons at us.didata.com> wrote:
> 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.
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
More information about the cisco-voip
mailing list