Subject: RE: [Sip] Questions on subscription dialogs

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

Hi Paul, 

>>>If you have just a subscription, and what to change the target, you 
>>>can use a resubscribe. No need to use UPDATE or INVITE to accomplish
that.
>>> 
>>[CHH] I agree. However, my main issue was not so much related to 
>>updating of the target, but more to the possibility to add media to an

>>ongoing subscription dialog.
>IMO the media is a property of an invite dialog usage. You can't add
media directly to a dialog, you must first add an invite dialog usage to
the dialog 
>and then it can have media. 

[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.

>I don't want to attempt drawing a UML diagram here with text art, so I
will try to do it with text:

[CHH] For the class dialog I guess you need two cseq attributes, one for
each direction, as in chapter 1 of the dialog usage draft.

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?

In fact, I think it would be good to document (e.g. in the dialog usage
draft) also the different dialog usage "subclasses", and what
information they contain. It may be obvious when reading the associated
RFCs/drafts, but the dialog usage draft is supposed to collect this kind
of information, so...

Regards,

Christer

	class: dialog
	  attribute: cseq
	  attribute: callid
	  attribute: to-tag
	  attribute: from-tag
	  attribute: route set
	  attribute: local contact
	  attribute: remote contact
	  attribute: ...
	  subclass: zero or one invite-dialog-usage
	  subclass: zero or more subscribe-dialog-usage

	class: invite-dialog-usage
	  attribute: expiration-time
	  attribute: active offer
	  attribute: active answer
	  attribute: offer/answer state
	  attribute: pending offer
	  attribute: pending answer
	  attribute: zero or more media-session
	  attribute: ...

	class: subscribe-dialog-usage
	  attribute: expiration-time
	  attribute: event-type
	  attribute: event-parameters
	  attribute: event-id
	  attribute: direction (watcher/notifier)
	  attribute: ...

_______________________________________________
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 07:55:21 -0500

> are) in the dialog usage draft.

IMO this stuff has been captured in the Sawada offer/answer draft.

> each direction, as in chapter 1 of the dialog usage draft.

Right.

> refer-dialogs. Because, I guess a refer dialog is not just a

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.

> RFCs/drafts, but the dialog usage draft is supposed to collect this kind

Yeah, that would be a good idea.

	Paul