[SR-Users] Handling RFC3578 (Overlap Dialing) in Kamailio/ Asynchronious transaction handling
Daniel-Constantin Mierla
miconda at gmail.com
Wed Feb 5 09:17:57 CET 2014
Hello,
I haven't read full thread, but I noticed in the config snippet below
that you use $shv(...) - this is single value variable that stores the
value in shared memory. The $ci is not replaced in definition of
$shv($ci), but is used as literal token '$ci'.
You should use htable module, defining a hash table, say 'overlap' and
then use $sht(overlap=>$ci).
Cheers,
Daniel
On 04/02/14 17:47, Moritz Graf 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/
>
>
>
> _______________________________________________
> 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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140205/abd453a9/attachment.html>
More information about the sr-users
mailing list