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@edvina.net wrote:
On 04 Feb 2014, at 15:43, Moritz Graf moritz.graf@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@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/