415 Unsupported Media Type with TLS through Asterisk 16.9 using PJSIP

I have a couple softphones (Bria and Zoiper, latest editions) and am working on implementing TLS through Asterisk 16.9 using PJSIP.

I can make calls to non-TLS endpoints just fine using the TLS registration.

However, when I make a TLS to TLS call (Bria to Zoiper, Bria to Bria, any combination of the two) using two different AORs and even the same AOR (calling myself) I get a “415 Unsupported Media Type”.

The SDP differences are:

m=audio 61006 RTP/SAVP 9 101 (initial invite to asterisk)
m=audio 16090 RTP/AVP 9 107 0 18 101 (destination endpoint aor invite)

I’ve been fighting this all day thinking I had my clients configured incorrectly, but it seems that it’s Asterisk that isn’t forwarding the correct SDP to the other client?

Pulling my hair out a bit. Thanks for any advice!

<--- History Entry 7 Received from x.x.x.x:51947 at 1586981075 --->
INVITE sip:809@my.asterisk.server SIP/2.0
Via: SIP/2.0/TLS 192.168.1.127;rport=51947;received=x.x.x.x;branch=z9hG4bK-524287-1---c7d0666577907366
Max-Forwards: 70
Contact: <sip:demo.800@x.x.x.x:51924;transport=TLS;rinstance=4abd2b702a62ad2c>
To: <sip:809@my.asterisk.server>
From: "Malcolm Reynolds" <sip:demo.800@my.asterisk.server>;tag=48ea9445
Call-ID: 102649NjRlN2U1ZjU3MTQ4NWQxM2ZiMDZlYTIzMzcxY2FkYzc
CSeq: 2 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, MESSAGE
Content-Type: application/sdp
Supported: replaces
User-Agent: Bria 5 release 5.8.3 stamp 102649
Authorization: Digest username="demo.800", realm="asterisk", nonce="1586981075/40a957bfec5cfce674c1af936a5892ce", uri="sip:809@my.asterisk.server", response="5cc9089cf62da8c778c469850b617eb6", algorithm=md5,     cnonce="eff611b5d631378a5de66bdbf8ae1fea", opaque="374acbf74e7cb2d1", qop=auth, nc=00000001
Content-Length: 596
Content-Type: application/sdp
Content-Length:   596

v=0
o=- 1586981075801714 1 IN IP4 192.168.1.127
s=Bria 5 release 5.8.3 stamp 102649
c=IN IP4 192.168.1.127
t=0 0
m=audio 61006 RTP/SAVP 9 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=crypto:1 AES_256_CM_HMAC_SHA1_80 inline:D9n90eIkWgRBx0oVBmbRIyqWYamV+C6NS/CrKZqLegMCJjNWhmYI0nthyUr9QA==
a=crypto:2 AES_256_CM_HMAC_SHA1_32 inline:H897t5QYDquXiwJas4u0T6C9mkddTR1VGsVGwhMTu00JwEgHZB36lVx+RXKupw==
a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:4fhyH1OFqkPEViZ9eJwdIw1h5HCplRoMf+8LQdUO
a=crypto:4 AES_CM_128_HMAC_SHA1_32 inline:5aQhz0W7Jlv8YAFYowHpydcq0+7QstAwZ+8hSJtO
a=sendrecv

<--- History Entry 10 Sent to x.x.x.x:59833 at 1586981075 --->
INVITE sip:demo.809@x.x.x.x:59833;transport=TLS;rinstance=b0f41511ec723238 SIP/2.0
Via: SIP/2.0/TLS x.x.x.x:5061;rport;branch=z9hG4bKPjb07f63e0-a7e4-4692-94f5-4714b27e2a04;alias
From: "Malcolm Reynolds" <sip:800@172.30.1.69>;tag=c7a095d8-c60e-4722-a5aa-26853b5de323
To: <sip:demo.809@x.x.x.x;rinstance=b0f41511ec723238>
Contact: <sip:asterisk@x.x.x.x:5061;transport=TLS>
Call-ID: 2b044970-d836-4ff9-b743-b4f59f960d76
CSeq: 11750 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
P-Asserted-Identity: "Malcolm Reynolds" <sip:800@172.30.1.69>
Remote-Party-ID: "Malcolm Reynolds" <sip:800@172.30.1.69>;party=calling;privacy=off;screen=no
Max-Forwards: 70
User-Agent: Asterisk 16.9.0
Content-Type: application/sdp
Content-Length:   447

v=0
o=- 671933868 671933868 IN IP4 x.x.x.x
s=Asterisk
c=IN IP4 x.x.x.x
t=0 0
m=audio 16090 RTP/AVP 9 107 0 18 101
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:BO+LxGGFz+HgY7XcnxJYjIbsnSICFQNMg4kZyzmF
a=rtpmap:9 G722/8000
a=rtpmap:107 opus/48000/2
a=fmtp:107 useinbandfec=1
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:20
a=sendrecv

It might also be important to note my PJSIP configuration for the endpoints:

endpoint/media_encryption=sdes
endpoint/media_encryption_optimistic=yes

Wondering if media_encryption_optimistic is the issue, testing …

Score!

m=audio 50874 RTP/SAVP 9 101
m=audio 17572 RTP/SAVP 9 107 0 18 101

So now very confused over what media_encryption_optimistic actually does. I incorrectly assumed it meant try to negotiate SRTP and fall back if it can’t, this way someone with devices of various capabilities, for example one that doesn’t support TLS, can use the same registration.

That is what it means, but it requires the remote side to support it. It’s done by offering a normal audio stream, but including crypto information. Clients that support it will then enable encryption if supported, and clients that don’t will ignore it. If a client doesn’t support it and requires encryption, then it will fail.

1 Like

Ahh! I see now …

m=audio 16090 RTP/AVP 9 107 0 18 101
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:BO+LxGGFz+HgY7XcnxJYjIbsnSICFQNMg4kZyzmF

Thanks for the help, again, as always :slight_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.