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

Moritz Graf moritz.graf at g-fit.de
Tue Feb 4 16:13:33 CET 2014


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 538 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140204/27254059/attachment.pgp>


More information about the sr-users mailing list