[SR-Users] Handling RFC3578 (Overlap Dialing) in Kamailio/ Asynchronious transaction handling
Olle E. Johansson
oej at edvina.net
Tue Feb 4 18:54:09 CET 2014
Again, you are trying to break the SIP Protocol. Check RFC 3261
for references. There should only be one SIP invite open at a time.
That's the reason the SIP community invented UPDATE.
And you assume a lot of things - that your invites are sent to the same
server, which may not be the case. DNS lookups and load balancing/failover
is done on a per transaction basis.
The timing is usually done with local dialplans and stuff in the
user agents. The proxy can answer each invite individually
and implement overlap support, but the timing should be left to
the user agent.
/O
On 04 Feb 2014, at 17:47, Moritz Graf <moritz.graf at g-fit.de> wrote:
> Hi,
>
> nah, that's not what I wanted to hear ;). And it's not really
> complicated. I hacked it down (my third choice in the initial mail) with
> $shv(). See (find also attached):
>
> ####################################################
> ### Hacky section
> xdbgl("Shared Variable of current ( Call-ID = $ci ) is $shv($(ci)) ");
> $var(numberLength) = $(var(calledNumber_normalized){s.len});
> xdbgl("Length of string ( $var(calledNumber_normalized) )is
> $var(numberLength) characters.");
> if ( $shv($(ci)) < $var(numberLength) ) {
> xdbgl("I detected, that the old value is lower, setting it to the
> new value.");
> $shv($(ci)) = $var(numberLength);
> }
> # sleeping to wait for potentially new invites
> sl_send_reply("100", "Trying..."); # So no retransmits happen
> usleep("500000"); #half a second, this is the timer i was speaking about
> if( $var(numberLength) < $shv($(ci)) ) {
> xdbgl("Detected newer INVITE, aborting this transaction with 484
> response");
> route("address_incomplete");
> break;
> }
> ######################################################
>
> Do you see any problems with this?
>
> So this is not really smooth, probably someone has a better solution for
> this??
>
> greetz
>
>
>
> Am 04.02.2014 16:16, schrieb 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
>> ol d 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/
>>
>>
>>
>> --
>> 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
> <handleOverlap.txt>_______________________________________________
> 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
More information about the sr-users
mailing list