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.
On 4/2/2013 5:18 PM, Lewis, Keith wrote:
Re: getInitiatingWebSession [Re: SIP over websocket draft.]