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

[Florian Floimair (JIRA)]

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

Florian Floimair commented on ASTERISK-29320:
---------------------------------------------

FYI another workaround (at least for me) was to set
outgoing_call_offer_pref = local (instead of remote_merge which is the default)
for the pjsip endpoints.
Also I could further narrow down that this only ever happens when the caller sets the callee on hold. The other way round it seems to be correct.


> 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.0.0, 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)