Hi Daniel,<br><br>Yes I am using forward() because I thought it would be the fastest solution.<br>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.<br>
<br>However, I've recently been looking at t_relay and in particular t_check_trans() and I think that might be the answer...<br><br>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.<br>
<br>Cheers,<br>Richard<br><div class="gmail_extra">
<br><br><div class="gmail_quote">On 30 November 2012 08:31, Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Hello,<br>
<br>
by stateless dispatcher do you mean using forward() to send out the
INVITE?<br>
<br>
Cheers,<br>
Daniel<div><div><br>
<br>
<div>On 11/28/12 1:40 PM, SIP Mailing-list
wrote:<br>
</div>
</div></div><blockquote type="cite"><div><div>Further edit:<br>
<br>
Actually I tried using ds_select_dst to forward the ACK on the
unconfirmed (unanswered; 603 Decline) call but it routed to
another destination.<br>
My work-around involves using ds_next_dst to send the ACK to *all*
destinations.<br>
<br>
Does anyone know if there is a way to fix this behaviour?<br>
Any help is much appreciated!<br>
<br>
Cheers,<br>
Richard<br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On 27 November 2012 20:12, SIP
Mailing-list <span dir="ltr"><<a href="mailto:sip@racitup.com" target="_blank">sip@racitup.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi guys,<br>
<br>
I wonder if someone could sanity check something for me.<br>
<br>
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.<br>
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.<br>
<br>
In a normal call, the flow goes:<br>
<span style="font-family:courier new,monospace">UAC
Proxy UAS<br>
1 INVITE --><br>
2 INVITE--><br>
3 <-- 200 OK<br>
--- ds_load_update()<br>
4 <-- 200 OK<br>
5 ACK --><br>
6 ACK --></span><br>
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!<br>
<br>
Now consider the non-200 case:<br>
<span style="font-family:courier new,monospace">UAC
Proxy UAS<br>
1 INVITE --><br>
2 INVITE--><br>
3 <-- 603 Decline<br>
--- ds_load_unset()<br>
4 <-- 603 Decline<br>
5 ACK --><br>
6 ACK --> ???</span><br>
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 :-(<br>
<br>
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?<br>
<br>
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.<br>
<br>
Edit: actually there is! The Route header is present on the
200 ACK, but <b>not</b> on the 3xx to 6xx ACK. Maybe I can
use loose_route... Anyway, any thoughts would be
appreciated!<br>
<br>
Cheers,<br>
Richard<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><span><font color="#888888">
</font></span></pre><span><font color="#888888">
</font></span></blockquote><span><font color="#888888">
<br>
<pre cols="72">--
Daniel-Constantin Mierla - <a href="http://www.asipto.com" target="_blank">http://www.asipto.com</a>
<a href="http://twitter.com/#!/miconda" target="_blank">http://twitter.com/#!/miconda</a> - <a href="http://www.linkedin.com/in/miconda" target="_blank">http://www.linkedin.com/in/miconda</a></pre>
</font></span></div>
</blockquote></div><br></div>