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

[Daniel-Constantin Mierla]

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 
> <mailto: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 list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://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/20121130/c3fcb68e/attachment.htm>