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

[JoshE (JIRA)]

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

JoshE commented on ASTERISK-26423:
----------------------------------

We've certainly seen this issue as well.  This gets to a philosophical issue of standards compliance vs practical implementation.  From our reading of the spec, it's pretty clear that the Asterisk 13 behavior on PJSIP (though different from Asterisk 11) is correct:

RFC 3264 (https://www.ietf.org/rfc/rfc3264.txt), on Page 5:

   The list of media formats for each media stream conveys two pieces of
   information, namely the set of formats (codecs and any parameters
   associated with the codec, in the case of RTP) that the offerer is
   capable of sending and/or receiving (depending on the direction
   attributes), and, in the case of RTP, the RTP payload type numbers
   used to identify those formats.  *If multiple formats are listed, it
   means that the offerer is capable of making use of any of those
   formats during the session.  In other words, the answerer MAY change
   formats in the middle of the session, making use of any of the
   formats listed, without sending a new offer.*

That said, Snom, Grandstream and several others make an incorrect simplifying assumption that sending codec = receiving codec and expecting the device to make a new offer if that should need to be changed.

Over the course of several months, we were able to work with Yealink to resolve this issue on all of their currently supported phones, though the older phones remain non-compliant.  You can find the firmware that resolves these issues in their forums.

Just throwing in my $.02 here: we'd certainly like to possibly have a knob to deal with this behavior for non-compliant endpoints, given the difficulty of getting all manufacturers to update software.

> 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: Andreas Wetzel
>
> 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)