[asterisk-bugs] [JIRA] (ASTERISK-26423) res_pjsip_sdp_rtp: Asymmetric RTP codec can cause audio loss and wonkiness

Marcelo Bello (JIRA) noreply at issues.asterisk.org
Tue Oct 11 08:47:01 CDT 2016


    [ https://issues.asterisk.org/jira/browse/ASTERISK-26423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=232637#comment-232637 ] 

Marcelo Bello commented on ASTERISK-26423:
------------------------------------------

This is a known issue with multiple brands of phones, such as:
- Yealink
- Grandstream
- Siemens Gigaset
- Cisco Linksys
- HTEK

Up until now it was always considered a bug on SIP phones, but the RE-INVITE behaviour described here also hints to a potential bug in PJSIP as well. At the very least, I believe the behavior of failing to consider the REINVITE from the SIP phone is something that should be fixed. However, I have not seen such REINVITE behavior on Yealink and GS phones, so fixing it could help the Gigaset devices, but I believe not Yealink and GS devices.

Yealink has already released a test firmware with a fix to accept Asymmetric RTP codec. Today I opened a ticket with Grandstream for the same issue, hopefully they will fix it soon.

Yealink (discussion thread with link to the firmware where the issue has been fixed):
http://forum.yealink.com/forum/showthread.php?tid=8330

Grandstream (first is the ticket, second is the report on their forums):
https://helpdesk.grandstream.com/users/show_ticket/61551
http://forums.grandstream.com/forums/index.php?topic=33128.0


> 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: Unassigned
>
> 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