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

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 14 Jun 2013 09:59:03 +0200

Hi all,

Once  draft-ietf-sipcore-sip-websocket-09 has been submitted, and
after some comments in the WG, I consider that there are still the
following open issues (to be addressed in a new revision):

1) Remove "_This section is non-normative_" text at the top of
non-normative sections.

Those sections don't contain normative keywords (MUST, SHOULD) so they
are indeed non-normative. No need for such an statement.

2 Decide whether the draft updates 3261 or not.

After recent discussion in the WG my opinion is that if somebody wants
to build a SIP UDP and/or TCP device during 2013 year, he does not
need to read draft-ietf-sipcore-sip-websocket, and thus the draft does
not update RFC 3261.

The other point of view is that the draft makes implementation of both
UDP and TCP transports non mandatory if WS is implemented. This opens
the door to two solutions:

a) Stating that in the draft (as currently it does).

b) A new WG item for allowing other transports without requiring UDP/TCP.

In draft-ietf-sipcore-sip-websocket-09 we have tryed to address all
the other open issues reported by members of the WG after 08 was
published. I hope changes and additions in 09 satisfy their concerns.
Otherwise please let us know and we will address them in rev 10.

Thanks a lot to all.

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

---

From: "Parthasarathi R" <[email-masked]>
Date: Sun, 16 Jun 2013 22:06:30 +0530

Hi Inaki,

Open Item 2 comment: The current statement states that 

     " All SIP elements MUST implement at least one of the following:

      *  Both UDP and TCP transports.

      *  SIP WebSocket transport."

I could not understand how this update resolve the issue in the following scenario:

 SIP UA1 (WS only)----Proxy-----SIP UA2 (UDP/TCP)

Here, the dialog is established with contact details for SIP UA1 & SIP UA2 as follows:

1) contact: sip:[email-masked];transport=ws
2) contact: sip:[email-masked];transport=tcp

In case SIP UA2 wishes to send RE-INVITE towards SIP UA1, how does it possible now as per the current update in Sec 5.2.4 of draft-ietf-sipcore-sip-websocket-09.

Apart from this, I'm fine with stating in the draft or new draft wherein this draft is updated with new draft reference.

Thanks
Partha 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Iñaki Baz Castillo
> Sent: Friday, June 14, 2013 1:29 PM
> To: SIPCORE (Session Initiation Protocol Core) WG
> Subject: [sipcore] Open isues in draft-ietf-sipcore-sip-websocket-09
> 
> Hi all,
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 16 Jun 2013 23:14:58 +0200

> In case SIP UA2 wishes to send RE-INVITE towards SIP UA1, how does it possible now as per the current update in Sec 5.2.4 of draft-ietf-sipcore-sip-websocket-09.

Hi Parthasarathi, this subject was heavily discussed during the past
year. It's clear that in 99% or 100% of cases, a SIP WebSocket Client
(i.e. a browser) will not be able to receive incoming WS connections
(it is not a SIP WebSocket Server) and thus, the proxy in your flow
has to perform record-routing, a *standard* mechanism defined in RFC
3261 for making your scenario feasible.

IMHO it is not so hard to assume that when SIP over WebSocket devices
are present, the proxy they connect to must perform record-routing.
The same is true for clients behind NAT.

Regards.

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

---

From: "Parthasarathi R" <[email-masked]>
Date: Mon, 17 Jun 2013 23:10:32 +0530

Hi Inaki,

As you mentioned, "record-route" is the right solution and not documented in the draft as of now. My comment is to explicitly add the statement for clarity.

Thanks
Partha

> Sent: Monday, June 17, 2013 2:45 AM
> To: Parthasarathi R
> Cc: SIPCORE (Session Initiation Protocol Core) WG
> Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-
> 09
> 
> > In case SIP UA2 wishes to send RE-INVITE towards SIP UA1, how does it
> possible now as per the current update in Sec 5.2.4 of draft-ietf-
> sipcore-sip-websocket-09.
> 
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 17 Jun 2013 19:49:57 +0200

> As you mentioned, "record-route" is the right solution and not documented in the draft as of now. My comment is to explicitly add the statement for clarity.

The draft describes a SIP transport, not a network topology.

For clients behind NAT, RFC 5626 (Outbound) already describes a
mechanism and requirements for clients and proxies to properly work.
RFC 5626 can perfectly be applied to scenarios in which SIP-WebSocket
is present. So no need to duplicate all the information provided by
RFC 5626 in this draft.

Anyhow, the Appendix "Implementation Guidelines" already suggests
using Record-Route within the "SIP WebSocket Server Considerations"
subsection:

   The SIP Outbound extension [RFC5626] seems an appropriate solution
   for this scenario.  Therefore these SIP WebSocket Clients and the SIP
   registrar implement both the Outbound and Path [RFC3327] extensions,
   and the SIP proxy acts as an Outbound Edge Proxy (as defined in
   [RFC5626] section 3.4).

And of course RFC 5626 already states that a Outbound Edge Proxy must
do record-routing. I hope this draft won't become a "general tutorial
for SIP and NAT".

Regards.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 17 Jun 2013 20:51:23 +0200

> In case SIP UA2 wishes to send RE-INVITE towards SIP UA1, how does it possible now as per the current update in Sec 5.2.4 of draft-ietf-sipcore-sip-websocket-09.

Hi Parthasarathi,

  SIP UA1 (SCTP/UDP/TCP)----Proxy-----SIP UA2 (UDP/TCP)

Here, the dialog is established with contact details for SIP UA1 & SIP
UA2 as follows:

1) contact: sip:[email-masked];transport=sctp
2) contact: sip:[email-masked];transport=tcp

In case SIP UA2 wishes to send RE-INVITE towards SIP UA1, please let
me know in which section of RFC 4168 (SIP STCP) it is stated that the
proxy must use Record-Route for the initial INVITE for this scenario
to work.

Regards.

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

---

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 18 Jun 2013 22:22:32 +0530

Hi Inaki,

I agree with you that RFC 4168 (SIP SCTP) does not explain the contact header usage. But it does not meant that it is the best practice. My comments is based on the later RFC namely RFC 5630 (The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)) and look into the draft for the explanation and Normative statements around contact header w.r.t SIPS URI. 

The current text in the draft is clear to explain the usage of contact header. It will confuse in case anybody implement by just looking into this draft. I think that it is required for SIP over WebSocket to explain the usage of contact header field with example and normative statement. 

Thanks
Partha

> Sent: Tuesday, June 18, 2013 12:21 AM
> To: Parthasarathi R

---

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 18 Jun 2013 22:24:25 +0530

Hi Inaki,

<snip> I hope this draft won't become a "general tutorial for SIP and NAT". </snip>

My reported "contact" header problem is related to SIP routing issue and not related to NAT.

Thanks
Partha

> Sent: Monday, June 17, 2013 11:20 PM
> To: Parthasarathi R
> > As you mentioned, "record-route" is the right solution and not
> documented in the draft as of now. My comment is to explicitly add the
> statement for clarity.
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 19 Jun 2013 00:56:07 +0200

2013/6/18 Parthasarathi R <[email-masked]>:
> I think that it is required for SIP over WebSocket to explain the usage of contact header field with example and normative statement.

Honestly I have no idea of what you mean.
draft-ietf-sipcore-sip-websocket must explain how to use the SIP
Contact header?

Sorry but I don't understand your concern. Could you please describe it again?

Thanks a lot.

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

---

From: "Avasarala, Ranjit (NSN - IN/Bangalore)" <[email-masked]>
Date: Wed, 19 Jun 2013 05:53:41 +0000

Hi Inaki

Usually contact header contains the address on which the callee can reach caller. But when a SIP message is sent in websocket, what is the use of putting contact header? 

Should Contact header contain browser's address, since SIP UA is anyway part of browser and the callee cannot anyway reach SIP UA directly.

So I think there needs to be text in the draft explaining this behavior. 

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Iñaki Baz Castillo
Sent: Wednesday, June 19, 2013 4:26 AM
To: Parthasarathi R
Cc: SIPCORE (Session Initiation Protocol Core) WG
Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09

Thanks a lot.

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 20 Jun 2013 01:08:15 +0530

Hi Inaki,

Just adding to Ranjit mentioned. The text similar to the following has to be added. "Record-route header MUST be added by SIP WebSocket Server in case WebSocket is the only supported SIP transport between SIP WebSocket client & server and SIP WebSocket server acts as SIP proxy" 

Thanks
Partha

> Behalf Of Avasarala, Ranjit (NSN - IN/Bangalore)
> Sent: Wednesday, June 19, 2013 11:24 AM
> To: ext Iñaki Baz Castillo; Parthasarathi R
> Usually contact header contains the address on which the callee can
> reach caller. But when a SIP message is sent in websocket, what is the
> use of putting contact header?
> 
> Should Contact header contain browser's address, since SIP UA is anyway
> part of browser and the callee cannot anyway reach SIP UA directly.
> 
> Behalf Of ext Iñaki Baz Castillo
> > I think that it is required for SIP over WebSocket to explain the
> usage of contact header field with example and normative statement.
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 20 Jun 2013 00:05:06 +0200

> Just adding to Ranjit mentioned. The text similar to the following has to be added. "Record-route header MUST be added by SIP WebSocket Server in case WebSocket is the only supported SIP transport…

That is just true in case the client is a web browser (a SIP WS Client
but not a SIP WS Server so it can not receive incoming WS
connections). So the text would be:

"Record-route header MUST be added by SIP WebSocket Server in case
WebSocket is the only supported SIP transport between client and
server, the server acts as SIP proxy, and the client is a SIP
WebSocket Client (but not a SIP WebSocket Server so it can not accept
incoming WebSocket connections)."

Does it sound ok?

If the WG agrees with this I will add such an statement in the draft.
BTW, in which section?

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 20 Jun 2013 00:09:23 +0200

> Usually contact header contains the address on which the callee can reach caller. But when a SIP message is sent in websocket, what is the use of putting contact header?

As said in my previous mail, that is just in case the client is a SIP
WebSocket Client but not a SIP WebSocket Server. Anyhow, the Contact
header MUST be added anyway as it can contain parameters other than
just the UA's address and transport. And it must be added in an INVITE
so the remote peer can create the "dialog target" and use its URI
value as Request-URI for in-dialog requests.

Those are SIP rules, they must be respected.

> Should Contact header contain browser's address, since SIP UA is anyway part of browser and the callee cannot anyway reach SIP UA directly.

Please take a look to the appendix B.1 of the draft:

B.1.  SIP WebSocket Client Considerations

   The JavaScript stack in web browsers does not have the ability to
   discover the local transport address used for originating WebSocket
   connections.  A SIP WebSocket client running in such an environment
   can construct a domain name consisting of a random token followed by
   the ".invalid" top-level domain name, as stated in [RFC2606], and
   uses it within its Via and Contact headers.

      The Contact URI provided by SIP UAs requesting (and receiving)
      Outbound support is not used for routing requests to those UAs,
      thus it is safe to set a random domain in the Contact URI
      hostport.

Clear? :)

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Jun 2013 11:57:51 -0400

> incoming WebSocket connections)."

How will the server know that the client is not capable of being a 
WebSocket Server?

I guess in many cases it might be able to know that because the client 
is a browser being controlled by scripting from the server. But in other 
cases ISTM that it just won't know.

	Thanks,
	Paul

---

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 25 Jun 2013 06:11:35 +0530

Paul,

I think that we are talking about two problems here

1) SIP routing issue because of SIP WebSocket Client has only WebSocket as a transport (Browser scenario)
	a) Solution: Record-route header has to be added by SIP WebSocket Server.
 
2) How will SIP WebSocket Server know that SIP WebSocket client supports only SIP WebSocket as a transport? (Non-browser scenario)
	a) AFAIK, there is no other environment other than browser has the limitation of not supporting UDP & TCP. In case any other environment exists, Please let me know.
	b) The beauty of RFC 3261 is that there is no need to negotiate the set of "SIP" transport protocol as it mandates for UDP, TCP. I agree that it is an open item how to represent the list of transport supported by a SIP UA in case of supporting WebSocket only transport scenario. But I'm not sure whether this WG is interested in solving this issue. We need to here from more folks and its relevant usecases.

Thanks
Partha

> Behalf Of Paul Kyzivat
> Sent: Thursday, June 20, 2013 9:28 PM
> To: [email-masked]
> >> Just adding to Ranjit mentioned. The text similar to the following
> has to be added. "Record-route header MUST be added by SIP WebSocket
> Server in case WebSocket is the only supported SIP transport between
> SIP WebSocket client & server and SIP WebSocket server acts as SIP
> proxy"
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Jun 2013 11:13:54 -0400

Partha,

You addressed your reply to me. But I just posed the question, not the 
answer. I'm waiting for those who proposed the language to clarify it.

The real issue is: how can a websocket server ever decide that it 
*doesn't* need to R-R?

	Thanks,
	Paul

---

From: Michael Procter <[email-masked]>
Date: Thu, 27 Jun 2013 14:57:07 +0100

On 26 June 2013 16:13, Paul Kyzivat <[email-masked]> wrote:
> The real issue is: how can a websocket server ever decide that it *doesn't*
> need to R-R?

The websocket server shouldn't R-R a request if it is a non-dialog-establishing
request (e.g. REGISTER, PUBLISH) or an in-dialog non-target-refresh request
(e.g. INFO).  It is probably fair to say that INVITEs should be, but
that specific
case is already covered by RFC5626, as Iñaki has pointed out.

Regards,

Michael

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Jun 2013 10:57:52 -0400

> case is already covered by RFC5626, as Iñaki has pointed out.

You miss my point. The cases you describe above are cases where it never 
makes sense to R-R. The only place the question is relevant is on dialog 
establishing requests.

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.

I think Iñaki said he was on vacation for a couple of weeks, so we may 
not hear from him on this soon.

	Thanks,
	Paul

---

From: Michael Procter <[email-masked]>
Date: Thu, 27 Jun 2013 16:32:42 +0100

> makes sense to R-R. The only place the question is relevant is on dialog

Apologies.  Partha seemed to be edging towards a more general
statement than simply for dialog establishing requests and your
question was similarly unrestricted.

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

That sounds like a step forward.  I think this problem, specifically
for the non-browser scenario, has overlaps with the scenario RFC5923
addresses.  Maybe the 'alias' via parameter would also be a clue that
R-R is not necessarily required.

Regards,

Michael

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 27 Jun 2013 21:39:21 +0530

Paul,

Thanks for the clarification. Let us wait for the clarification on R-R issue.

Thanks
Partha

> Sent: Wednesday, June 26, 2013 8:44 PM
> To: Parthasarathi R
> Cc: [email-masked]
> > 1) SIP routing issue because of SIP WebSocket Client has only
> WebSocket as a transport (Browser scenario)
> > 2) How will SIP WebSocket Server know that SIP WebSocket client
> supports only SIP WebSocket as a transport? (Non-browser scenario)
> > 	a) AFAIK, there is no other environment other than browser has
> the limitation of not supporting UDP & TCP. In case any other
> environment exists, Please let me know.
> > 	b) The beauty of RFC 3261 is that there is no need to negotiate
> the set of "SIP" transport protocol as it mandates for UDP, TCP. I
> agree that it is an open item how to represent the list of transport
> supported by a SIP UA in case of supporting WebSocket only transport
> scenario. But I'm not sure whether this WG is interested in solving
> this issue. We need to here from more folks and its relevant usecases.
> >
> > Thanks
> > Partha
> >