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

SIP Mailing-list sip at racitup.com
Tue Nov 27 21:12:08 CET 2012


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/20121127/55a22020/attachment.htm>


More information about the sr-users mailing list