<html><head></head><body>I'm not sure this is a task for a proxy like Kamailio, even with its fancy new async relay features. To truly customise how successive INVITEs are dealt with like this, I think it needs to be handled by a UAS that has complete latitude in terms of how it computes state. <br>
<br><br><div class="gmail_quote">On 4 February 2014 10:13:33 GMT-05:00, Moritz Graf <moritz.graf@g-fit.de> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Hi,<br /><br />sure. That's why it's called "transaction oriented".<br />On a SIP-Theory basis, the second INVITE opens a new transaction!! For<br />correlation the Call-ID keeps the same! This is how all of the big<br />carriers I know handle OverlapDialing.<br /><br />The problem is:<br />* I am receiving an INVITE.<br />* At this point I don't know if there will be a second INVITE or not. So<br />I have to wait.<br />* If the timer elapses, ok handle this INVITE.<br />* But if there IS a second (third..) INVITE, I have to cancel the first<br />and then handle the second.<br /><br />Sounds like nobody has done this before... any suggetions appriciated.<br /><br />greetz<br /><br /><br />Am 04.02.2014 15:56, schrieb Alex Balashov:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> Indeed, Section 3.1 in the referenced RFC covers this pretty well.<br /> <br /> On 4 February 2014 09:47:38
GMT-05:00, "Olle E. Johansson"<br /> <oej@edvina.net> wrote:<br /> <br /> <br /> On 04 Feb 2014, at 15:43, Moritz Graf <moritz.graf@g-fit.de> wrote:<br /> <br /> <br /> Shortly explained what RFC3578 is: In a open numbering plan you<br /> never<br /> know if the INVITE you received is already complete, or if there are<br /> more numbers coming in. One way of accomplishing this is to set up a<br /> timer. If the timer elapses you assume the number is complete.<br /> If not,<br /> you are receiving a new INVITE with one digit more. Now you have to<br /> close the old transaction with a "484 - Address<br /> Incomplete"-response and<br /> start the timer again. (Find the algorithm I want to implement<br /> attached)<br /> <br /> You are not allowed to have two open INVITEs, the second one SHOULD get<br /> a 491 response. The client should not send a new INVITE if the old
INVITE<br /> transaction is not complete.<br /> <br /> I don't th<br /> ink<br /> overlap dialing in SIP was ever meant to be timer based. Consider<br /> that the first INVITE can go to a different proxy than the second. There's no<br /> dialog, no route set.<br /> <br /> /O<br /><hr /><br /> <br /> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br /> sr-users@lists.sip-router.org<br /> <a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br /> <br /> <br /> --<br /> Sent from my Nexus 10, with all the figments of autocorrect that might<br /> imply.<br /> <br /> Alex Balashov - Principal<br /> Evariste Systems LLC<br /> 235 E Ponce de Leon Ave<br /> Suite 106<br /> Decatur, GA 30030<br /> United States<br /> Tel: +1-678-954-0670<br /> Web: <a href="http://www.evaristesys.com">http://www.evaristesys.com</a>/, <a
href="http://www.alexbalashov.com">http://www.alexbalashov.com</a>/<br /></blockquote><br /></pre></blockquote></div><br>
--<br>
Sent from my Nexus 10, with all the figments of autocorrect that might imply.<br>
<br>
Alex Balashov - Principal<br>
Evariste Systems LLC<br>
235 E Ponce de Leon Ave<br>
Suite 106<br>
Decatur, GA 30030<br>
United States<br>
Tel: +1-678-954-0670<br>
Web: <a href="http://www.evaristesys.com">http://www.evaristesys.com</a>/, <a href="http://www.alexbalashov.com/">http://www.alexbalashov.com/</a></body></html>