[OpenSIPS-Users] Load Balancer Issue

Nilanjan Banerjee nil.banerjee at gmail.com
Sat Nov 10 13:06:35 CET 2012


Hi Bogdan,

  You were spot on. Fixed the ROUTE headers for ACK and BYE in the sipp
scenario and everything just worked perfectly. Thanks a lot for bearing
with me with your continued support.  Much appreciate it.

Nilanjan.

On Fri, Nov 9, 2012 at 11:07 PM, Bogdan-Andrei Iancu <bogdan at opensips.org>wrote:

> **
> Nilanjan,
>
> The caller script is broken - in ACK, is should be ROUTE hdrs where you
> have the RECORD-ROUTE ones :) .ACK should look like:
>
>
> U 2012/11/01 11:19:02.006514 X.X.X.23:5080 -> X.X.X.206:5060
> ACK sip:X.X.X.5:5070;transport=UDP SIP/2.0.
> Route:  <sip:X.X.X.206;lr;ftag=31168SIPpTag001;did=0ec.de85e9a>,
> <sip:X.X.X.8;lr>.
> Via: SIP/2.0/UDP X.X.X.23:5080;branch=z9hG4bK-31168-1-5.
> From: sipp <sip:sipp at X.X.X.23:5080>;tag=31168SIPpTag001.
> To: sut <sip:service at X.X.X.5:5070>;tag=30500SIPpTag011.
> Call-ID: 1-31168 at X.X.X.23.
> CSeq: 1 ACK.
> Contact: sip:sipp at X.X.X.23:5080.
> Max-Forwards: 70.
> Subject: Performance Test.
> Content-Length: 0.
>
> I guess it is an err in your sipp scenario.
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
>
> On 11/09/2012 07:24 PM, Nilanjan Banerjee wrote:
>
> Hi Bogdan,
>
>   Thanks for your reply. The answer to both your questions is yes. Sample
> of OK and ACK at the caller as follows:
>
> #
> U 2012/11/01 11:19:02.006375 X.X.X.206:5060 -> X.X.X.23:5080
> SIP/2.0 200 OK.
> Record-Route: <sip:X.X.X.8;lr>,
> <sip:X.X.X.206;lr;ftag=31168SIPpTag001;did=0ec.de85e9a>.
> Via: SIP/2.0/UDP X.X.X.23:5080;branch=z9hG4bK-31168-1-0.
> From: sipp <sip:sipp at X.X.X.23:5080>;tag=31168SIPpTag001.
> To: sut <sip:service at X.X.X.5:5070>;tag=30500SIPpTag011.
> Call-ID: 1-31168 at X.X.X.23.
> CSeq: 1 INVITE.
> Contact: <sip:X.X.X.5:5070;transport=UDP>.
> Content-Type: application/sdp.
> Content-Length:   137.
> .
> v=0.
> o=user1 53655765 2353687637 IN IP4 X.X.X.5.
> s=-.
> c=IN IP4 X.X.X.5.
> t=0 0.
> m=audio 6000 RTP/AVP 0.
> a=rtpmap:0 PCMU/8000.
>
> #
> U 2012/11/01 11:19:02.006514 X.X.X.23:5080 -> X.X.X.206:5060
> ACK sip:X.X.X.5:5070;transport=UDP SIP/2.0.
> Record-Route:  <sip:X.X.X.206;lr;ftag=31168SIPpTag001;did=0ec.de85e9a>,
> <sip:X.X.X.8;lr>.
> Via: SIP/2.0/UDP X.X.X.23:5080;branch=z9hG4bK-31168-1-5.
> From: sipp <sip:sipp at X.X.X.23:5080>;tag=31168SIPpTag001.
> To: sut <sip:service at X.X.X.5:5070>;tag=30500SIPpTag011.
> Call-ID: 1-31168 at X.X.X.23.
> CSeq: 1 ACK.
> Contact: sip:sipp at X.X.X.23:5080.
> Max-Forwards: 70.
> Subject: Performance Test.
> Content-Length: 0.
> .
>
> Thanks,
> Nilanjan.
>
> On Fri, Nov 9, 2012 at 10:29 PM, Bogdan-Andrei Iancu <bogdan at opensips.org>wrote:
>
>>  Hi Nilanjan,
>>
>> Check in the trace if :
>> 1) the 200 OK getting back to the caller has 2 RR headers (one from Proxy
>> and one from LB).
>>
>> 2) the ACK from caller (before LB) has 2 Route headers, one pointing to
>> LB, next to Proxy.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>
>>
>>   On 11/09/2012 05:01 PM, Nilanjan Banerjee wrote:
>>
>> Hi Bogdan,
>>
>>   Thanks a lot for your suggestion and sorry for the delay in getting
>> back with this...I tried the following configuration as you have suggested
>> for the Load Balancer and the Proxy:
>>
>> ______________
>> Load Balancer:
>> ______________
>>
>> route{
>>         if (!mf_process_maxfwd_header("3")) {
>>                 sl_send_reply("483","looping");
>>                 exit;
>>         }
>>
>>         if (!has_totag()) {
>>                 # initial request
>>                 record_route();
>>         } else {
>>                 # sequential request -> obey Route indication
>>                 loose_route();
>>                 t_relay();
>>                 exit;
>>         }
>>
>>         # detect resources and do load balancing
>>
>>          load_balance("1","sc");
>>
>>         # LB function returns negative if no suitable destination (for
>> requested resources) is found,
>>         # or if all destinations are full
>>         if ($retcode<0) {
>>              sl_send_reply("500","Service full");
>>              exit;
>>         }
>>
>>         xlog("Selected destination is: $du\n");
>>
>>         # send it out
>>         if (!t_relay()) {
>>                 sl_reply_error();
>>         }
>> }
>>
>> ______
>> Proxy
>> ______
>>
>> route{
>>
>>         if (!has_totag()) {
>>                 # initial request
>>                 record_route();
>>         } else {
>>                 # sequential request -> obey Route indication
>>                 loose_route();
>>         }
>>
>>         if (!t_relay()) {
>>              #   xlog("L_ERR","sl_reply_error\n");
>>                 sl_reply_error();
>>         }
>>
>> }
>>
>> However, I am still getting the same error - basically the ACK and the
>> BYE messages are skipping the Proxy and the response to the BYE is sent to
>> the Proxy. Here are the sample ACK and BYE for the following setup I am
>> using:
>>
>> X.X.X.23:5080 --> X.X.X.206:5060 --> X.X.X.8:5060 --> X.X.X.5:5070
>> (sipp UAC)       --> (Load Balancer) -->  (Proxy)         --> (sipp UAS)
>>
>> #
>> U 2012/11/01 11:19:22.901990 X.X.X.206:5060 -> X.X.X.5:5070
>> ACK sip:X.X.X.5:5070;transport=UDP SIP/2.0.
>> Record-Route:  <sip:X.X.X.206;lr;ftag=31168SIPpTag005;did=9d.087b203>,
>> <sip:X.X.X.8;lr>.
>> Via: SIP/2.0/UDP X.X.X.206;branch=z9hG4bK0112.20fe162.2.
>> Via: SIP/2.0/UDP X.X.X.23:5080;branch=z9hG4bK-31168-5-5.
>> From: sipp <sip:sipp at X.X.X.23:5080>;tag=31168SIPpTag005.
>> To: sut <sip:service at X.X.X.5:5070>;tag=30500SIPpTag015.
>> Call-ID: 5-31168 at X.X.X.23.
>> CSeq: 1 ACK.
>> Contact: sip:sipp at X.X.X.23:5080.
>> Max-Forwards: 69.
>> Subject: Performance Test.
>> Content-Length: 0.
>> .
>>
>> #
>> U 2012/11/01 11:19:22.934118 X.X.X.23:5080 -> X.X.X.206:5060
>> BYE sip:X.X.X.5:5070;transport=UDP SIP/2.0.
>> Record-Route:  <sip:X.X.X.206;lr;ftag=31168SIPpTag001;did=0ec.de85e9a>,
>> <sip:X.X.X.8;lr>.
>> Via: SIP/2.0/UDP X.X.X.23:5080;branch=z9hG4bK-31168-1-7.
>> From: sipp <sip:sipp at X.X.X.23:5080>;tag=31168SIPpTag001.
>> To: sut <sip:service at X.X.X.5:5070>;tag=30500SIPpTag011.
>> Call-ID: 1-31168 at X.X.X.23.
>> CSeq: 2 BYE.
>> Contact: sip:sipp at X.X.X.23:5080.
>> Max-Forwards: 70.
>> Subject: Performance Test.
>> Content-Length: 0.
>> .
>>
>> Looks like the loose routing for the messages after the initial requests
>> is not happening properly according to the Record-Route header. Not sure,
>> if I am doing things right in the client side while introducing the
>> Record-Route header - hence attaching the modified sipp uac and uas I am
>> using.
>>
>> Would greatly appreciate your time and help if you could please throw
>> some light into this matter.
>>
>> Thanks,
>> Nil.
>>
>>
>> On Thu, Oct 25, 2012 at 7:30 PM, Bogdan-Andrei Iancu <bogdan at opensips.org
>> > wrote:
>>
>>>  Hi Nil,
>>>
>>> Seems the problem is in the proxy, where you do not do RR at all.
>>>
>>> Try
>>>
>>> ____________
>>>
>>> Proxy:
>>> ____________
>>>
>>> route{
>>>
>>>         if (!has_totag()) {
>>>                 # initial request
>>>                 record_route();
>>>         } else {
>>>                 # sequential request -> obey Route indication
>>>                 loose_route();
>>>         }
>>>
>>>          if (!t_relay()) {
>>>              #   xlog("L_ERR","sl_reply_error\n");
>>>                 sl_reply_error();
>>>         }
>>> }
>>>
>>>
>>> Regards,
>>>
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>>
>>>
>>>   On 10/22/2012 02:25 PM, Nilanjan Banerjee wrote:
>>>
>>> Thanks Bogdan for taking time to respond to my post. I think you have
>>> guessed it right, I am using the sample routing script given in the Load
>>> Balancer (LB) tutorial and that is most likely sending the ACK and BYE
>>> messages directly to Client 2 bypassing the Proxy. The routing code
>>> snippets I am using at the LB and the Proxy are shown below. Could you
>>> please tell me what's going wrong over here? I am using record route
>>> support at both the clients. Alternatively if you could please tell me what
>>> should go in the routing blocks of the LB and the Proxy so that all the
>>> messages go through the LB and the Proxy then that will be of immense help
>>> too.
>>>
>>> Regards,
>>> Nil.
>>>
>>> ____________
>>>
>>> Load Balancer:
>>> ____________
>>>
>>> route{
>>>         if (!mf_process_maxfwd_header("3")) {
>>>                 sl_send_reply("483","looping");
>>>                 exit;
>>>         }
>>>
>>>         if (!has_totag()) {
>>>                 # initial request
>>>                 record_route();
>>>         } else {
>>>                 # sequential request -> obey Route indication
>>>                 loose_route();
>>>                 t_relay();
>>>                 exit;
>>>         }
>>>
>>>         # detect resources and do balancing
>>>
>>>          load_balance("1","sc");
>>>
>>>
>>>         # LB function returns negative if no suitable destination (for
>>> requested resources) is found,
>>>         # or if all destinations are full
>>>         if ($retcode<0) {
>>>              sl_send_reply("500","Service full");
>>>              exit;
>>>         }
>>>
>>>         xlog("Selected destination is: $du\n");
>>>
>>>         # send it out
>>>         if (!t_relay()) {
>>>                 sl_reply_error();
>>>         }
>>> }
>>>
>>> ____________
>>>
>>> Proxy:
>>> ____________
>>>
>>> route{
>>> record_route();
>>>         if (!t_relay()) {
>>>              #   xlog("L_ERR","sl_reply_error\n");
>>>                 sl_reply_error();
>>>         }
>>> }
>>>
>>>
>>> On Sun, Oct 21, 2012 at 7:39 PM, Bogdan-Andrei Iancu <
>>> bogdan at opensips.org> wrote:
>>>
>>>>  Hi Nil,
>>>>
>>>> I wild guess is you are not correctly do "loose_route" on the LB, so
>>>> instead of following the Route (to OpenSIPS Proxy), it goes directly to end
>>>> destination in RURI (Client 2).
>>>>
>>>> Of course, I assume that all parties (LB + Proxy) do record_route() for
>>>> the call, right ?
>>>>
>>>> Regards,
>>>>
>>>> Bogdan-Andrei Iancu
>>>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>>>
>>>>
>>>> On 10/21/2012 10:09 AM, Nilanjan Banerjee wrote:
>>>>
>>>>  Hello,
>>>>
>>>>   I am trying to build the following setup using OpenSIPS load balancer
>>>> and the proxy functionality:
>>>>
>>>> Client 1 (sipp) <----> OpenSIPS Load Balancer <----> OpenSIPS Proxy
>>>> <----> Client 2 (sipp)
>>>>
>>>> At the client ends I am using the following commands:
>>>>
>>>> Client 1: sipp -sn uac -rsa [Load Balancer Address] [Client 2 Address]
>>>>
>>>> Client 2: sipp -sn uas
>>>>
>>>> The Load Balancer is configured with a destination as the OpenSIPS
>>>> Proxy and the Proxy is configured to simply forward the SIP messages based
>>>> on IP address (using only forward(); in the routing block).
>>>>
>>>> Now everything (INVITE, OK and ACK messages) works fine except the BYE
>>>> messages that are getting forwarded by the Load Balancer directly to Client
>>>> 2 unlike the INVITE, OK and ACK messages that traverse the Proxy. Client 2
>>>> however, sends the OK to the BYE to the OpenSIPS Proxy. Since the BYE
>>>> messages do not traverse the Proxy, the OK to the BYE messages are getting
>>>> retransmitted repeatedly by Client 2 and the sessions are not getting
>>>> terminated properly. How do I make the BYE messages to go through the Proxy
>>>> or the OK message sent directly to the Load Balancer so that the
>>>> retransmissions do not happen and the sessions get terminated properly?
>>>>
>>>> [NB: When the Load Balancer is taken out of the loop and the Proxy
>>>> configuration is kept the same, all the SIP messages traverses the Proxy
>>>> and everything works fine i.e., the BYE and the OKs to the BYEs are handled
>>>> properly and sessions get terminated properly.]
>>>>
>>>> Would greatly appreciate any help in this matter. Thanks in advance.
>>>>
>>>> Nil.
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20121110/8aea20a6/attachment-0001.htm>


More information about the Users mailing list