[cisco-voip] Audio cut-through delays upon transfer

Fri Apr 13 00:42:55 EDT 2018

Indeed it does. Also it seems if you don't lose any packets after the first then the count is still zero. I managed to get a packet capture from one end and it looks fine, just 5 seconds later audio packets from the other end start showing up. On another call I did see out of order and then retransmitted SCCP TCP packets during call setup which is a bit of concern, the only layer 3 device between the phones and CUCM is a 2921.

Parameter Origination Destination MediaTransportAdd_Ip 10.100.254.10 10.100.253.203 PayLoadCapability 6 6 MediaCap_g723BitRate 0 0 Packets Sent 14381 14381 Octets Sent 2473532 2473532 Packets Received 13870 14380 Octets Received 2385640 2473360 Packets Lost 0 0 Jitter 0 0 Latency 0 0 QoS G G VideoCap_Codec 0 0 VideoCap_Bandwidth 0 0 VideoCap_Resolution 0 0 VideoTransportAddress_IP 0.0.0.0 0.0.0.0 VideoTransportAddress_Port 0 0

James Andrewartha
Network & Projects Engineer
Christ Church Grammar School
Claremont, Western Australia
Ph. (08) 9442 1757
Mob. 0424 160 877
________________________________
From: Anthony Holloway <avholloway+cisco-voip at gmail.com>
Sent: Thursday, 12 April 2018 2:55 AM
To: Ryan Ratliff (rratliff)
Cc: James Andrewartha; cisco-voip list
Subject: Re: [cisco-voip] Audio cut-through delays upon transfer

Makes sense.

[image.png]

On Wed, Apr 11, 2018 at 1:19 PM Ryan Ratliff (rratliff) <rratliff at cisco.com<mailto:rratliff at cisco.com>> wrote:
Lost is a delta in sequence numbers from one packet to the next. If you never receive a first packet you can't lose any.

-Ryan

On Apr 11, 2018, at 12:01 PM, Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway+cisco-voip at gmail.com>> wrote:

How does it show 0 packets received, but also 0 packets lost?  Somethings not right in the report from CMR.

On Tue, Apr 10, 2018 at 10:48 PM James Andrewartha <jandrewartha at ccgs.wa.edu.au<mailto:jandrewartha at ccgs.wa.edu.au>> wrote:
On 13/01/17 09:25, James Andrewartha wrote:
> We've experienced something similar for about 2.5 years, on some calls
> one party won't be able to hear audio for 5-10 seconds. These are all
> internal calls, single site, phones (7965 and 7975, SCCP) on a flat L2
> network, one pub, one sub. It even survived an upgrade from 8.6 to 10.5.
> We opened a case and TAC asked for a trace of it happening, but we
> couldn't reproduce it easily. I keep meaning to get back to it, but
> haven't had the time given how hard it is to reproduce.

Well, some staff have moved to a demountable with a switch daisy-chained
from another and it's happening quite a bit now. Looking at the CDR I
can see that one end is just not receiving the packets. The phones are
on the same subnet/VLAN, and the switch ports have no errors. I'm going
to set up a span capture but does anyone have any suggestions on where
to look? CUCM 10.5.2.15900-8, 7975/7965 with SCCP[47]5.9-4-2SR2-2S.

Parameter       Origination     Destination
MediaTransportAdd_Ip    10.100.254.227  10.100.253.223
PayLoadCapability       6       6
MediaCap_g723BitRate    0       0
Packets Sent    714     712
Octets Sent     122808  122464
Packets Received        711     0
Octets Received         122292  0
Packets Lost    0       0
Jitter  0       0
Latency         0       0
QoS     G       G
VideoCap_Codec  0       0
VideoCap_Bandwidth      0       0
VideoCap_Resolution     0       0
VideoTransportAddress_IP        0.0.0.0         0.0.0.0
VideoTransportAddress_Port      0       0
 --
James Andrewartha
Network & Projects Engineer
Christ Church Grammar School
Claremont, Western Australia
Ph. (08) 9442 1757
Mob. 0424 160 877
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180413/ac886d6b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 201088 bytes
Desc: image.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180413/ac886d6b/attachment.png>