sips schema not in contact url when registering over WSS

[anthmFS]

When JsSIP registers to a remote endpoint over a secure web socket wss, the contact addr does not indicate the sips url scheme, instead it has sip. So when trying to call that registered user its using the wrong scheme so it cannot properly find the socket connection.

I have added code on my server side to detect the WSS transport in the via and rewrite the contact to sips but it probably should be offered by the client too. The RFC draft also shows the usage of the sip schema in the contact on a register as the proper behavior but it probably should be modified on the next revision.

Despite the fact that its a idle socket connection that does not close, it still requires the knowledge of the proper schema on our sip stack to locate the cached socket connection to send calls back to the browser. There is a hash made from the combo of schema ip and rport.

[ibc]

Hi @freeswitch, when using RFC 5626 (Outbound) there is no need for the client to use SIPS in conjunction with a secure transport. This is explained in RFC 5630 section 3.1.3. Your server should not lookup the socket connection based on the registered Contact URI (user, IP, port, transport...) but based on the Outbound Flow Token as specified in RFC 5626.

So IMHO the approach in your server (detect the WSS transport in the via and rewrite the contact to SIPS) is wrong. And the draft is correct. This subject has been extensively discussed in sip-implementors and SIPCORE WG maillists.

BTW we have decided to ignore SIPS mechanism in JsSIP. SIPS was a bad idea, something that provides NO real security but just complexity that nobody knows how exactly to implement. Please check mail threads in those maillists about this topic.

I insist: your server SIP-WS implementation should not expect SIPS in a TLS-TCP or WSS connection. That's not a SIP requirement at all. JsSIP is an RFC 5626 "Outbound" client so the proxy/server it connects too should allow RFC 5626 usage.

[ibc]

In order not to let open issues I will close this one now. I promise that the arguments in my previous comments are right (and highly explained and documented in maillists and drafts/RFCs).

[saghul]

While you are right, let me play devils advocate :-) Is there any harm done if JsSIP would use sips in the contact?

[ibc]

Yes, the harm is the extra time it requires to implement an unuseful and disastrous mechanism ;)

[anthmFS]

I spent about an hour deciding if I was going to bother filing this. I run a large project and ultimately I decided the right thing to do was to file it so my input was recorded.

The continued pedantic pursuit of conceived interpretations of specs are the undoing of most protocols.
It says in your RFC draft that you must use sips when you are using WSS, its lame, I agree. So take that out and allow a separate wss transport. Do something besides dig the hole deeper like every other RFC related to SIP.

[ibc]

The draft does not say that "you must use SIPS when you are using WSS". Instead it says that "you must use WSS when you are using SIPS". From section 9.2:

The SIPS scheme in a SIP URI dictates that the entire request path to
the target be secure.  If such a path includes a WebSocket connection
it MUST be a secure WebSocket connection.

So let me know please: is it so crucial SIPS for your project/application? could I know why? nobody in the world wants SIPS, it is badly designed and provides nothing but just interoperability problems. And in the context of SIP Outbound clients (RFC 5626), SIPS makes ever less sense (and JsSIP runs in that context).

OverSIP SIP proxy allows both SIP WS and SIP WSS connections, and does not need SIPS schema over WSS transport (same for TLS over TCP).

So, why to spent so big effort for implementing SIPS in JsSIP? If so, when SIPS is enabled JsSIP should check that all SIP URI's in received requests and responses use SIPS schema, and reject them otherwise... Unneeded complexity that IMHO provides nothing. SIPS mechanism should just be deleted from RFCs (sorry, I spent too much time studying and implementing SIPS in the past and I don't like remembering such a horrible experience...).

[ibc]

BTW: when JsSIP uses a WSS secure connection it should write WSS in the Via header, that's right, I will report it right now.

[ibc]

WSS in Via issue: #53

[anthmFS]

I if you hold the paper, I'll light the match and we can burn up any reference or documentation to sips. I agree its stupid and I wish they did not even conceive the idea.

In this case, my challenge is to determine, by looking at nothing but the contact, if its a secure or insecure socket connection because our sip stack [sofia-sip] separates the connected sockets by the schema that they are under, so even when you don't specify sips its still implied sips schema when you use a TLS connection because the code is written with a goal of compliance.

As I described, I decided to write my contact in the reg db with sips to work around the issue. The url dialed to call someone registered to a websocket is nearly irrelevant as the contact addr is nothing more than a way to find a connected socket since the browser cannot accept incoming connections besides from open connections. If this is going to be a bigger problem I am going to have to dig into the code of the stack we use to try to make it not factor the schema into the equation but since its a real thing i'd be breaking it more than fixing it if I change that particular code. Right now it works since I can use via to get the WSS.

[ibc]

Hi @freeswitch, let me comment inline:

our sip stack [sofia-sip] separates the connected sockets by the schema that they are under

AFAIK 99% (maybe the 100%) of existing SIP phones set SIP schema + ;transport=tls in the Contact when they connect via TLS-TCP. ;transport=tls does not exist in any RFC but that's another story...

What I mean is that I expect that your SIP stack also examines the ;transport param, and if it's "tls" then it assigns the connection into the "TLS-TCP sockets list", am I right?

so even when you don't specify sips its still implied sips schema when you use a TLS connection because the code is written with a goal of compliance.

Again, if Sofia determines that from the Contact URI it means that, in case of TLS-TCP transport, it requires the Contact to have SIPS schema or ;transport=tls, right?

As I described, I decided to write my contact in the reg db with sips to work around the issue.

So, assuming that the above I say is correct, why don't you simply rewrite the Contact transport param to "wss"? Of course, ;transport=wss is not defined in our draft, in the same way that using SIP over TLS involves a Contact URI with ;transport=tcp and using SIP over TLS-SCTP involves a Contact URI with ;transport=sctp.

Anyhow, if the SIP request (i.e. REGISTER) arrives to your server with a top Via with "WSS" transport (using "WSS" in Via is right, the same for "TLS" and "TLS-SCTP"), should not that be enough for your SIP stack?

[anthmFS]

Its enough for the sip stack but as I said it automatically stores the hash back to the socket also considering the scheme, so the WSS in the via puts it into the sips scheme. We have to do that because there is an imaginary wss scheme that must exist on the server end so you can tell it how to bind properly and also not use sips there for reasons already acknowledged.

I have found the compromise buy storing the wss in part of the contact that is not sent back to the client but still triggers the wss lookup. So I guess this will make everyone happy because it will find the right socket and it will still only say transport=ws in the invite.....

[ibc]

Great. But just one question: if JsSIP would properly set "WSS" into the Via when connecting over a secure WebSocket connection (#53), would that make your SIP stack happy without requiring Contact rewriting ("transport=ws" => "transport=wss")? If so, things will work automatically once JsSIP fixes #53.

[ibc]

BTW if JsSIP receives an incoming request with a Request-URI containing "transport=wss" (instead of "ws" as set by JsSIP in REGISTER's Contact), JsSIP will accept the request (it does not inspect the RURI transport param but just the username part).

[anthmFS]

Our sip stack already auto-fixed the VIA I think because I was already seeing a WSS in the via at the top of the stack. EIther that or its already right in your code. My solution in the end only involved modifying the proxy url that is stored with the contact telling the stack where to route the packet so it does not modify the real contact, it will be send to JsSIP with transport=ws even on secure per the draft. I used a technique we have for anti-nat so you can store the path uri in the contact which is stripped when a call is made using that contact and its decoded and applied as the destination addr. This is also used for proxy registrations with a path variable in it. This way it maps the contact to the scheme/ip/rport of the cached socket and its able to find it for outbound calls.

[anthmFS]

I currently have it working both ways without using either of the "hack" params defined in the configuration section.

[ibc]

My fault, issue #53 is invalid: JsSIP properly sets "WSS" in Via when under a WSS connection.