Uff, that could have led to some ugly failures!! Ur right! That's sth my sipp-tests don't cover...
Thx aaa lot!
greetz
Am 05.02.2014 09:17, schrieb Daniel-Constantin Mierla:
> 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.g...@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"
>>> <o...@edvina.net> wrote:
>>>
>>>
>>> On 04 Feb 2014, at 15:43, Moritz Graf <moritz.g...@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@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@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
>
--
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.g...@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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
