[asterisk-bugs] [JIRA] (ASTERISK-30193) chan_pjsip should return all codecs on a re-INVITE without SDP

Asterisk Team (JIRA) noreply at issues.asterisk.org
Fri Aug 26 03:48:09 CDT 2022


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

Asterisk Team commented on ASTERISK-30193:
------------------------------------------

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.

Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/].

> chan_pjsip should return all codecs on a re-INVITE without SDP
> --------------------------------------------------------------
>
>                 Key: ASTERISK-30193
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-30193
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_pjsip
>    Affects Versions: 16.25.3
>         Environment: Linux
>            Reporter: Henning Westerholt
>            Severity: Major
>
> h2. Description
> Currently chan_pjsip on receiving a re-INVITE without SDP will only return the codecs that are previously negotiated and not offering all enabled codecs.
> This causes interoperability issues with different equipment (e.g. from Cisco) for some of our customers and probably also in other scenarios involving 3PCC infrastructure.
> h2. Standard reference
> The RFC 3261 states that a UAS SHOULD behave as it would be a new call, i.e. returning all available codecs.
> h3. RFC 3261 section 14.2:
> {quote}
> "A UAS providing an offer in a 2xx (because the INVITE did not contain an
> offer) SHOULD construct the offer as if the UAS were making a brand new
> call, subject to the constraints of sending an offer that updates an
> existing session, as described in \[13\] in the case of SDP. Specifically,
> this means that it SHOULD include as many media formats and media types that the UA is willing to support."
> {quote}
> Further relevant RFC quotes can be found in the following discussing [link|https://lists.cs.columbia.edu/pipermail/sip-implementors/2016-January/030448.html]
> h2. Other material
> An old discussion with community members can be found at this [link|https://community.asterisk.org/t/pjsip-re-invite-without-sdp-codec-negotiation/75935]
> h2. Proposed solution
> I want to propose a new configuration option to configure this behaviour: 
> *all_codecs_on_empty_reinvite*
> I have created a patch against asterisk 16 to implement this option and functionality and will submit it in Gerrit for further review.
> In my opinion the mentioned option should be enabled by default, but of course due to the large installed base that could expect a different behaviour you might have another opinion in this regards.
> h2. Tests
> h3. General
> The patch has been tested on a test system and will be also included in our customer installation(s).
> h3. Test traces
> I have reproduced SIP traces below. The output with disabled parameter is the current behaviour, here it shows only the currently used codecs. In the output with enabled parameter I've configured 4 codecs on the asterisk, to easily spot the difference.
> h4. Output from Test System with enabled parameter:
> {noformat}
> 2022/08/10 12:56:33.769294 YYY.ZZZ.64.8:5096 -> YYY.ZZZ.79.29:5065
> INVITE sip:YYY.ZZZ.79.29:5065 SIP/2.0
> Via: SIP/2.0/UDP YYY.ZZZ.64.8:5096;rport;branch=z9hG4bKPjpA51QDMeluT1Lt3ST2CquLXhocD74i.v
> Max-Forwards: 70
> From: sip:1101 at kam03.tst.nbg.domain.com;tag=.5BjZZ3xdAW93NStuwDVXfjXsSftFLJy
> To: sip:1100 at kam03.tst.nbg.domain.com;tag=31142ded-bcc6-43b1-9d2a-ed4c646da437
> Contact: <sip:1101 at YYY.ZZZ.64.8:5096;ob>
> Call-ID: yy8jj3ktcypN3z75pmxuh9kvKj89JPfa
> CSeq: 8980 INVITE
> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
> Supported: replaces, 100rel, timer, norefersub
> Session-Expires: 1800;refresher=uac
> Min-SE: 90
> User-Agent: PJSUA v2.9 Linux-5.4.0.122/x86_64/glibc-2.31
> Content-Length:  0
> 2022/08/10 12:56:33.771150 YYY.ZZZ.79.29:5065 -> YYY.ZZZ.64.8:5096
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP YYY.ZZZ.64.8:5096;rport=5096;received=YYY.ZZZ.64.8;branch=z9hG4bKPjpA51QDMeluT1Lt3ST2CquLXhocD74i.v
> Call-ID: yy8jj3ktcypN3z75pmxuh9kvKj89JPfa
> From: <sip:1101 at kam03.tst.nbg.domain.com>;tag=.5BjZZ3xdAW93NStuwDVXfjXsSftFLJy
> To: <sip:1100 at kam03.tst.nbg.domain.com>;tag=31142ded-bcc6-43b1-9d2a-ed4c646da437
> CSeq: 8980 INVITE
> Session-Expires: 1800;refresher=uac
> Require: timer
> Contact: <sip:YYY.ZZZ.79.29:5065>
> Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
> Supported: 100rel, timer, replaces, norefersub
> Server: Asterisk PBX 16.25.3
> Content-Type: application/sdp
> Content-Length:   317
> v=0
> o=- 3869124992 3869124996 IN IP4 YYY.ZZZ.79.29
> s=Asterisk
> c=IN IP4 YYY.ZZZ.79.29
> t=0 0
> m=audio 10676 RTP/AVP 9 0 107 97 96
> a=rtpmap:9 G722/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:107 opus/48000/2
> a=rtpmap:97 speex/8000
> a=rtpmap:96 telephone-event/8000
> a=fmtp:96 0-16
> a=ptime:20
> a=maxptime:60
> a=sendrecv
> {noformat}
> h4. Output from Test System with disabled parameter:
> {noformat}
> 2022/08/10 12:50:31.522677 YYY.ZZZ.64.8:5096 -> YYY.ZZZ.79.29:5065
> INVITE sip:YYY.ZZZ.79.29:5065 SIP/2.0
> Via: SIP/2.0/UDP YYY.ZZZ.64.8:5096;rport;branch=z9hG4bKPji1l8qrazPZUb87Yh.3Auw7sapFxz85j.
> Max-Forwards: 70
> From: sip:1101 at kam03.tst.nbg.domain.com;tag=ywbuXOEtb2GuhOYgSwbXvKfIMOwvFR6j
> To: sip:1100 at kam03.tst.nbg.domain.com;tag=fec38f0d-e41e-43ff-a801-3ba74fcafeb1
> Contact: <sip:1101 at YYY.ZZZ.64.8:5096;ob>
> Call-ID: k4KYt0RyHxmqBF79gMQm2mrERAl80vS3
> CSeq: 2596 INVITE
> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
> Supported: replaces, 100rel, timer, norefersub
> Session-Expires: 1800;refresher=uac
> Min-SE: 90
> User-Agent: PJSUA v2.9 Linux-5.4.0.122/x86_64/glibc-2.31
> Content-Length:  0
> 2022/08/10 12:50:31.524108 YYY.ZZZ.79.29:5065 -> YYY.ZZZ.64.8:5096
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP YYY.ZZZ.64.8:5096;rport=5096;received=YYY.ZZZ.64.8;branch=z9hG4bKPji1l8qrazPZUb87Yh.3Auw7sapFxz85j.
> Call-ID: k4KYt0RyHxmqBF79gMQm2mrERAl80vS3
> From: <sip:1101 at kam03.tst.nbg.domain.com>;tag=ywbuXOEtb2GuhOYgSwbXvKfIMOwvFR6j
> To: <sip:1100 at kam03.tst.nbg.domain.com>;tag=fec38f0d-e41e-43ff-a801-3ba74fcafeb1
> CSeq: 2596 INVITE
> Session-Expires: 1800;refresher=uac
> Require: timer
> Contact: <sip:YYY.ZZZ.79.29:5065>
> Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
> Supported: 100rel, timer, replaces, norefersub
> Server: Asterisk PBX 16.25.3
> Content-Type: application/sdp
> Content-Length:   236
> v=0
> o=- 3869124630 3869124634 IN IP4 YYY.ZZZ.79.29
> s=Asterisk
> c=IN IP4 YYY.ZZZ.79.29
> t=0 0
> m=audio 29398 RTP/AVP 9 96
> a=rtpmap:9 G722/8000
> a=rtpmap:96 telephone-event/8000
> a=fmtp:96 0-16
> a=ptime:20
> a=maxptime:150
> a=sendrecv
> {noformat}



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



More information about the asterisk-bugs mailing list