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

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 5 Jul 2013 11:27:02 +0200

2013/6/27 Paul Kyzivat <[email-masked]>:
> 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
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 5 Jul 2013 11:36:51 +0200

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

> 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
<[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Jul 2013 11:53:38 -0400

I don't claim to have the answer here, but the discussion is helpful.

The analogy to other transports doesn't hold wrt TCP/UDP because until 
now both TCP and UDP support was *required*. There is a better analogy 
to IPv4 vs. IPv6.

But in general all of these things end up being treated as examples or 
best practices rather than normative requirements. You make a good case 
for leaving it at that.

	Thanks,
	Paul

---

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 17 Jul 2013 22:42:39 +0530

Hi Inaki,

I have mentioned earlier (http://www.ietf.org/mail-archive/web/sipcore/current/msg05614.html) that the issue raised by me is related to SIP routing and you are mixing it with NAT & Firewall.

In case you wish to cover the issue in the holistic way, Please suggest the complete text.

I have disagreement for the statement that SIP over SCTP does not document those issue, so SIP over WebSocket will not document the same. 

Thanks
Partha

PS: I have work experience in SCTP transport with RR added by proxy to overcome this issue.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Iñaki Baz Castillo
> Sent: Friday, July 05, 2013 3:07 PM
> To: Paul Kyzivat
> Cc: SIPCORE (Session Initiation Protocol Core) WG
> Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-
> 09
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore