Skip to main content

Re: getInitiatingWebSession [Re: SIP over websocket draft.]

  • From: binod pg < >
  • To:
  • Subject: Re: getInitiatingWebSession [Re: SIP over websocket draft.]
  • Date: Wed, 20 Mar 2013 18:06:30 +0530
  • List-id: <jsr359-experts.sipservlet-spec.java.net>
  • Organization: Oracle Corporation

George,

Are you explaining an implementation issue here?

The low level connector that we talk here could very well be
the http protocol stack in the converged container.

You are not saying that the converged container MUST NOT
handle the sip/websocket requests. Are you?

thanks,
Binod.

On 3/20/2013 4:12 PM, George Vagenas wrote:
" type="cite">
Hi Keith,

I agree with your approach for a low level connector that will route requests to either the web container or to the sip container based on the URL and the Sec-WebSocket-Protocol header. 

Consider the case where a converged container is behind a web proxy that is able to handle websocket requests. 
In this topology, the proxy will accept a HTTP 1.1 request with "Upgrade: websocket" header in order to upgrade the connection and will pass the request to the appropriate host which lets say is the converged container, If the converged container cannot filter the request based on the Sec-WebSocket-Protocol header and direct it to the web or the sip container, then there is no way to establish a SIP WebSocket connection since this will be a request that came to the HTTP connector. 

A solution would be the proxy to check the Sec-WebSocket-Protocol header and proxy the request to the SIP WebSocket connector, that is to the sip container, but this will limit our options and doesn't sound as the best solution since we might not be able to control the proxy.

The issue sounds a lot like an implementation detail, but i think we should approach this as an issue of the spec. Since WebSocket will always use existing HTTP connections, we need to consider the case where a HTTP request with upgrade should be routed to the sip container, and specify this mechanism in the spec.

George

On Mon, Mar 18, 2013 at 10:28 PM, Lewis, Keith < " target="_blank"> > wrote:
Binod,

I have read the new version of the document.
Could you help me understand the scenario you envisage in 12.2.4

It says

The HttpSession on which the original handshake for the websocket happened can be accessed by SIP Servlets using getInitiatingWebSession method

The handshake uses a HTTP request and response but this does not mean that there is a HttpSession associated with this websocket connection. After receiving a new websocket connection with Sec-WebSocket-Protocol set to "sip" how will the SIP container be able to know which HttpSession to return from the call to getInitiatingWebSession()?

At the F2F we envisaged a low level "connector" function that would process http messages and direct them EITHER to ther web container OR the sip container depending on a combination of the URL and the Sec-WebSocket-Protocol header. A client that interacts with a Http servlet in that environment would need to make a new connection to interact with a SIP servlet. Have we changed our mind about that approach?

Keith


On Wed, Mar 13, 2013 at 3:46 PM, binod pg < " target="_blank"> > wrote:
I just modified the document with more usecases. I also did some refactoring of the APIs.
Please take a look. It is still work in progress. Sorry for typos etc.

The current converged appsession model is not suitable for websockets. In case of websockets,
the client open a persistent connecton. The persistent websocket connection would then receive
many SIP messages. The alternate solutions described below would require that many  sipsessions
belonging to different websocket connections in that http session over a long period of time gets
associated with one single application session.

In the websocket scenario, there is one http session, many sip sessions (and thus many sip application sessions).

Also, web development introduces mash up of services from different places. So, the
sip/websocket client, an application uses, might actually be written by a third party, which is included
as a JS library in the application. So, advanced SIP programming techniques may even be difficult for
the developer.

thanks,
Binod.

On 3/8/2013 7:32 AM, Lewis, Keith wrote:
Comments below

On Thu, Mar 7, 2013 at 9:18 AM, Binod < " target="_blank"> > wrote:
On Wednesday 06 March 2013 10:15 PM, Lewis, Keith wrote:
This sound difficult to implement and it is not clear that it is needed.
Isnt it simply the HTTP session of the HTTP request that did the protocol
upgrade? What is the implementation issue here?

The issue is described in the next paragraph. Web containers do not normally store the last received jsessionid for a connection - they do not need to since the jsessionid comes in every request. It would seem strange to require them to do so just in case the connection is switched to SIP.

The http sessions are accessed by via the jsessionid.
A web container expects to get the jsessionid cookie in every message and so would not normally have it stored.

We already have the method SipApplicationSession.getSession(id, Protocol.HTTP) which can locate a particular http session. The sessionId can be passed from the client in a SIP message.
But there can be multiple sip application sessions created because of
the SIP traffic in the websocket connection. Hope you are not saying
that the httpsession should be associated with all of them.

No I am saying that the existing session targetting mechanisms can be used ensure that the existing http session and a new sip session are both part of the same app session. (1) the http servlet can create an app session then use the encodeURI mehod to create a URI and pass it back to the client (2) the client can use this URI as the top route for an initial request sent to the SIP container and can also pass the jsessionid as a parameter (3) the container will create a new sip session which is part of the app session created earlier, if there is more than one http session in the app session the jsessionid can be used to find the relevant one.

There is probably something similar that can be done with app key targeting.

Using the app session means that it is not relevant whether the connection used by the client for the http request is the same as the one used for the SIP requests or a different one. In addition in a clustered environment where the websocket connection is terminated at a load balancer the use of session targeting will ensure that the sessions are on the same node of the cluster.

We already have mechanisms to allow a client to initiate both http and sip sessions to the same server and then have them interact. Is there something special about a websocket connection that means that these mechanisms are not sufficient?

Keith
 
thanks,
Binod.


Keith


On Tue, Mar 5, 2013 at 6:48 AM, Binod < " target="_blank"> > wrote:
Hi folks,

To follow up on our discussion in the last meeting, here is
my proposal on handling converged application scenario.

Note that this is applicable only for converged containers.
Standalone SIP containers are not required to support this
feature.

Usecase:

It is often useful for developers who embed sip web socket server
endpoints into a larger web application (eg: a webrtc app) to be
able to share information on a per client basis between the web
resources (JSPs, JSFs, Servlets for example) and the web socket
endpoints servicing that client. Because web socket connections
are initiated with an http request, there is an association between
the HttpSession under which a client is operating and any web
sockets that are established within that HttpSession.

Proposal:

Add a method in SipSessionsUtil to retrieve the HttpSession.
HttpSession httpSession = ssu.getInitiatingWebSession(sipSession);

Let me know what do you think.

thanks,
Binod.


On Wednesday 27 February 2013 08:58 PM, Binod wrote:
Hi,

Please find a draft version of SIP over websocket support attached.
This is as per the discussions we had in the F2F.

However, I am thinking, if we should have a way to obtain HTTP Session
that originated the websocket traffic to the application. That can help
developers write interesting converged application that use HTTP and SIP
together.

thanks,
Binod.


 
--------------------
Note: The information contained in this message may be privileged and confidential 
and protected from disclosure. If the reader of this message is not the intended 
recipient, or an employee or agent responsible for delivering this message to the 
intended recipient, you are hereby notified that any dissemination, distribution or 
copying of this communication is strictly prohibited. If you have received this 
communication in error, please notify us immediately by replying to the message and 
deleting it from your computer. Thank you. Thrupoint, Inc.
nXaR2cC3





 
--------------------
Note: The information contained in this message may be privileged and confidential 
and protected from disclosure. If the reader of this message is not the intended 
recipient, or an employee or agent responsible for delivering this message to the 
intended recipient, you are hereby notified that any dissemination, distribution or 
copying of this communication is strictly prohibited. If you have received this 
communication in error, please notify us immediately by replying to the message and 
deleting it from your computer. Thank you. Thrupoint, Inc.
nXaR2cC3






 
--------------------
Note: The information contained in this message may be privileged and confidential 
and protected from disclosure. If the reader of this message is not the intended 
recipient, or an employee or agent responsible for delivering this message to the 
intended recipient, you are hereby notified that any dissemination, distribution or 
copying of this communication is strictly prohibited. If you have received this 
communication in error, please notify us immediately by replying to the message and 
deleting it from your computer. Thank you. Thrupoint, Inc.
nXaR2cC3




--
George Vagenas



Re: SIP over websocket draft.

(continued)

Re: SIP over websocket draft.

Binod 03/06/2013

Re: SIP over websocket draft.

Lewis, Keith 03/06/2013

getInitiatingWebSession [Re: SIP over websocket draft.]

Binod 03/07/2013

Re: getInitiatingWebSession [Re: SIP over websocket draft.]

Lewis, Keith 03/08/2013

Re: getInitiatingWebSession [Re: SIP over websocket draft.]

Binod 03/08/2013

Re: getInitiatingWebSession [Re: SIP over websocket draft.]

binod pg 03/13/2013

Re: getInitiatingWebSession [Re: SIP over websocket draft.]

Lewis, Keith 03/18/2013

Re: getInitiatingWebSession [Re: SIP over websocket draft.]

Binod 03/19/2013

Re: getInitiatingWebSession [Re: SIP over websocket draft.]

George Vagenas 03/20/2013

Re: getInitiatingWebSession [Re: SIP over websocket draft.]

George Vagenas 03/20/2013

Re: getInitiatingWebSession [Re: SIP over websocket draft.]

binod pg 03/20/2013

Re: getInitiatingWebSession [Re: SIP over websocket draft.]

George Vagenas 03/20/2013

Re: SIP over websocket draft.

Lewis, Keith 03/06/2013

Re: SIP over websocket draft.

Binod 03/07/2013

Re: SIP over websocket draft.

Lewis, Keith 03/08/2013

Re: SIP over websocket draft.

Nitzan Nissim 03/10/2013

Re: SIP over websocket draft.

binod pg 03/12/2013
 
 
Close
loading
Please Confirm
Close