Subject: [sipcore] Question on Require in responses

From: "Elwell, John" <[email-masked]>
Date: Mon, 27 Apr 2009 14:22:40 +0100

What is the meaning of the Require header field in responses (in general
- not the specific use in RFC 3262)?

The table in section 20 of RFC 3261 does not limit the field to
requests, but the description in 20.32 only describes meaning for the
field when used in requests.

John

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Apr 2009 09:32:46 -0400

John,

I don't have a general answer for you. IMO the answer to this is closely 
related to the definition of the scope of the negotiated agreement, 
which AFAIK is never defined in a general way, but may be defined for 
certain options.

As a example, 3262 defines the use of Require:100rel in responses.

	Thanks,
	Paul

Elwell, John wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 27 Apr 2009 16:01:09 +0200

But I think the essence of the question is that Require in requests is a compatibility mechanism. As such, a receiver performs actions if it DOES NOT understand the option tag.

I would understand that the RFC 3262 usage is that the receiver performs NO ACTION if it does not understand the option tag. Would it be reasonably to assume that is a general usage of Require when received in responses. 

regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Monday, April 27, 2009 2:33 PM
> To: Elwell, John
> Cc: SIPCORE
> Subject: Re: [sipcore] Question on Require in responses
> 
> John,
> 
> I don't have a general answer for you. IMO the answer to this 
> is closely related to the definition of the scope of the 
> negotiated agreement, which AFAIK is never defined in a 
> general way, but may be defined for certain options.
>

---

From: Brett Tate <[email-masked]>
Date: Mon, 27 Apr 2009 07:18:21 -0700

The following is a snippet from RFC 3261 section 8.2.4: 

"Any extensions applied to a non-421 response MUST be listed in a Require header field included in the response.  Of course, the server MUST NOT apply extensions not listed in the Supported header field in the request."

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Elwell, John
> Sent: Monday, April 27, 2009 9:23 AM
> To: SIPCORE
> Subject: [sipcore] Question on Require in responses
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Apr 2009 10:35:48 -0400

Keith,

I don't think I understand the point you are making.

DRAGE, Keith (Keith) wrote:
> But I think the essence of the question is that Require in requests is a compatibility mechanism.
> As such, a receiver performs actions if it DOES NOT understand the option tag.

That is at least *part* of the behavior for Require.
Nominally its definition was carried over from http, and it only
required behavior of the recipient for the one request. In that
view it would make no sense in responses.

But the usage and behavior has been overloaded for particular event types.

> I would understand that the RFC 3262 usage is that the receiver performs NO ACTION
> if it does not understand the option tag.

If there is Require:100rel in a request, and the UAS doesn't understand 
it, then it will return a 420 response.

If it receives Supported:100rel, and doesn't understand it, then it 
ignores it.

If it receives Require:100rel and *does* understand it, then it is 
supposed to do something. And among the things it is supposed to do is 
to include Require:100rel in provisional responses.

> Would it be reasonably to assume that is a general usage of Require when received in responses. 

Presumably, if the UAC included Supported:foo or Require:foo in a 
request, then it ought to understand if it receives Require:foo in a 
response to that request. So it ought not *ignore* it. But what it ought 
to do isn't defined generically. Presumably it ought to do whatever the 
specification of the foo event says it should do.

If the UAC didn't indicate support for, and doesn't understand, the foo 
option, then what should it do if it receives Require:foo in a response? 
It can't do as the UAS would, and return a 420 to indicate its lack of 
support. So I guess it only has a couple of choices:
- ignore it
- tear down the session.

But that doesn't really answer the question of what the *meaning* of a 
Require header in a response is. I think the answer must be "the meaning 
is defined on an opion-specific basis".

That's not very satisfying. Overloading the behavior was, IMO, a 
mistake. But that is where we are.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 27 Apr 2009 15:30:41 +0100

Brett,

Thanks, that seems to help. It is a pity 20.32 doesn't mention this
extended meaning of the Require header field.

John 

> From: Brett Tate [mailto:[email-masked]] 
> Sent: 27 April 2009 15:18
> To: Elwell, John; SIPCORE
> Subject: RE: Question on Require in responses
> 
> "Any extensions applied to a non-421 response MUST be listed 
> in a Require header field included in the response.  Of 
> course, the server MUST NOT apply extensions not listed in 
> the Supported header field in the request."
> 
> 
> [mailto:[email-masked]] On Behalf
> > Of Elwell, John

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 27 Apr 2009 23:24:07 +0200

I wrote:

> I would understand that the RFC 3262 usage is that the receiver 
> performs NO ACTION if it does not understand the option tag.

In this I was specifically referring to the response usage, and not to the request usage, but forgot to say so. 

Paul wrote, and I think managed to answer my question in doing so:

> If the UAC didn't indicate support for, and doesn't 
> understand, the foo option, then what should it do if it 
> receives Require:foo in a response? 
> It can't do as the UAS would, and return a 420 to indicate 
> its lack of support. So I guess it only has a couple of choices:
> - ignore it
> - tear down the session.
>
> But that doesn't really answer the question of what the 
> *meaning* of a Require header in a response is. I think the 
> answer must be "the meaning is defined on an opion-specific basis".
> 
> That's not very satisfying. Overloading the behavior was, 
> IMO, a mistake. But that is where we are.
> 

Which is essentially saying there is no possible action on an option-unspecific basis, which is where I was hoping we would get to, i.e. ignore.

But I wanted to make sure because this is overloaded.

Anyone want to vote for tear down the session instead?

Anyone think this is worthy of a correction to add that the above understanding?

regards

Keith

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Monday, April 27, 2009 3:36 PM
> To: DRAGE, Keith (Keith)
> Cc: Elwell, John; SIPCORE
> Nominally its definition was carried over from http, and it 
> only required behavior of the recipient for the one request. 
> In that view it would make no sense in responses.
> 
> > I would understand that the RFC 3262 usage is that the receiver 
> > performs NO ACTION if it does not understand the option tag.
> 
> If there is Require:100rel in a request, and the UAS doesn't 
> understand it, then it will return a 420 response.
> 
> If it receives Supported:100rel, and doesn't understand it, 
> then it ignores it.
> 
> If it receives Require:100rel and *does* understand it, then 
> it is supposed to do something. And among the things it is 
> supposed to do is to include Require:100rel in provisional responses.
> 
> Presumably, if the UAC included Supported:foo or Require:foo 
> in a request, then it ought to understand if it receives 
> Require:foo in a response to that request. So it ought not 
> *ignore* it. But what it ought to do isn't defined 
> generically. Presumably it ought to do whatever the 
> If the UAC didn't indicate support for, and doesn't 
> understand, the foo option, then what should it do if it 
> receives Require:foo in a response? 
> It can't do as the UAS would, and return a 420 to indicate 
> its lack of support. So I guess it only has a couple of choices:
> - ignore it
> - tear down the session.
> 
> But that doesn't really answer the question of what the 
> *meaning* of a Require header in a response is. I think the 
> answer must be "the meaning is defined on an opion-specific basis".
> 
> That's not very satisfying. Overloading the behavior was, 
> IMO, a mistake. But that is where we are.
> 
> 	Thanks,
> 	Paul
> 
> > regards
> > 
> > Keith
> > 
> >> I don't have a general answer for you. IMO the answer to this is 
> >> closely related to the definition of the scope of the negotiated 
> >> agreement, which AFAIK is never defined in a general way, 
> but may be 
> >> defined for certain options.
> >>

---

From: Adam Roach <[email-masked]>
Date: Mon, 27 Apr 2009 17:02:26 -0500

> Anyone think this is worthy of a correction to add that the above understanding?

Not unless we're going to add corrections for all the other bizzare, 
noncompliant, bone-headed things that implementations can get wrong. 
Personally, I don't think we need to get into the business of specifying 
things this far outside the realm of reasonable behavior --  we have 
much more pressing things to do with the limited RAI resources.

But, if we go down this path, we'd better make it complete. I'd suggest 
starting by clarifying how a UAC reacts to a 700-class response.

/a

---

From: Dean Willis <[email-masked]>
Date: Mon, 27 Apr 2009 19:22:50 -0500

On Apr 27, 2009, at 9:18 AM, Brett Tate wrote:

> "Any extensions applied to a non-421 response MUST be listed in a  
> Require header field included in the response.  Of course, the  
> server MUST NOT apply extensions not listed in the Supported header  
> field in the request."

Of course, we often don't do that. For example, RFC 5373 (AnswerMode)  
uses its own header fields to indicate, in responses, whether the  
extension was applied.  I suspect this behavior was held-over from  
when iANSwerMode was a P-header draft, and therefore wasn't allowed to  
have an option tag.

So by the logic of RFC 3261 8.2.4, EVERY SIP extension MUST have an  
Option-Tag. This rather conflicts with RFC 3427.

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 28 Apr 2009 07:21:18 +0200

Hi,

One question I sometimes get is whether 'Require:foo' only applies to
the specific request where it is carried, or to the whole session.

For example, if I include 'Require:100rel' in the initial INVITE, I
assume it doesn't mean that I automatically also require reliable
provisional responses also for future re-INVITEs within the session (I
wuold have to include 'Require:100rel' also in the re-INVITEs for that).

But, if I include 'Require:timer' in the initial INVITE, that applies to
the whole session.

Regards,

Christer

> Sent: 27. huhtikuuta 2009 17:36
> To: DRAGE, Keith (Keith)
> Cc: SIPCORE

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 28 Apr 2009 07:49:06 +0100

Only extensions that are present in the response. However, even this I
don't think we do, e.g., when sending History-Info in a response.

John 

> From: Dean Willis [mailto:[email-masked]] 
> Sent: 28 April 2009 01:23
> To: Brett Tate

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Apr 2009 10:38:57 -0400

> But, if I include 'Require:timer' in the initial INVITE, that applies to

Actually, I think it is much clearer with Timer.
That option only says you are capable of supporting the feature, and 
does not say if you want to use it or not. Headers are used to negotiate 
the use of the feature. Once the use of the timer is negotiated, it 
remains only until the next reINVITE or UPDATE, where it must be 
renegotiated.

100rel is less clear. I think  your position is a reasonable one, but I 
don't know if it is universally held.

	Thanks,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Tue, 28 Apr 2009 07:41:16 -0700

Concerning RFC 3261 section 8.2.4, I don't think the section was attempting to mandate the use of option-tags to extend SIP.  If it was, it obviously failed.

And I'm definitely not attempting to defend the first sentence of my section 8.2.4 snippet.  When I previously attempted to get draft-ietf-sip-session-timer altered to remove the useless adding of Require:timer to responses, Jonathan's argument for leaving it was that it made it easier for proxies, UAC, and etcetera to quickly glance at the response's Require instead of just looking for the Session-Expires.  In my opinion, the RFC extending SIP specifies if appropriate to echo option-tag from request's Supported into response's Require; thus there are likely some SIP extension RFCs that intentionally (or accidentally) don't follow RFC 3261's MUST for useless echoing of option-tag.

> Sent: Monday, April 27, 2009 8:23 PM
> To: Brett Tate

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 28 Apr 2009 19:27:14 +0200

Hi, 

>>But, if I include 'Require:timer' in the initial INVITE, that applies 
>>to the whole session.
>
does not say if you want to use it or not.

True. Require:timer only requires the other party to support the
extension. But, never the less, the scope is still wider than a single
transaction. 

>Headers are used to negotiate the use of the feature. Once the use of
the timer is negotiated, it remains only until the next reINVITE or
UPDATE, where it must be renegotiated.

I think 4028 is actually a little confusing and unclear about that.

First, it does talk about "initial session refresh requests", but the
word initial and refresh in the same definition is a little confusing...

Second, it only says that headers etc must be included in session
refresh requests - not in target refresh requests, and the RFC
explicitly says that those are two different things.

But, we've had enough discussions about the session-timer during the
years, so I don't want to start a new one :)

Maybe that is something that should be added to the potential issues to
fix in RFC3262, toghether with the reject-an-offer-in-PRACK and
does-4xx-cease-retransmission one...

Regards,

Christer

>> required behavior of the recipient for the one request.
>> supposed to do something. And among the things it is supposed to do 
>> is to include Require:100rel in provisional responses.
>>
>> response to that request. So it ought not
>> *ignore* it. But what it ought to do isn't defined generically. 
>> Presumably it ought to do whatever the specification of the foo event

>> says it should do.
>>
>> If the UAC didn't indicate support for, and doesn't understand, the 
>> foo option, then what should it do if it receives Require:foo in a 
>> response?
>> It can't do as the UAS would, and return a 420 to indicate its lack 
>> of support. So I guess it only has a couple of choices:
>> - ignore it
>> - tear down the session.
>>
>> *meaning* of a Require header in a response is. I think the answer 
>> must be "the meaning is defined on an opion-specific basis".
>>

---

From: Dean Willis <[email-masked]>
Date: Tue, 28 Apr 2009 12:54:54 -0500

> remains only until the next reINVITE or UPDATE, where it must be

A Supported or Require usage of an option ALWAYS says only that someone
(sender or receiver) is capable of supporting the extension.

Some extension definitions define when the extension will and will not
be used (for exampple "A UA supporting this extension will engage the
extension whenever it receives a request having the option tag for this
extension in a Supported header field") but this is outside of the
semantic of Require.

A "Require" header is just a shortcut for doing an "OPIONS", and then
sending the extension-requiring request only if the result of the
OPTIONS request indicates support for the required extension.

People clearly don't get this, and we've had to push the issue on almost
every extension. People clearly want inclusion of an option-tag in a
require to force the other end to engage the "required behavior", but it
just doesn't work that way. It's a mechanism for negotiating a common
understanding of the protocol, not for authorization control.

I think this is why we had the confusion about option-tag definitions
that led to precluding informational-track extensions from registering
options tags.

--
Dean Willis

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Apr 2009 14:51:14 -0400

> (sender or receiver) is capable of supporting the extension.

Good theory, but not entirely true.

This thread has already pointed out the use of Require:100rel in a 
response. 3262 says:

    If a provisional response is received for an initial request, and
    that response contains a Require header field containing the option
    tag 100rel, the response is to be sent reliably.  If the response is
    a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be
    ignored, and the procedures below MUST NOT be used.

    The provisional response MUST establish a dialog if one is not yet
    created.

    Assuming the response is to be transmitted reliably, the UAC MUST
    create a new request with method PRACK.  This request is sent within
    the dialog associated with the provisional response (indeed, the
    provisional response may have created the dialog).  PRACK requests
    MAY contain bodies, which are interpreted according to their type and
    disposition.

This phrasing certainly says to me that the Require:100rel means that 
the UAC MUST enable the feature.

Of course it didn't need to be written that way. There is something else 
in a response that indicates it is reliable: the RSeq header. It would 
have been sufficient to say that if the UAC Supports 100rel, and 
receives a response with an RSeq header, then it must send a PRACK. And 
the Require:100rel in the response would simply have been one more 
assurance that the UAC in fact supports it. (In addition to it having 
indicated Support in the request.)

> that led to precluding informational-track extensions from registering

I agree with you, but our own specs have helped to create this confusion.

	Thanks,
	Paul

---

From: "Dale Worley" <[email-masked]>
Date: Tue, 28 Apr 2009 16:50:20 -0400

> extension in a Supported header field") but this is outside of the

That is what they *should* mean, but we've often overloaded them with
additional semantics.  Usually, Supported in a request means "apply this
extension if you understand it" and Supported in a response means "I
have applied this extension to processing this request".

Dale

---

From: Dean Willis <[email-masked]>
Date: Tue, 28 Apr 2009 18:13:30 -0500

On Apr 28, 2009, at 1:51 PM, Paul Kyzivat wrote:

> This phrasing certainly says to me that the Require:100rel means  
> that the UAC MUST enable the feature.

No, it's simply telling the UAC that 100-rel was applied by the UAS. A  
100-rel compliant UAC responds to this knowledge by generating a PRACK  
transaction. It was not the Require:100-rel that compelled this  
behavior; rather it was specified behavior of RFC 3262 that compelled  
it. As you point out, any other technique that revealed the usage of  
100-rel by the UAS could have informed the UAC to generate the PRACK.

One could quite reasonably argue that this was not well executed in  
the text of RFC 3262. But then again, just looking at the 100-REL  
state machine is enough to argue for tossing that whole spec and all  
its little friends (preconditions, early-session, ad nausea) in the  
dustbin.

--
Dean

>
>
> Of course it didn't need to be written that way. There is something  
> else in a response that indicates it is reliable: the RSeq header.  
> It would have been sufficient to say that if the UAC Supports  
> 100rel, and receives a response with an RSeq header, then it must  
> send a PRACK. And the Require:100rel in the response would simply  
> have been one more assurance that the UAC in fact supports it. (In  
> addition to it having indicated Support in the request.)
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 29 Apr 2009 10:02:59 +0200

Hi, 

>>>A Supported or Require usage of an option ALWAYS says only that 
>>>someone (sender or receiver) is capable of supporting the extension.
>>
>No, it's simply telling the UAC that 100-rel was applied by 
>the UAS. A 100-rel compliant UAC responds to this knowledge 
>by generating a PRACK transaction. It was not the 
>Require:100-rel that compelled this behavior; rather it was 
>specified behavior of RFC 3262 that compelled it. As you 
>point out, any other technique that revealed the usage of 
>One could quite reasonably argue that this was not well 
>executed in the text of RFC 3262. But then again, just 
>looking at the 100-REL state machine is enough to argue for 
>tossing that whole spec and all its little friends 
>(preconditions, early-session, ad nausea) in the dustbin.

I was talking more about the meaning of Require in REQUESTs.

In my opinion, Require:100rel in the REQUEST means that the UAS not only
must support it, but that the UAS must only use it if sending non-100
provisional responses.

The same thing goes for preconditions. If the UAC in the REQUEST require
preconditions, it does not only mean that UAS must support it, but that
the UAS must also use it.

In fact, I think the same thing also goes for timer. Require:timer in
the REQUEST means that the UAS must not only support session-timer, but
that the UAS must start the session timer negotiation.

What is the use in requireing the UAS to support foo, if you don't also
require it to use foo (if applicable)?

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Wed, 29 Apr 2009 14:57:53 -0500

> I was talking more about the meaning of Require in REQUESTs.

OK. That definition is fairly clear in RFC 3261 20.32

"The Require header field contains a list of option tags, described in  
Section 19.2. Each option tag defines a SIP extension that MUST be  
understood to process the request. Frequently, this is used to  
indicate that a specific set of extension header fields need to be  
understood. A UAC compliant to this specification MUST only include  
option tags corresponding to standards-track RFCs"
Note that this does not say that the extension must be applied to the  
request, only that the UAC must understand the extension in order to  
be able to process the request.
> must support it, but that the UAS must only use it if sending non-100

There's a semantic difference. The Require: 100rel in the request  
means that the UAS must understand 100rel in order to process the  
request, and that if it does not, then it must reject the request.

RFC 3262 is badly worded, where it says in section 3, UAS behavior:

"The UAS MUST send any non-100 provisional response reliably if the  
initial request contained a Require header field with the option tag  
100rel."
This should key off the option-tag in the "Supported" header field,  
not the "Require", and be worded "The UAS SHOULD send any non-100  
provisional response reliably if the initial request contained a  
Supported header field with the option tag 100rel."

After all, what happens if the 180 is not sent reliably and doesn't  
contain an SDP? Does the protocol break? Or do we just wait for the  
200 (OK) to complete offer/answer?

> the UAS must also use it.

Again, what does it break if the UAS understands preconditions, but  
doesn't actually need to exercise them on its end of the circuit?

RFC 3312 is kind of mixed up in its use of Require and Supported, and  
in fact contradicts RFC 3261 by conflating the two (#261 says you  
would always put the option tag in Supported and might also put in in   
Require.). 3312 says:
"We define the option tag "precondition" for use in the Require and  
Supported header fields. An offerer MUST include this tag in the  
Require header field if the offer contains one or more "mandatory"  
strength-tags. If all the strength-tags in the description are  
"optional" or "none", the offerer MUST include this tag in either a  
Supported header field or in a Require header field. It is, however,  
RECOMMENDED that the Supported header field be used in this case. The  
lack of preconditions in the answer would indicate that the answerer  
did not support this extension."
But even here, it's not the presence of the option tag in a Require  
that drives the UAS to use preconditions, it's the strength-tags in  
the precondition description. The use in the Require field is only to  
cause the transaction to fail if the UAS does not support  
preconditions, and the recommendation is to force this failure only if  
the preconditions are mandatory, and it encourages call-completion for  
a non-3312 UAS if the preconditions are optional.

> that the UAS must start the session timer negotiation.

RFC 4028 specifically says:

"The UAC MAY include a Require header field in the request with the  
value 'timer' to indicate that the UAS must support the session timer  
to participate in the session. This does not mean that the UAC is  
requiring the UAS to perform the refreshes, only that it is requiring  
the UAS to support the extension."
So I think you're wrong on that one.

> require it to use foo (if applicable)?

Because "wanting it to use foo" and "knowing that it is capable of  
using foo" are two different things, and the difference is frequently  
dependent on the specfic foo in question.

For example, in AnswerMode, we might require that the far end support  
AutoAnswer, which (even though it supports it), it might not choose to  
do due to policy. And we clearly say that it's the presence of the  
Answer-Mode header field that triggers the automatic answering  
behavior, not the "Require". Otherwise we wouldn't need header fields,  
we'd just need option tags for all SIP extensions.

Let's hammer on that point:

The option tag is a means of 1) discovering whether or not the far-end  
supports a specific extension and of 2) declaring the criticality of  
understanding that extension relative to satisfying a request and 3)  
informing the UAC of what extensions were applied to the request in  
order to generate the response. This is purely a function of  
capability negotiation, not one of invocation.

The extension itself (typically, an extension header field, although  
there are other types of extensions) is what causes the extension to  
be invoked.

If we did it your way, then we wouldn't need SIP extension header  
fields. We'd just use option-tags, and extend them with parameters.

For example, instead of Referred-By as its own header field, we'd just  
say "Require: referred-by=[email-masked]"

--
Dean

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Thu, 30 Apr 2009 02:03:51 -0400

>[mailto:[email-masked]] On Behalf Of Dean Willis
>Sent: Thursday, April 30, 2009 1:28 AM
>To: Christer Holmberg
>Cc: SIPCORE
>"The Require header field contains a list of option tags, 
>described in Section 19.2. Each option tag defines a SIP 
>extension that MUST be understood to process the request. 
>Frequently, this is used to indicate that a specific set of 
>extension header fields need to be understood. A UAC compliant 
>to this specification MUST only include option tags 
>corresponding to standards-track RFCs"
>Note that this does not say that the extension must be applied 
>to the request, only that the UAC must understand the 
>extension in order to be able to process the request.
>>
>> In my opinion, Require:100rel in the REQUEST means that the UAS not 
>> only must support it, but that the UAS must only use it if sending 
>> non-100 provisional responses.
>
>There's a semantic difference. The Require: 100rel in the 
>request means that the UAS must understand 100rel in order to 
>process the request, and that if it does not, then it must 
>reject the request.
>
>"The UAS MUST send any non-100 provisional response reliably 
>if the initial request contained a Require header field with 
>the option tag 100rel."
>This should key off the option-tag in the "Supported" header 
>field, not the "Require", and be worded "The UAS SHOULD send 
>any non-100 provisional response reliably if the initial 
>request contained a Supported header field with the option tag 100rel."

Yeah, and just to be clear I would also like to add that the "UAS
supports option tag 100rel". If UAS does not support it, then it can
ignore that extension.

>
>After all, what happens if the 180 is not sent reliably and 
>doesn't contain an SDP? Does the protocol break?
>Or do we just 
>wait for the 200 (OK) to complete offer/answer?

No that does not break protocol and sdp in 200 OK completes offer-answer
exchange. But if 180 is sent reliably and does not contain sdp, that
breaks the protocol. Not exactly sure why this limitation has been
there. But in some cases, UAS does not have sdp to send in reliable
non-100 response and then it uses other ways to get around that rule,
like sending sdp with inactive attributes, dummy port numbers etc.

>
>>
>> The same thing goes for preconditions. If the UAC in the REQUEST 
>> require preconditions, it does not only mean that UAS must 
>support it, 
>> but that the UAS must also use it.
>
>Again, what does it break if the UAS understands 
>preconditions, but doesn't actually need to exercise them on 
>its end of the circuit?
>
>RFC 3312 is kind of mixed up in its use of Require and 
>Supported, and in fact contradicts RFC 3261 by conflating the 
>two (#261 says you  
>"We define the option tag "precondition" for use in the 
>Require and Supported header fields. An offerer MUST include 
>this tag in the Require header field if the offer contains one 
>or more "mandatory"  
>"optional" or "none", the offerer MUST include this tag in 
>either a Supported header field or in a Require header field. 
>It is, however, RECOMMENDED that the Supported header field be 
>used in this case. The lack of preconditions in the answer 
>would indicate that the answerer did not support this extension."
>But even here, it's not the presence of the option tag in a 
>Require that drives the UAS to use preconditions, it's the 
>strength-tags in the precondition description. The use in the 
>Require field is only to cause the transaction to fail if the 
>UAS does not support preconditions, and the recommendation is 
>to force this failure only if the preconditions are mandatory, 
>and it encourages call-completion for a non-3312 UAS if the 
>preconditions are optional.
>
>> the REQUEST means that the UAS must not only support session-timer, 
>> but that the UAS must start the session timer negotiation.
>
>"The UAC MAY include a Require header field in the request 
>with the value 'timer' to indicate that the UAS must support 
>the session timer to participate in the session. This does not 
>mean that the UAC is requiring the UAS to perform the 
>refreshes, only that it is requiring the UAS to support the extension."
>> What is the use in requireing the UAS to support foo, if you don't 
>> also require it to use foo (if applicable)?
>
>
>Because "wanting it to use foo" and "knowing that it is 
>capable of using foo" are two different things, and the 
>difference is frequently dependent on the specfic foo in question.
>
>For example, in AnswerMode, we might require that the far end 
>support AutoAnswer, which (even though it supports it), it 
>might not choose to do due to policy. And we clearly say that 
>it's the presence of the Answer-Mode header field that 
>triggers the automatic answering behavior, not the "Require". 
>Otherwise we wouldn't need header fields, we'd just need 
>option tags for all SIP extensions.
>
>The option tag is a means of 1) discovering whether or not the 
>far-end supports a specific extension and of 2) declaring the 
>criticality of understanding that extension relative to 
>satisfying a request and 3) informing the UAC of what 
>extensions were applied to the request in order to generate 
>the response. This is purely a function of capability 
>negotiation, not one of invocation.
>
>The extension itself (typically, an extension header field, 
>although there are other types of extensions) is what causes 
>the extension to be invoked.
>
>If we did it your way, then we wouldn't need SIP extension 
>header fields. We'd just use option-tags, and extend them with 
>parameters.
>
>For example, instead of Referred-By as its own header field, 
>we'd just say "Require: referred-by=[email-masked]"

Yeah in some cases, the tag in Require/Supported header, just reinforces
behavior of some extension without having anything to do with actual
usage. Actual value that the UA has to use is in some other header,
parameter etc.

Sanjay

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 30 Apr 2009 08:23:36 +0200

Hi, 

Changed the subject, so we can keep the request- and response issues
separate.

>extension header fields need to be understood. A UAC 
>compliant to this specification MUST only include option tags 
>Note that this does not say that the extension must be 
>applied to the request, only that the UAC must understand the 

Well, if the UAS doesn't understand 100rel it can't send reliable
responses, which means it can't process the request correctly.

The meaning of "must be able to process the request" is kinda difuse,
and I think the meaning is different depending on which
option-tag/extension we're talking about...

>doesn't contain an SDP? Does the protocol break? Or do we 
>just wait for the 200 (OK) to complete offer/answer?

In my understanding it is an error if the 180 is not sent reliably (it
doesn't always need to contain SDP, though).

Am I the only one who has that understanding?

>>The same thing goes for preconditions. If the UAC in the REQUEST
require preconditions, it does not only mean that UAS must support it, 

Well, for one thing the UAS may not send an SDP answer before 200 OK,
which means that the UAC is not able to update its precondition status
before 200 OK. That maybe doesn't break the protocol, but it may have
impact on early media, may cause clipping when the call has been
answered etc.

And, as for 100rel, I think that many UACs would see it as an error if
preconditions aren't used.

But, again, I'd be happy to hear that I am the only one who thinks so :)

>two (#261 says you would always put the option tag in Supported and
might also 
>put in in  Require.). 3312 says:
>this tag in the Require header field if the offer contains 
>one or more "mandatory" strength-tags. If all the strength-tags in the
description 
>are "optional" or "none", the offerer MUST include this tag 
>in either a Supported header field or in a Require header 
>field. It is, however, RECOMMENDED that the Supported header 
>field be used in this case. The lack of preconditions in the 
>answer would indicate that the answerer did not support this 
>extension."
>to force this failure only if the preconditions are 
>mandatory, and it encourages call-completion for a non-3312 
>UAS if the preconditions are optional.
>
>the session timer to participate in the session. This does 
>not mean that the UAC is requiring the UAS to perform the 

I didn't say that the UAS was required to actually perform the
refreshes.

But, I assume that "must support the extension" in this case means that
the UAS must participate in the negotiation on who is going to do the
refreshes etc.

Otherwise, if nothing is really required by the UAS, why does it matter
whether it supports the extension or not?

>option tags for all SIP extensions.

So, then I think that Require has different meanings depending on the
extension.

Because, my understanding is still that e.g. Require:100rel actually
sends prov resps reliably. Of course, the UAS can choose whether it's
going to send prov resps in the first place, but if it does so it is
required to use the extension.

Another example: RFC 3329 requires servers which receive
Require/Proxy-Require:sec-agree to actually perform some actions.

>The option tag is a means of 1) discovering whether or not 
>the far-end supports a specific extension and of 2) declaring 
>the criticality of understanding that extension relative to 
>header fields. We'd just use option-tags, and extend them 
>with parameters.
> 

Sure, but that's just an encoding issue.

However, it's not about "my way" versus some other way. I just want
everyone to have a common understanding.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 30 Apr 2009 08:30:57 +0200

Hi, 

>>contain an SDP? Does the protocol break?
>>Or do we just
>No that does not break protocol and sdp in 200 OK completes 
>offer-answer exchange. But if 180 is sent reliably and does 
>not contain sdp, that breaks the protocol.

Only if the INVITE didn't contain SDP :)

Regards,

Christer

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Thu, 30 Apr 2009 02:39:17 -0400

>From: Christer Holmberg [mailto:[email-masked]] 
>Sent: Thursday, April 30, 2009 12:01 PM
>To: Sanjay Sinha (sanjsinh); Dean Willis
>Cc: SIPCORE
>Subject: RE: [sipcore] Question on Require in responses
>
>
>Hi, 
>

Yeah that's correct, my statement should be qualified with that.

Thanks

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 30 Apr 2009 17:06:58 +0200

> there are other types of extensions) is what causes the extension to 
Depends a bit how you define extension, but I would argue that if I 
require an extension to be supported on a transaction/dialog by the UAS 
and the UAS accepts the request that this means that for this call the 
UAS behaves as it should according to the extensions specification.

Saying that an extensions invokes itself is meaningless to me.

A UAS may choose to only invoke the extension behaviour if it finds that 
the extension is required. That comes close to saying that the 
require:extension invokes the behaviour in the UAS, but it is not at all 
the same.

/Hans Erik

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 30 Apr 2009 17:18:31 +0200

> So, then I think that Require has different meanings depending on the
The Require does not have different meanings, the extensions are 
different. Different extensions expose different behaviour.
> sends prov resps reliably. 
Require: 100rel does not send responses ;-)

> Require/Proxy-Require:sec-agree to actually perform some actions.
This is because the assumption is that when the extension is supported 
that it will also be active.

---

From: Dean Willis <[email-masked]>
Date: Thu, 30 Apr 2009 12:38:02 -0500

On Apr 30, 2009, at 10:06 AM, Hans Erik van Elburg wrote:

>
> Dean Willis wrote:
>> The option tag is a means of 1) discovering whether or not the far- 
>> end supports a specific extension and of 2) declaring the  
>> criticality of understanding that extension relative to satisfying  
>> a request and 3) informing the UAC of what extensions were applied  
>> to the request in order to generate the response. This is purely a  
>> function of capability negotiation, not one of invocation.
>>
>> although there are other types of extensions) is what causes the  
>> extension to be invoked.
> require an extension to be supported on a transaction/dialog by the  
> UAS and the UAS accepts the request that this means that for this  
> call the UAS behaves as it should according to the extensions  
> specification.
>
> A UAS may choose to only invoke the extension behaviour if it finds  
> that the extension is required. That comes close to saying that the  
> require:extension invokes the behaviour in the UAS, but it is not at  
> all the same.
>

The Require doesn't control whether the UAS invokes the extension. The  
UAS may invoke the extension on its own recognizance.  Most likely, it  
chooses to do so based on 1) the presence of a Supported indicator for  
the extension in a request as evidence that the UAC supports the  
extension or the presence of an extension header in the request that  
also indicates support in the UAC and 2) support for that extension in  
the UAS. Other extensions may not require support in the UAC, so may  
be enacted by this UAS purely on local policy.

For example, consider any SIP extension, such as Answer-Mode. If a UAS  
gets a request with an Answer-Mode header, it knows that the UAC  
supports Answer-Mode. The UAS then decides based on local policy  
(probably authorization policy) how it is going to handle the request,  
that is, whether or not it will auto-answer.  Since the UAS supports  
the extension, the presence or absence of a Require: answer-mode makes  
absolutely no difference to it.

The only time the presence of a Require properly impacts the behavior  
of a UAS is if that UAS does NOT support the extension indicated by  
the Require.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 Apr 2009 19:23:21 -0400

> UAS behaves as it should according to the extensions specification.

There are several issues in what you say above:

"if I require an extension to be supported on a transaction/*dialog* by 
the UAS"

supported for a transaction, and supported for a dialog are two very 
different things. We certainly don't have a way to say whether you want 
one or the other.

These headers were derived from http, and there they really only apply 
for one transaction. Nominally that is all they mean for sip too.

In practice, particular features really have a broader scope than that, 
but there is little/no formality about that.

"if... and the UAS accepts the request that means that *for this call* 
the UAS behaves as it should according to the extensions specification"

There you have assumed that the scope is, depending on your terminology,
- the call
- the session
- the dialog
- the dialog usage

But in general you cannot assume that. The support may cease on the next 
transaction, explicitly or implicitly. It is far from clear that 
support, or requirements to support, continue if not restated in every 
transaction. Nor is there any guarantee that support, if indicated in 
the response to a transaction, will continue even momentarily before the 
next transaction.

And of course there is no guarantee that features that are indicated as 
supported in response to an OPTIONS will continue to be supported when a 
call is made to the same address.

	Thanks,
	Paul