4 Feb
2014
4 Feb
'14
4:16 p.m.
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