Sony Manuel's blog

Linking multiple SIP and Converged HTTP sessions in a SailFin cluster

In my previous blog we saw how to link SIP and Converged HTTP Session to a SipApplicationSession (SAS). For SailFin cluster we need to configure Converged Load-Balancer(CLB) so that SIP and HTTP requests for a SAS are processed by the same back-end instance This is achieved by using consistent hash routing policy and appropriate Data Centric Rules (DCR) for extracting the hash key. For details on CLB see the functional specification or read the blog here.

For the conference sample we discussed, we want all SIP and HTTP traffic for a particular conference to hit the same back-end. So the key here is the conference name or id. A DCR file that can be used for this purpose is shown below.

 

<?xml version="1.0" encoding="ISO-8859-1"?> <user-centric-rules>   <sip-rules>     <if>          <header name="Conference-Name"         return="request.Conference-Name">         <exist/>       </header>           <else return="request.to.uri.resolve.user" />     </if>   </sip-rules>        <http-rules>        <if>       <request-uri parameter="Conference-Name" return="parameter.Conference-Name">         <exist/>       </request-uri>                  <else return="request.Host"/>     </if>   </http-rules>        </user-centric-rules>

Once CLB is configured with consistent hash routing and the DCR file it would route SIP and HTTP traffic for the same hash key to a particular back-end instance. The hash is applied only for initial requests. For subsequent requests it uses the sticky information for routing (Cookie in case of HTTP and bekey in request URI for SIP requests).

Posted at 12:07AM May 07, 2008 by sonymanuel in Sun  |  Comments[0]

SIPp and SailFin

If you using SIPp to make calls to SailFin read Jens's blog for some of the parameters that has to be copied from Contact header of the 200 OK to the request URI of subsequent requests. For SailFin single instance you need to copy parameter fid (fragment id). This is used by the container for associating dialog to a call. For  SailFin cluster you need to copy both fid and bekey. bekey is used by Converged Load Balancer front-end to route request to the backend.

For a UAC  generate the default scenario from SIPp using

$sipp -sd uac > uac.xml

Update the uac.xml as highlighted.

 Tracing the SIPp call you can see the following.

UDP message received [357] bytes : SIP/2.0 200 OK^M Content-Length: 0^M Contact: <sip:$127.0.0.1:15060;fid=instance2_1;bekey=sailfin>^M To: "sut"<sip:service@127.0.0.1:15060>;tag=ffvglcl9-d^M Cseq: 1 INVITE^M Via: SIP/2.0/UDP 127.0.0.1:5061;branch=z9hG4bK-11792-1-0^M Server: Glassfish_SIP_1.0.0^M Call-Id: 1-11792@127.0.0.1^M From: "sipp"<sip:sipp@127.0.0.1:5061>;tag=11792SIPpTag001^M ^M ----------------------------------------------- 2008-05-06 01:11:57:894.606 UDP message sent (382 bytes): ACK sip:service@127.0.0.1:15060;fid=instance2_1;bekey=sailfin SIP/2.0^M Via: SIP/2.0/UDP 127.0.0.1:5061;branch=z9hG4bK-11792-1-5^M From: sipp <sip:sipp@127.0.0.1:5061>;tag=11792SIPpTag001^M To: sut <sip:service@127.0.0.1:15060>;tag=ffvglcl9-d^M Call-ID: 1-11792@127.0.0.1^M CSeq: 1 ACK^M Contact: sip:sipp@127.0.0.1:5061^M Max-Forwards: 70^M Subject: Performance Test^M Content-Length: 0^M ^M ----------------------------------------------- 2008-05-06 01:11:59:897.111 UDP message sent (382 bytes): BYE sip:service@127.0.0.1:15060;fid=instance2_1;bekey=sailfin SIP/2.0^M Via: SIP/2.0/UDP 127.0.0.1:5061;branch=z9hG4bK-11792-1-7^M From: sipp <sip:sipp@127.0.0.1:5061>;tag=11792SIPpTag001^M To: sut <sip:service@127.0.0.1:15060>;tag=ffvglcl9-d^M Call-ID: 1-11792@127.0.0.1^M CSeq: 2 BYE^M Contact: sip:sipp@127.0.0.1:5061^M Max-Forwards: 70^M Subject: Performance Test^M Content-Length: 0^M ^M

 

Posted at 01:31AM May 06, 2008 by sonymanuel in Sun  |  Comments[1]