Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route and tranaction state model.

["Christer Holmberg" <[e-mail]>]

Hi, 
  
>>>>REFER is an odd case. It is always described as creating an implicit

>>>>subscription. I think this means that it is not a SUBSCRIBE. My view

>>>>is that REFER creates an explicit subscription to a specific event 
>>>>package, "dialog progress". If REFER is not creating a subscription 
>>>>the 'norefersub' should be included.
>>>>
>>>>3625bis does create an interesting case for REFER, REFER 
>>>>dialogs are created when the 202 Accepted is received. Is  this
going 
>>>>to be the case or should the NOTIFY be used?
>>>It makes at least as much sense in the REFER case as the SUBSCRIBE
case.
>>>I worked on an impl of SUBSCRIBE and REFER, and definitely shared 
>>>code between them.
>>>
>>>It will be bad enough to migrate an implementation from 3265 to
3265bis.
>>>It will be much worse if REFER creates a dialog but SUBSCRIBE does
not.
>>>
>>>>Do we also need to rewrite RFC3515?
>>>I don't suppose it could be part of 3265bis? :-(
>> 
>>Would we then also deprecate dialog re-use for REFER?
> 
>I don't know. I think dialog reuse for REFER is quite 
>institutionalized, so it would be very difficult to remove it now.

I agree. 

But, that means that dialog re-use for subscriptions are still
possilble, even if invovled entities otherwise are 3265bis compliant.
Maybe that should be mentioned in 3265bis.

Regards,

Christer