Subject: RE: [Sip] Questions on subscription dialogs

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 28 Feb 2006 10:55:52 +0100

Hi Paul,

Thanks for your reply! Comments inline ([CHH]). 

>>Q1: Is it allowed to send non-NOTIFY request within a subscription 
>>dialog (initiated by SUBSCRIBE), assuming the users support it?
>>
>Yes, with limits. In general, a request that is legal outside a dialog
is also legal within a dialog. (E.g. OPTIONS.) In some cases (e.g. 
>MESSAGE) other limitations have been applied. (You aren't supposed to
use MESSAGE within a dialog as a way to avoid session mode messaging.)
>
>It is legal, though generally discouraged, to send requests within an
existing dialog that establish a new dialog usage. Sending an INVITE
within a 
>dialog established by a SUBSCRIBE falls into this category.

[CHH] Is the discouragement documented somewhere? Or, is it just one of
the "unwritten rules"? :)

>>Q2: If Q1==TRUE, is it allowed to add media during a subscription 
>>dialog, by sending an SDP offer in an UPDATE/re-INVITE?
>An INVITE in this case (at least the first one) would not be a
reINVITE. 
>It would establish a new invite dialog usage within an already
established dialog.

[CHH] Well, it would contain a To tag, and I believe it is said
somewhere that it then should be treated as a re-INVITE. But, at the end
I guess it doesn't matter what we call it, as long as it is allowed to
send it.

>IMO an UPDATE is only permitted within an existing invite dialog usage.

>So you would have to send an INVITE to establish the usage before you
could use UPDATE to do a subsequent offer/answer.

[CHH] Where is that said? I was looking in RFC 3311, and eventhough the
text examples talk about INVITE initiated dialogs I didn't find any text
forbidding it to be used elswhere. But, of course I may have missed
it...

>>>Q3: If Q2==TRUE, is it allowed to use re-INVITE, eventhough the
dialog was not initiated using INVITE?
>>See above. Beware that I have heard of no implementation that actually
support this.

[CHH] Neither have I - so far :)

>>Q4: If Q1==TRUE, if I send an empty re-INVITE within a subscription 
>>dialog, e.g. to update the remote target, I assume the receiver MUST 
>>create and include an SDP offer in the 200 OK response, eventhough no 
>>media has previously been used within the dialog?
>Again see above. The invite must follow all the normal rules.
>
>Note that as defined, all the usages of the dialog share the same
targets. If you have a dialog shared by an invite usage and a subscribe
usage, then 
>either a reinvite or a resubscribe will update the target they share in
common.

[CHH] I agree. It's still the same dialog, I think, eventhough there
seem to be different "usage" of it. But, if you use (re-)INVITE, an SDP
offer MUST be included (either in the request or response), according to
the normal rules.

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

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: Tue, 28 Feb 2006 08:44:08 -0500

Christer,

More in line. Once again we are spelling out the unwritten rules of dialogs.

	Paul

> the "unwritten rules"? :)

I believe it has mostly been written in email threads here. I'm not sure 
if it is enshrined in any RFC or draft. (I think it might be mentioned 
in the target-dialog draft, and I think it might be mentioned in a draft 
by ben or robert.)

I know there was a discussion thread a few months ago about this. I was 
nearly alone in advocating that shared dialogs are not always evil.

> I guess it doesn't matter what we call it, as long as it is allowed to

You may be right. The language in 3261 is very sloppy in this regard. It 
implies, but doesn't formalize, the notion of dialog usages, and mixes 
up dialogs and their usages a lot. IMO a reinvite refreshes an invite 
dialog usage.

> forbidding it to be used elswhere. But, of course I may have missed

I doubt it is said anywhere. Its another thing that has evolved via 
discussion, and enshrined in draft-sawada-sipping-sip-offeranswer-00.

> offer MUST be included (either in the request or response), according to

We are in violent agreement here.

> 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. I don't want to attempt drawing a 
UML diagram here with text art, so I will try to do it with text:

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Feb 2006 09:20:23 -0500

I botched up the data model I posted in the last message. (Too early in 
the morning.) I will try again:

	class: dialog
	  attribute: cseq
	  attribute: callid
	  attribute: to-tag
	  attribute: from-tag
	  attribute: route set
	  attribute: local contact
	  attribute: remote contact
	  association: one or more dialog-usage
	    constraint: at most one invite-dialog-usage
	  attribute: ...

	class: dialog-usage
	  association: exactly one dialog

	  superclass: dialog-usage

	  superclass: dialog-usage

Paul Kyzivat wrote:
>>>> create and include an SDP offer in the 200 OK response, eventhough 
>>>> no media has previously been used within the dialog?
>>>
>>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 28 Feb 2006 10:13:40 -0500

I think most of the wisdom on dialog usages is captured in:

http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialogusage-00.txt

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com