SIP/2.0 415 Unsupported Media Type after upgrade to 20.6.0

[erichowey]

I currently have a system that I’m upgrading from 16.2.0 to 20.6.0. I have a carrier trunk that I’ve used for a long time. After attempting an upgrade to 20.6.0, my system started responding to invites with SIP/2.0 415 Unsupported Media Type. I’m kind of baffled since the config is no different on the 20.6.0 system.

pjsip.conf

[itq-in]
type=endpoint
transport=transport-udp-v4
context=lb-from-carrier
dtmf_mode=rfc4733
disallow=all
allow=ulaw
allow_subscribe=no
direct_media=no
aors=itq-in-aor

[itq-in-identify]
type=identify
endpoint=itq-in
srv_lookups=no
match=<redacted ip> ;PHLAPAFGTKR_603 DID In Philly
match=<redacted ip> ;ATLNGAQSTKR_1991 Omni Atlanta
match=<redacted ip> ;CHCGIL24TKR_1178 DID In Chicago
match=<redacted ip> ;CHCGIL24TKR_1184 TollFree In Chicago
match=<redacted ip> ;CHCGIL24TKR_2928 TollFree In Chicago 2
match=<redacted ip> ;DLLSTX37TKR_2217 Toll Free In Dallas

[itq-in-aor] ; qualify=yes emulation
type=aor
contact=sip:asterisk@<redacted ip> ;PHLAPAFGTKR_603 DID In Philly
contact=sip:asterisk@<redacted ip> ;ATLNGAQSTKR_1991 Omni Atlanta
contact=sip:asterisk@<redacted ip> ;CHCGIL24TKR_1178 DID In Chicago
contact=sip:asterisk@<redacted ip> ;CHCGIL24TKR_1184 TollFree In Chicago
contact=sip:asterisk@<redacted ip> ;CHCGIL24TKR_2928 TollFree In Chicago 2
contact=sip:asterisk@<redacted ip> ;DLLSTX37TKR_2217 Toll Free In Dallas

sip debug

<--- Received SIP request (1379 bytes) from UDP:<redacted ip>:5060 --->
INVITE sip:+1<redacted tn>@<redacted ip>:5060 SIP/2.0
Via: SIP/2.0/UDP <redacted ip>:5060;branch=z9hG4bK00B05bd7076a59d82b5
From: <sip:+1<redacted tn>@<redacted ip>>;tag=gK005a4db2
To: <sip:+1<redacted tn>@<redacted ip>>
Call-ID: 90222306_104797818@<redacted ip>
CSeq: 671432 INVITE
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed
Contact: <sip:+1<redacted tn>@<redacted ip>:5060>
P-Asserted-Identity: <sip:+1<redacted tn>;verstat=TN-Validation-Passed@<redacted ip>:5060>
Supported: timer,100rel,precondition
Session-Expires: 1800
Min-SE: 90
Content-Length:   563
Content-Type: multipart/mixed;boundary=sonus-content-delim
MIME-Version: 1.0

--sonus-content-delim
Content-Disposition: session; handling=required
Content-Length:   237
Content-Type: application/sdp

v=0
o=Sonus_UAC 955190 723305 IN IP4 <redacted ip>
s=SIP Media Capabilities
c=IN IP4 <redacted ip>
t=0 0
m=audio 45156 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20

--sonus-content-delim
Content-Disposition: signal; handling=required
Content-Type: application/isup; version=ansi88; base=ansi88

`
<--- Transmitting SIP response (393 bytes) to UDP:<redacted ip>:5060 --->
SIP/2.0 415 Unsupported Media Type
Via: SIP/2.0/UDP <redacted ip>:5060;rport=5060;received=<redacted ip>;branch=z9hG4bK00B05bd7076a59d82b5
Call-ID: 90222306_104797818@<redacted ip>
From: <sip:+1<redacted tn>@<redacted ip>>;tag=gK005a4db2
To: <sip:+1<redacted tn>@<redacted ip>>;tag=32629010-5a87-40bb-8356-cecd416ee14f
CSeq: 671432 INVITE
Server: Asterisk
Content-Length:  0

[jcolp]

I believe the behavior comes from:

commit e12244153a245d19d7ebd32cb17208104c64f443
Author: Torrey Searle <torrey@voxbone.com>
Date:   Thu Mar 19 10:34:42 2020 +0100

    res_pjsip_session: implement processing of Content-Disposition
    
    RFC5621 requires any content type with a Content-Disposition
    with handling=required to be rejected with a 415 response
    
    ASTERISK-28782 #close
    
    Change-Id: Iad969df75936730254b95c1a8bc3b48497070bb4

Or issue:

https://issues-archive.asterisk.org/ASTERISK-28782

Previous versions ignored it, while that change added support for actually respecting it. In the given multipart there is:

Content-Disposition: signal; handling=required
Content-Type: application/isup; version=ansi88; base=ansi88

Which since Asterisk doesn’t support application/isup would not be handled, and cause the 415 to be sent. There is no option to disable obeying this standard.

There is no immediate “fix” for this aside from having that content removed from the message. Otherwise reverting the change would do it, or adding an option to disable obeying the standard.

[erichowey]

Thank you for taking time out of your day to answer as always @jcolp .

[erichowey]

My carrier removed the application/isup content type and everything works! Thank you again.