Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09

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

Please, let me insist even a bit more on it:



2013/7/5 Iñaki Baz Castillo <[e-mail]>:
> Any TCP SIP UA is capable of listening for incoming connections but
> that does not mean that the proxy should not R-R. If the UA is behind
> NAT then RFC 5626 must be used (I avoid here proprietary similar
> mechanisms), and RFC 5626 *alreay* mandates R-R for such a mechanism
> to work. If GRUU is also in use then the proxy can decide not to R-R
> (not needed since incoming requests will arrive via the registration
> path which will of course include Outbound stuff).



a) If the SIP-WS UA runs in a browser then the website developer can
make usage of RFC 5626 so the UA *requests* Outbound usage to its
proxy.

b) If the SIP-WS UA runs in a desktop and is both a SIP WS Client and
SIP WS Server (and let's assume it has public IP) then it can avoid
requesting Outbound to the proxy. If the proxy does R-R it is because
the proxy wants to be in the patch of the dialog (local policy) and
not because it is required for the dialog to work.


Of course, in case b), if the peer does not speak WS and the proxy
does not R-R here we have a problem, but this is *exactly* the same
problem as if the caller was a UA using SCTP in its Contact URI. So
again, this is about local policy in the proxy whether to decide it
does R-R or not.

I don't find "Record-Route" word in RFC 4168 so I expect there should
be no "MUST" keyword about Record-Route in
draft-ietc-sipcore-sip-websocket. Let me know if I'm wrong.



Summarizing:

- This is not an issue introduced by this new WS transport.
- The issue is not new.
- There are already standard mechanism to make it to work (the
*client* can request them to the proxy !).
- I see no reason at all to mandate nothing in the sip-ws draft about this.
- Guidelines section in the draft already covers it in an informative way.



Hope I am right.

Best regards.



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