Subject: RE: [Sip] Questions on subscription dialogs

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 1 Mar 2006 14:12:05 +0100

Hi, 

>>[CHH] Yes. The question is, again, whether you require a (re-)INVITE 
>>for that, or if you can use an UDPATE, but I guess that (and all other

>>unwritten rules related to this) shall be defined (unless they already
>>are) in the dialog usage draft.
>IMO this stuff has been captured in the Sawada offer/answer draft.

[CHH] Fair enough, I'll check that.

However, the usage of UPDATE as such within a non-invite dialog has
nothing to do with offer/answer, and should also be documented in a
dialog related specification.

>>And, one thing which is missing from your "UML diagram" is 
>>refer-dialogs. Because, I guess a refer dialog is not just a 
>>subscribe-dialog, is it?
>I've been through an implementation of this, and IMO a refer dialog
usage is no different from a subscribe-dialog-usage. Different
mechanisms are used to 
>establish them, but once that process is kicked off there is no
remaining difference - the same state is maintained for each, and the
same mechanism 
>(resubscribe) is used to refresh them.

[CHH] The REFER request does not contain subscription duration
information. So, if there are no resubscribes, for how long does the
refer dialog live?

And, if I send the REFER request within a invite dialog, and then send
BYE for the invite dialog, the refer dialog will stay alive?

Regards,

Christer

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 01 Mar 2006 08:31:02 -0500

> dialog related specification.

Perhaps. IMO it should simply state that such usage is not permitted.

> information. So, if there are no resubscribes, for how long does the

I think that is covered in the REFER RFC. How the value is initially 
determined is part of the unique process of establishing the usage, but 
once established IMO it is no different. In other words, *some* 
expiration time is determined and becomes part of the state.

> BYE for the invite dialog, the refer dialog will stay alive?

IMO it is clear that the refer dialog usage MUST stay alive until the 
watcher terminates it with resubscribe or the notifier terminates it 
with a final NOTIFY. Like most of this information, I think this is 
implied by current RFCs but is often not very explicitly called out. So 
explicit clarification is desirable.

	Paul

	Paul