Collocating HTTP/SIP requests and Sip Application Session in SailFin

In a cluster environment, Sip Application Sessions(SAS) will be distributed across multiple instances within cluster. As an example, sessions of two registered users may lie on two different instances. Now they want to call each other. There are lot many queries that in such a scenario, there will be a requirement to remotely access each other SASes which may be residing on remote instance. Instead we suggested them to step back and understand whether access to both SASes is really required to establish a call. In all cases, developers were able to leverage Data Centric Rules and SipApplicationKey annotation to their benefit and route requests to instance where required SAS already exists.

Approaches provided in this blog will help you design your applications to deliver high performance and scalability. In following sections we will look at couple of usecases and suggested way to implement those usecases.



Before we start looking at different usecases, and approach to implement them, lets step back and look at key constraint to keep in mind when developing and deploying any application in SailFin :
  1. Data Centric Rules (DCR) : Converged load-balancer(CLB) in SailFin routes SIP request based on consistent-hash algorithm. For consistent-hash algorithm, developer can specify DCR used to extract key from SIP/HTTP requests. Developer can provide DCR implementation either as JAVA based plugin, or xml file. Developer need to understand DCR in detail and provide their own implementation when deploying a pure sip application or converged application. Developer must consider this as a required step, and thus it is captured before we move to usecases and their solutions.
  2. Sip Application Key (SAK) : JSR 289 defines a new annotation, namely SipApplicationKey, used to associate request with a particular SAS. Please read section on SipApplicationKey in JSR 289 for more details.
Having understood both DCR and SAK, lets dig further deep into its implication. CLB will route request based on key extracted from the request, and that request will get associated with SAS having key returned by method annotated with SipApplicationKey.  If developer ensures that key generated either by DCR or SipApplicationKey annotated method is same, then SAS associated with request will be found on instance where CLB routes it. Thus it must be ensured that implementation of DCR plugin and SipApplicationKey annotated method is same.

Also DCR plugin implementation is not application specific. It is global, and applicable to all applications deployed in cluster.

There are some more details provided in article : http://wiki.glassfish.java.net/Wiki.jsp?page=SakConstr



Usecase 1 : Invite request for a registered user

Lets assume their are two users Bob and Alice. DCR is configured to extract user name from request, and same implementation is used for method annotated with SipApplicationKey. Hence from REGISTER request of Bob, extracted hash key will be Bob and will be associated with SAS with id Bob. Similarly it will happen for Alice REGISTER request as well.

SAS distribution across instances
Figure 1 : SAS distribution across instances in cluster

Lets assume we have two instances in our cluster(say my-cluster), say instance1 and instance2. Bob's SAS exists on instance1, while Alice's SAS exists on instance2 as depicted in above image.

Now Alice calls Bob, by sending an INVITE.

INVITE sip:bob@abc.com SIP/2.0
Max-Forwards: 70
Content-Length: 469
Contact: <sip:alice@10.12.158.243:18440>
To: <sip:bob@abc.com>
Cseq: 1 INVITE
Content-Type: application/sdp
From: <sip:alice@abc.com>;tag=g0th11uw-p
Call-Id: 5329857039370318739
<SDP CONTENT>

Alice INVITE need to reach Bob. For that purpose, Bob's contact address must be available. Now question is which SAS should handle it. There are many options. Lets go over them one by one.

Option 1 : When an user logs in by sending REGISTER request, we can store his/her contact address in back-end database. In such a scenario, contact address for Bob is available to any SAS in any instance by accessing back-end database. In this scenario, any SAS, i.e. Bob's or Alice's SAS can handle it. So key need to be user name extracted either from request-uri, To or From header in INVITE request.

Option 2
: There is no back-end database to store the contact address, rather it is saved as an attribute in SAS. So Bob's SAS has Bob's contact address, and similarly Alice's SAS has Alice's contact address. In such a scenario, Alice's INVITE must be routed to Bob's SAS. So key need to be user name extracted either from request-uri or To header in INVITE request. However in such a scenario, Bob's SAS will not be aware of ongoing call between Alice and Bob. In many cases Alice's SAS need not be involved at all.

Lets make it slightly more complex and impose a requirement that both Bob's and Alice's SAS must be informed with this call, say for billing purpose.

Option 3 : We can still use Option 2. However when a call is established, an OPTIONS message can be send to Alice's SAS indicating a established call between Alice and Bob. It can have all details as required by application.

OPTIONS sip:alice@abc.com SIP/2.0
Max-Forwards: 70
To: <sip:alice@abc.com>
Cseq: 1 OPTIONS
Called-user: bob
Call-start-time: hh:mm:ss
Call-status: established

Call-ID: 5329857039370318739
From: <sip:bob@abc.com>;tag=g0tgzdp8-4
Call-Id: 5384938674088777810

Another OPTIONS message is sent when call is terminated. This way Alice's SAS is aware of call time and other details. However in such a scenario, Alice's SAS only participates passively.

Option 4
: In case Alice's SAS need to actively participate in call, it can be achieved in following manner.

B2BUA
Figure 2 : INVITE request from Alice to Bob

So CLB is configured to route initial Alice INVITE to Alice's SAS, which then does B2BUA and send out second leg INVITE request out on network. It comes back to CLB which routes this second leg INVITE to Bob's SAS. Bob's SAS then does B2BUA and send INVITE request to Bob.

A sample B2BUA second leg invite is shown below :

INVITE sip:bob@abc.com SIP/2.0
Max-Forwards: 70
Content-Length: 469
Contact: <sip:instance2.abc.com;fid=instance2_1>
To: <sip:bob@abc.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Cseq: 1 INVITE
Use-key: bob
Content-Type: application/sdp
From: <sip:alice@abc.com>;tag=g1epr4dy-7rn
Call-Id: 7871275959464839001

To handle above case, key must be generated for INVITE request in following manner :
  • If Use-key header exists in INVITE request, use its value as key
  • Else extract user name in From Header and use it as key
Such rules can be easily written using Java based DCR plugin.

Note : These list of options are not exhaustive. Developers may find more innovative approaches to address their scenario.



Usecase 2 :  Call center

A client, say Alice, calls a call-center for some query. Lets say key is extracted as user name in From header. So Alice INVITE is handled by Alice's SAS. However at that point of time, all call-center agents are busy on call. Hence application queues Alice's request, say in database or JMS queue.

S.NO.  USERNAME
1 CLIENT1
2 CLIENT2
3 CLIENT3
4 ALICE
Table 1 : Calls in queue

At a later point of time, a call-center agent becomes available and can handle Alice's request. However there is no guarantee that processing of this queued request will happen on same instance where Alice's SAS exists. What is the required in such a scenario is that call-center agent contact's address must be send to Alice's SAS to continue Alice's call. So an OPTIONS message can  be generated to handle this case.

OPTIONS sip:alice@abc.com SIP/2.0
Max-Forwards: 70
To: <sip:alice@abc.com>
Cseq: 1 OPTIONS
Call-center-agent: xyz
Call-center-agent-address: xyz@10.12.200.234:15443
From: <sip: xyz@abc.com>;tag=g0tgzdp8-4
Call-Id: 5384938674088777810

Once this OPTIONS message reaches Alice's SAS, INVITE will be send to provided contact address to establish the call.


Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

kshitiz

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today