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

Friendly Automation (JIRA) noreply at issues.asterisk.org
Thu Oct 27 14:47:09 CDT 2022


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

Friendly Automation commented on ASTERISK-30193:
------------------------------------------------

Change 19493 merged by George Joseph:
res_pjsip: return all codecs on a re-INVITE without SDP

[https://gerrit.asterisk.org/c/asterisk/+/19493|https://gerrit.asterisk.org/c/asterisk/+/19493]

> 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
>            Assignee: Henning Westerholt
>
> 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