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

[SIP Mailing-list]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20121128/d4148a1b/attachment.htm>