[SR-Users] Handling RFC3578 (Overlap Dialing) in Kamailio/ Asynchronious transaction handling

[Alex Balashov]

Indeed, Section 3.1 in the referenced RFC covers this pretty well. 

On 4 February 2014 09:47:38 GMT-05:00, "Olle E. Johansson" <oej at edvina.net> wrote:
>
>On 04 Feb 2014, at 15:43, Moritz Graf <moritz.graf at g-fit.de> wrote:
>
>> 
>> Shortly explained what RFC3578 is: In a open numbering plan you never
>> know if the INVITE you received is already complete, or if there are
>> more numbers coming in. One way of accomplishing this is to set up a
>> timer. If the timer elapses you assume the number is complete. If
>not,
>> you are receiving a new INVITE with one digit more. Now you have to
>> close the old transaction with a "484 - Address Incomplete"-response
>and
>> start the timer again. (Find the algorithm I want to implement
>attached)
>You are not allowed to have two open INVITEs, the second one SHOULD get
>a 491 response. The client should not send a new INVITE if the old
>INVITE
>transaction is not complete.
>
>I don't think overlap dialing in SIP was ever meant to be timer based.
>Consider
>that the first INVITE can go to a different proxy than the second.
>There's no
>dialog, no route set.
>
>/O
>_______________________________________________
>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

--
Sent from my Nexus 10, with all the figments of autocorrect that might imply.

Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140204/8b7b018b/attachment.html>