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