[cisco-voip] MGCP Audio Cut Through Delay

[Wes Sisk]

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
>>
>>
>>
>>