Re: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-00 (previously draft-ibc-rtcweb-sip-websocket-00)

[Iñaki Baz Castillo <[e-mail]>]

2011/12/5 Gilad Shaham <[e-mail]>:
>> Take into account that when a JavaScript code (running in a web
>> browser) open a WebSocket connection given a WS URI with domain, the
>> JavaScript code is not aware of the resulting IP nor the IP family
>> (IPv4 or IPv6). So IMHO using a IP address in Via/Contact is a bad
>> idea.
>
> I agree the later messages should not try to resolve an IP address, but I
> still don't see why it's that much different to have an invalid IP rather
> than an invalid domain. The advantage of an IP is that you are sure no one
> would try to resolve it, although it's true you would have no idea whether
> to place IPv4 or IPv6 in there and you'd just have to choose one of them. So
> it's not that I think one is better than the other, but some may ask for
> this option from compatibility point of view - I assume some implementations
> were never built with domain name in Contact header or in Via header in
> mind, although this is perfectly legitimate to do so. Anyway, if you
> strongly object to IP, domain is good too.

Hi, I strongly expect that any SIP implementation must accept a
hostname in the Via sentby-host, if not the problem is not here :)

And about a hostname in the Contact URI, GRUU already does it so if we
enforce GRUU we do require that remote peers must allow a Contact URI
with hostname. If not, the problem is not here again :)

IMHO "domain.invalid" is the best choice, as it is an "standard"
unresolvable domain according to RFC 2606 section 2:

      ".invalid" is intended for use in online construction of domain
      names that are sure to be invalid and which it is obvious at a
      glance are invalid.



>> Assuming that a domain is used, I think that which one to set should
>> not be normative, for the following reasons:
>>
>> 1) If Outbound is being used (and it's a MUST for these kind of SIP
>> endpoints) the host in Via and Contact does not matter (for
>> registration or dialogs).
>>
>> 2) If GRUU is used, the host in Contact would be a globally routable
>> URI. If GRUU is not used, then there is no way  at all for SIP REFER
>> mechanism to work (since a SIP WebSocket client can only be contacted
>> via the WS connection it has opened with the WS server). So the domain
>> in Contact does not matter (with GRUU it will always work, without
>> GRUU it will never work).
>>
>>
> Seems right. So we are saying a UA MAY include an invalid host part in the
> registration Contact header and any request top Via header. The UA MUST
> support Outbound and SHOULD (or MUST) support GRUU.
> Actually, there is good reason to consider mandating GRUU for this scenario.
> The reason is that suppose 2 different users named Alice register to 2
> different AORs. Both Alice users go through the same proxy (named P1) that
> supports websockets and it forwards the requests to the different
> registrars. When an incoming request to one of the Alices comes in, a proxy
> will forward the request to alice@<invalid host> through P1, but P1 cannot
> distinguish the two and they are in fact different users. I also believe UAs
> should be encouraged to compare the instance id of incoming requests.

In the scenario you describe Outbound must take place (the registrar
can only send incoming requests to the users via their outbound SIP
EDGE proxy implementing WebSocket transport). So the Path header the
EDGE proxy adds to the REGISTER includes a flow token (RFC 5626),
probably in the URI username part.

When the registrar routes an incoming request to a registration
binding of one of those WS clients, such request will contain a Route
header with same value as the Path header during registration, and the
EDGE proxy will associate the flow token in such Route URI to the
corresponding WebSocket connection. This is, the Outbound EDGE proxy
does not inspect the request URI for incoming requets, but just the
Route URI and the Outbound flow token in it.

-- 
Iñaki Baz Castillo
<[e-mail]>