Subject: Re: [Sip] Questions on subscription dialogs (correction)

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 1 Mar 2006 10:42:54 +0100

Paul,

What should also be mentioned here is RFC4235 (dialog event package) which 
is to my knowledge the first place where the dialog FSM is explicitly 
defined. Consequently, to support that package your 'dialog' class would 
need a 'state' attribute with values from { Trying, Early, Proceeding, 
Confirmed, Terminated }

So
attribute : state

Furthermore, the dialog could also maintain state about the peer's SIP 
capabilities:
attribute: allowedMethods
attribute: allowedEvents
attribute: acceptedContentTypes ( perhaps also for languages, encodings, 
etc, i.e. all the Accept-* headers)

Then, for 100rel support you would need
association: pending 100rel responses (i.e. those that have not been PRACKed 
yet)

In addition, for dialog-usage (from RFC3261 section 12.1.1)
attribute: secure
I first considered this to be part of the dialog class, given that once the 
"secure" flag is set each Contact MUST be SIPS and hence a transition to 
unsecure is not possible. But then I realized that one could start unsecure 
(i.e. with INVITE sip:AoR ) but provide a SIPS Contact, then start a new 
dialog usage (e.g. SUBSCRIBE sips:Contact )

BTW, this leads me to think that this is an omission in RFC3261: It should 
state that
1) The "secure" flag should be set not only when the dialog-creating request 
is sent over TLS using a SIPS URI (section 12.1.2), but also when a SIPS 
Contact is provided
2) At the UAS side (section 12.1.1) the "secure" flag should be set not only 
when the request arrives over TLS, but also if the received Contact is SIPS 
or the Contact provided in the response is SIPS
3) The UAC should set its "secure" flag if the Contact provided in the 
dialog-creating response (by the UAS) is SIPS
4) The "secure" flag should be set when a target-refresh request includes a 
SIPS Contact

Alternatively, perhaps it should explicitly be disallowed for UAC to send a 
request using "sip:" while providing a "sips:" Contact. A UAS that provides 
a "sips:" Contact for a "sip:" request is also questionable, since the other 
side may not support TLS. This is also something that could be stated 
explicitly

Regards,

jeroen

>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
>
> class: invite-dialog-usage
>   superclass: 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
>   superclass: dialog-usage
>   attribute: expiration-time
>   attribute: event-type
>   attribute: event-parameters
>   attribute: event-id
>   attribute: direction (watcher/notifier)
>   attribute: ...
>
> 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 

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

I sense some interest in doing some work here. Given all the discussion 
about the amount of work in the groups, we should discuss whether this 
is work the group (presumably sip or sipping) wants to take on. Maybe 
this is a subject for hallway discussion at the Dallas meeting.

More inline.

	Paul

Jeroen van Bemmel wrote:
> Paul,
> 
> What should also be mentioned here is RFC4235 (dialog event package) 
> which is to my knowledge the first place where the dialog FSM is 
> explicitly defined. Consequently, to support that package your 'dialog' 
> class would need a 'state' attribute with values from { Trying, Early, 
> Proceeding, Confirmed, Terminated }
> 
> So
> attribute : state

In spite of its name, the dialog event package isn't about dialogs, it 
is about invite dialog usages. (It doesn't report anything about 
subscriptions.)

So that attribute needs to be added to invite dialog usage.

> etc, i.e. all the Accept-* headers)

This is a hot button of mine. The scope is currently undefined for 
Supported, Required, Accept-*. It is debatable whether they are or 
should be dialog scoped.

> association: pending 100rel responses (i.e. those that have not been 
> PRACKed yet)

Yup.

> I first considered this to be part of the dialog class, given that once 
> the "secure" flag is set each Contact MUST be SIPS and hence a 
> transition to unsecure is not possible. But then I realized that one 
> could start unsecure (i.e. with INVITE sip:AoR ) but provide a SIPS 
> Contact, then start a new dialog usage (e.g. SUBSCRIBE sips:Contact )

I'm not at all sure about this. (Haven't thought about it.) But target 
refresh affects all usages, so if target refresh affects the secure 
flag, then that would be dialog state.

> BTW, this leads me to think that this is an omission in RFC3261: It 
> should state that
> 1) The "secure" flag should be set not only when the dialog-creating 
> request is sent over TLS using a SIPS URI (section 12.1.2), but also 
> when a SIPS Contact is provided
> 2) At the UAS side (section 12.1.1) the "secure" flag should be set not 
> only when the request arrives over TLS, but also if the received Contact 
> is SIPS or the Contact provided in the response is SIPS
> 4) The "secure" flag should be set when a target-refresh request 
> includes a SIPS Contact
> 
> Alternatively, perhaps it should explicitly be disallowed for UAC to 
> send a request using "sip:" while providing a "sips:" Contact. A UAS 
> that provides a "sips:" Contact for a "sip:" request is also 
> questionable, since the other side may not support TLS. This is also 
> something that could be stated explicitly
> 
> Regards,
> 
> jeroen
> 
>> 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
>>> 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.
>>>
>>> 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.
>>>
>>>>>> 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?
>>>>>
>>>>>
>>>>>
>>> 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