Why Does SIP.js use random a sip uri?

[michael...@gmail.com]

I am curious why the SIP URIs used for things like Register look like this:

<sip:0e7m...@192.0.2.198;transport=ws>

or

<sip:6gjl...@ec2c66jsa0ei.invalid;transport=ws>

The user could be parsed from the SIP uri passed to SIP.UA and the host could be set to the local ip of the client or the client's external IP if it is known.

[James Criscuolo]

Hi Michael,

  SIP.js follows (and was built around) the SIP over Websockets RFC, which introduces these type of URIs. Is there some reason you are looking for this information in particular? It is generally somewhere else in your message headers, such as the to or from field.

James

On Monday, June 20, 2016 at 6:08:24 PM UTC-4, michael...@gmail.com wrote:

I am curious why the SIP URIs used for things like Register look like this:

<sip:0e7m...@192.0.2.198;transport=ws>

or

<sip:6gjlmali@ec2c66jsa0ei.invalid;transport=ws>

[Michael Cargile]

Really was just curious. I was troubleshooting an issue with my WebRTC phone I built with SIP.js and saw that. Thought it was really strange and that I might have done something wrong. Perhaps I had not initialized some variable and SIP.js was filling it in with garbage. I then spent an hour looking through the SIP.js code and realized it was intentional. Glad to see it is part of the RFC.

That said the RFC you linked to shows alice@df7jal23ls0d.invalid as an example so putting the username there will not break the RFC and would be less confusing than 0e7mjlnm and the like.

I also noticed that the RFC says this:

Since the JavaScript stack in a browser has no way to
determine the local address from which the WebSocket connection was
made, this implementation uses a random ".invalid" domain name for
the Via header "sent-by" parameter and for the hostport of the URI in
the Contact header (see Appendix B.1).

but that is actually not true anymore. With WebRTC and STUN you can easily get the local IP of the client as demonstrated here http://net.ipcalf.com/ and here https://diafygi.github.io/webrtc-ips/. I will admit that it is a bit creepy that you can do this without any kind of log of it happening and no way of blocking it, but that is a browser security issue (discussed here https://bugzilla.mozilla.org/show_bug.cgi?id=959893 for FF) not a WebRTC issue. Also Appendix B.1 says: "A SIP WebSocket Client running in such an environment CAN construct a domain name consisting of a random token followed by the ".invalid" top-level domain name...." The CAN here suggests to me that if there is a better way to create this URI such as getting the IP from STUN it does not break the RFC to do so. Using the local ip would fix issues cause by servers not supporting these randomtoken.invalid domain names which makes the "hackIpInContact" option necessary.

I would be happy to add a toggleable option to the code to implement this if I knew there was a good chance it would be accepted. I would probably also put in a mechanism to detect if the STUN call fails and fall back to the randomtoken.invalid. That way if support for blocking the STUN calls gets added it will not completely break things.

Thoughts?

On Tue, Jun 21, 2016 at 9:41 AM, James Criscuolo <ja...@onsip.com> wrote:

Hi Michael,

  SIP.js follows (and was built around) the SIP over Websockets RFC, which introduces these type of URIs. Is there some reason you are looking for this information in particular? It is generally somewhere else in your message headers, such as the to or from field.

James

On Monday, June 20, 2016 at 6:08:24 PM UTC-4, michael...@gmail.com wrote:

I am curious why the SIP URIs used for things like Register look like this:

<sip:0e7m...@192.0.2.198;transport=ws>

or

<sip:6gjl...@ec2c66jsa0ei.invalid;transport=ws>

[Eric Green]

I would be alright with this being a configurable option on the UA (opt-in) with the default behavior being the current method of .invalid. My main concern would be browsers blocking or breaking this in the future because of the security implications, but if it fails back to .invalid it should be fine. Our documentation will just have to reflect as much. My last question is how would you choose which address to use? (public vs private, ipv4 vs ipv6). 

-Eric Green

<sip:6gjlmali@ec2c66jsa0ei.invalid;transport=ws>

[Eric Tamme]

FWIW - many SIP proxies that support websockets utilize the flow token as a mechanism of, well identifying the flow.  I'm not certain how well, or if it would work at all if you changed the flow token to simply a user@ip.  Do you have any known implementations that would support this Michael?

-Eric

--
You received this message because you are subscribed to the Google Groups "SIP.js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sip_js+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sip_js/c83e5bde-bfa0-4fbc-9fff-b744301f27fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
sip:eric....@onsip.com

[Michael Cargile]

Honestly have not delved that deep into any WebRTC proxy code. I would definitely test this once it was implemented before expecting it to get merged in.

I assumed though that they would use the same mechanism as standard SIP proxy for keeping track of things such as Call-ID. Among other things the current implementation has that hackIpInContact option that sets the IP to 192.0.2.* instead of randomtoken.invalid. As this itself is an IP I believe using the actual IP should work without issue on any server that the hackIpInContact works on already.

<sip:6gjl...@ec2c66jsa0ei.invalid;transport=ws>

The user could be parsed from the SIP uri passed to SIP.UA and the host could be set to the local ip of the client or the client's external IP if it is known.

--
You received this message because you are subscribed to the Google Groups "SIP.js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sip_js+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sip_js/c83e5bde-bfa0-4fbc-9fff-b744301f27fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
sip:eric....@onsip.com

--
You received this message because you are subscribed to a topic in the Google Groups "SIP.js" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sip_js/hd-GBOFgKsE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sip_js+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sip_js/576AB0CB.4020301%40onsip.com.

[Michael Cargile]

I would make the option accept multiple values: token, pub4, priv4, pub6, priv6

token = randomtoken.invalid (default)

pub4 = IPv4 Public

priv4 = IPv4 Private

pub6 = IPv6 Public
priv6 = IPv6 Private

<sip:6gjl...@ec2c66jsa0ei.invalid;transport=ws>

[Eric Green]

Sounds good. We would be inclined to accept a PR like this if you submitted. We would be even more inclined to accept it if it also contained working tests ;)

Thanks,

-Eric Green

<sip:6gjlmali@ec2c66jsa0ei.invalid;transport=ws>