2010/4/1 Timo Reimann timo.reimann@1und1.de:
Hi,
sorry for not replying any earlier. I was distracted by other, higher prioritized tasks (such as vacation :) ).
That's an important task! ;)
I just completed a major refurbishment on the proposal page according to what we have discussed on the mailing list. Unfortunately, I had to do it in one big piece instead of changing the page iteratively since the changes depend on each other more or less. This is what I have modified:
- Dialog state transition on responses is now done when a response is
forwarded (instead of when it is received).
Ok
- References to and examples of spiraled routing with the
"allow_multiple_dialogs_for_spiral" parameter set to "yes" are gone. There's just one way of spiraling left, plus a new callback DLGCB_SPIRALED that allows users to hook up to spiraling events in order to imitate the old behavior (without the drawback of having multiple Kamailio dialogs to represent the same SIP dialog).
Ok
- dialog_out does not need a state anymore.
Ok
Please have a look and tell me what you think about it. (You will probably need to re-read from top to bottom.) Furthermore, while I was working on the page, I came up with two more questions and would be grateful for some further feedback:
It's really ok. I just did a minor fix you can see in the history. At the end of this mail I comment, however, a possible problem I see.
(1) Is the inv_branch parameter really needed? Initially, my impression was that proxies require it in order to know which branches to prune in case of remote forking and a final response coming in. However, the inv_branch shouldn't be required for that IMHO since callbacks to the response handling function pass along the dialog_in's hash ID that the responses refer to. By matching the dialog_in's dialog_id with entries in the dialog_out table, it can determine all the branches belonging to a given call, and thereby also those that need to be deleted.
Right. As now dialog status just relies on the responses sent upstream to the client I think inv_branch is not required anymore.
I just see a minor issue with this. Imagine P1 is running the Dialog module and a proxy P2 behind it does parallel forking and replies 2 early dialogs. This would mean two entries under dialog_out table. Later P2 sends a negative final response for the first dialog. Just the dialog_out entry matching the To-tag would be deleted, while the other one would exist until the whole dialog is confirmed or terminated. Anyhow, I think this is not a big problem.
(2) Is the dialog_out table required for anything else but displaying dialog data (e.g., callee To-tag, callee CSeq number, etc.) over the MI interface right now? Specifically, is it needed for proper state keeping? AFAICS, the current proposal's state machine may operate on response codes/request methods and current state alone. I realize that displaying statistics is important enough to hold on to the dialog_out table; this question is for clarification purposes only.
dialog_out entries are important in order to mantain the proper CSeq of caller and callee and also remote target and route set for each dialog (useful when using the Dialog module MI function to terminate a call). Also dialog_out entries store per (early-)dialog flags (dflags), probably needed by some modules also during early-dialog (i.e. mediaproxy and "engage_media()" method).
Also, currently I see an issue related to "Concurrently confirmed calls":
------------- Immediately afterwards, Bob-2 replies 200 as well. The delay is too short for the proxy to cancel Bob-2 yet so it forwards the response it as well, thereby establishing another dialog. That is, a new dialog_in and dialog_out entry will be created from Bob-2's 200 response and associated with each other. In order to preserve any dflags from the dialog just confirmed, the proxy will also copy the dflags from the dialog_out entry under the current hash ID (which, remember, was passed as part of the callback). Specifically, it will find the dialog_out entry “branch1” for the hash ID “1111a” and copy its dflags to the new dialog_out entry -------------
Imagine the following case:
- alice calls to bob and the proxy forks to bob1 and bob2. - Both replies 183 with SDP. - 183 from bob2 requires PRACK. - alice sends PRACK for bob2 (so its associated entry in dialog_out gets the caller_cseq incremented). - Module XXX sets a dflag(N) just for the dialog with bob1. - bob1 replies 200. - At this point the dialog_out entry for bob2 is destroyed. - But bob2 replies 200 before receiving the CANCEL. - As the text above states a new entry in dialog_out would be created by copying the dflags from the already confirmed dialog_out entry (so dfalg(N) is set), and copying the dialog_in's original_caller_cseq into its caller_cseq.
This would be obviously wrong becase the created dialog for bob2 has a wrong caller_cseq and wrong dflags.
However the solution seems easy: When a dialog gets confirmed mantain the rest of dialog_out entries for a while (maybe 3-5 seconds), time enough to ensure that if a new 200 arrives within an existing early-dialog it will match (an update properly) such entry in dialog_out. What do you think?
Thanks a lot for all, really good job refactoring the page :)
Hi,
Iñaki Baz Castillo wrote:
(1) Is the inv_branch parameter really needed? Initially, my impression was that proxies require it in order to know which branches to prune in case of remote forking and a final response coming in. However, the inv_branch shouldn't be required for that IMHO since callbacks to the response handling function pass along the dialog_in's hash ID that the responses refer to. By matching the dialog_in's dialog_id with entries in the dialog_out table, it can determine all the branches belonging to a given call, and thereby also those that need to be deleted.
Right. As now dialog status just relies on the responses sent upstream to the client I think inv_branch is not required anymore.
I just see a minor issue with this. Imagine P1 is running the Dialog module and a proxy P2 behind it does parallel forking and replies 2 early dialogs. This would mean two entries under dialog_out table. Later P2 sends a negative final response for the first dialog. Just the dialog_out entry matching the To-tag would be deleted, while the other one would exist until the whole dialog is confirmed or terminated. Anyhow, I think this is not a big problem.
Forking proxies do not forward negative replies until a call has been finally deemed unsuccessful. This means that once a negative response arrives at P1, the entire call has failed and thus, P1 may safely delete all branches belonging to that call. The way to find these branches is by looking up all dialog_out entries with the dialog ID that matches the one from the dialog_in table referenced by the callback-provided hash ID. (Oh boy!)
Or, looking at our "Parallel forking" example, if P1's dialog tables would look as following (showing just the relevant columns) right before the reception of a final response:
dialog_in: | hash_id | dialog_id | | 1111 | 1111a |
dialog_out: | dialog_id | To-tag | | 1111a | foo | | 1111a | bar |
Then, on reception of a final negative response, it will extract hash ID 1111 from the dialog callback parameter, find that it maps to dialog ID 1111a, and lookup both dialog_out entries with that dialog ID 1111a.
That's how I see it.
(2) Is the dialog_out table required for anything else but displaying dialog data (e.g., callee To-tag, callee CSeq number, etc.) over the MI interface right now? Specifically, is it needed for proper state keeping? AFAICS, the current proposal's state machine may operate on response codes/request methods and current state alone. I realize that displaying statistics is important enough to hold on to the dialog_out table; this question is for clarification purposes only.
dialog_out entries are important in order to mantain the proper CSeq of caller and callee and also remote target and route set for each dialog (useful when using the Dialog module MI function to terminate a call). Also dialog_out entries store per (early-)dialog flags (dflags), probably needed by some modules also during early-dialog (i.e. mediaproxy and "engage_media()" method).
Alright. I've added some of your examples to the wiki page as further rationale behind the new proposal.
Also, currently I see an issue related to "Concurrently confirmed calls":
Immediately afterwards, Bob-2 replies 200 as well. The delay is too short for the proxy to cancel Bob-2 yet so it forwards the response it as well, thereby establishing another dialog. That is, a new dialog_in and dialog_out entry will be created from Bob-2's 200 response and associated with each other. In order to preserve any dflags from the dialog just confirmed, the proxy will also copy the dflags from the dialog_out entry under the current hash ID (which, remember, was passed as part of the callback). Specifically, it will find the dialog_out entry “branch1” for the hash ID “1111a” and copy its dflags to the new dialog_out entry
Imagine the following case:
- alice calls to bob and the proxy forks to bob1 and bob2.
- Both replies 183 with SDP.
- 183 from bob2 requires PRACK.
- alice sends PRACK for bob2 (so its associated entry in dialog_out
gets the caller_cseq incremented).
- Module XXX sets a dflag(N) just for the dialog with bob1.
- bob1 replies 200.
- At this point the dialog_out entry for bob2 is destroyed.
- But bob2 replies 200 before receiving the CANCEL.
- As the text above states a new entry in dialog_out would be created
by copying the dflags from the already confirmed dialog_out entry (so dfalg(N) is set), and copying the dialog_in's original_caller_cseq into its caller_cseq.
This would be obviously wrong becase the created dialog for bob2 has a wrong caller_cseq and wrong dflags.
However the solution seems easy: When a dialog gets confirmed mantain the rest of dialog_out entries for a while (maybe 3-5 seconds), time enough to ensure that if a new 200 arrives within an existing early-dialog it will match (an update properly) such entry in dialog_out. What do you think?
Sounds reasonable. I wonder how much dependent the current dialog module implementation is on the transaction deletion timer (i.e., if there is already a delay that prevents the dialog from being removed right after a final response has been forwarded). Unless you or someone else knows, I'll try to find that out and update the wiki accordingly.
Cheers,
--Timo
2010/4/12 Timo Reimann timo.reimann@1und1.de:
I just see a minor issue with this. Imagine P1 is running the Dialog module and a proxy P2 behind it does parallel forking and replies 2 early dialogs. This would mean two entries under dialog_out table. Later P2 sends a negative final response for the first dialog. Just the dialog_out entry matching the To-tag would be deleted, while the other one would exist until the whole dialog is confirmed or terminated. Anyhow, I think this is not a big problem.
Forking proxies do not forward negative replies until a call has been finally deemed unsuccessful. This means that once a negative response arrives at P1, the entire call has failed and thus, P1 may safely delete all branches belonging to that call. The way to find these branches is by looking up all dialog_out entries with the dialog ID that matches the one from the dialog_in table referenced by the callback-provided hash ID. (Oh boy!)
Or, looking at our "Parallel forking" example, if P1's dialog tables would look as following (showing just the relevant columns) right before the reception of a final response:
dialog_in: | hash_id | dialog_id | | 1111 | 1111a |
dialog_out: | dialog_id | To-tag | | 1111a | foo | | 1111a | bar |
Then, on reception of a final negative response, it will extract hash ID 1111 from the dialog callback parameter, find that it maps to dialog ID 1111a, and lookup both dialog_out entries with that dialog ID 1111a.
That's how I see it.
And I agree, you are right :)
dialog_out entries are important in order to mantain the proper CSeq of caller and callee and also remote target and route set for each dialog (useful when using the Dialog module MI function to terminate a call). Also dialog_out entries store per (early-)dialog flags (dflags), probably needed by some modules also during early-dialog (i.e. mediaproxy and "engage_media()" method).
Alright. I've added some of your examples to the wiki page as further rationale behind the new proposal.
Thanks.
Imagine the following case:
- alice calls to bob and the proxy forks to bob1 and bob2.
- Both replies 183 with SDP.
- 183 from bob2 requires PRACK.
- alice sends PRACK for bob2 (so its associated entry in dialog_out
gets the caller_cseq incremented).
- Module XXX sets a dflag(N) just for the dialog with bob1.
- bob1 replies 200.
- At this point the dialog_out entry for bob2 is destroyed.
- But bob2 replies 200 before receiving the CANCEL.
- As the text above states a new entry in dialog_out would be created
by copying the dflags from the already confirmed dialog_out entry (so dfalg(N) is set), and copying the dialog_in's original_caller_cseq into its caller_cseq.
This would be obviously wrong becase the created dialog for bob2 has a wrong caller_cseq and wrong dflags.
However the solution seems easy: When a dialog gets confirmed mantain the rest of dialog_out entries for a while (maybe 3-5 seconds), time enough to ensure that if a new 200 arrives within an existing early-dialog it will match (an update properly) such entry in dialog_out. What do you think?
Sounds reasonable. I wonder how much dependent the current dialog module implementation is on the transaction deletion timer (i.e., if there is already a delay that prevents the dialog from being removed right after a final response has been forwarded). Unless you or someone else knows, I'll try to find that out and update the wiki accordingly.
With the current design (the existing one I mean) a dialog is deleted from memory after 4-5 seconds after being terminated. This is due to a TM timer, so it's seems easy to reuse.
Regards.
2010/4/13 Iñaki Baz Castillo ibc@aliax.net:
However the solution seems easy: When a dialog gets confirmed mantain the rest of dialog_out entries for a while (maybe 3-5 seconds), time enough to ensure that if a new 200 arrives within an existing early-dialog it will match (an update properly) such entry in dialog_out. What do you think?
Unfortunatelly I'm trying to figure out this solution and now I don't like it:
- Imagine there are two branches, both with 180. - Both share the same "dialog_id" field in "dialog_out" table. - Bob-1 replies 200. The second entry remains 3 seconds before being deleted. - But before these 3 seconds Bob-2 also replies 200. - Such 200 would match the second "dialog_out" entry, but then, how to change its dialog_id field?? In the example it must change from "1111a" to "1111b".
Any suggestion for it? I leave it as TODO in the wiki for now.
Thanks.
2010/4/13 Iñaki Baz Castillo ibc@aliax.net:
Unfortunatelly I'm trying to figure out this solution and now I don't like it:
- Imagine there are two branches, both with 180.
- Both share the same "dialog_id" field in "dialog_out" table.
- Bob-1 replies 200. The second entry remains 3 seconds before being deleted.
- But before these 3 seconds Bob-2 also replies 200.
- Such 200 would match the second "dialog_out" entry, but then, how to
change its dialog_id field?? In the example it must change from "1111a" to "1111b".
Any suggestion for it? I leave it as TODO in the wiki for now.
Idea:
dflags just can be set in onreply_route (since just the responses create a dialog). So the dialog dflags should be set for 1XX responses and also for a 2XX response (again). This is more a workaround however.
Iñaki Baz Castillo wrote:
2010/4/13 Iñaki Baz Castillo ibc@aliax.net:
However the solution seems easy: When a dialog gets confirmed mantain the rest of dialog_out entries for a while (maybe 3-5 seconds), time enough to ensure that if a new 200 arrives within an existing early-dialog it will match (an update properly) such entry in dialog_out. What do you think?
Unfortunatelly I'm trying to figure out this solution and now I don't like it:
- Imagine there are two branches, both with 180.
- Both share the same "dialog_id" field in "dialog_out" table.
- Bob-1 replies 200. The second entry remains 3 seconds before being deleted.
- But before these 3 seconds Bob-2 also replies 200.
- Such 200 would match the second "dialog_out" entry, but then, how to
change its dialog_id field?? In the example it must change from "1111a" to "1111b".
Any suggestion for it? I leave it as TODO in the wiki for now.
What about this:
When the dialog module detects that a concurrent call is about to be confirmed, it copies that second call's dialog_out entry from the old location (1111a) to a new one (1111b). Afterwards, it creates a new dialog_in entry with the same hash ID (1111) but pointing to the new location (1111b). Along that process, it also copies the first call's dflags just like we have discussed before.
What did I miss at night-time?
Cheers,
--Timo
2010/4/13 Timo Reimann timo.reimann@1und1.de:
Unfortunatelly I'm trying to figure out this solution and now I don't like it:
- Imagine there are two branches, both with 180.
- Both share the same "dialog_id" field in "dialog_out" table.
- Bob-1 replies 200. The second entry remains 3 seconds before being deleted.
- But before these 3 seconds Bob-2 also replies 200.
- Such 200 would match the second "dialog_out" entry, but then, how to
change its dialog_id field?? In the example it must change from "1111a" to "1111b".
Any suggestion for it? I leave it as TODO in the wiki for now.
What about this:
When the dialog module detects that a concurrent call is about to be confirmed, it copies that second call's dialog_out entry from the old location (1111a) to a new one (1111b). Afterwards, it creates a new dialog_in entry with the same hash ID (1111) but pointing to the new location (1111b). Along that process, it also copies the first call's dflags just like we have discussed before.
What did I miss at night-time?
It sounds Ok, but for this we must be really sure that, upon receipt of the first 200, the other pending branches are not immediately removed so the second 200 (after less than 1-2 seconds) would match an entry in dialog_out.
Regards.
Iñaki Baz Castillo wrote:
2010/4/13 Timo Reimann timo.reimann@1und1.de:
Unfortunatelly I'm trying to figure out this solution and now I don't like it:
- Imagine there are two branches, both with 180.
- Both share the same "dialog_id" field in "dialog_out" table.
- Bob-1 replies 200. The second entry remains 3 seconds before being deleted.
- But before these 3 seconds Bob-2 also replies 200.
- Such 200 would match the second "dialog_out" entry, but then, how to
change its dialog_id field?? In the example it must change from "1111a" to "1111b".
Any suggestion for it? I leave it as TODO in the wiki for now.
What about this:
When the dialog module detects that a concurrent call is about to be confirmed, it copies that second call's dialog_out entry from the old location (1111a) to a new one (1111b). Afterwards, it creates a new dialog_in entry with the same hash ID (1111) but pointing to the new location (1111b). Along that process, it also copies the first call's dflags just like we have discussed before.
What did I miss at night-time?
It sounds Ok, but for this we must be really sure that, upon receipt of the first 200, the other pending branches are not immediately removed so the second 200 (after less than 1-2 seconds) would match an entry in dialog_out.
Agreed. Does the SIP standard specify the time interval for which another branch's 200 response must still conclude another (concurrently confirmed) call? Or is this time interval naturally bound to some standard-provided timer?
I've tried to figure that out from RFC 3261 but couldn't find anything.
Cheers,
--Timo
2010/4/14 Timo Reimann timo.reimann@1und1.de:
It sounds Ok, but for this we must be really sure that, upon receipt of the first 200, the other pending branches are not immediately removed so the second 200 (after less than 1-2 seconds) would match an entry in dialog_out.
Agreed. Does the SIP standard specify the time interval for which another branch's 200 response must still conclude another (concurrently confirmed) call? Or is this time interval naturally bound to some standard-provided timer?
I've tried to figure that out from RFC 3261 but couldn't find anything.
Theorically (just RFC 3261) an INVITE transaction is terminated in the exact moment a 200 arrives. See RFC 3261 page 128 (figure 5):
When in either the "Calling" or "Proceeding" states, reception of a 2xx response MUST cause the client transaction to enter the "Terminated" state, and the response MUST be passed up to the TU. [...] The client transaction MUST be destroyed the instant it enters the "Terminated" state. This is actually necessary to guarantee correct operation. The reason is that 2xx responses to an INVITE are treated differently; each one is forwarded by proxies, and the ACK handling in a UAC is different. Thus, each 2xx needs to be passed to a proxy core (so that it can be forwarded) and to a UAC core (so it can be acknowledged). No transaction layer processing takes place. Whenever a response is received by the transport, if the transport layer finds no matching client transaction (using the rules of Section 17.1.3), the response is passed directly to the core. Since the matching client transaction is destroyed by the first 2xx, subsequent 2xx will find no match and therefore be passed to the core.
However all this text is fixed in this draft:
http://tools.ietf.org/html/draft-sparks-sip-invfix-03 now: http://tools.ietf.org/html/draft-sparks-sipcore-invfix-01
A new state "Accepted" is added for client and server transaction diagram. We care now about the client transaction:
7.2. Client Transaction Impacts
In order to correctly distinguish retransmissions of 2xx responses from stray 2xx responses, the INVITE client state machine is modified to not transition immediately to "Terminated" on receipt of a 2xx response. Instead, the machine will transition to a new "Accepted" state, and remain there just long enough, determined by a new timer M, to receive and pass to the TU any retransmissions of the 2xx response or any additional 2xx responses from other branches of a downstream fork of the matching request. If a 2xx response is received while the client INVITE state machine is in the "Calling" or "Proceeding" states, it MUST transition to the "Accepted" state, pass the 2xx response to the TU, and set Timer M to 64*T1. A 2xx response received while in the "Accepted" state MUST be passed to the TU and the machine remains in the "Accepted" state.
So, TM client transaction should wait for 64xT1 seconds before destroying the client transaction after receiving a 200 OK. IMHO this should also be the time the entries in dialog_out should remain. Do you agree?
Regards.
Iñaki Baz Castillo wrote:
2010/4/14 Timo Reimann timo.reimann@1und1.de:
It sounds Ok, but for this we must be really sure that, upon receipt of the first 200, the other pending branches are not immediately removed so the second 200 (after less than 1-2 seconds) would match an entry in dialog_out.
Agreed. Does the SIP standard specify the time interval for which another branch's 200 response must still conclude another (concurrently confirmed) call? Or is this time interval naturally bound to some standard-provided timer?
I've tried to figure that out from RFC 3261 but couldn't find anything.
Theorically (just RFC 3261) an INVITE transaction is terminated in the exact moment a 200 arrives. See RFC 3261 page 128 (figure 5):
[snap]
However all this text is fixed in this draft:
http://tools.ietf.org/html/draft-sparks-sip-invfix-03 now: http://tools.ietf.org/html/draft-sparks-sipcore-invfix-01
A new state "Accepted" is added for client and server transaction diagram. We care now about the client transaction:
[snap]
So, TM client transaction should wait for 64xT1 seconds before destroying the client transaction after receiving a 200 OK. IMHO this should also be the time the entries in dialog_out should remain. Do you agree?
Agreed as discussed on the developer meeting on IRC before.
Cheers,
--Timo
Hi, I've done some pending improvements in the proposed specification. Please Timo, check it as I've done further changes in the "Response processing" section (along with others in "Concurrently confirmed calls" example).
IMHO the proposal is in "Release Candidate 1" status :) Please take a look to it and comment anything you consider. As it is now all the corner cases should already be covered (if not, it's a bug).
Thanks a lot.
Iñaki Baz Castillo wrote:
Hi, I've done some pending improvements in the proposed specification. Please Timo, check it as I've done further changes in the "Response processing" section (along with others in "Concurrently confirmed calls" example).
IMHO the proposal is in "Release Candidate 1" status :) Please take a look to it and comment anything you consider. As it is now all the corner cases should already be covered (if not, it's a bug).
Your changes look good, they pretty much fill a few gaps. I made some more changes, basically just details. Please have a look at it.
One thing worth mentioning is that I proposed to introduce a new callback DLGCB_CREATED_CONCUR which is executed every time a concurrently confirmed call is established. I've been thinking about whether such calls should be mapped to DLGCB_CREATED but came to the conclusion that it should be a separate callback: This type of call is pretty much a corner case, not only because it happens rarely but also because it doesn't follow the regular "INVITE requests initiate dialogs" schema. Therefore, I believe it deserves a special callback, even at the price of having to register for another callback type. The alternative would be to use DLGCB_CREATED and provide a flag to indicate whether a regular or concurrent session setup is involved. Personally, I find the DLGCB_CREATED_CONCUR approach cleaner as it indicates to the user that the way a dialog has just been established requires special attention. What's your opinion on this issue?
Apart from that, the following remarks/questions remain to me:
(1) Why did you remove sflags? Is it not used anymore? I should mention though that I never fully grasped what it was good for so you'll have an easy time convincing me. :)
(2) In the "Response processing" section, it says:
"1. First, inspect if there is an already dialog_out entry with same To-tag (for the same dialog):
1. [...] 2. If so, update the matching dialog_out entry in case the response includes new information (as “Contact” header or route set)."
Is it possible to specify the cases when such updating is needed? This will get important when we reach the point of implementation as you likely do not want to compare every possible header value for a possible update.
Cheers,
--Timo
2010/4/15 Timo Reimann timo.reimann@1und1.de:
Your changes look good, they pretty much fill a few gaps. I made some more changes, basically just details. Please have a look at it.
Great. I've just fixed an error when you say:
- If it's "confirmed" then this is a "concurrently confirmed call" case. Create a new Dialog ID token **X** and assign it to the created or updated //dialog_out// entry. Then, duplicate the //dialog_in// entry, set its Dialog ID value to **X**, and copy the dflags from a previously confirmed //dialog_out// entry.
As I already explained in a previous mail in this thread, copying dflags is not appropriate. Imagine you set mediaproxy dflag for first provisional response (fisrt dialog) but not for the second provisional response (second dialog) as second UAS is not behind NAT. If the second UAS replies a second 200, it should not get the mediaproxy dflag for its confirmed dialog.
In fact the solutio is doing nothing. After the first 200 all the entries in dialog_out still exist for a while (until transaction expires by TM), so the second 200 would match its dialog_out entry (with custom dflags) and just needs to update its dialog_id. So IMHO there is no need to do nothing else.
One thing worth mentioning is that I proposed to introduce a new callback DLGCB_CREATED_CONCUR which is executed every time a concurrently confirmed call is established. I've been thinking about whether such calls should be mapped to DLGCB_CREATED but came to the conclusion that it should be a separate callback: This type of call is pretty much a corner case, not only because it happens rarely but also because it doesn't follow the regular "INVITE requests initiate dialogs" schema. Therefore, I believe it deserves a special callback, even at the price of having to register for another callback type. The alternative would be to use DLGCB_CREATED and provide a flag to indicate whether a regular or concurrent session setup is involved. Personally, I find the DLGCB_CREATED_CONCUR approach cleaner as it indicates to the user that the way a dialog has just been established requires special attention. What's your opinion on this issue?
I agree. This is a real corner case and shouldn't "dirty" the most normal cases :)
Apart from that, the following remarks/questions remain to me:
(1) Why did you remove sflags? Is it not used anymore? I should mention though that I never fully grasped what it was good for so you'll have an easy time convincing me. :)
I already asked somewhere what such sflag means. Nobody answered so I suspect it's not important (in fact I cannot imagine its usage). Of course is somebody explains its usage it can be easily added :)
(2) In the "Response processing" section, it says:
"1. First, inspect if there is an already dialog_out entry with same To-tag (for the same dialog):
1. [...] 2. If so, update the matching dialog_out entry in case the response includes new information (as “Contact” header or route set)."
Is it possible to specify the cases when such updating is needed? This will get important when we reach the point of implementation as you likely do not want to compare every possible header value for a possible update.
Good point. Note that during an INVITE transaction the Contact and route set (Record-Route headers) could happen in a provisional response (optionally) and in the 200 (mandatory). However there are some rules I must study. For example: if the Route set changes in the 200 they must be ignored (or perhaps it was the Contact?). I remember I open a long thread in SIP implementors maillist about it, resulting in a very good explanation of all this stuf. I must find it.
Regards.
Iñaki Baz Castillo wrote:
2010/4/15 Timo Reimann timo.reimann@1und1.de:
Your changes look good, they pretty much fill a few gaps. I made some more changes, basically just details. Please have a look at it.
Great. I've just fixed an error when you say:
- If it's "confirmed" then this is a "concurrently confirmedcall" case. Create a new Dialog ID token **X** and assign it to the created or updated //dialog_out// entry. Then, duplicate the //dialog_in// entry, set its Dialog ID value to **X**, and copy the dflags from a previously confirmed //dialog_out// entry.
As I already explained in a previous mail in this thread, copying dflags is not appropriate. Imagine you set mediaproxy dflag for first provisional response (fisrt dialog) but not for the second provisional response (second dialog) as second UAS is not behind NAT. If the second UAS replies a second 200, it should not get the mediaproxy dflag for its confirmed dialog.
In fact the solutio is doing nothing. After the first 200 all the entries in dialog_out still exist for a while (until transaction expires by TM), so the second 200 would match its dialog_out entry (with custom dflags) and just needs to update its dialog_id. So IMHO there is no need to do nothing else.
You are right, copying flags makes no sense and the transaction deletion timer will make sure set flags will still be there. Case closed.
(2) In the "Response processing" section, it says:
"1. First, inspect if there is an already dialog_out entry with same To-tag (for the same dialog):
- [...]
- If so, update the matching dialog_out entry in case the response includes new information (as “Contact” header or route set)."
Is it possible to specify the cases when such updating is needed? This will get important when we reach the point of implementation as you likely do not want to compare every possible header value for a possible update.
Good point. Note that during an INVITE transaction the Contact and route set (Record-Route headers) could happen in a provisional response (optionally) and in the 200 (mandatory). However there are some rules I must study. For example: if the Route set changes in the 200 they must be ignored (or perhaps it was the Contact?). I remember I open a long thread in SIP implementors maillist about it, resulting in a very good explanation of all this stuf. I must find it.
Alright. Let me know when you found the time to dig it out.
Cheers,
--Timo
2010/4/15 Timo Reimann timo.reimann@1und1.de:
Alright. Let me know when you found the time to dig it out.
This is the thread. I must re-read it: https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-August/020028....
2010/4/15 Iñaki Baz Castillo ibc@aliax.net:
2010/4/15 Timo Reimann timo.reimann@1und1.de:
Alright. Let me know when you found the time to dig it out.
This is the thread. I must re-read it: https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-August/020028....
The conclusion is easy:
The 200 must contain Record-Route and Contact so the Dialog module shuld just care about such fields in the 2XX response. Anyhow, for information purposes, it could extract these fields from provisional responses and set the dialog_out entries according. I will add it to the wiki.
Other issue: dialog flags.
The proposal just allows setting a dflag during onreply_route. This makes a lot of sense as there is no dialog yet in route, branch_route and failure_route. So setdflag() function just could be inoked in onreply_route. Is it ok?
Regards.
Iñaki Baz Castillo wrote:
2010/4/15 Iñaki Baz Castillo ibc@aliax.net:
2010/4/15 Timo Reimann timo.reimann@1und1.de:
Alright. Let me know when you found the time to dig it out.
This is the thread. I must re-read it: https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-August/020028....
The conclusion is easy:
The 200 must contain Record-Route and Contact so the Dialog module shuld just care about such fields in the 2XX response. Anyhow, for information purposes, it could extract these fields from provisional responses and set the dialog_out entries according.
What about terminating early dialogs using the MI interface? Assuming that a provisional response carried a Contact header and no final response was sent yet, it seems to me that terminating such an early dialog would only be possible if the dialog module actually stored the header. This is beyond purely informational purposes.
On the other hand, I don't think terminating early dialogs isn't supported by the current implementation anyway. Changing that would just mean another feature, making it less critical.
Other issue: dialog flags.
The proposal just allows setting a dflag during onreply_route. This makes a lot of sense as there is no dialog yet in route, branch_route and failure_route. So setdflag() function just could be inoked in onreply_route. Is it ok?
Dialogs are already established in spiraling cases, however. Might it prove useful if dflag manipulation worked the instant a spiral is happening (which may be in route or branch_route)?
Cheers,
--Timo
2010/4/15 Timo Reimann timo.reimann@1und1.de:
Iñaki Baz Castillo wrote:
2010/4/15 Iñaki Baz Castillo ibc@aliax.net:
2010/4/15 Timo Reimann timo.reimann@1und1.de:
Alright. Let me know when you found the time to dig it out.
This is the thread. I must re-read it: https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-August/020028....
The conclusion is easy:
The 200 must contain Record-Route and Contact so the Dialog module shuld just care about such fields in the 2XX response. Anyhow, for information purposes, it could extract these fields from provisional responses and set the dialog_out entries according.
What about terminating early dialogs using the MI interface? Assuming that a provisional response carried a Contact header and no final response was sent yet, it seems to me that terminating such an early dialog would only be possible if the dialog module actually stored the header. This is beyond purely informational purposes.
Yes, right. What I've added to the wiki allows this feature in fact :)
On the other hand, I don't think terminating early dialogs isn't supported by the current implementation anyway. Changing that would just mean another feature, making it less critical.
Could it be specified into the proposal as a requeriment? anyhow is not critical at all.
Other issue: dialog flags.
The proposal just allows setting a dflag during onreply_route. This makes a lot of sense as there is no dialog yet in route, branch_route and failure_route. So setdflag() function just could be inoked in onreply_route. Is it ok?
Dialogs are already established in spiraling cases, however.
Well, I don't consider it an established dialog, but just a "prosceeding" dialog (an entry in dialog_in) which prevent the creation of a new one in order to avoid spirals.
Might it prove useful if dflag manipulation worked the instant a spiral is happening (which may be in route or branch_route)?
Humm, I don't see how it could be useful.
Iñaki Baz Castillo wrote:
2010/4/15 Timo Reimann timo.reimann@1und1.de:
Iñaki Baz Castillo wrote:
2010/4/15 Iñaki Baz Castillo ibc@aliax.net:
2010/4/15 Timo Reimann timo.reimann@1und1.de:
Alright. Let me know when you found the time to dig it out.
This is the thread. I must re-read it: https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-August/020028....
The conclusion is easy:
The 200 must contain Record-Route and Contact so the Dialog module shuld just care about such fields in the 2XX response. Anyhow, for information purposes, it could extract these fields from provisional responses and set the dialog_out entries according.
What about terminating early dialogs using the MI interface? Assuming that a provisional response carried a Contact header and no final response was sent yet, it seems to me that terminating such an early dialog would only be possible if the dialog module actually stored the header. This is beyond purely informational purposes.
Yes, right. What I've added to the wiki allows this feature in fact :)
On the other hand, I don't think terminating early dialogs isn't supported by the current implementation anyway. Changing that would just mean another feature, making it less critical.
Could it be specified into the proposal as a requeriment? anyhow is not critical at all.
If it's a lot of effort, I wouldn't make it a requirement. However, since we will have to touch the MI functions anyway (e.g., Contact headers from both caller and callee are now stored in different tables), terminating early dialogs might be easily implemented anyway.
But as we agree that it's non-critical, let's just make it low-priority.
Other issue: dialog flags.
The proposal just allows setting a dflag during onreply_route. This makes a lot of sense as there is no dialog yet in route, branch_route and failure_route. So setdflag() function just could be inoked in onreply_route. Is it ok?
Dialogs are already established in spiraling cases, however.
Well, I don't consider it an established dialog, but just a "prosceeding" dialog (an entry in dialog_in) which prevent the creation of a new one in order to avoid spirals.
Yeah sorry that's what I meant, establishing as in a dialog structure has been set up.
Might it prove useful if dflag manipulation worked the instant a spiral is happening (which may be in route or branch_route)?
Humm, I don't see how it could be useful.
Ok so let's settle with onreply_route.
Cheers,
--Timo
On Thursday 15 April 2010, Iñaki Baz Castillo wrote:
I already asked somewhere what such sflag means. Nobody answered so I suspect it's not important (in fact I cannot imagine its usage). Of course is somebody explains its usage it can be easily added :)
Hi Iñaki,
this are the stored dialog script flags. They can be checked with exported functions (dlg_setflag(..), as described in the dialog readme. If you want to keep these three functions, you probably would also need the column in the DB.
Cheers,
Henning
2010/4/15 Henning Westerholt henning.westerholt@1und1.de:
On Thursday 15 April 2010, Iñaki Baz Castillo wrote:
I already asked somewhere what such sflag means. Nobody answered so I suspect it's not important (in fact I cannot imagine its usage). Of course is somebody explains its usage it can be easily added :)
Hi Iñaki,
this are the stored dialog script flags. They can be checked with exported functions (dlg_setflag(..), as described in the dialog readme. If you want to keep these three functions, you probably would also need the column in the DB.
Thanks, you are right. However this is better accomplished in the new design as each early dialog could have different dflags (something not possible with the current Dialog module). See http://www.kamailio.org/dokuwiki/doku.php/dialog-stateful:new-dialog-module-...
Apart from that, I've done some improvements in the proposal by explaining how the dialog_out entries are updated (and also by adding more information about dflags).
Regards.
On Thursday 15 April 2010, Iñaki Baz Castillo wrote:
this are the stored dialog script flags. They can be checked with exported functions (dlg_setflag(..), as described in the dialog readme. If you want to keep these three functions, you probably would also need the column in the DB.
Thanks, you are right. However this is better accomplished in the new design as each early dialog could have different dflags (something not possible with the current Dialog module).
Hi Iñaki,
don't used this specific feature yet, if there is a compatible replacement its just fine for me.
Cheers,
Henning
2010/4/15 Henning Westerholt henning.westerholt@1und1.de:
On Thursday 15 April 2010, Iñaki Baz Castillo wrote:
this are the stored dialog script flags. They can be checked with exported functions (dlg_setflag(..), as described in the dialog readme. If you want to keep these three functions, you probably would also need the column in the DB.
Thanks, you are right. However this is better accomplished in the new design as each early dialog could have different dflags (something not possible with the current Dialog module).
Hi Iñaki,
don't used this specific feature yet, if there is a compatible replacement its just fine for me.
It's not fully compatible as the current specification of the dialog flags module is "buggy" (along with the full module due its limitations). IMHO it's clear that this is different of a transaction flag mechanism. The dialog exists after a response > 100 is received so just when handling such response makes sense to set, reset or inspect a dflag.
Regards.
-
Henning Westerholt -
Iñaki Baz Castillo -
Timo Reimann