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
<mailto: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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://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
