Subject: [Sip] Supported: in ACK

From: Dean Willis <[email-masked]>
Date: Sun, 11 Jun 2006 02:22:38 -0500

So, I'm having a Table 2 debate with Joel R., who notices these  
things. I don't like RFC 3261's Table 2 much, as you may recall . . .

Can you or should you include a Supported or Require header in an ACK  
request?

Table 2 says "Not applicable", if I'm reading it right.

RFC 3261 says:

    If the UAC supports extensions to SIP that can be applied by the
    server to the response, the UAC SHOULD include a Supported header
    field in the request listing the option tags (Section 19.2) for  
those
    extensions.

And some of our extensions, at least some of the proposed extensions,  
might actually apply to ACK -- OTOH, there's not a response to ACK,  
so I'm perplexed as to how the Supported: header would be applied by  
the server to the response, since there isn't one.

JDR has, if I understand him, said several times that one includes  
Supported: with all extensions in every request, and ACK is a  
request, sort of.

And, some published examples apparently include Supported: in ACK.  
Should they?

--
Dean

_______________________________________________
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: "Jeroen van Bemmel" <[email-masked]>
Date: Mon, 12 Jun 2006 01:08:36 +0200

Dean,

Before answering, let's discuss the question: should it be split into

1) Can/should you include Supported in ACK
2) Can/should you include (Proxy-)Require in ACK

and then perhaps distinguish between ACK to 2xx (end to end) and ACK to 
non-2xx (hop to hop)

Regards,

jeroen

----- Original Message ----- 
From: "Dean Willis" <[email-masked]>
To: "Sip IETF" <[email-masked]>
Sent: Sunday, June 11, 2006 9:22 AM
Subject: [Sip] Supported: in ACK

>
> So, I'm having a Table 2 debate with Joel R., who notices these  things. I 
> don't like RFC 3261's Table 2 much, as you may recall . . .
>
>    field in the request listing the option tags (Section 19.2) for  those
>    extensions.
>
> might actually apply to ACK -- OTOH, there's not a response to ACK,  so 
> I'm perplexed as to how the Supported: header would be applied by  the 
> server to the response, since there isn't one.
>
> Supported: with all extensions in every request, and ACK is a  request, 
> sort of.
>
> And, some published examples apparently include Supported: in ACK.  Should 
> they?
>
> --
> Dean
>

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 11 Jun 2006 15:13:59 -0700

Is there any case where the Supported in the ACK might include things  
that were not in the INVITE? If not, seems like we should suggest  
that UAS figure out the other sides capabilities by looking at the  
INVITE not the ACK.

On Jun 11, 2006, at 12:22 AM, Dean Willis wrote:

> Can you or should you include a Supported or Require header in an  
> ACK request?
>
> And some of our extensions, at least some of the proposed  
> extensions, might actually apply to ACK -- OTOH, there's not a  
> response to ACK, so I'm perplexed as to how the Supported: header  
> would be applied by the server to the response, since there isn't one.
>

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 11 Jun 2006 15:13:59 -0700

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 11 Jun 2006 21:11:48 -0700

> 1) Can/should you include Supported in ACK
In thinking of the answer to this, I end up asking, who cares? What  
would ever read this information or do anything with it? I can  
imagine there might be a case I am not thinking of but I'm missing  
the use case for this.

> 2) Can/should you include (Proxy-)Require in ACK
I suspect the answer is no because the Proxy has no way to reject an  
ACK so the UA could only require things that it knew the proxy  
supported which would make requiring them sort of redundant. Put  
another way, do you really want all the ACKs to just silently  
disappear? that sounds bad.

>
> and then perhaps distinguish between ACK to 2xx (end to end) and  
> ACK to non-2xx (hop to hop)
>
> Regards,
>
> jeroen
>
> ----- Original Message ----- From: "Dean Willis"  
> <[email-masked]>
>> And, some published examples apparently include Supported: in  
>> ACK.  Should they?
>>
>> --
>> Dean
>>

---

From: "Samir Srivastava" <[email-masked]>
Date: Mon, 12 Jun 2006 02:26:42 -0500

> 2) Can/should you include (Proxy-)Require in ACK
I suspect the answer is no because the Proxy has no way to reject an ACK
so the UA could only require things that it knew the proxy supported
which would make requiring them sort of redundant. Put another way, do
you really want all the ACKs to just silently disappear? that sounds
bad.

SS>> will there be use case for _stateless_ proxy to act on these,
provided ACK MUST have the same set of tags as that of INVITE. Some
applications might be using ACK as trigger for the established
Calls (otherwise call will be BYE'ed), They might be passing the initial
messages statelessly.

---

From: Dean Willis <[email-masked]>
Date: Mon, 12 Jun 2006 14:16:28 -0500

> 1) Can/should you include Supported in ACK

Ok, I agree those are separate questions.

> 2) Can/should you include (Proxy-)Require in ACK

I don't think you can, since a proxy cannot reject an ACK that has a  
Proxy-Require: that is not supported by the proxy.

> ACK to non-2xx (hop to hop)

Not quite sure about this.

--
Dean

---

From: "Alberto Cuda" <[email-masked]>
Date: Tue, 13 Jun 2006 09:57:41 +0200

> Proxy-Require: that is not supported by the proxy.

I think it should, otherwise we are causing problems to stateless proxies:
if they reject an INVITE request containing a Proxy-Require they do not
understand, they should drop the ACK request as well, or they will try
to forward it.

    Cheers.
       Alberto.

--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

---

From: Dean Willis <[email-masked]>
Date: Tue, 13 Jun 2006 11:04:09 -0500

> understand, they should drop the ACK request as well, or they will try

That actually sounds quite reasonable, and I think you've changed my  
mind.

--
Dean

---

From: "Alberto Cuda" <[email-masked]>
Date: Tue, 13 Jun 2006 19:01:54 +0200

> That actually sounds quite reasonable, and I think you've changed my  

In the meantime I've changed mine :-)

Actually stateless proxies should be able to detect their own ACKs
by some other means, like an hash to put in the To-Tag: there are
other cases (e.g. 483) where they can't simply tell if the original
INVITE failed and why. Unfortunately I could not find any place
in RFC3261 suggesting how stateless proxies can filter their own
ACKs, so I wonder how current implementation deal with it...

BTW ACKs to non-2xx responses can't have a Proxy-Require header:
once removed this use case, IMHO the safe bet is to forbid
Proxy-Require from "2xx" ACKs too, since the only effect they
could have is to cause retransmissions.

    Cheers.
       Alberto.

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 13 Jun 2006 20:12:36 +0200

I was just about to write the very same comment...

The problem is bigger than only 420 (Bad Extension), it occurs for all 3xx-6xx responses generated by a stateless proxy.

Adding Proxy-Require to the ACK means that it must be remembered or derived from the 420 response. The former is cumbersome for a stateless proxy, and the latter is inelegant to say the least

Instead, I would propose the following:

1) Standardize a prefix (like Via magic cookie) to be used in the to-tag by stateless proxies when generating a non-2xx final response. Something like "error-"
2) When generating an ACK to non-2xx, require elements to insert a 'Max-Forwards: 0' header

(2) makes sense because an ACK to non-2xx should never be forwarded

When both these rules are implemented, there is no need for Proxy-Require in ACK to non-2xx.
However, as to Proxy-Require in ACK to 2xx: it is needed in case a Privacy service is used with "header" Privacy.

Regards,

jeroen

----- Original Message ----- 
  From: Alberto Cuda 
  To: Dean Willis 
  Cc: Jeroen van Bemmel ; Sip IETF 
  Sent: Tuesday, June 13, 2006 7:01 PM
  Subject: Re: [Sip] Supported: in ACK

  Cheers.
  Alberto.

  --------------------------------------------------------------------
  CONFIDENTIALITY NOTICE
  This message and its attachments are addressed solely to the persons
  above and may contain confidential information. If you have received
  the message in error, be informed that any use of the content hereof
  is prohibited. Please return it immediately to the sender and delete
  the message. Should you have any questions, please contact us by
  replying to [email-masked].
          Thank you
                                          www.telecomitalia.it
  --------------------------------------------------------------------

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 13 Jun 2006 23:19:27 +0200

On second thought, 

1) The tag must be unique to the responding proxy. One option might be to add the value of Max-Forwards after the prefix, i.e. "error-68" if Max-Forwards is 68.
  A stateless proxy must then drop an ACK iff to-tag starts with "error-" and max-forwards equals the number in the tag

  This has the benefit that it may also aid in debugging. Another alternative would be to simply recommend each proxy to decide for itself what unique tag it uses for non-2xx ACK filtering

2) Max-Forwards:0 will not work when there are other stateless proxies between the UAC and the responding proxy, so not a good idea

Jeroen
  ----- Original Message ----- 
  From: Jeroen van Bemmel 
  To: Alberto Cuda ; Dean Willis 
  Cc: Sip IETF 
  Sent: Tuesday, June 13, 2006 8:12 PM
  Subject: Re: [Sip] Supported: in ACK

  Regards,

  jeroen

  ----- Original Message ----- 
    From: Alberto Cuda 
    To: Dean Willis 
    Cc: Jeroen van Bemmel ; Sip IETF 
    Sent: Tuesday, June 13, 2006 7:01 PM
    Subject: Re: [Sip] Supported: in ACK

    Cheers.
    Alberto.

------------------------------------------------------------------------------

---

From: "Alberto Cuda" <[email-masked]>
Date: Thu, 15 Jun 2006 10:08:43 +0200

Jeroen van Bemmel wrote:

> However, as to Proxy-Require in ACK to 2xx: it is needed in case a 
> Privacy service is used with "header" Privacy.
>  

Do you mean also in cases where some failure happens? In that case, I guess
this holds true also for CANCEL & non-2xx requests...

    Cheers.
       Alberto.

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: "Alberto Cuda" <[email-masked]>
Date: Thu, 15 Jun 2006 10:10:21 +0200

> this holds true also for CANCEL & non-2xx requests...

(Of course I meant non-2xx ACK requests).

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 15 Jun 2006 11:50:33 -0400

inline.

> Ok, I agree those are separate questions.

Yes, and you need to further split it into ACK for 2xx and non-2xx.
In both cases though, Supported makes no sense since the purpose would 
be to tell the UAS that it can apply certain processing to the response. 
Since there is no response, this is moot.

> Proxy-Require: that is not supported by the proxy.

Not true. Let us consider ACK-2xx and ACK-non-2xx separately.

For non-2xx, Section 8.2.2.3 has the definitive word on this, and it says:

Note that Require and Proxy-Require MUST NOT be used in a SIP CANCEL
    request, or in an ACK request sent for a non-2xx response.  These
    header fields MUST be ignored if they are present in these requests.

However, for ACK-2xx, it says this:

An ACK request for a 2xx response MUST contain only those Require and
    Proxy-Require values that were present in the initial request.

It may very well be the case that an ACK cannot be succesfully processed 
unless a particular extension is understood, in which case 
Require/Proxy-Require make sense. But what about it being rejected? 
Well, it won't ever need to be, because the ACK-2xx cannot contain 
anything that wasn't in the INVITE. So, if a particular option tag was 
in the INVITE, and not supported by the UAS, that would have produced a 
420 and an ACK-non-2xx without any Require. However, if the option tag 
was supported, there would have been a 200 OK followed by ACK-200 that 
includes that very same option tag. But, we know its supported so the 
ACK would never need to be rejected.

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

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 15 Jun 2006 18:51:14 +0200

Only if the proxy providing the privacy service forwards CANCEL and INVITE statelessly.

Since CANCEL cannot have Proxy-Require, this implies that a proxy providing RFC3323 privacy service MUST handle INVITE and CANCEL statefully. This is not clearly stated in the RFC (and probably true for any extension using Proxy-Require)

Regards,

Jeroen