[asterisk-bugs] [JIRA] (ASTERISK-29320) res_pjsip_sdp_rtp: Codec preference order of remote is not correct on unhold

[Alexander Traud (JIRA)]

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

Alexander Traud commented on ASTERISK-29320:
--------------------------------------------

Adding a bit of analysis: In the debug log, the offending line is:{code}remote: (ulaw|g726|gsm|alaw|g722|ilbc) local: (g722|gsm) joint: (gsm|g722){code}Asterisk does not use its local preference but the remote preference order, this is the idea behind the new default ‘remote_merge’ strategy. However, Asterisk ‘thinks’ the remote preference order is not the presented SDP m(edia)=audio: 0 8 9 97 3 2 … but 0 2 3 8 9 97 instead. In other words: The [RTP Payload Type|https://www.iana.org/assignments/rtp-parameters] itself is used. Because gsm is 3 and therefore lower than g722 which is 9, the order swaps in this case here. This is caused by the [source code|https://github.com/asterisk/asterisk/blame/18/res/res_pjsip_sdp_rtp.c#L458]:{code}ast_rtp_codecs_payload_formats(&codecs, remote, &fmts);{code}This returns a variable called {{remote}} of type {{ast_format_cap}}. However, that format cap(ability) is not a ‘list’ but a ‘bag’, a ‘set’ with an unknown order. In other words: The remote order of media formats got lost.

Until this is fixed:
Therefore, Asterisk 16 LTS is a working workaround because that source code did not exist before.
Therefore, using just a single media format is a working workaround because then the lost order does not matter.

> res_pjsip_sdp_rtp: Codec preference order of remote is not correct on unhold
> ----------------------------------------------------------------------------
>
>                 Key: ASTERISK-29320
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29320
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip_sdp_rtp
>    Affects Versions: GIT, 18.2.1
>         Environment: CentOS 7
>            Reporter: Ross Beer
>            Assignee: Unassigned
>         Attachments: debug.txt, Flow.jpg
>
>
> When having two endpoints configured with the allow set to 'alaw,gsm' and then calling from one endpoint to another the call is set up with 'alaw' and there is two-way audio. 
> If a call is then put on hold and then re-connected there is either one way or no audio. This looks to be caused by the incorrect codec order in the 200 response from Asterisk:
> {noformat}
> Media Attribute (a): rtpmap:3 GSM/8000
> Media Attribute (a): rtpmap:8 PCMA/8000
> Media Attribute (a): rtpmap:101 telephone-event/8000
> Media Attribute (a): fmtp:101 0-16
> Media Attribute (a): ptime:20
> Media Attribute (a): maxptime:150
> Media Attribute (a): recvonly
> {noformat}
> If you set the endpoint to a single codec the issue is resolved.



--
This message was sent by Atlassian JIRA
(v6.2#6252)