Skip to main content

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

  • From: "Lewis, Keith" < >
  • To: jsr359-experts < >
  • Subject: Re: getInitiatingWebSession [Re: SIP over websocket draft.]
  • Date: Wed, 10 Apr 2013 12:09:26 +0100

All,

I still have concerns that if we provide the getInitiatingWebSession() method it will be misunderstood and misused by applications. These concerns also apply to getURL(). I seem to be the only one voicing these concerns, it would be interesting to hear the opinion of others with more experience of using SIP over websockets.

In case my understanding of the client side is wrong it may be helpful to list my assumptions.
  1. The client has implemented RFC3261 as modified by the SIP-WEBSOCKET-DRAFT.
  2. Websocket connections are established by the transport layer of RFC3261 using the IP address and port passed down to it.
  3. Following the recommendation in RFC3261 section 18.1.1 an existing websocket connection can be reused to send SIP requests as long as the IP address, port and transport match.
  4. The client may reuse an existing connection even if the message is being handled by a different application on the server side.
Even though it would be possible to create a client that uses websocket connections in a way that does not conform RFC3261 it would be strange to provide explicit support for this in JSR359.

In (2) the information the basic information the client uses to establish the websocket connection is the IP address, the port and whether to use TLS. When creating the HTTP handshake there is no HTTP path made available to the transport layer. One possible strategy is to always use a path of "/" - this is what can be seen  in all the examples shown in SIP-WEBSOCKET-DRAFT. Another possible (but cumbersome) strategy would be to use the address and port to lookup a path from some local configuration. In either case a single path will be used for all websocket connections to a particular address & port.

If the client chooses to include cookies in the HTTP handshake as described in RFC6265 it must only include cookies that have the relevant path. If the client is using the strategy of always using a path of "/" that will limit the set of cookies sent to those with a path of "/". In particular there will be no jsessionid cookie unless there is a web application deployed with a context root of "/".

Even if a jsessionid cookie is included in the HTTP handshake its usefulness would be limited. The SIP messages sent over a websocket connection may be routed to one of several SIP applications deployed on the server. If a client only interacts with a single converged application it may be that the jsessionid cookie used in the initial handshake will identify a session owned by the converged application that handles the SIP. As soon as the client starts to interact with two converged applications it will difficult to ensure that both can use the getInitiatingWebSession() facility. If the session is not owned by the application processing the sip then the call of getInitiatingWebSession() must return null since applications are only allowed to interact with http sessions they have created.

In addition if the keep alive feature is being used the websocket connection could persist for several days, it is likely that the http session identified by the jsessionid will have expired during that time.

It would seem to be possible for a SIP container to support both the client and server parts of SIP-WEBSOCKET-DRAFT without any changes to the API exposed to applications other than those required for SIP-Outbound. The usefulness of any transport specific API exposed to applications is limited by the fact that a single connection can be shared by several applications. In addition there is a danger that naive developers may use facilities that turn out not to deliver what they expect. For these reasons it is not clear to me that we need any of the API methods described in section 13 of the EDR.

Sorry about the long email, hopefully it clarifies my concerns.

Keith


On Wed, Apr 3, 2013 at 4:03 PM, binod pg < " target="_blank"> > wrote:
Hi Keith,

Thanks for the discussion.

RFC 6265 http://tools.ietf.org/html/rfc6265 specifies how a servers might maintain
a stateful session for http requests using set-cookie and cookie headers.

As you can see, once the server sends a cookie to the client, it will send the cookie
in each subsequent requests including the http request that initiates the connection.

RFC 6455 (see section 1.3) support RFC 6265 cookies in the handshake request.

HttpSession interface in Java EE make use of cookies for their session management
apart from URL rewriting.
http://docs.oracle.com/javaee/5/api/javax/servlet/http/HttpSession.html

So, the association is not exactly done by our specification. What we do in our specification
is to give APIs  for application to make use of this association.

thanks,
Binod.


On 4/3/2013 7:02 PM, Lewis, Keith wrote:
Binod,

thanks for your reply.

<snip>
With websockets, there is an implicit relationship between http sessions and the sip messages, even when application
does not do an explicit association between the http session and SAS. The relation is between the http session of the
handshake request that establishes the sip/websocket connection AND the messages transported over that connection.
</snip>

The assertion above is the one that is not obvious to me.

The handshake of RFC6455 uses HTTP messages as defined in RFC2616.
Neither of these specs defines the notion of a http session and ties it to the lifetime of a connection.
RFC6265 defines sessions but this applies to a request-response pair and not to a connection.

Is there a spec defining this "implicit relationship" between an http session and a websocket connection or is this something we are defining as part of JSR359?

My intention in asking these questions is not to be obstructive but to ensure that we are not making unwarranted assumptions.

Keith


On Wed, Apr 3, 2013 at 11:32 AM, binod pg < " target="_blank"> > wrote:
Hi Keith,

The convergence capabilities in current JSR 289 are done using an explicit association of the http session with
the sipapplication session by the application.  This was necessary, since there is no other relationship between
http session and sip applicaion session. This has the following implications.

-  The encoded SIP URI need to be communicated to the caller in someway so that resulting calls end up
    in the same sip application session. As you know,  this is a deprecated approach in 289.

- The http URL is encoded with SAS key. Here, there is an implicit assumption that SAS is already present,
    which may not be true. For example, a websocket connection will be created before an application send
   a message, which in turn creates a SAS.

More over, web applications are often written as a mashup of libraries. So, the sip/websocket endpoints are
very likely to be one of widget someone integrates with their web application. So, a client side logic (like using
encoded URI) may be difficult to do.

Even if you managed to do the association, a http session is associated always with one SAS.  All the calls originating
from that http session will have to be part of same SAS. I.e All the b2bs in the server might end up using the same
SAS. So, saving the application state can become complicated for some applications.

With websockets, there is an implicit relationship between http sessions and the sip messages, even when application
does not do an explicit association between the http session and SAS. The relation is between the http session of the
handshake request that establishes the sip/websocket connection AND the messages transported over that connection.
Note that this is not specified as a http session to sip session association. I don't think this relation exist for any other
transports. The proposal is simply exposing that relation to the application. Given there is no application level plumbing
done for association, this is immune to how the libraries are mashed up in a web app.

Then to your other comments.

About SipWebSocketContextListener: Application might want to send a message as soon as a websocket connection
is established. So, the onOpen callback would help in such a scenario. Another use case is a webrtc application that
just do the offer/answer exchange using sip/websocket protocol without a registrar.  Application would need to send
the INVITE to the callee, even before callee sends a message.

I haven't thought about specific usecases for onClose and onError. But it is likely that, application might want to do some cleanup
related to websocket connection during these methods.

And you are right that the wording of section 12.3 is wrong. I only meant that In case the WebSocket connections are initiated
with an http request url within the context-root of a converged application, then an application router might just want to
select the same application.

thanks,
Binod.


On 4/2/2013 5:18 PM, Lewis, Keith wrote:
Binod,

I am still not sure what is special about a websocket connection compared to other transports in regard to coordinating SIP and HTTP sessions from the same client.

It seems to me that the use cases described in 12.2.1 could also apply to a client that sends SIP over UDP, TCP or TLS.  We mentioned briefly at the F2F some of the limitations of our current converged container mechanisms. If we provide a better API it would be good for it to apply to any transport rather that provide new features only for websocket connections.

It also seems strange to provide the SipWebSocketContextListener when we do not have an equivalent for a TCP connection. Why do applications need this? Is this because the closing of the connection implies some change of application state? I could not see anything in the sip-websocket-draft to suggest this other than via the reference to SIP Outbound.

I also do not understand the reason for section 12.3 - "Application Composition". It talks about a connection which has been initiated by a converged application whereas I thought that websocket connections were initiated by the client side. When does this paragraph apply?

During the F2F discussion of sip over websockets the statement was made that from the point of view of the SIP container "this is just another transport". Was that statement incorrect?

Keith



On Tue, Mar 19, 2013 at 11:04 AM, Binod < " target="_blank"> > wrote:
Hi Keith,

We have three deployment models mentioned in section 1.5 of the
specification. If a pure sip servlet container is handling the websocket
transport, then it is not required to retrieve the inititiatingwebsession.

However, in case of a converged container, for a converged sip/http
application, it should be possible for obtaining the initiatingwebsession.
The handshake request can have jsessionid cookie or the url may be
encoded with the jsessionId to retrieve the http session from the
converged container.

The use cases for converged container were not discussed in the F2F.

thanks,
Binod.

On Tuesday 19 March 2013 01:58 AM, Lewis, Keith 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





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






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

Lewis, Keith 04/02/2013

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

binod pg 04/03/2013

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

Lewis, Keith 04/03/2013

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

binod pg 04/03/2013

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

Lewis, Keith 04/10/2013
 
 
Close
loading
Please Confirm
Close