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.
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.
2010/3/19 Alex Hermann alex@speakup.nl:
After quickly scanning though the proposal, i have 2 comments:
- 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?
- 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 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
2010/3/19 marius zbihlei marius.zbihlei@1and1.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.
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
2010/3/20 Timo Reimann Timo.Reimann@1und1.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.
(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?
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.
(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 :)
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.
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
2010/3/20 Timo Reimann Timo.Reimann@1und1.de:
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.
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.
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.
Great!
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.
2010/3/20 Iñaki Baz Castillo ibc@aliax.net:
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.
2010/3/20 Iñaki Baz Castillo ibc@aliax.net:
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.
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?
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.
UA1 --> P1 --> P2 --> P1 --> UA2
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.
Regards, Ovidiu Sas
2010/3/20 Ovidiu Sas osas@voipembedded.com:
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?
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).
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.
2010/3/20 Ovidiu Sas osas@voipembedded.com:
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).
On Sat, Mar 20, 2010 at 6:00 PM, Iñaki Baz Castillo ibc@aliax.net wrote:
2010/3/20 Ovidiu Sas osas@voipembedded.com:
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?
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
Regards, Ovidiu Sas
2010/3/20 Ovidiu Sas osas@voipembedded.com:
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?
Perhaps you are interested in creating a dialgo if the request comes from a certain address... just wondering.
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
Ok, so in this case you would need a dialog for each time the same INVITE arrives to the proxy, right?
Regards.
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@aliax.net wrote:
2010/3/20 Ovidiu Sas osas@voipembedded.com:
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?
Perhaps you are interested in creating a dialgo if the request comes from a certain address... just wondering.
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
Ok, so in this case you would need a dialog for each time the same INVITE arrives to the proxy, right?
Yes.
2010/3/21 Ovidiu Sas osas@voipembedded.com:
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.
2010/3/21 Iñaki Baz Castillo ibc@aliax.net:
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.
Ovidiu Sas wrote:
On Sat, Mar 20, 2010 at 6:00 PM, Iñaki Baz Castillo ibc@aliax.net wrote:
2010/3/20 Ovidiu Sas osas@voipembedded.com:
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?
How do you know that a spiral will occur?
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/22 Timo Reimann timo.reimann@1und1.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).
2010/3/22 Iñaki Baz Castillo ibc@aliax.net:
2010/3/22 Timo Reimann timo.reimann@1und1.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).
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 wrote:
2010/3/22 Iñaki Baz Castillo ibc@aliax.net:
2010/3/22 Timo Reimann timo.reimann@1und1.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).
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.
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@1und1.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.
On Monday 22 March 2010, Iñaki Baz Castillo wrote:
[..] 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 :)
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
2010/3/22 Henning Westerholt henning.westerholt@1und1.de:
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.
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, 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.
I agree.
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.
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.
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?
It shouldn't change at all. Its sole purpose is to allow dialog users to get to know about spiraled routing and, if desired, the INVITE message that is being spiraled. From a dialog event perspective, it is effectively the same as creating a new dialog in the multiple-dialogs approach except for the fact that no additional dialog will be created.
The pseudo-code would be something like this:
dlg_onreq() { if (no_dlg_exists(callid, fromtag)) { create_new_dlg(); return; }
// spiraling if (cbs_exist(DLGCB_SPIRALED)) { run_dlg_callbacks(DLGCB_SPIRALED); }
For further illustration, let me get back to Ovidiu's spiraling example:
UA1 --> P1 --> P2 --> P1 --> UA2
P1 is supposed to run the qos module, and P2 should relay media using, say, the mediaproxy module. Now, if the qos module requires to hook up to both P1's first (non-spiraled) and second (spiraled) INVITE message, it will initially register for DLGCB_CREATED and receive a callback on reception of the first one. There, the qos module would simply register for DLGCB_SPIRALED events associated with the just-created dialog, and in consequence, receive another callback when the second (spiraled) INVITE is transferred. This will allow to complete SDP-based tracking without the need for creating a duplicate dialog state in the dialog module.
Cheers,
--Timo
-
Alex Hermann -
Henning Westerholt -
Iñaki Baz Castillo -
marius zbihlei -
Ovidiu Sas -
Timo Reimann