[Home]

Summary:ASTERISK-24330: Requirement for 'wss' value in Contact header transport parameter on inbound traffic violates RFC7118
Reporter:Marek Cervenka (cervajs)Labels:
Date Opened:2014-09-16 12:35:45Date Closed:2016-12-02 11:30:43.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/WebSocket Resources/res_http_websocket
Versions:11.12.0 Frequency of
Occurrence
Related
Issues:
is duplicated byASTERISK-25840 Asterisk 13.7.0 unable to send INVITEs to jsSIP (WebRTC) peer connected over WSS
is related toASTERISK-26796 res_pjsip_transport_websocket: Via header is 'WS' when it should be 'WSS'
Environment:Attachments:
Description:i'm trying make webrtc client with SIP.js library

i have working asterisk 11.12.0 wss configuration

when i REGISTER the header looks like

{noformat}
REGISTER sip:sip.example.com SIP/2.0
Via: SIP/2.0/WSS 192.0.2.136;branch=z9hG4bK7133687
Max-Forwards: 70
To: <sip:web_101_5416b222f0efa@sip.example.com>
From: <sip:web_101_5416b222f0efa@sip.example.com>;tag=qok8o8thta
Call-ID: 1np04l3k9bumr5aqbi6tpr
CSeq: 81 REGISTER
Contact: <sip:rlr4g88u@192.0.2.136;transport=ws>;reg-id=1;+sip.instance="<urn:uuid:f55544fa-c05d-468b-9c51-fd7a837864b5>";expires=600
Allow: ACK,CANCEL,BYE,OPTIONS,INFO,NOTIFY,INVITE
Supported: path,gruu,outbound
User-Agent: SIP.js/0.6.2
Content-Length: 0
{noformat}

the problem is in the contact line
{{Contact: <sip:rlr4g88u@192.0.2.136;transport=ws>;}}

it's correct - http://tools.ietf.org/html/rfc7118#section-5.2

but it's not working.
if i change the code in SIP.js to transport=wss then it works
Comments:By: Iñaki Baz Castillo (ibc) 2016-03-11 10:01:23.962-0600

;transport=wss and ;transport=tls do no exist, they are not defined in any RFC. Please Asterisk devs, fix this.
By: Chris Coleman (chris_espace) 2016-09-03 02:53:31.678-0500

Please do this simple fix.  Get websockets working properly.  So clients don't have to attempt any clunky workarounds that violate the RFC.
By: Matt Jordan (mjordan) 2016-11-28 13:28:53.635-0600

I actually think this bug occurred with chan_pjsip, and not with chan_sip (although in chan_sip, we do send {{WS}} instead of {{ws}} in the {{;transport=}} attribute). I should have a patch up on Gerrit to tweak both.
By: Matt Jordan (mjordan) 2016-11-28 13:43:33.185-0600

Patch for 13/14/master up on Gerrit, tested with JSSIP:

*{{chan_sip}}:*

{code}
JsSIP:Transport received text message:

SIP/2.0 200 OK
Via: SIP/2.0/WSS mv355e3cim2b.invalid;branch=z9hG4bK8985649;received=127.0.0.1
From: "webrtc" <sip:webrtc@127.0.0.1:8089>;tag=c406nnt75p
To: <sip:webrtc@127.0.0.1:8089>;tag=as34f4e40e
Call-ID: nke8scs73bopit8bp8f4r8
CSeq: 2 REGISTER
Server: Asterisk PBX GIT-13-13.4.0.0-1993-g845c5f4M
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Expires: 600
Contact: <sip:u3gd5q2g@mv355e3cim2b.invalid;transport=ws>;expires=600
Date: Mon, 28 Nov 2016 19:40:40 GMT
Content-Length: 0

{code}

*{{res_pjsip}}:*

{code}
JsSIP:Transport received text message:

SIP/2.0 200 OK
Via: SIP/2.0/WSS cg6elanq9ev8.invalid;rport=37609;received=127.0.0.1;branch=z9hG4bK5252818
Call-ID: od04q3nal4ppiqij2n86jq
From: "webrtc" <sip:webrtc@127.0.0.1>;tag=u7uca7br4t
To: <sip:webrtc@127.0.0.1>;tag=z9hG4bK5252818
CSeq: 2 REGISTER
Date: Mon, 28 Nov 2016 19:42:18 GMT
Contact: <sip:htqr4nmd@127.0.0.1:37609;transport=ws>;expires=599
Expires: 600
Server: Asterisk PBX GIT-13-13.4.0.0-1993-g845c5f4M
Content-Length:  0

{code}
By: Friendly Automation (friendly-automation) 2016-12-02 11:30:44.641-0600

Change 4509 merged by Joshua Colp:
res_pjsip/chan_sip: Advertise 'ws' in the SIP URI transport parameter

[https://gerrit.asterisk.org/4509|https://gerrit.asterisk.org/4509]
By: Friendly Automation (friendly-automation) 2016-12-02 12:19:03.849-0600

Change 4510 merged by Joshua Colp:
res_pjsip/chan_sip: Advertise 'ws' in the SIP URI transport parameter

[https://gerrit.asterisk.org/4510|https://gerrit.asterisk.org/4510]
By: Friendly Automation (friendly-automation) 2016-12-02 12:28:26.574-0600

Change 4511 merged by Joshua Colp:
res_pjsip/chan_sip: Advertise 'ws' in the SIP URI transport parameter

[https://gerrit.asterisk.org/4511|https://gerrit.asterisk.org/4511]
By: Jørgen H (jorgen) 2017-02-16 05:57:22.750-0600

This commit breaks tls-based websocket (wss) suport causing error messages like:
ERROR[48671]: res_pjsip.c:3616 endpt_send_request: Error 171060 'Unsupported transport (PJSIP_EUNSUPTRANSPORT)' sending OPTIONS request to endpoint xxx
Asterisk 14.3.0 with pjsip 2.6.0


FYI: My sipjs (0.7.5) works fine without modifications with wss://
By: Iñaki Baz Castillo (ibc) 2017-02-16 06:01:47.925-0600

That's a bug in PJSIP. As clearly explained above, ";transport=wss" does not exist.
By: Joshua C. Colp (jcolp) 2017-02-16 06:04:48.863-0600

This issue was fixed, and I have asked for an actual log on ASTERISK-26796 to see the signaling being done for the registration.
By: Joshua C. Colp (jcolp) 2017-02-16 06:09:18.208-0600

Actually it looks like we did it too much, the Via is using WS instead of WSS so the patch filed is correct.
By: Iñaki Baz Castillo (ibc) 2017-02-16 06:11:57.871-0600

I'm not tracking the issue in detial, but if you mean that Asterisk is setting Via WS instead of Via WSS when sending a SIP request over a secure WebSocket connection, that's indeed wrong.
By: Joshua C. Colp (jcolp) 2017-02-16 06:13:34.444-0600

[~ibc] That is indeed it and the patch from [~jorgen] fixes it so I've cherry picked it to the appropriate places. After that goes in we'll comply.
By: Jørgen H (jorgen) 2017-02-16 06:24:00.160-0600

Although it works with my patch, It might not be correct according to rfc if the contact-header should contain ws and not wss. Anyone know?

With my patch, asterisk sends:

<--- Transmitting SIP response (410 bytes) to WSS:1.2.3.49428 --->
SIP/2.0 200 OK
Via: SIP/2.0/WSS phik34tfvglg.invalid;rport=9428;received=1.2.3.4;branch=z9hG4bK1222842
Call-ID: 5t8m0qtd1mf8pgpsnvgopa
From: <sip:XX>;tag=md844frjls
To: <sip:XX>;tag=z9hG4bK1222842
CSeq: 82 REGISTER
Date: Thu, 16 Feb 2017 12:09:41 GMT
Contact: <sip:jg4f4clc@1.2.3.4:9428;transport=WSS>;expires=599
Content-Length:  0

By: Iñaki Baz Castillo (ibc) 2017-02-16 06:26:13.595-0600

That's incorrect. A SIP URI (and that includes the one in the Request-URI or the one in the Contact header) can never have ";transport=wss".
By: Joshua C. Colp (jcolp) 2017-02-16 06:35:56.288-0600

Gah PJSIP. Interestingly we change ensure it is ws but it must be changing it elsewhere.
By: Jørgen H (jorgen) 2017-02-16 09:35:29.050-0600

Given that you want to register the transport in asterisk as WS and not WSS,
then it seems like:

res/res_pjsip.c:2740

in sip_dialog_create_from()

type = pjsip_transport_get_type_from_name(&sip_uri->transport_param);

transport name is WS, so asterisk tries to get transport with name WS and receives the unsecure transport because it is first in the transport list.

Solution 1: Remove the registration of the non-TLS'ed websocket transport in asterisk making non-TLS websocket unsupported at all..
Solution 2: pjsip_transport_get_type_from_name must be changed to also check for flags
Solution 3: Keep the registration of the TLS-transport as WSS and not WS and perhaps change pjproject-2.6/pjsip/src/pjsip/sip_transport.c and the function pjsip_transport_get_type_name() to return WS instead of WSS in case of TLS-enabled websocket pjsip_transport_type_e (=10)


By: Jørgen H (jorgen) 2017-02-16 09:43:30.952-0600

Or perhaps solution 4:  Add a new field in the transport struct that defines what the value of transport=<value> in the contact-header should be.
Then the representation/protocol name of a transport doesn't necessarily need to match the name in the transport= header.