Skip to main content

Summary of sip/websocket discussion

  • From: binod pg < >
  • To:
  • Subject: Summary of sip/websocket discussion
  • Date: Wed, 19 Mar 2014 10:50:01 +0530
  • Organization: Oracle Corporation

Hi everyone,

Please see below a summary about what we will be discussing today in the meeting.

- Please read RFC 7118 (esp. section A.2 and A.3)

About 359  section  14.3.2
This is a way to pass information from web to SIP application. Note that unlike previously discussed
HTTP and SIP session convergence, this proposal only deals with sharing information available to the server
at the time of handshake. This information primarily include web security principal and http headers. There
is an email discussion between me and Keith about this. What is proposed in that mail thread
is a listener to intercept websocket handshake request and let application initialize SipWebSocketContext
with what it want to populate. Please see the mail thread here:

I spoke with Keith yesterday to converge on this better and we agree that the following two methods to
SipWebSocketContext would be simpler to cover the requirement. I will make changes to the specification
unless anyone disagree.

  1. Principal getWebSecurityPrincipal():

   Returns a object containing the name
   of the authenticated user at the time of websocket
   handshake. This is also required for authentication usecase (see below).

 2. String getSavedHttpHeader(String name):

   Returns the http header saved by the sip container at the time of
   websocket handshake. A sip container that support sip over websockets
is required to allow administrators to configure the names of http headers
that will be saved. If the header is not configured or was not available in
   the handshake request, this method returns null.

About 359 section 14.6.1
As explained in RFC 7118 (esp. section A.2 and A.3), web authentication can happen at a time before websocket
handshake. This would establish a web principal or web identity with the container. RFC 7118 explains two ways
a SIP authentication happen
- During websocket handshake using the sip principal and a token encoded in websocket URL as explained in section A.2
- During websocket handshake using session cookie established during original HTTP authentication.

There is some mechanism needed to establish and verify the SIP principal in these situations. There are three options
given in 14.6.1 for this purpose. Keith is alluding to using option 3 and using custom JAAS callbacks defined by
each container vendor.
See his mail here:

I would like to know other members opinion on this topic to decide which way we should go. Should we standardize on
a mechanism (either option 1 or 2)? Or should we let it be decided by the container vendors?

Keith also proposed a way for SIP servlets to verify that the SIP identity in the message actually maps to the established
web principal. We agree that the getWebSecurityPrincipal method would help achieve that requirement.


Summary of sip/websocket discussion

binod pg 03/19/2014
Please Confirm