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 <mico...@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 <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 > listsr-us...@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 > >
_______________________________________________ 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
