Subject: RE: [Sip] Questions on subscription dialogs

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

Hi Jonathan,

The draft does not currently cover the media issue. But, I think it
SHALL cover it.

Regards,

Christer

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: 28. helmikuuta 2006 17:14
To: Paul Kyzivat
Cc: Christer Holmberg (JO/LMF); IETF SIP List
Subject: Re: [Sip] Questions on subscription dialogs

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

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

-Jonathan R.

Paul Kyzivat wrote:

> Christer,
> 
> More in line. Once again we are spelling out the unwritten rules of 
> dialogs.
> 
>     Paul
> 
> Christer Holmberg (JO/LMF) wrote:
> 
>> 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"? :)
> 
> 
> 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.
> 
>>>> 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.
> 
> 
> 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.
> 
>>> 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...
> 
> 
> I doubt it is said anywhere. Its another thing that has evolved via 
> discussion, and enshrined in draft-sawada-sipping-sip-offeranswer-00.
> 
>>>>> 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.
> 
> 
> We are in violent agreement here.
> 
>>> 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. 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: ...
> 
> _______________________________________________
> 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
> 

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

_______________________________________________
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: Robert Sparks <[email-masked]>
Date: Wed, 1 Mar 2006 10:13:54 -0600

Christer -

I'm not yet sure exactly what you're looking for the draft to cover  
wrt the media issue.
Was it specifically an answer to your first question? If not, could  
you summarize for me?

The draft talks about dialogs and dialog usages in general. It uses  
SUBSCRIBE dialogs
only as motivating examples.

To respond to your initial question - as this draft points out, you  
are asking for a
world of interoperability hurt to attempt to create an INVITE usage  
inside the
SUBSCRIBE usage. Yes - it is legal per 3261, but the general  
consensus is that
it is a really bad idea, and the intent of the dialog-usage draft is  
to capture why.

RjS