5 Feb
2014
5 Feb
'14
3:17 a.m.
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:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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(a)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(a)edvina.net> wrote:
On 04 Feb 2014, at 15:43, Moritz Graf <moritz.graf(a)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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users