[Home]

Summary:ASTERISK-19888: Choppy Audio from one client, great audio from two others, difference in RTP type number, why?
Reporter:Shaun Clark (shaunc869)Labels:
Date Opened:2012-05-18 17:31:26Date Closed:2012-05-21 10:40:31
Priority:MajorRegression?
Status:Closed/CompleteComponents:
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I have three clients connected to the same Asterisk box talking iLBC to alaw out to the PSTN:

1. X-Lite
2. LinPhone Android
3. pjSIP Android

X-Lite and Linphone do great call after call, but the pjSIP client has some great calls and some not so great calls, on the asterisk side I ran a rtp set debug on and see the following:

1. X-Lite:

Sent RTP packet to      50.43.101.83:43282 (type 98, seq 040329, ts 010400, len 000050)
Sent RTP packet to      50.43.101.83:43282 (type 98, seq 040330, ts 010560, len 000050)
Got  RTP packet from    4.55.18.66:20412 (type 08, seq 000076, ts 012160, len 000160)
Sent RTP packet to      4.55.18.66:20412 (type 08, seq 006652, ts 005280, len 000160)
Got  RTP packet from    4.55.18.66:20412 (type 08, seq 000077, ts 012320, len 000160)

2. LinPhone:

Sent RTP packet to      4.55.18.70:17386 (type 08, seq 024332, ts 018560, len 000160)
Got  RTP packet from    50.43.101.83:62802 (type 100, seq 000087, ts 023440, len 000050)
Got  RTP packet from    4.55.18.70:17386 (type 08, seq 000174, ts 027840, len 000160)
Sent RTP packet to      4.55.18.70:17386 (type 08, seq 024333, ts 018720, len 000160)
Got  RTP packet from    4.55.18.70:17386 (type 08, seq 000175, ts 028000, len 000160)
Sent RTP packet to      50.43.101.83:62802 (type 100, seq 003122, ts 026400, len 000050)

3. pjSIP

Sent RTP packet to      4.55.18.70:12172 (type 08, seq 021861, ts 036160, len 000160)
Sent RTP packet to      4.55.18.70:12172 (type 08, seq 021862, ts 036320, len 000160)
Sent RTP packet to      50.43.101.83:23794 (type 102, seq 035108, ts 044480, len 000050)
Got  RTP packet from    4.55.18.70:12172 (type 08, seq 000288, ts 046080, len 000160)
Got  RTP packet from    4.55.18.70:12172 (type 08, seq 000289, ts 046240, len 000160)
Sent RTP packet to      50.43.101.83:23794 (type 102, seq 035109, ts 044640, len 000050)
Sent RTP packet to      4.55.18.70:12172 (type 08, seq 021863, ts 036480, len 000160)
Got  RTP packet from    4.55.18.70:12172 (type 08, seq 000290, ts 046400, len 000160)

The only difference I see is the type number from the client, any chance this explains the choppy audio and if so what does that seq number mean? Thanks!
Comments:By: Shaun Clark (shaunc869) 2012-05-18 18:04:54.297-0500

Show SIP Debug gives me:

X-Lite:

User-Agent: X-Lite 4 release 4.1 stamp 63215
Content-Length: 394

v=0
o=- 1337382269182124 1 IN IP4 50.43.101.83
s=CounterPath X-Lite 4.1
c=IN IP4 50.43.101.83
t=0 0
a=ice-ufrag:b35471
a=ice-pwd:09a09d16f0c37d4adbc32e48f5c1d497
m=audio 44934 RTP/AVP 98 101
a=rtpmap:98 iLBC/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=candidate:1 1 UDP 659136 10.3.10.41 53710 typ host
a=candidate:1 2 UDP 659134 10.3.10.41 53711 typ host
<------------->


LinPhone


v=0
o=99093 3081 3081 IN IP4 50.43.101.83
s=Talk
c=IN IP4 50.43.101.83
b=AS:256
t=0 0
m=audio 58358 RTP/AVP 100 101
a=rtpmap:100 iLBC/8000
a=fmtp:100 mode=30
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
m=video 59138 RTP/AVP 103
a=rtpmap:103 VP8/90000
<------------->


pjSIP

v=0
o=- 3546370822 3546370822 IN IP4 50.43.101.83
s=pjmedia
c=IN IP4 50.43.101.83
b=AS:84
t=0 0
a=X-nat:8
m=audio 30237 RTP/AVP 102 9 101
c=IN IP4 50.43.101.83
b=TIAS:64000
a=rtcp:61461 IN IP4 50.43.101.83
a=sendrecv
a=rtpmap:102 ILBC/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
<------------->



Not sure if this helps more.
By: David Woolley (davidw) 2012-05-21 05:38:05.555-0500

Thanks for your comments. This does not appear to be a bug report. We appreciate the difficulties you are facing, but it would make more sense to raise your question in the support tracker, http://www.asterisk.org/support.

I expect a bug marshall to close this (the standard for of the canned response says this, but I can't actually do it).

It is not clear which RTP stream is causing problems.

You need to do some background reading on RTP if you are going to use low level diagnostics, like this.