Subject: RE: [Sip] Questions on subscription dialogs

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

Hi, 

>>[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.
>Perhaps. IMO it should simply state that such usage is not permitted.

[CHH] IF that is the decission, yes, assuming that SUBSCRIBE (for
subscription dialogs) can be used to achieve everything legal one would
like to use UPDATE for. I am not arguing against you - I just think we
need to be very sure. 

>>[CHH] The REFER request does not contain subscription duration 
>>information. So, if there are no resubscribes, for how long does the 
>>refer dialog live?
>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.
>>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?
>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.

What if there never is any NOTIFY, and no resubscribe? I know this would
happen mostly/only in error cases, e.g. when end-points are rebooted
etc, but it may happen. Yes, one CAN say it's an "implementation issue".

For invite dialogs this can be handled using the session-timer
mechanism, but it can't be used for a refer/subscription dialog...

The session-timer, and how it affects different dialog usages, is
probably something that should also be mentioned in the dialog usage
draft, I think.

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

The problem is that the old RFCs don't (for obvious reasons) talk about
dialog usage. They talk more about "requests within existing dialogs",
and then it's not that obvious that terminating that existing dialog may
not necessarily terminate whatever the request created.

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: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 2 Mar 2006 06:51:24 +0100

Hi Robert, 

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

The draft does give a general statement, saying that dialog re-usage is
a bad idea (I may not fully agree, but that's another issue). 

I do not believe the draft talks about "INVITE usage inside the
SUBSCRIBE usage". Maybe I've missed it, and/or maybe we don't want to
describe all "usage combinations", but I don't think it's there.

Anyway, I will provide my comments on the draft itself in a separate
e-mail, so let's move the discussion there.

Regards,

Christer

On Mar 1, 2006, at 4:11 AM, Christer Holmberg ((JO/LMF)) wrote:

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

_______________________________________________
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