15 Apr
2010
15 Apr
'10
3:53 p.m.
2010/4/15 Timo Reimann <timo.reimann(a)1und1.de>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
<ibc(a)aliax.net>