Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-sip-websocket-06.txt

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 4 Mar 2013 23:21:23 +0100

Hi Robert, please read below:

2013/2/25 Robert Sparks <[email-masked]>:
> Hi Iñaki (and SIPCORE participants):
>
> One thing from my initial review that I don't think I've seen a response to
> (nor do I see how the draft revision addressed it) -
> apologies if we had discussed this and I've forgotten:
>
>
>
> On 11/27/12 4:35 PM, Robert Sparks wrote:
>>
>> * Should there be some additional discussion of what an element should do if someone clicks on "sip:foo.example.com;transport=ws" or receives that in a contact in a 302 or in a Refer-To: header field? Taken to an extreme, what's a proxy that understands sip over websockets supposed to do if it gets a message containing Route header fields (think preloaded routes) where the next route value is for a transport=ws hop that a connection doesn't yet exist for?

I replied to this subject in a previous mail, let me write it again (I
will extend it a bit more now):

Typical WebSocket capable SIP proxies/servers won't be able to
establish outgoing WS connections and, ever less, typical SIP WS
clients (browsers and probably mobile apps) won't be able to receive
incoming WS connections. Thus a SIP proxy receiving a request with a
;ws preloaded Route would fail due to "unsupported transport" when
performing RFC 3263 rules, and the same for a UA that receives a 302
or a Refer-To pointing to a SIP URI with ;transport=ws.

Which is the best SIP response code for that kind of "error"? Well,
IMHO it does not exist so some existing proxies reply a custom 478
"Unsupported Transport" error when the request requires being routed
via an unsupported transport.

However I expect that SIP WebSocket clients should/will implement
Outbound and GRUU and will work in enviroments in which proxies and
registrars also implement Outbound and GRUU. Therefore the problem you
mention would not occur since both Outbound and GRUU avoid it. The SIP
WebSocket UA would provide a GRUU based Contact when establishing
dialogs and thus the remote peer would send a GRUU URI in the Refer-To
header.

If this is ok I have the revision 08 ready to be submitted (which
includes the new "SIP Transport Registry" as requested by the WG).

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Robert Sparks <[email-masked]>
Date: Mon, 04 Mar 2013 16:32:41 -0600

> will extend it a bit more now):
Thanks, and sorry I couldn't find your earlier response.
> includes the new "SIP Transport Registry" as requested by the WG).
Well, we've had some discussion here, but if I read what you're saying 
correctly,
you're not adding any discussion to the draft. I think there's value in 
doing so,
but we can keep talking about it during IETF LC.

Please submit the revision you have when submissions open Monday. Please 
be sure to address Keith's
concern: "The IANA considerations for the new registry needs to indicate 
it is grouped with the other SIP registries."
if you haven't already. What he's asking for is that we make an 
adjustment like this one:
OLD:
This document adds a new registry, "SIP Transport".
NEW:
This document adds a new registry, "SIP Transport" to the "Session 
Initiation Protocol (SIP) Parameters" registry page.

Thanks,

RjS

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 5 Mar 2013 00:08:04 +0100

> but we can keep talking about it during IETF LC.

I think that the same issue would occur in other cases as when a UA
establishes a dialog using SCTP as Contact URI transport. The remote
could use such a Contact into a Refer-To or 302 and same problem would
occur if the destination does not support SCTP transport.

Using an Outbound proxy (so hopefully RFC 5626) and GRUU mitigates
this problem. Even more, IMHO both Outbound and GRUU are the required
and standarized solution for all those scenarios which cover more than
just the new WS transport defined in the draft.

> Please submit the revision you have when submissions open Monday. Please be
> sure to address Keith's
> concern: "The IANA considerations for the new registry needs to indicate it
> is grouped with the other SIP registries."
> if you haven't already. What he's asking for is that we make an adjustment
> like this one:
> OLD:
>

Thanks for pointing it.

So I will submit the new revision 08 on Monday.

Thanks a lot. Best regards.

-- 
Iñaki Baz Castillo
<[email-masked]>