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

[Alex Balashov]

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. 


On 4 February 2014 10:13:33 GMT-05:00, Moritz Graf <moritz.graf at g-fit.de> wrote:
>Hi,
>
>sure. That's why it's called "transaction oriented".
>On a SIP-Theory basis, the second INVITE opens a new transaction!! For
>correlation the Call-ID keeps the same! This is how all of the big
>carriers I know handle OverlapDialing.
>
>The problem is:
>* I am receiving an INVITE.
>* At this point I don't know if there will be a second INVITE or not.
>So
>I have to wait.
>* If the timer elapses, ok handle this INVITE.
>* But if there IS a second (third..) INVITE, I have to cancel the first
>and then handle the second.
>
>Sounds like nobody has done this before... any suggetions appriciated.
>
>greetz
>
>
>Am 04.02.2014 15:56, schrieb 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 th
>>      ink
>>     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/
>
>
>-- 
>
>Moritz Graf, B.Sc.
>Betrieb NGN-Plattform
>
>G-FIT GmbH & Co. KG
>Greflingerstr. 26, 93055 Regensburg
>
>Telefon +49 (9 41) 69 85 - 1 86
>Telefax +49 (9 41) 69 85 - 2 86
>mailto:moritz.graf at g-fit.de
>http://www.g-fit.de
>
>G-FIT Gesellschaft für innovative Telekommunikationsdienste mbH & Co.
>KG, Kommanditgesellschaft, Sitz Regensburg, Registergericht Regensburg,
>HRA 7626; Geschäftsführer: Dipl.Inf. (FH) Alfred Rauscher
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>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/3fe12335/attachment.html>