Skip to main content

SailFin: Join and Replaces support, Part I

Posted by binod on November 14, 2008 at 1:32 AM PST

In a typical customer support scenario, a customer support executive (E) might want his manager (M) to join his call with a customer (C). How to achieve that? In SIP world, Join header specified by RFC 3911 helps in handling this situation. It defines a new header named Join, which holds the call-information. I.e the SIP message from the person Joining the call will contain a Join header with the call-information of the call he wish to join.

In SailFin, you can write a B2bua application to handle this. So, the scenario will be something like this.

(E has established the call with C)
(M contacts B2bua with an INVITE request with Join header to join the call)

Here is an example INVITE message with Join header
INVITE;transport=UDP SIP/2.0^M
From: Manager <>;tag=8691SIPpTag001^M
To: Executive <>^M
Call-ID: 1-8691@^M
Contact: <;transport=UDP>^M
Join: 1-8690@;to-tag=fnidovzg-r;from-tag=8690SIPpTag001^M
Max-Forwards: 70^M
Subject: simplejoin Test^M
Test-Type: uas^M
Content-Type: application/sdp^M
Content-Length:   127^M

SailFin (as per JSR 289) make sure that the request from M uses the same SipApplicationSession of the existing call between E and C. This would help in finding all sessions in the call from the B2Bua code.

It is also possible to get the session which the new request is joining by using the new utility method in the SipSessionsUtil.

protected void doInvite(SipServletRequest request) {
       SipSession css = 
       sipSessionsUtil.getCorrespondingSipSession(request.getSession(), "Join");

With these capabilities, B2bua SIP Servlet will be able to find out who are the existing parties in the call and who is joining the call so that it can do any other business logic and further processing for media mixing to initiate 3-way conference. Note that, as per JSR 289, this functionality is available only for SIP Servlets that act as UA. When SIP Servlets act as proxy, container will just pass the Join header to the other end without processing it.

It is also important to understand how M's SIP client gets hold of the existing call information (call-id, from-tag and to-tag) between E and C to form the Join header. RFC 3911 doesnt specify any particular mechanism for this. SIP REFER could be a one good way by which C can pass this information to M.

C -----------------[ON CALL]----------------E 
(E has established the call with C)
(E Sends a sip REFER to M)
A SIP call-flow for the Join header is available in the tech-invite. It has details of SIP messages involved in this communication.
If you want to take a look at a test code, it is available here. Replaces is essentially the same. I will explain that in the next part of this blog.
Related Topics >>