Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-03.txt

From: [email-masked]
Date: Fri, 07 Sep 2012 05:41:00 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF.

	Title           : The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)
	Author(s)       : Inaki Baz Castillo
                          Jose Luis Millan Villegas
                          Victor Pascual
	Filename        : draft-ietf-sipcore-sip-websocket-03.txt
	Pages           : 20
	Date            : 2012-09-07

Abstract:
   The WebSocket protocol enables two-way realtime communication between
   clients and servers.  This document specifies a new WebSocket sub-
   protocol as a reliable transport mechanism between SIP (Session
   Initiation Protocol) entities to enable usage of SIP in new
   scenarios.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-sipcore-sip-websocket-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-websocket-03

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: José Luis Millán <[email-masked]>
Date: Fri, 7 Sep 2012 15:27:20 +0200

Hi,

This is the summary of the change log:

* Removed Appendix B "HTTP Topology Hiding"

* Added "Via received parameter" section as an update to RFC3261

* Added "SIP transport implementation requirements" section as and
update to RFC3261

This modifications address the comments and feedback received on
draft-ibc-sipcore-sip-websocket-02

Regards.

2012/9/7  <[email-masked]>:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Victor Pascual Avila <[email-masked]>
Date: Wed, 12 Sep 2012 22:36:27 +0200

Could you please take a new look at the document (-03), and indicate
whether you are ok with the changes?

Thanks!
-Victor

---

From: Lishitao <[email-masked]>
Date: Thu, 13 Sep 2012 06:29:52 +0000

Hi
I get one question about how to use this sip-websocket protocol. 

If my browser has already establish a websocket connection, and has a phone call using it, and I want to initiate another call, can I use the same websocket connection, 
or I need to establish a new websocket connection, or using websocket multiplexing?

Regards
shitao

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of José Luis Millán
> Sent: Friday, September 07, 2012 9:27 PM
> To: SIPCORE (Session Initiation Protocol Core) WG
> Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-03.txt
> 
> Hi,
>

---

From: José Luis Millán <[email-masked]>
Date: Thu, 13 Sep 2012 12:10:35 +0200

Hi,

> or I need to establish a new websocket connection, or using websocket multiplexing?

The same rules for other connection oriented transports in SIP applies
to this one. You can use a persistent connection to send and receive
multiple even unrelated requests over the same connection.

Regards.

---

From: Lishitao <[email-masked]>
Date: Sat, 22 Sep 2012 01:59:45 +0000

Hi
Thanks for your relay. 

In section 8.1, the example for registration, it mentioned that it support outbound and GRUU, my another question is how does the SIP agent get the instance-ID?

Does it come from Javascript or by the browser? That every time when JS downloaded into the browser, it will assign a new instance-ID for the user, or wherever the user register from, the JS(or the browser) always assign the same instance-ID for the same user.

Regards
shitao 

> From: José Luis Millán [mailto:[email-masked]]
> Sent: Thursday, September 13, 2012 6:11 PM
> To: Lishitao
> Cc: SIPCORE (Session Initiation Protocol Core) WG
> > If my browser has already establish a websocket connection, and has a phone
> call using it, and I want to initiate another call, can I use the same websocket
> connection,
> >> >         Title           : The WebSocket Protocol as a Transport for
> the
> >> Session Initiation Protocol (SIP)

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 22 Sep 2012 17:09:08 +0200

> Does it come from Javascript or by the browser? That every time when JS downloaded into the browser, it will assign a new instance-ID for the user, or wherever the user register from, the JS(or the…

Since the instance-id must be unique per device, and here the device
is the web browser (or the mobile app or whatever) IMHO the instance
-id must be generated by the JS application the first time it is
executed, so it generates a random instance-id and stores it via
Cookie or via local storage of HTML5 (in the hard disk). IMHO that
would be a good approach.

Regards.

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

---

From: Lishitao <[email-masked]>
Date: Thu, 27 Sep 2012 06:23:50 +0000

> Of I?aki Baz Castillo
> Sent: Saturday, September 22, 2012 11:09 PM
> To: Lishitao
> Cc: SIPCORE (Session Initiation Protocol Core) WG; José Luis Millán
> > In section 8.1, the example for registration, it mentioned that it support
> outbound and GRUU, my another question is how does the SIP agent get the
> instance-ID?
> >
> > Does it come from Javascript or by the browser? That every time when JS
> downloaded into the browser, it will assign a new instance-ID for the user, or
> wherever the user register from, the JS(or the browser) always assign the
> same instance-ID for the same user.
> 

So ,if I open another browser on the same machine and try to register using the same SIP URI, it will get the same instance-ID, and also has to support multiple registration.
If I open a browser on another machine and try to register using the same SIP URI, it will get a different instance-ID, and register as a different user.
Right?
Regards
shitao

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Sep 2012 14:59:56 -0400

> If I open a browser on another machine and try to register using the same SIP URI, it will get a different instance-ID, and register as a different user.

shitao,

I think you bring up interesting issues that an implementer must take 
into account.

If you attempt to concurrently register instances from multiple windows 
on the same machine, it will be a problem if they use the same 
instanceID, unless they can coordinate and share a single registration. 
Assuming they can't share a single registration, some fallback must be 
used. E.g. the *first* instance could use a persistent instanceID saved 
locally, while subsequent instances might dynamically assign a temporary 
instanceID.

If you open browsers on multiple machines, using the same AOR, then they 
*should* be seen as independent instances, but may register as the same 
user. (That is what using the same AOR means.)

	Thanks,
	Paul (as individual)

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 29 Sep 2012 20:06:24 +0200

2012/9/28 Paul Kyzivat <[email-masked]>:
> If you attempt to concurrently register instances from multiple windows on
> the same machine, it will be a problem if they use the same instanceID,
> unless they can coordinate and share a single registration.

Hi Paul, there is a new draft for WebSocket that allows different
"clients" running in the same browser (i.e. using multiple tabs) to
share the same WebSocket connection to the same server by using
multiplexation:

http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-06

--------------------------------
    Abstract

   The WebSocket Protocol [RFC6455] requires a new transport connection
   for every WebSocket connection.  This presents a scalability problem
   when many clients connect to the same server, and is made worse by
   having multiple clients running in different tabs of the same user
   agent.  This extension provides a way for separate logical WebSocket
   connections to share an underlying transport connection.
---------------------------------

This WebSocket extension is transparent for the WebSocket sub-protocol
on top of the WS connection (i.e. "sip") so when this specification
becomes a standard there will be no problem in using it for SIP
WebSocket clients (of course the WebSocket server acting as a SIP
server/proxy must implement it).

Regards.

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