Dale - inline
Dale Worley wrote:
On Tue, 2008-12-02 at 16:39 +0530, 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.
"Expires: 0" is definitely valid, as it is used in SUBSCRIBEs that do
"one-shot retrieval" of event packages. See RFC 3265.
Does Expires value in INVITE is modified by intermittent SIP entities
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:[EMAIL PROTECTED]". Since the
"Expires" header cannot be repeated, the new value replaces the old
value.)
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
If yes, then what should be UAS behavior when it receives INVITE with
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
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip