[SR-Users] Problem with Stateless Dispatcher Call Load Distribution (Algorithm 10)
Daniel-Constantin Mierla
miconda at gmail.com
Fri Nov 30 09:31:57 CET 2012
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>
More information about the sr-users
mailing list