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

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

2013/6/27 Paul Kyzivat <[e-mail]>:
> The simple answer would be that websocket proxy handling a dialog
> establishing request should *always* R-R. But there has been an assertion
> that there may be some sip-websocket UACs that are also capable of being
> sip-websocket servers. In that case, it would be desirable for the proxy to
> *not* R-R, so that it won't be in the signaling path for the entire dialog.
> But how would the proxy know that it is safe to not R-R?
>
> One thing that comes to mind for me is that the UAC could decide whether or
> not to tag its contact URI with ";gr". If it were so tagged, then that says
> it is globally routable, so it would be safe for the proxy to bypass the
> R-R. If the contact isn't a gruu, then the proxy would decide that it must
> R-R.

Hi, let me show a similar example:

  alice --- (SCTP) --- Proxy --- (UDP) --- bob

- alice calls to bob with Contact SCTP URI.

- bob does not implement SCTP.

- if Proxy does not R-R then bob has no way to contact alice for
sending her in-dialog requests.

Now my question: how does the proxy know whether it must do R-R or not
in this scenario?

IMHO there is no reply for this question, and anyhow, this is not an
issue related to SIP-over-WS. So IMHO there is no need to address this
issue into the draft (instead it should be covered in some other work
like RFC 5626bis or RFC 5627bis). Am I wrong?

Whether the proxy does R-R or not if decided by local policy. It's
safe for a proxy to always add R-R in connections from clients (via
UDP, TCP, WS transports). And as Paul pointed out, the proxy could
decide not to add R-R in case the UA's Contact has ;gr so R-R is not
needed.



Please let me insist on it a bit more:

>  But there has been an assertion
> that there may be some sip-websocket UACs that are also capable of being
> sip-websocket servers. In that case, it would be desirable for the proxy to
> *not* R-R, so that it won't be in the signaling path for the entire dialog.
> But how would the proxy know that it is safe to not R-R?

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).


So honestly, I don't understand why draft-ietf-sipcore-sip-websocket
should address issues that are not different than when using other
transports, and that are already covered by other specifications.
Correct me if I'm wrong.


Best regards.


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