[SR-Users] Handling RFC3578 (Overlap Dialing) in Kamailio/ Asynchronious transaction handling
Moritz Graf
moritz.graf at g-fit.de
Tue Feb 4 17:47:58 CET 2014
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
-------------- next part --------------
### 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 potetially new invites
sl_send_reply("100", "Trying..."); # So no retransmits happen
usleep("500000");
if( $var(numberLength) < $shv($(ci)) ) {
xdbgl("Detected newer INVITE, aborting this transaction with 484 response");
route("address_incomplete");
break;
}
-------------- 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/7a743597/attachment-0001.pgp>
More information about the sr-users
mailing list