[asterisk-bugs] [JIRA] (ASTERISK-26423) res_pjsip_sdp_rtp: Asymmetric RTP codec can cause audio loss and wonkiness
Andreas Wetzel (JIRA)
noreply at issues.asterisk.org
Thu Oct 27 11:56:10 CDT 2016
[ https://issues.asterisk.org/jira/browse/ASTERISK-26423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=233002#comment-233002 ]
Andreas Wetzel commented on ASTERISK-26423:
-------------------------------------------
I have applied the patch to Asterisk 13.12.0 and testing with the Gigaset S850A GO shows a significant improvement:
{noformat}
No. Timestamp (Dir) Address SIP Message
===== ========== ============================== ===================================
00000 1477585228 * <== 10.6.6.64:5060 INVITE sip:301 at rakanishu.de;user=phone SIP/2.0
00001 1477585228 * ==> 10.6.6.64:5060 SIP/2.0 401 Unauthorized
00002 1477585228 * <== 10.6.6.64:5060 ACK sip:301 at rakanishu.de;user=phone SIP/2.0
00003 1477585228 * <== 10.6.6.64:5060 INVITE sip:301 at rakanishu.de;user=phone SIP/2.0
00004 1477585228 * ==> 10.6.6.64:5060 SIP/2.0 100 Trying
00005 1477585228 * ==> 10.6.8.6:5060 INVITE sip:ekiga at 10.6.8.6 SIP/2.0
00006 1477585228 * <== 10.6.8.6:5060 SIP/2.0 100 Trying
00007 1477585228 * <== 10.6.8.6:5060 SIP/2.0 180 Ringing
00008 1477585228 * ==> 10.6.6.64:5060 SIP/2.0 180 Ringing
00009 1477585231 * <== 10.6.8.6:5060 SIP/2.0 200 OK
00010 1477585231 * ==> 10.6.8.6:5060 ACK sip:ekiga at 10.6.8.6 SIP/2.0
00011 1477585231 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00012 1477585231 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00013 1477585231 * <== 10.6.6.64:5060 INVITE sip:10.6.6.1:5060 SIP/2.0
00014 1477585231 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00015 1477585231 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00016 1477585233 * <== 10.6.6.64:5060 BYE sip:10.6.6.1:5060 SIP/2.0
00017 1477585233 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00018 1477585233 * ==> 10.6.8.6:5060 BYE sip:ekiga at 10.6.8.6 SIP/2.0
00019 1477585233 * <== 10.6.8.6:5060 SIP/2.0 200 OK
{noformat}
The endless loop of reinvites is gone and after a single reINVITE from the S850A GO, both parties are happily exchanging RTP data using type 09/G722 with functioning audio in both directions:
{noformat}
Got RTP packet from 10.6.6.64:5018 (type 09, seq 000061, ts 51262560, len 000160)
Sent RTP P2P packet to 10.6.6.64:5018 (type 08, len 000160)
Got RTP packet from 10.6.6.64:5018 (type 09, seq 000062, ts 51262720, len 000160)
Sent RTP P2P packet to 10.6.6.64:5018 (type 08, len 000160)
Got RTP packet from 10.6.6.64:5018 (type 09, seq 000063, ts 51262880, len 000160)
Sent RTP P2P packet to 10.6.6.64:5018 (type 08, len 000160)
Got RTP packet from 10.6.6.64:5018 (type 09, seq 000064, ts 51263040, len 000160)
Sent RTP packet to 10.6.6.64:5018 (type 09, seq 004928, ts 000960, len 000160)
Got RTP packet from 10.6.6.64:5018 (type 09, seq 000065, ts 51263200, len 000160)
Sent RTP packet to 10.6.6.64:5018 (type 09, seq 004929, ts 001120, len 000160)
Sent RTP packet to 10.6.6.64:5018 (type 09, seq 004930, ts 001280, len 000160)
Sent RTP packet to 10.6.6.64:5018 (type 09, seq 004931, ts 001440, len 000160)
Sent RTP packet to 10.6.6.64:5018 (type 09, seq 004932, ts 001600, len 000160)
Sent RTP packet to 10.6.6.64:5018 (type 09, seq 004933, ts 001760, len 000160)
Got RTP packet from 10.6.6.64:5018 (type 09, seq 000066, ts 51263360, len 000160)
Sent RTP packet to 10.6.6.64:5018 (type 09, seq 004934, ts 001920, len 000160)
Got RTP packet from 10.6.6.64:5018 (type 09, seq 000067, ts 51263520, len 000160)
Sent RTP packet to 10.6.6.64:5018 (type 09, seq 004935, ts 002080, len 000160)
Got RTP packet from 10.6.6.64:5018 (type 09, seq 000068, ts 51263680, len 000160)
Sent RTP packet to 10.6.6.64:5018 (type 09, seq 004936, ts 002240, len 000160)
...
{noformat}
Which can also be confirmed by looking at the individual channels:
{noformat}
core show channel PJSIP/S850A-1-00000006
-- General --
Name: PJSIP/S850A-1-00000006
Type: PJSIP
UniqueID: sip.rakanishu.de-1477585770.9
LinkedID: sip.rakanishu.de-1477585770.9
Caller ID: S850A-1
Caller ID Name: (N/A)
Connected Line ID: 301
Connected Line ID Name: (N/A)
Eff. Connected Line ID: 301
Eff. Connected Line ID Name: (N/A)
DNID Digits: (N/A)
Language: en
State: Up (6)
NativeFormats: (g722)
WriteFormat: slin16
ReadFormat: slin16
WriteTranscode: Yes (slin at 16000)->(g722 at 16000)
ReadTranscode: Yes (g722 at 16000)->(slin at 16000)
Time to Hangup: 0
Elapsed Time: 0h2m20s
Bridge ID: 96d98461-cbd4-4b9f-b6ac-861c212a5137
-- PBX --
Context: local-in
Extension: 301
Priority: 1
Call Group: 0
Pickup Group: 0
Application: Dial
Data: PJSIP/ekiga
Call Identifer: [C-00000003]
Variables:
BRIDGEPVTCALLID=22f9ac08-7fb7-4386-bf7e-8e65817b8847
BRIDGEPEER=PJSIP/ekiga-00000007
DIALEDPEERNUMBER=ekiga
DIALEDPEERNAME=PJSIP/ekiga-00000007
DIALSTATUS=ANSWER
DIALEDTIME=
ANSWEREDTIME=
CDR Variables:
level 1: calledsubaddr=
level 1: callingsubaddr=
level 1: dnid=
level 1: clid="" <S850A-1>
level 1: src=S850A-1
level 1: dst=301
level 1: dcontext=local-in
level 1: channel=PJSIP/S850A-1-00000006
level 1: dstchannel=PJSIP/ekiga-00000007
level 1: lastapp=Dial
level 1: lastdata=PJSIP/ekiga
level 1: start=1477585770.828084
level 1: answer=1477585773.047506
level 1: end=0.000000
level 1: duration=139
level 1: billsec=137
level 1: disposition=8
level 1: amaflags=3
level 1: uniqueid=sip.rakanishu.de-1477585770.9
level 1: linkedid=sip.rakanishu.de-1477585770.9
level 1: sequence=6
{noformat}
{noformat}
core show channel PJSIP/ekiga-00000007
-- General --
Name: PJSIP/ekiga-00000007
Type: PJSIP
UniqueID: sip.rakanishu.de-1477585770.10
LinkedID: sip.rakanishu.de-1477585770.9
Caller ID: 301
Caller ID Name: (N/A)
Connected Line ID: S850A-1
Connected Line ID Name: (N/A)
Eff. Connected Line ID: S850A-1
Eff. Connected Line ID Name: (N/A)
DNID Digits: (N/A)
Language: en
State: Up (6)
NativeFormats: (alaw)
WriteFormat: slin16
ReadFormat: slin16
WriteTranscode: Yes (slin at 16000)->(slin at 8000)->(alaw at 8000)
ReadTranscode: Yes (alaw at 8000)->(slin at 8000)->(slin at 16000)
Time to Hangup: 0
Elapsed Time: 0h2m43s
Bridge ID: 96d98461-cbd4-4b9f-b6ac-861c212a5137
-- PBX --
Context: local-in
Extension:
Priority: 1
Call Group: 0
Pickup Group: 0
Application: AppDial
Data: (Outgoing Line)
Call Identifer: [C-00000003]
Variables:
BRIDGEPVTCALLID=1109113516 at 10_6_6_64
BRIDGEPEER=PJSIP/S850A-1-00000006
DIALEDPEERNUMBER=ekiga
CDR Variables:
level 1: calledsubaddr=
level 1: callingsubaddr=
level 1: dnid=
level 1: clid="" <301>
level 1: src=301
level 1: dcontext=local-in
level 1: channel=PJSIP/ekiga-00000007
level 1: lastapp=AppDial
level 1: lastdata=(Outgoing Line)
level 1: start=1477585770.849915
level 1: answer=1477585773.047438
level 1: end=1477585773.054909
level 1: duration=2
level 1: billsec=0
level 1: disposition=8
level 1: amaflags=3
level 1: uniqueid=sip.rakanishu.de-1477585770.10
level 1: linkedid=sip.rakanishu.de-1477585770.9
level 1: sequence=7
{noformat}
'pjsip show channelstats' however still displays a wrong codec/no codec at all for the channels. No idea where it gets that information from:
{noformat}
BridgeId ChannelId ........ UpTime.. Codec. Count Lost Pct Jitter Count Lost Pct Jitter RTT....
===========================================================================================================
96d98461 S850A-1-00000006 00:00:33 ulaw 1499 86 5 0.000 1454 0 0 0.000 0.000
96d98461 ekiga-00000007 00:00:33 1456 33056 2270 0.000 1494 0 0 0.001 0.000
{noformat}
> res_pjsip_sdp_rtp: Asymmetric RTP codec can cause audio loss and wonkiness
> --------------------------------------------------------------------------
>
> Key: ASTERISK-26423
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-26423
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Resources/res_pjsip_sdp_rtp
> Affects Versions: 13.11.2
> Environment: FreeBSD 10.3-RELEASE-p8 i386
> Gigaset S850A GO IP phone
> Reporter: Andreas Wetzel
> Assignee: Joshua Colp
> Attachments: ASTERISK-26423.diff
>
>
> This is an interoperability issue between asterisk/pjsip and a Gigaset S850A GO IP telephone due to way codecs are negotiated between both devices.
> When a call is placed from the S850A GO the initial INVITE message contains the list of configured codecs in the preferred order, i.e. g722, pcma, pcmu. When asterisk responds with OK, it also presents the configured codec list and preferred order, lets assume it's also g722, pcma, pcmu. What the S850A GO now seems to be doing is to pick the first codec from asterisk's list which it also supports. If asterisk now sends RTP data to the S850A GO, that is encoded in a format different than the one it has picked, the phone sends reINVITEs whose sdp only contains the single codec it has chosen. Asterisk confirms that it would respect this and sends OK with also only the single codec, but continues to send RTP data encoded in a different format, leading to an endless loop of reINVITEs and OK messages, with only one way audio. This occurs for example when calling an extension that does only support pcma and pcmu, in which case asterisk will send alaw encoded RTP to the S850A GO, as it was in it's list of supported codecs.
> I understand that this issue is in part caused by the firmware of the S850A GO phone. Similar issues seem to exist with a number of other manufacturers like Grandstream, Yealink and Snom. Nevertheless I feel that asterisk/pjsip is not behaving correctly in this regard either. If asterisk acknowledges the use of a single codec as was requested by the device in the reINVITE message, then it should obey that and not continue sending differently encoded RTP to the device.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list