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

[Timo Reimann]

Iñaki Baz Castillo wrote:
> 2010/4/15 Timo Reimann <timo.reimann at 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.

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):
>>
>>   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.

Alright. Let me know when you found the time to dig it out.


Cheers,

--Timo