4 Feb
2014
4 Feb
'14
9:43 a.m.
Hoho,
i want to implement RFC3578 (transaction oriented) in Kamailio.
Therefore I have to correlate two different Invites with same Call-ID. I
see various ways of accomplishing this, but I am stuck at all of my
solutions.
Find the algorithm I want to implement attached.
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)
The following lines, I'm going to explain my thoughts. For reference I'm
calling "Thread A" the first INVITE coming in and "Thread B" the
second.
#######################
### using Module ASYNC
* Thread A -> async_route("handle_overlap","<timer t99
value>");
* Thread B -> if new incoming transaction,
** set avp("<call-id>")= <digitlength of called number> and
** call async_route("handle_overlap","<timer t99 value>");
* in route[handle_overlap]
** if avp("call-id") greater than "<digitlength of called
number>"
*** cancel transaction with "484 -Address Incomplete"
** if avp("call-id") equals "<digitlength of called number>"
*** handle call => the number is complete
PROBLEM: The old transaction is not canceled immediately, but after t99
elapsed...
#######################
### using Module TMX
using t_suspend() and t_continue(), but here i see the following problems:
* Thread A calls "t_suspend()"
** How is it possible to cancel "Thread A"'s transaction from Thread B?
** If there is no Thread B, so the numbers were complete, how can I get
Thread A to continue processing??
* General TMX-Question: Are there any examples available?
#######################
### using simple sleep() and shv()/avp()
Sounds like dirty hacking... I'd appriciate a solution with one of
aboves modules. But if there is a solution available, I'd try this.
Thx in advise
Moritz
--
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@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
4 Feb
4 Feb
9:47 a.m.
New subject: Handling RFC3578 (Overlap Dialing) in Kamailio/ Asynchronious transaction handling
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 old INVITE
transaction is not complete.
I don't think 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
9:56 a.m.
New subject: Handling RFC3578 (Overlap Dialing) in Kamailio/ Asynchronious transaction handling
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:
--
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/
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 old
INVITE
transaction is not complete.
I don't think 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
10:13 a.m.
New subject: Handling RFC3578 (Overlap Dialing) in Kamailio/ Asynchronious transaction handling
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 old 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/
--
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@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
10:16 a.m.
New subject: Handling RFC3578 (Overlap Dialing) in Kamailio/ Asynchronious transaction handling
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:
--
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/
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
old 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/
--
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@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
------------------------------------------------------------------------
_______________________________________________
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
11:47 a.m.
New subject: Handling RFC3578 (Overlap Dialing) in Kamailio/ Asynchronious transaction handling
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(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/
--
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@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
12:54 p.m.
New subject: Handling RFC3578 (Overlap Dialing) in Kamailio/ Asynchronious transaction handling
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(a)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(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/
--
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@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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
12:58 p.m.
New subject: Handling RFC3578 (Overlap Dialing) in Kamailio/ Asynchronious transaction handling
On 02/04/2014 12:54 PM, Olle E. Johansson wrote:
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.
In fairness, RFC 3578 does offer a fair bit of commentary on this caveat:
However, having subsequent INVITEs routed in different ways brings
some problems as well. The first INVITE, for instance, might be
routed to a particular gateway, and a subsequent INVITE, to another.
The result is that both gateways generate an IAM. Since one of the
IAMs (or both) has an incomplete number, it would fail, having
already consumed PSTN resources.
[...]
Routing in SIP can be controlled by the administrator of the network.
Therefore, a gateway can be configured to generate SIP overlap
signalling in the way described below only if the SIP routing
infrastructure ensures that INVITEs will only reach one gateway.
When the routing infrastructure is not under the control of the
administrator of the gateway, the procedures of Section 2 have to be
used instead.
And, while I agree that this is ridiculous and is in conflict with the
basic spirit of SIP, somehow 3578 did become an RFC... I am as puzzled
by that as you may be. :-)
-- Alex
--
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/
3:51 p.m.
New subject: Handling RFC3578 (Overlap Dialing) in Kamailio/ Asynchronious transaction handling
On 04 Feb 2014, at 18:58, Alex Balashov <abalashov(a)evaristesys.com> wrote:
On 02/04/2014 12:54 PM, Olle E. Johansson wrote:
That's applying a strict route. IMS has some similar overrides too... Ouch.
Regardless, it doesn't talk about overlapping INVITE transactions, just a series
of INVITE transactions.
/O
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.
In fairness, RFC 3578 does offer a fair bit of commentary on this caveat:
However, having subsequent INVITEs routed in different ways brings
some problems as well. The first INVITE, for instance, might be
routed to a particular gateway, and a subsequent INVITE, to another.
The result is that both gateways generate an IAM. Since one of the
IAMs (or both) has an incomplete number, it would fail, having
already consumed PSTN resources.
[...]
Routing in SIP can be controlled by the administrator of the network.
Therefore, a gateway can be configured to generate SIP overlap
signalling in the way described below only if the SIP routing
infrastructure ensures that INVITEs will only reach one gateway.
When the routing infrastructure is not under the control of the
administrator of the gateway, the procedures of Section 2 have to be
used instead.
And, while I agree that this is ridiculous and is in conflict with the basic spirit of
SIP, somehow 3578 did become an RFC... I am as puzzled by that as you may be. :-) 
5 Feb
5 Feb
3:17 a.m.
New subject: Handling RFC3578 (Overlap Dialing) in Kamailio/ Asynchronious transaction handling
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
4:18 a.m.
New subject: Handling RFC3578 (Overlap Dialing) in Kamailio/ Asynchronious transaction handling
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:
--
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@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
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
6 Feb
6 Feb
5:37 a.m.
New subject: Handling RFC3578 (Overlap Dialing) in Kamailio/ Asynchronious transaction handling
Hi,
so with this heavy use of the usleep(); command i have to set the
"children=" parameter to a very high value.
Calculating with expected CAPS of 30 and up to 7 subsequent INVITES per
call and the sleep of 2 seconds, it's:
20*7*2 = 280
So it has to be
children=280
Do you see a Problem with this?
Is there any way to go arround this?
-> Is it possible with the ASYNC-Module? But I am not opening a
transaction. By now everything is without any transaction, I'm handling
this with the sht(callid->$ci) now.
-> Is there any example of how to user ASYNC? I can't find one.. :(
-> Also is there a example of the usage of the suspend() and continue()
functions of tmx?
greetz Moritz
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:
--
Moritz Graf, B.Sc.
Betrieb NGN-Plattform
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
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
4028
days inactive
4030
days old
11 comments
4 participants
participants (4)
-
Alex Balashov -
Daniel-Constantin Mierla -
Moritz Graf -
Olle E. Johansson