In those scenarios you typically need simultaneous packet captures on both sides and debugging on anything in the infrastructure to identify the bad actor.
-Ryan On Apr 13, 2018, at 12:42 AM, James Andrewartha <[email protected]<mailto:[email protected]>> wrote: 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 <[email protected]<mailto:[email protected]>> 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) <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://puck.nether.net/mailman/listinfo/cisco-voip _______________________________________________ cisco-voip mailing list [email protected]<mailto:[email protected]> https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
