[SR-Users] Problem with Stateless Dispatcher Call Load Distribution (Algorithm 10)

[SIP Mailing-list]

Hi Daniel,

Yes I am using forward() because I thought it would be the fastest solution.
I guess I was lead on by the dispatcher documentation saying it can be used
statelessly, so I tried to do the whole route script stateless.

However, I've recently been looking at t_relay and in particular
t_check_trans() and I think that might be the answer...

I do think it would be great if the ds_select_dst/domain functions
performed a lookup in the hash table for non-INVITEs and set the right
destination though.

Cheers,
Richard


On 30 November 2012 08:31, Daniel-Constantin Mierla <miconda at gmail.com>wrote:

>  Hello,
>
> by stateless dispatcher do you mean using forward() to send out the INVITE?
>
> Cheers,
> Daniel
>
>
> On 11/28/12 1:40 PM, SIP Mailing-list wrote:
>
> Further edit:
>
> Actually I tried using ds_select_dst to forward the ACK on the unconfirmed
> (unanswered; 603 Decline) call but it routed to another destination.
> My work-around involves using ds_next_dst to send the ACK to *all*
> destinations.
>
> Does anyone know if there is a way to fix this behaviour?
> Any help is much appreciated!
>
> Cheers,
> Richard
>
>
> On 27 November 2012 20:12, SIP Mailing-list <sip at racitup.com> wrote:
>
>> Hi guys,
>>
>> I wonder if someone could sanity check something for me.
>>
>> I currently have a simple load balancer set up using algorithm 10 (call
>> load distribution) from the dispatcher module. I'm using Record-Routing so
>> that I can clear down the call load record at the end of the call.
>> Everything looked like it was working okay until I just spotted a problem
>> that I think might be a bug. It's to do with ACKs to non-200 responses.
>>
>> In a normal call, the flow goes:
>> UAC                Proxy               UAS
>> 1     INVITE -->
>> 2                          INVITE-->
>> 3                         <-- 200 OK
>> --- ds_load_update()
>> 4     <-- 200 OK
>> 5      ACK -->
>> 6                           ACK -->
>> Now between step 3 and 4 the proxy runs ds_load_update which according to
>> the documentation "set internal state to confirmed for the call load" entry
>> in the internal call state store. This means the proxy knows where to send
>> the ACK at step 5 because it is safely in the call state store so you can
>> use ds_select_dst again on the ACK to get it to the right place. Works fine!
>>
>> Now consider the non-200 case:
>> UAC               Proxy               UAS
>> 1     INVITE -->
>> 2                          INVITE-->
>> 3                      <-- 603 Decline
>> --- ds_load_unset()
>> 4  <-- 603 Decline
>> 5      ACK -->
>> 6                           ACK --> ???
>> Between step 3 and 4 the proxy is supposed to run ds_load_unset() which
>> unconditionally removes the call from the call state store. Now when the
>> ACK comes in at step 5, the proxy has no record of the call and so doesn't
>> know where to send the ACK. This results in retried Declines and ACKs.
>> Broken :-(
>>
>> If the proxy doesn't run ds_load_unset() on the 603 response, is there
>> some kind of timer that will cause the call to be removed from the call
>> state store on unconfirmed calls?
>>
>> I don't think I can run ds_load_unset on the ACK because there's nothing
>> in the ACK that tells me it is because of a 603, rather than a 200.
>>
>> Edit: actually there is! The Route header is present on the 200 ACK, but
>> *not* on the 3xx to 6xx ACK. Maybe I can use loose_route... Anyway, any
>> thoughts would be appreciated!
>>
>> Cheers,
>> Richard
>>
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20121201/edc65b39/attachment.htm>