what is Payload type 95

Question

We getting choppy sound with 711a.

Zoper sending before 711a 

RTP undefined (PT : 95) SSRC:76e9c4c0 PORT:26792 packets:2 L:0 J:0 [0.84s]

what is this?

Answer 1

I believe (but im not sure) that this is the empty rtp packet that is sent to open up the nat.

The choppy sound for sure is not related to this.

What is the direction of the choppy sound ?

Have you checked the network jitter ?

Comments

User Agent Zoiper r55b5166 2600hz

Codec G.711a G.711a

Received packets 198 692

Seconds between last RTP and last SIP packet 0 0

Lost packets 0 0

MOS fixed 50 1.0 4.5

MOS fixed 200 1.7 4.5

MOS adaptive 500 1.0 3.8

MOS XR (avg/min) 0.0/0.0 0.0/0.0

Max RTP jitter 73 4

Avg RTP jitter 39.3 0.2

Max RTCP jitter 0

Avg RTCP jitter 0

Max RTCP fraction loss 0 0.8

Avg RTCP fraction loss 0 0.3

PDV 50 - 70 37 0

PDV 70 - 90 1 0

It is not a jitter problem, direction zoiper -> server

---

look at the difference between received and transmitted packets.
Can you check the time between 2 rtp packets, preferably captured somewhere in the middle.
I am suspecting that one of the devices has timing issues and this is causing packets to be sent faster or slower than every 20ms

---

v=0
o=Zoiper 0 0 IN IP4 192.168.1.105
s=Zoiper
c=IN IP4 ххххххххххх
t=0 0
m=audio 32780 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv

timing is not present, is this mean timing set to default - ptime=20 ?

our server 200 ok sdp part

v=0
o=FreeSWITCH 1470037247 1470037248 IN IP4 XXXXXXXX
s=FreeSWITCH
c=IN IP4 xxxxxxxx
t=0 0
m=audio 24612 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

timing is set to 20 ms


Wiresharc shows RTP zoiper -> server 
Dropped by jitter buffer 76% Wrong timestump 20% jitter set 50 ms
if jitter 500 ms anyway 40% drops

---

Hello,

It's better to check with wireshark and check if the timestamps (timestamp measured in the middle of the path) are approximately 20ms apart (you can do it with the stream analysis too but that function seems a bit buggy).

We have seen several pc's in the past with clocks that are 50% slower or faster than they should be.

(we have seen a couple of android phones like that too)