Subject: [Sip] Query related to Expires header with value 0 in INVITE

From: "Anita Tailor" <[email-masked]>
Date: Tue, 2 Dec 2008 16:39:32 +0530

Hi All,

I have some queries related to expires header in SIP message.

RFC 3261 Section 20.19
" The value of this field is an integral number of seconds (in decimal)
   between 0 and (2**32)-1, measured from the receipt of the request"

Does this mean 0 is a valid value of Expires header ? I am confused because of "between" word here as meaning might different if "from 0 to  (2**32)-1" have used.

Does Expires value in INVITE is modified by intermittent SIP entities before it reaches to its destination?
If yes, then what should be UAS behavior when it receives INVITE with value 0 in Expires header ? Should UAS respond with 487 ?

Section 13.1.1 [1]
  "If the request is an INVITE that contains an Expires header
 field, the UAS core sets a timer for the number of seconds
 indicated in the header field value.  When the timer fires, the
 invitation is considered to be expired.  If the invitation
 expires before the UAS has generated a final response, a 487
 (Request Terminated) response SHOULD be generated."

Thanks in Advance
Anita

Conexant E-mail Firewall (Conexant.Com) made the following annotations
---------------------------------------------------------------------
********************** Legal Disclaimer **************************** 

"This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you." 

********************************************************************** 

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

_______________________________________________
Sip mailing list  https://www.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: Tue, 02 Dec 2008 15:42:34 -0500

Anita Tailor wrote:
> /RFC 3261 Section 20.19///
> 
> /" The value of this field is an integral number of seconds (in decimal)
>    between 0 and (2**32)-1, measured from the receipt of the request"/
> 
>  
> 
> Does this mean 0 is a valid value of Expires header ? I am confused 
> because of "between" word here as meaning might different if "from 0 to  
> (2**32)-1" have used.

Its certainly valid in *some* contexts. For instance in REGISTER and 
SUBSCRIBE this is the way to terminate a registration or subscription.

> before it reaches to its destination?

According to table 2 of 3261, proxies are not permitted to add, modify, 
or delete this header. But of course a B2BUA can do as it wishes.

> If yes, then what should be UAS behavior when it receives INVITE with 
> value 0 in Expires header ? Should UAS respond with 487 ?
> 
> /Section 13.1.1 [1]/
> 
> /  "If the request is an INVITE that contains an Expires header
>  (Request Terminated) response SHOULD be generated."/

The above is SHOULD strength. I expect you will find many UAs that don't 
bother with this.

But if you are implementing the UAS, this would be a good thing to do. 
There is no point in establishing a session if the caller no longer 
wants it.

	Paul

---

From: "Dale Worley" <[email-masked]>
Date: Tue, 02 Dec 2008 16:18:48 -0500

> because of "between" word here as meaning might different if "from 0
> to  (2**32)-1" have used.

"Expires: 0" is definitely valid, as it is used in SUBSCRIBEs that do
"one-shot retrieval" of event packages.  See RFC 3265.

> before it reaches to its destination?

Yes, it can be modified by SIP proxies.  (Officially, the proxy is
forwarding the message to the URI "sip:xxx@yyy?Expires=1234".  Since the
"Expires" header cannot be repeated, the new value replaces the old
value.)

> value 0 in Expires header ? Should UAS respond with 487 ?

The concept is that the INVITE expires immediately.  What might this
mean?  Clearly, the UA cannot "ring" for any length of time.  This
suggests that the INVITE should be given an immediate 487 response.

However, it seems that there should be an exception:  If the UAS is set
to answer immediately (that is, to respond 200 without waiting for human
intervention), as happens in some applications, it could instead
immediately respond with 200.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Dec 2008 16:53:26 -0500

Dale - inline

> "Expires" header cannot be repeated, the new value replaces the old

As I read 3261, a proxy can't do this. The section on adding headers 
from the URI to the message is in section 8, for UACs. In section 16, 
for proxies, there is no comparable language. Instead, the proxy must 
remove any parameters that aren't allowed in the R-URI, which would 
include the headers. And it may indeed add additional headers, but I 
believe it is restricted in doing so by Table 2. Table 2 doesn't permit 
the proxy to add, modify, or delete an Expires header.

Now this does seem a bit inconsistent. If a URI in a 3xx includes 
headers, then they would apply if the 3xx is returned to the UAC, but 
not apply if the 3xx is recursed by a proxy.

	Thanks,
	Paul

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 03 Dec 2008 11:56:25 -0500

> not apply if the 3xx is recursed by a proxy.

Interesting...  People have discussed proxies for a long time as if they
handled target URIs similarly to UASs generating initial requests, that
is, header-parameter parts are extracted from the request-URI and turned
into headers.

Looking at RFC 3261 section 16.6 step 2, none of this is discussed.
Step 5 says "The proxy MAY add any other appropriate header fields to
the copy at this point." which seems to allow the proxy great latitude.

Table 2 does forbid the proxy from modifying the Expires header.  But
perhaps that's an oversight?  One could also argue that the proxy rules
apply to UACs when they're recursing on 3xx responses, as they're
"acting like proxies" then.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Dec 2008 13:36:29 -0500

> is, header-parameter parts are extracted from the request-URI and turned

Its amazing isn't it, what we think the specs say vs. what they actually 
say?

I have to admit that before replying to you I wasn't certain where 
headers in URIs were applied. I had to review 3261 before I decided that 
it was only UACs, not Proxies.

> the copy at this point." which seems to allow the proxy great latitude.

Proxies *do* have a lot of latitude. But they are constrained by Table 
2. I know a lot of people don't like table 2 - there are a lot of 
limitations in what it can describe, and it isn't maintained as well as 
it might be. Yet there are things, like this, that are not stated 
anywhere else.

> perhaps that's an oversight? 

We need to input from a real old-timer to answer that. Its before my time.

> One could also argue that the proxy rules

That would have been one way to do it. But that isn't how it was written 
up. And they can't be exactly the same. A UAC can act on an http: URI in 
a 3xx, where a proxy isn't permitted to.

What this will really do is revive all the chatter about banning forking 
and recursing on 3xx.

	Thanks,
	Paul

---

From: Neelakantan Balasubramanian <[email-masked]>
Date: Wed, 3 Dec 2008 10:47:46 -0800

See below.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Anita Tailor
Sent: Tuesday, December 02, 2008 5:10 AM
To: [email-masked]
Subject: [Sip] Query related to Expires header with value 0 in INVITE

Hi All,

RFC 3261 Section 20.19

>>> It doesn't look like properly.  See  RFC 3261 Section 13.2.1

   The UAC MAY add an Expires header field (Section 20.19) to limit the
   validity of the invitation.  If the time indicated in the Expires
   header field is reached and no final answer for the INVITE has been
   received, the UAC core SHOULD generate a CANCEL request for the
   INVITE, as per Section 9.

So, immediately after INVITE, the UAC should generate CANCEL.  But it has to wait until it gets some response.

Section 9.1

   If no provisional response has been received, the CANCEL request MUST
   NOT be sent; rather, the client MUST wait for the arrival of a
   provisional response before sending the request.

Proxies do not modify headers present in the request it receives.  See section 16.6.

Section 13.1.1 [1]

So the UAS should generate a 487 right away.

Thanks in Advance
Anita

---

From: Neelakantan Balasubramanian <[email-masked]>
Date: Wed, 3 Dec 2008 10:16:03 -0800

See below.

Hi All,

RFC 3261 Section 20.19

Section 9.1

Section 13.1.1 [1]

Thanks in Advance
Anita

---

From: "孙永光" <[email-masked]>
Date: Thu, 11 Dec 2008 09:11:14 +0800

Hi All

IMO the UAS should response 487 when it receives INVITE with "Expires = 0"
andalso as I know the ETSI test case suggests  "UAS should response 487 when
it receives INVITE with "Expires = 0" "

Thanks
Samman/孙永光(SunYongGuang)
MSN:[email-masked] <[email-masked]>

2008-12-11

2008/12/4 Neelakantan Balasubramanian <[email-masked]>

>  See below.
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Anita
> Tailor
> *Sent:* Tuesday, December 02, 2008 5:10 AM
> *To:* [email-masked]
> *Subject:* [Sip] Query related to Expires header with value 0 in INVITE
>
>
>
> Hi All,
>
>
>
> *RFC 3261 Section 20.19***
>
> *" The value of this field is an integral number of seconds (in decimal)
>    between 0 and (2**32)-1, measured from the receipt of the request"*
>
>
>
> Does this mean 0 is a valid value of Expires header ? I am confused because
> of "between" word here as meaning might different if "from 0 to  (2**32)-1"
> have used.
>
>
>
> If yes, then what should be UAS behavior when it receives INVITE with value
> 0 in Expires header ? Should UAS respond with 487 ?
>
>
>
>
>
> *Section 13.1.1 [1]*
>
> *  "If the request is an INVITE that contains an Expires header
>  (Request Terminated) response SHOULD be generated."*
>
>
>
> "This email may contain confidential and privileged material for the sole
> use of the intended recipient. Any unauthorized review, use or distribution
> by others is strictly prohibited. If you have received the message in error,
> please advise the sender by reply email and delete the message. Thank you."
>

-- 
msn:[email-masked] <[email-masked]>