18 Mar
2010
18 Mar
'10
2:57 p.m.
Hi, due to the long thread about "improving the dialog module"
(http://lists.sip-router.org/pipermail/sr-dev/2010-March/006378.html)
I've decided to create a wiki page in Kamailio's web site in order to
propose a new design for the module.
Please check it:
http://www.kamailio.org/dokuwiki/doku.php/dialog-stateful:new-dialog-module…
This is just a proposal so comments and questions are really welcome :)
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
19 Mar
19 Mar
4:58 a.m.
On Thursday 18 March 2010 19:57:58 Iñaki Baz Castillo wrote:
I've decided to create a wiki page in
Kamailio's web site in order to
propose a new design for the module.
Please check it:
This looks like a welcome improvement.
After quickly scanning though the proposal, i have 2 comments:
1) Shouldn't caller_routeset be in dialog_in? Unless I missed something, this
would be the same for every dialog_out entry.
2) Please also try to accommodate for reboot-persistent dialog variables, ie
store them in the database.
--
Alex Hermann
7:09 a.m.
2010/3/19 Alex Hermann <alex(a)speakup.nl>nl>:
After quickly scanning though the proposal, i have 2
comments:
1) Shouldn't caller_routeset be in dialog_in? Unless I missed something, this
would be the same for every dialog_out entry.
Does such field store the Route URI list of the initial INVITE when it
arrives to the proxy? If so, then you are totally right. However I
wasn't sure of such meaning. Can somebody confirm it please?
2) Please also try to accommodate for
reboot-persistent dialog variables, ie
store them in the database.
AFAIK all the Dialog module pseudo-variables read the current dialog
list data. When storing the dialogs in database such entries are
readed into memory upon restart, so the pseudo-variables could be
"re-generated", am I wrong? doesn't it already occur?
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
10:22 a.m.
Iñaki Baz Castillo wrote:
Hi, due to the long thread about "improving the
dialog module"
(http://lists.sip-router.org/pipermail/sr-dev/2010-March/006378.html)
I've decided to create a wiki page in Kamailio's web site in order to
propose a new design for the module.
Please check it:
http://www.kamailio.org/dokuwiki/doku.php/dialog-stateful:new-dialog-module…
Hello Iñaki,
I have a small question regarding a spiral case.
If I got everything correct the proxy will create 2 dialog_in entries
one for the original INVITE and one for the spiraled one (*NOTE*: Even
if a spiral remains being the same dialog, from the point of view of the
Dialog module a new dialog is generated when same INVITE arrives again
to the proxy after doing a spiral. ). When a >100 answer is received
from the caller, 2 dialog_out entries will be created (one for each
dialog_in value). These two out dialogs will have the same to_tag but
refer to different dialog_in ids (the one of the INVITE and the one of
the spiraled INVITE).
If a final answer is received (a 200 OK) how will the dialog module know
to match the reply to the correct dialog_out, having in mind that the
match is done via to_tag?
Greetings
Marius
10:40 a.m.
2010/3/19 marius zbihlei <marius.zbihlei(a)1and1.ro>ro>:
Hello Iñaki,
I have a small question regarding a spiral case.
If I got everything correct the proxy will create 2 dialog_in entries one
for the original INVITE and one for the spiraled one (*NOTE*: Even if a
spiral remains being the same dialog, from the point of view of the Dialog
module a new dialog is generated when same INVITE arrives again to the proxy
after doing a spiral. ). When a >100 answer is received from the caller, 2
dialog_out entries will be created (one for each dialog_in value). These two
out dialogs will have the same to_tag but refer to different dialog_in ids
(the one of the INVITE and the one of the spiraled INVITE).
If a final answer is received (a 200 OK) how will the dialog module know to
match the reply to the correct dialog_out, having in mind that the match is
done via to_tag?
Tha match is not done against the To-tag. Instead the TM module
matches the 200 to the last INVITE transaction (generatd after the
spiral). Also, such transaction match would invoke a dialog module
callback which already know the related dialog entry.
Please take a look to a new example I've writen for the case of a spiral:
http://www.kamailio.org/dokuwiki/doku.php/dialog-stateful:new-dialog-module…
Thanks a lot.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
8:24 p.m.
Hi, due to the long thread about "improving the
dialog module"
(http://lists.sip-router.org/pipermail/sr-dev/2010-March/006378.html)
I've decided to create a wiki page in Kamailio's web site in order to
propose a new design for the module.
This is just a proposal so comments and questions are really welcome :)
Two remarks:
(1) Under "dialog_out table", the following is stated:
"A response arrives to the proxy and TM modules invokes the Dialog module callback
for the previously generated dialog.
*Such callback ignores the response if its Call-ID or From-tag doesn't match the entry
in dialog_in table with same hash_id*[...]"
I do not think the module has to check whether the response's Call-ID and From-tag
match the entry in the dialog_in table because a mismatch should never happen: When the tm
callback to dlg_reply() was registered in dlg_onreq(), the hash ID of the very dialog
created during dlg_onreq() was passed as argument to tm's registration function. And
since the tm module makes sure that you cannot receive a response-based callback for a
different transaction than the one the registration was carried out from, the dialog that
the response-triggered callback will point to must be the right one.
(2) The "Spiral" example only shows one possible implementation with two dialog
states created for an effectively single dialog. However, during the thread on the mailing
list that started off the re-design proposal, we discussed another approach where a single
dialog state is maintained for spirals only (denoted "dialog continuation" by
myself).
Is there a reason why this approach isn't taken into consideration on the wiki page?
If it's just a matter of time and effort, I'd be glad to add some text and another
example in order to let people comment on this further.
Like I said before, I really consider having dialog callback users deal with module
deficits the worse choice if a better option is available.
Cheers,
--Timo
9 p.m.
2010/3/20 Timo Reimann <Timo.Reimann(a)1und1.de>de>:
Two remarks:
(1) Under "dialog_out table", the following is stated:
"A response arrives to the proxy and TM modules invokes the Dialog module
callback for the previously generated dialog.
*Such callback ignores the response if its Call-ID or From-tag doesn't match
the entry in dialog_in table with same hash_id*[...]"
I do not think the module has to check whether the response's Call-ID and
From-tag match the entry in the dialog_in table because a mismatch should
never happen: When the tm callback to dlg_reply() was registered in
dlg_onreq(), the hash ID of the very dialog created during dlg_onreq() was
passed as argument to tm's registration function. And since the tm module
makes sure that you cannot receive a response-based callback for a different
transaction than the one the registration was carried out from, the dialog
that the response-triggered callback will point to must be the right one.
At transaction layer just the branch and CSeq is inspected in order to
match response with its corresponding client transaction. So the
following could occur (due to a spoofed reply):
### Request sent from proxy to Bob:
INVITE sip:bob@example.org SIP/2.0
Via: SIP/2.0/UDP 1.2.3.4;branch=aaaaaaaa
From: sip:alice@example.org;tag=1111
Call-ID: 11111111
CSeq: 1 INVITE
### Spoofed response frmo Bob (matches the transaction but not the dialog):
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 1.2.3.4;branch=aaaaaaaa
From: sip:alice@example.org;tag=2222
Call-ID: 22222222
CSeq: 1 INVITE
So in this case, the fact that TM matches the response against an
existing client transaction doesn't mean that the response is valid
according to dialog rules so such values (From tag and Call-ID) should
be matched by the Dialog module.
Do you agree? or do I miss something yet?
(2) The "Spiral" example only shows one
possible implementation with two
dialog states created for an effectively single dialog. However, during the
thread on the mailing list that started off the re-design proposal, we
discussed another approach where a single dialog state is maintained for
spirals only (denoted "dialog continuation" by myself).
Is there a reason why this approach isn't taken into consideration on the
wiki page? If it's just a matter of time and effort, I'd be glad to add some
text and another example in order to let people comment on this further.
Like I said before, I really consider having dialog callback users deal with
module deficits the worse choice if a better option is available.
It's just a proposal, of course comments and suggestions are more than
welcome :)
Could you please point me to your suggestion about "dialog continuation"?
However, if we want a new spiral not no create a new dialog then it
would be easily feasible just by adding a constrain when creating a
dialog upon receipt of an INVITE:
"If there is already an entry in dialog_in table with same From-tag
and Call-ID then the new INVITE is part of a spiral and no new dialog
is created for it".
Would it make sense? Certainly I'm thinking it would be just better.
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
20 Mar
20 Mar
5:33 a.m.
(1) Under
"dialog_out table", the following is stated:
"A response arrives to the proxy and TM modules invokes the Dialog module
callback for the previously generated dialog.
*Such callback ignores the response if its Call-ID or From-tag doesn't match
the entry in dialog_in table with same hash_id*[...]"
I do not think the module has to check whether the response's Call-ID and
From-tag match the entry in the dialog_in table because a mismatch should
never happen: When the tm callback to dlg_reply() was registered in
dlg_onreq(), the hash ID of the very dialog created during dlg_onreq() was
passed as argument to tm's registration function. And since the tm module
makes sure that you cannot receive a response-based callback for a different
transaction than the one the registration was carried out from, the dialog
that the response-triggered callback will point to must be the right one.
At transaction layer just the branch and CSeq is inspected in order to
match response with its corresponding client transaction. So the
following could occur (due to a spoofed reply):
### Request sent from proxy to Bob:
INVITE sip:bob@example.org SIP/2.0
Via: SIP/2.0/UDP 1.2.3.4;branch=aaaaaaaa
From: sip:alice@example.org;tag=1111
Call-ID: 11111111
CSeq: 1 INVITE
### Spoofed response frmo Bob (matches the transaction but not the dialog):
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 1.2.3.4;branch=aaaaaaaa
From: sip:alice@example.org;tag=2222
Call-ID: 22222222
CSeq: 1 INVITE
So in this case, the fact that TM matches the response against an
existing client transaction doesn't mean that the response is valid
according to dialog rules so such values (From tag and Call-ID) should
be matched by the Dialog module.
Do you agree? or do I miss something yet? (2) The
"Spiral" example only shows one possible implementation with two
dialog states created for an effectively single dialog. However, during the
thread on the mailing list that started off the re-design proposal, we
discussed another approach where a single dialog state is maintained for
spirals only (denoted "dialog continuation" by myself).
Is there a reason why this approach isn't taken into consideration on the
wiki page? If it's just a matter of time and effort, I'd be glad to add some
text and another example in order to let people comment on this further.
Like I said before, I really consider having dialog callback users deal with
module deficits the worse choice if a better option is available.
It's just a proposal, of course comments and suggestions are more than
welcome :) Could you please point me to your suggestion about
"dialog continuation"?
However, if we want a new spiral not no create a new dialog then it
would be easily feasible just by adding a constrain when creating a
dialog upon receipt of an INVITE:
"If there is already an entry in dialog_in table with same From-tag
and Call-ID then the new INVITE is part of a spiral and no new dialog
is created for it".
Yeah, that's exactly what I had in mind (and, in fact, what I have
prototype-implemented already in Kamailio 1.5). Implemention-wise, I needed
to extend dlg_onreq() and two or three helper functions slightly.
By the way, the look-up in the dialog hash table based on From-tag and
Call-ID, and skipping of a new dialog creation is just what I call
"dialog continuation". It's a pretty fancy word for a rather simple thing,
but for completeness, I mentioned it first in the very first post of
the "Improving the dialog module" thread:
http://lists.sip-router.org/pipermail/sr-dev/2010-March/006378.html
(under "Solutions", (1))
Cheers,
--Timo
8:36 a.m.
2010/3/20 Timo Reimann <Timo.Reimann(a)1und1.de>de>:
If the UAC receives such spoofed response (wrong From-tag/Call-ID) I
think it would ignore it. So if Dialog module doesn't do the same we
would end with a dialog (in dialog_out) which in fact doesn't exist in
the UAC.
This is whay I think such check should be done.
Great!
So in this
case, the fact that TM matches the response against an
existing client transaction doesn't mean that the response is valid
according to dialog rules so such values (From tag and Call-ID) should
be matched by the Dialog module.
Do you agree? or do I miss something yet?
I agree about the possibility of message forgery (which I simply did not
have in mind), and that another check on the Call-ID and From-tag will
avoid illegitimate tinkering with the dialog state. Generally, I don't know whether we should look at
the security issue at
all here. I'm not much of a SIP security guy though, so off the top of my
head I wouldn't know if there are other, more effective measures to
counter "attacks" against the dialog state. If not, the check looks
reasonable (and quite easy to implement). If there are, or if From-tag
spoofing is just the tip of the eisberg and we need a more suitable
security mechanism anyway, such a one should be sought.
Matching From-tag and Call-ID seems enough reasonable for me. However
there could be other security issues realted to dialog, difficult to
handle/check at proxy level (as a proxy is, by definition, not
dialog-aware).
Anyhow, Dialog module should be just a helper, nothing related to
accounting (IMHO).
OK -- just wondered if some new facts invalidated the
single-dialog approach
by now. Glad to hear that's not the case. :)
I will extend the wiki page on that issue as soon as I find some spare time.
I think it would be better if the wiki page contains a single
proposal, without offering choices as these choices could be discussed
here (I could be wrong, of course).
What I mean is that, if the unique dialog approach (when spiral
occurs) is definitely better than the multiple dialogs approach, then
let's modify it in the wiki :)
The question would be, is there somebody who prefers the spiral
multiple dialogs approach? why?
Could you
please point me to your suggestion about "dialog continuation"?
However, if we want a new spiral not no create a new dialog then it
would be easily feasible just by adding a constrain when creating a
dialog upon receipt of an INVITE:
"If there is already an entry in dialog_in table with same From-tag
and Call-ID then the new INVITE is part of a spiral and no new dialog
is created for it".
Yeah, that's exactly what I had in mind (and, in fact, what I have
prototype-implemented already in Kamailio 1.5). Implemention-wise, I needed
to extend dlg_onreq() and two or three helper functions slightly. By the way, the look-up in the dialog hash table based
on From-tag and
Call-ID, and skipping of a new dialog creation is just what I call
"dialog continuation". It's a pretty fancy word for a rather simple thing,
but for completeness, I mentioned it first in the very first post of
the "Improving the dialog module" thread:
http://lists.sip-router.org/pipermail/sr-dev/2010-March/006378.html
(under "Solutions", (1))
Ops, so long time ago that I forgot :)
Thanks a lot.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
9:49 a.m.
2010/3/20 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
OK -- just
wondered if some new facts invalidated the single-dialog approach
by now. Glad to hear that's not the case. :)
I will extend the wiki page on that issue as soon as I find some spare time.
What I mean is that, if the unique dialog approach
(when spiral
occurs) is definitely better than the multiple dialogs approach, then
let's modify it in the wiki :)
The question would be, is there somebody who prefers the spiral
multiple dialogs approach? why?
Ok, good and bad news: I've re-read the entire thread and realized of
the following complex case:
---------------------
UA1 --> P1 --> P2 --> P1 --> UA2
Now, UA2 rejects the call, but P2 decides to reroute the call to an IVR
UA1 --> P1 --> P2 --> IVR
What will be the state of the dialog on P1?
-----------------------
I've taken such example from the thread:
http://lists.sip-router.org/pipermail/sr-dev/2010-March/006397.html
So I've changed the wiki page in order to expose a single dialog
approach when spiral occurs. It's definitely better as you said.
However I've found an important bug which is not solved in any of the
suggested proposals.
Please check the new "spiral" example I've writen (the same as the
above complex flow) in which the new issue arises and let me know your
opinion for the proposed fix:
http://www.kamailio.org/dokuwiki/doku.php/dialog-stateful:new-dialog-module…
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
11:37 a.m.
2010/3/20 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
Ok, good and bad news: I've re-read the entire
thread and realized of
the following complex case:
---------------------
UA1 --> P1 --> P2 --> P1 --> UA2
Now, UA2 rejects the call, but P2 decides to reroute the call to an IVR
UA1 --> P1 --> P2 --> IVR
What will be the state of the dialog on P1?
-----------------------
So I've changed the wiki page in order to expose a single dialog
approach when spiral occurs. It's definitely better as you said.
However I've found an important bug which is not solved in any of the
suggested proposals.
Please check the new "spiral" example I've writen (the same as the
above complex flow) in which the new issue arises and let me know your
opinion for the proposed fix:
http://www.kamailio.org/dokuwiki/doku.php/dialog-stateful:new-dialog-module…
Well, I'm very happy as I've improved the specification in order to
fix the above complex case. Please check it, it should allow *any*
exotic case, if not it's a bug.
http://www.kamailio.org/dokuwiki/doku.php/dialog-stateful:new-dialog-module…
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
11:46 a.m.
OK -- just
wondered if some new facts invalidated the single-dialog approach
by now. Glad to hear that's not the case. :)
I will extend the wiki page on that issue as soon as I find some spare time.
I think it would be better if the wiki page contains a single
proposal, without offering choices as these choices could be discussed
here (I could be wrong, of course).
What I mean is that, if the unique dialog approach (when spiral
occurs) is definitely better than the multiple dialogs approach, then
let's modify it in the wiki :)
The question would be, is there somebody who prefers the spiral
multiple dialogs approach? why?
12:02 p.m.
2010/3/20 Ovidiu Sas <osas(a)voipembedded.com>om>:
It's one of the goals, yes. One of the current lacks of the Dialog
module is the forking support as just an unique dialog entry is
generated (not wnough for modules like mediaproxy).
The question
would be, is there somebody who prefers the spiral
multiple dialogs approach? why?
Does this new design takes in consideration the modules that are on
top of the existing dialog module? For instance the qos module is keeping track of the
media endpoints
for the dialog.
As I pointed out in a previous e-mail, in a spiral case when P2 is
proxying the media, the SDP for the first INVITE that is hitting P1
will be different then the SDP for the second INVITE that is hitting
P1 and in this case the single dialog approach will not work.
This is a good argument to come back to the multiple dialogs approach
in case of spiral. There is no problem in using it as with the current
proposal it involves no failures even in exotic cases.
In any case, I would prefer to keep the existing
dialog module as is
and any new work to be done in a new module.
Most probably it's a good idea as the required changes are enough to
make the transition complex.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
6 p.m.
2010/3/20 Ovidiu Sas <osas(a)voipembedded.com>om>:
For instance the qos module is keeping track of the
media endpoints
for the dialog.
As I pointed out in a previous e-mail, in a spiral case when P2 is
proxying the media, the SDP for the first INVITE that is hitting P1
will be different then the SDP for the second INVITE that is hitting
P1 and in this case the single dialog approach will not work.
UA1 --> P1 --> P2 --> P1 --> UA2
Hi Ovidiu, let me a question:
In your case, wouldn't be enought if the dialog is created after the
spiral occurs?
I mean, without creating it for the first time the INVITE arrives to
the proxy (so just invoke dlg_manage() after the spiral).
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
6:54 p.m.
On Sat, Mar 20, 2010 at 6:00 PM, Iñaki Baz Castillo <ibc(a)aliax.net> wrote:
2010/3/20 Ovidiu Sas <osas(a)voipembedded.com>om>:
How do you know that a spiral will occur?
For instance the qos module is keeping track of
the media endpoints
for the dialog.
As I pointed out in a previous e-mail, in a spiral case when P2 is
proxying the media, the SDP for the first INVITE that is hitting P1
will be different then the SDP for the second INVITE that is hitting
P1 and in this case the single dialog approach will not work.
UA1 --> P1 --> P2 --> P1 --> UA2
Hi Ovidiu, let me a question:
In your case, wouldn't be enought if the dialog is created after the
spiral occurs? I mean, without creating it for the first time the
INVITE arrives to
the proxy (so just invoke dlg_manage() after the spiral).
If you have one single dialog for four media endpoints, how are you
going to manage them?
- first INVITE: UAC + P2
- second INVITE: P2 + UAS
Regards,
Ovidiu Sas
7:20 p.m.
2010/3/20 Ovidiu Sas <osas(a)voipembedded.com>om>:
Perhaps you are interested in creating a dialgo if the request comes
from a certain address... just wondering.
Ok, so in this case you would need a dialog for each time the same
INVITE arrives to the proxy, right?
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
In your case,
wouldn't be enought if the dialog is created after the
spiral occurs?
How do you know that a spiral will occur? I mean,
without creating it for the first time the INVITE arrives to
the proxy (so just invoke dlg_manage() after the spiral).
If you have one single dialog for four media endpoints, how are you
going to manage them?
- first INVITE: UAC + P2
- second INVITE: P2 + UAS
7:22 p.m.
IMHO, I think it's better to have a dialog for each initial INVITE (no
to-tag) that is hitting the proxy and a cloned dialog for each branch.
The original dialog that is created when the INVITE arrives would be
for the first branch. If there's no forking, we are done.
If there is forking, a new dialog will be created (by cloning the
existing one) for each branch.
For each reply (forking case), we match the right dialog (based on branch).
For in dialog requests (for spiral case) we match on Route set.
Once we have a final reply to the original INVITE, there will be on
single winning dialog and all the other dialogs will be destroyed.
It may be a little heavy, but it's a clean design, easy to follow and
debug. And it is addressing all the issues: spiral and forking.
Just my 2c.
As long as the new dialog work is not affecting the existing dialog,
I'm happy. The current dialog design is not perfect, but it works in
most of the common scenarios. If one knows the limitations of the
dialog module, it can come up with workaround solutions and so far I'm
ok with the current dialog module. It can be improved, of course, but
works well for some common scenarios.
Regards,
Ovidiu Sas
On Sat, Mar 20, 2010 at 7:20 PM, Iñaki Baz Castillo <ibc(a)aliax.net> wrote:
2010/3/20 Ovidiu Sas <osas(a)voipembedded.com>om>:
Perhaps you are interested in creating a dialgo if the request comes
from a certain address... just wondering.
Ok, so in this case you would need a dialog for each time the same
INVITE arrives to the proxy, right?
Yes.
In your
case, wouldn't be enought if the dialog is created after the
spiral occurs?
How do you know that a spiral will occur? I mean,
without creating it for the first time the INVITE arrives to
the proxy (so just invoke dlg_manage() after the spiral).
If you have one single dialog for four media endpoints, how are you
going to manage them?
- first INVITE: UAC + P2
- second INVITE: P2 + UAS
7:40 p.m.
2010/3/21 Ovidiu Sas <osas(a)voipembedded.com>om>:
IMHO, I think it's better to have a dialog for
each initial INVITE (no
to-tag) that is hitting the proxy and a cloned dialog for each branch.
The original dialog that is created when the INVITE arrives would be
for the first branch. If there's no forking, we are done.
And what about if the forking occurs in a proxy behind us? then there
is still a single outgoing transaction, but with different
early-dialogs in top of it.
If there is forking, a new dialog will be created (by
cloning the
existing one) for each branch.
This means cloning too much info. Why to clone fixed dialog
information as caller contact, route-set, caller socket, from-tag,
call-id...?
Also, if Alice calls Bob and there is forking (so there are N
early-dialogs) then from the point of view of the caller there is just
one dialog, and not N. This is what the dialog_in table tries to
achieve in my proposal.
For each reply (forking case), we match the right
dialog (based on branch).
Again you miss the case of remote forking.
Once we have a final reply to the original INVITE,
there will be on
single winning dialog and all the other dialogs will be destroyed.
And what about if there are two 200 at the same time? then both would
arrive to the UAC, the UAC would send a BYE for one of them and such
BYE would terminate the dialog in Kamailio (while it remains active
with the other branch that also replies 200).
It may be a little heavy, but it's a clean design,
easy to follow and
debug. And it is addressing all the issues: spiral and forking.
Just my 2c.
Well, I think addressing all the issues requires more than 10 lines of
text as there are complex cases not considered in your mail.
I strongly suggest you to read the proposal I'm working on (which is
more elaborated than what I tell in my mails):
http://www.kamailio.org/dokuwiki/doku.php/dialog-stateful:new-dialog-module…
Of course I'll add again the multidialog approach for spiral
scenarios. But as you can see any other exotic case is addressed in
the proposal (or that is what I've tryed).
As long as the new dialog work is not affecting the
existing dialog,
I'm happy. The current dialog design is not perfect, but it works in
most of the common scenarios. If one knows the limitations of the
dialog module, it can come up with workaround solutions and so far I'm
ok with the current dialog module.
That's the point. I don't consider that the current design of the
dialog module is easily "upgradeable" when coming to address the
corner and special cases described in this thread.
It can be improved, of course, but works well for
some common scenarios.
So please, tell me what exactly is missing in the proposal I' writting :)
Thanks a lot.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
21 Mar
21 Mar
10:22 a.m.
2010/3/21 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
Of course I'll add again the multidialog approach
for spiral
scenarios. But as you can see any other exotic case is addressed in
the proposal (or that is what I've tryed).
Due to the need (in some cases) of having multiple dialogs entries
when spiral occurs, I've added an option
"allow_multiple_dialogs_for_spiral".
I've also writen two complex spiral examples with such option (enabled
and disabled).
Please check it:
http://www.kamailio.org/dokuwiki/doku.php/dialog-stateful:new-dialog-module…
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
22 Mar
22 Mar
8:10 a.m.
Ovidiu Sas wrote:
On Sat, Mar 20, 2010 at 6:00 PM, Iñaki Baz Castillo
<ibc(a)aliax.net> wrote:
Assuming a single-dialog approach, what about a new dialog callback type
that is executed when a spiral is detected, e.g., something like
DLGCB_SPIRALING? Couldn't mediaproxy and akin hook up to that in
addition and thereby continue to work just like they did before?
Cheers,
--Timo
2010/3/20 Ovidiu Sas
<osas(a)voipembedded.com>om>:
How do you know that a spiral will occur? For instance the qos module is keeping track of
the media endpoints
for the dialog.
As I pointed out in a previous e-mail, in a spiral case when P2 is
proxying the media, the SDP for the first INVITE that is hitting P1
will be different then the SDP for the second INVITE that is hitting
P1 and in this case the single dialog approach will not work.
UA1 --> P1 --> P2 --> P1 --> UA2
Hi Ovidiu, let me a question:
In your case, wouldn't be enought if the dialog is created after the
spiral occurs?
8:15 a.m.
2010/3/22 Timo Reimann <timo.reimann(a)1und1.de>de>:
Assuming a single-dialog approach, what about a new
dialog callback type
that is executed when a spiral is detected, e.g., something like
DLGCB_SPIRALING? Couldn't mediaproxy and akin hook up to that in
addition and thereby continue to work just like they did before?
This would be a workaround for the current dialog module.
But in the proposal I'm writing (based on all these threads) there is
no need for it as creating different dialogs when spiral occurs is
already implemented (as optional feature).
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
8:20 a.m.
2010/3/22 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
2010/3/22 Timo Reimann <timo.reimann(a)1und1.de>de>:
Also, assuming single-dialog approach with the suggested
DLGCB_SPIRALING callback, how could mediaproxy (or any other module)
manage it in order to set certain behavior for the dialog?
IMHO it would be easier if multiple early dialogs are created when
spiral occurs, so each one has its own hash_id, dflags and so.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
Assuming a single-dialog approach, what about a
new dialog callback type
that is executed when a spiral is detected, e.g., something like
DLGCB_SPIRALING? Couldn't mediaproxy and akin hook up to that in
addition and thereby continue to work just like they did before?
This would be a workaround for the current dialog module.
But in the proposal I'm writing (based on all these threads) there is
no need for it as creating different dialogs when spiral occurs is
already implemented (as optional feature).
9:18 a.m.
Iñaki Baz Castillo wrote:
2010/3/22 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
When I said "single-dialog", I was thinking "single-dialog-in" while
still maintaining multiple dialog-outs, not single (or even no)
dialog-outs. My understanding of the mediaproxy module is really limited
so I'm just bringing forward an idea for commenting by other people who
know more than I do in that area.
Generally, I was just thinking about a way to get rid of the optional
feature (allow_multiple_dialogs_for_spiral) and replace it by installing
another callback. It's just that, if we could avoid multiple dialog-ins
completely, we wouldn't have to care about (i.e., test) how the new
module implementation behaves for various scenarios in both single- and
multiple dialog-in mode. We'd have just one mode to verify, reducing the
number of code paths.
Moreover, I'm not sure if a simple flag is really all we need. Ovidiu
mentioned the need for multiple endpoints but I don't think the current
proposal could provide that, and probably it shouldn't: After all, what
the dialog module is to model IMHO is SIP dialogs with exactly two peers
per call. Splitting up a single SIP dialog into two Kamailio dialogs
with different endpoints simply doesn't mirror the SIP dialog concept
anymore, and it's the modules built on top of the dialog module which
should deal with that, not the dialog module itself.
Cheers,
--Timo
2010/3/22 Timo Reimann
<timo.reimann(a)1und1.de>de>:
Also, assuming single-dialog approach with the suggested
DLGCB_SPIRALING callback, how could mediaproxy (or any other module)
manage it in order to set certain behavior for the dialog?
IMHO it would be easier if multiple early dialogs are created when
spiral occurs, so each one has its own hash_id, dflags and so. Assuming a single-dialog approach, what about a
new dialog callback type
that is executed when a spiral is detected, e.g., something like
DLGCB_SPIRALING? Couldn't mediaproxy and akin hook up to that in
addition and thereby continue to work just like they did before?
This would be a
workaround for the current dialog module.
But in the proposal I'm writing (based on all these threads) there is
no need for it as creating different dialogs when spiral occurs is
already implemented (as optional feature).
10:03 a.m.
2010/3/22 Timo Reimann <timo.reimann(a)1und1.de>de>:
When I said "single-dialog", I was thinking
"single-dialog-in" while
still maintaining multiple dialog-outs, not single (or even no)
dialog-outs.
Humm, I meant the same :)
This is, each dialog-in would have one or more dialog-outs associated.
The point is what to do what a spiral occurs (creating or not a new
dialog-in for such "new" INVITE).
Perhaps you mean that when a spiral occurs no new dialog-in entry
would be created but new dialog-outs would be inserted?
If so, I think it would complex to implement and see no real benefict
for it (perhaps I miss soemthing).
My understanding of the mediaproxy module is really
limited
so I'm just bringing forward an idea for commenting by other people who
know more than I do in that area.
MediaProxy module "fails" when using "engage_mediaproxy()" as it
depends on dialog module and, until now, dialog module mantains a
single dialog even if parallel forking occurs, so there is no way for
MediaProxy dialog to force RTP throught the mediaproxy server just for
some of those (early-)dialogs (i.e. those detected as NAT).
Generally, I was just thinking about a way to get rid
of the optional
feature (allow_multiple_dialogs_for_spiral) and replace it by installing
another callback. It's just that, if we could avoid multiple dialog-ins
completely, we wouldn't have to care about (i.e., test) how the new
module implementation behaves for various scenarios in both single- and
multiple dialog-in mode. We'd have just one mode to verify, reducing the
number of code paths.
Ok, but I still don't understand the purpose of such new callback.
What/ would be useful for? an example?
Moreover, I'm not sure if a simple flag is really
all we need. Ovidiu
mentioned the need for multiple endpoints but I don't think the current
proposal could provide that, and probably it shouldn't.
The proposal I've writen is supposed to provide it as shown in the examples :)
After all, what
the dialog module is to model IMHO is SIP dialogs with exactly two peers
per call. Splitting up a single SIP dialog into two Kamailio dialogs
with different endpoints simply doesn't mirror the SIP dialog concept
anymore, and it's the modules built on top of the dialog module which
should deal with that, not the dialog module itself.
I agree, from the point of view of SIP protocol a dialog exists
between two endpoints. However we are already "breaking" such concept
when we try to "monitor/handle" dialogds in a proxy (which should be
dialog aware). This is, at this point it's not so important to mantain
the "romantic" concept of the SIP protocol :)
Anyhow I've considered the posibility of having different dialog-in
entries (each one with its own dialog-outs entries) just because
Ovidiu explained it's required for QOS module to work.
From the point of view of MediaProxy module it could be
useful in the
case we don't want to modify the SDP until the spiral occurs (for
any
exotic reason I cannot imagine right now).
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
1:59 p.m.
On Monday 22 March 2010, Iñaki Baz Castillo wrote:
Well, i think that one of the important decisions that must be done in a
design process is to agree and adhere to some scope that is covered from an
implementation. And my proposal for the scope in this regards is that we track
dialogs like they are defined in 3261. This standard is probably not perfect,
but i don't agree to you here that it defines something romantic. ;-)
Its for me the same thing here as in the TM module, which (for the most cases)
only cares about SIP transactions, and not about e.g. dialogs or media
sessions. More advanced functionality is implemented on top of it, in an own
dedicated layer.
Best regards,
Henning
[..]
MediaProxy module "fails" when using "engage_mediaproxy()" as it
depends on dialog module and, until now, dialog module mantains a
single dialog even if parallel forking occurs, so there is no way for
MediaProxy dialog to force RTP throught the mediaproxy server just for
some of those (early-)dialogs (i.e. those detected as NAT).
> Generally, I was just thinking about a way to get rid of the optional
> feature (allow_multiple_dialogs_for_spiral) and replace it by installing
> another callback. It's just that, if we could avoid multiple dialog-ins
> completely, we wouldn't have to care about (i.e., test) how the new
> module implementation behaves for various scenarios in both single- and
> multiple dialog-in mode. We'd have just one mode to verify, reducing the
> number of code paths.
Hi Iñaki,
first, thanks for your proposal, it helps a lot to better understand this long
discussion! Having read it i must say that i also not like this additional
parameter that much.
Ok, but I still don't understand the purpose of
such new callback.
What/ would be useful for? an example?
This callback is useful for dialog clients (like qos) in order to be monitored
when a spiraled request is received. A way to achive the existing behaviour
without the "allow_multiple_dialogs_for_spiral" parameter.
After all,
what the dialog module is to model IMHO is SIP dialogs with
exactly two peers per call. Splitting up a single SIP dialog into two
Kamailio dialogs with different endpoints simply doesn't mirror the SIP
dialog concept anymore, and it's the modules built on top of the dialog
module which should deal with that, not the dialog module itself.
I agree, from the point of view of SIP protocol a dialog exists
between two endpoints. However we are already "breaking" such concept
when we try to "monitor/handle" dialogs in a proxy (which should be
dialog aware). This is, at this point it's not so important to mantain
the "romantic" concept of the SIP protocol :)
2:21 p.m.
2010/3/22 Henning Westerholt <henning.westerholt(a)1und1.de>de>:
Ok, but how would work such callback? This is, a dialog is generated
for the first time an INVITE arrives to the proxy and later a spiral
occurs. A special callback is invoked. And what? what does it mean?
How do the info about the dialog look after such callback has been
invoked? does it change?
Of course, I don't like neither the option
"allow_multiple_dialogs_for_spiral". I've just introduced it because
somethiing liek it seems to be needed for certain modules. If it can
be replaced by a more ellegant solution (as the callback you suggest
if finally I understand its aim) then it's more than welcome :)
I agree.
Ok, but I
still don't understand the purpose of such new callback.
What/ would be useful for? an example?
This callback is useful for dialog clients (like qos) in order to be monitored
when a spiraled request is received. A way to achive the existing behaviour
without the "allow_multiple_dialogs_for_spiral" parameter. I agree, from
the point of view of SIP protocol a dialog exists
between two endpoints. However we are already "breaking" such concept
when we try to "monitor/handle" dialogs in a proxy (which should be
dialog aware). This is, at this point it's not so important to mantain
the "romantic" concept of the SIP protocol :)
Well, i think that one of the important decisions that must be done in a
design process is to agree and adhere to some scope that is covered from an
implementation. And my proposal for the scope in this regards is that we track
dialogs like they are defined in 3261. This standard is probably not perfect,
but i don't agree to you here that it defines something romantic. ;-)
Probably not a good choice to name it :)
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
8:35 p.m.
Ok, but I still don't understand the purpose of
such new callback.
What/ would be useful for? an example?
This callback is useful for dialog clients (like qos) in order to be monitored
when a spiraled request is received. A way to achive the existing behaviour
without the "allow_multiple_dialogs_for_spiral" parameter.
5206
days inactive
5211
days old
26 comments
6 participants
participants (6)
-
Alex Hermann -
Henning Westerholt -
Iñaki Baz Castillo -
marius zbihlei -
Ovidiu Sas -
Timo Reimann