[sr-dev] new dialog module design: tm trigger for dialog management

[Timo Reimann]

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