Subject: [Sip] How long is a Contact valid

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 6 Oct 2005 10:03:44 +0200

Hi,

RFC3261 says (also said in the GRUU draft) that a Contact URI shall be valid for requests outside of the dialog for which the Contact URI was created.

Currently, however, it is not possible for the creator of the Contact URI to indicate to the other user for how long the URI is valid, since the "expires" parameter is only allowed in REGISTER requests, and 3xx responses. So, the remote user of course assume that the URI is valid for the duration of the current dialog (or until a target refresh is recieved), but it does now know for how long the URI can be used for requests outside of the dialog. The GRUU draft DOES say that the URI ideally should be valid as long as the AOR it's associated to, but that may not always be the case.

My first question is: is there a reason why the "expires" parameter couldn't be allowed for INVITE requests and 200 responses, to indicate for how long the value is valid for out-of-current-dialog usage?

My second question is (assuming the "expirese" parameter could be used in INVITE/200): I may want the Contact URI to be valid for the duration of the dialog for which it was created. However, in most cases it is impossible to know for how long a dialog will last, in order to generate an "expires" value, so I wonder if it would be possible to define some kind of a "session" value, which means that the Contact value is valid only for the duration of the session for which it was generated? Maybe a zero value could be used to indicate this?

Regards,

Christer
Ericsson

_______________________________________________
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: Thu, 06 Oct 2005 09:25:00 -0400

> My first question is: is there a reason why the "expires" parameter couldn't be allowed for INVITE requests and 200 responses, to indicate for how long the value is valid for out-of-current-dialog…

I can think of a pragmatic reason why this might be a bad thing to do:

The "expires=" parameter contains a duration, not an absolute time. This 
means that any recipient would have to timestamp it when received, and 
then recompute the expiration time any time it passed it elsewhere.

For instance, when receiving it in an INVITE, it would be timestamped. 
Then when sending a REFER, the expiration time would have to be updated 
in the Refer-To header. And then the recipient of the refer would also 
have to timestamp it, and recompute the expiration time to decide if it 
is ok to send an INVITE to it.

Of course, registrars do this, but this change would extend the pain.

> My second question is (assuming the "expirese" parameter could be used in INVITE/200): I may want the Contact URI to be valid for the duration of the dialog for which it was created. However, in mo…

IMO this is a solution looking for a problem. Do we have a problem where 
we need to know when Contacts expire?

	Paul

---

From: "Dale R. Worley" <[email-masked]>
Date: Thu, 06 Oct 2005 09:40:24 -0400

On Thu, 2005-10-06 at 10:03 +0200, Christer Holmberg (JO/LMF) wrote:
> My second question is (assuming the "expirese" parameter could be used
> in INVITE/200): I may want the Contact URI to be valid for the
> duration of the dialog for which it was created. However, in most
> cases it is impossible to know for how long a dialog will last, in
> order to generate an "expires" value, so I wonder if it would be
> possible to define some kind of a "session" value, which means that
> the Contact value is valid only for the duration of the session for
> which it was generated? Maybe a zero value could be used to indicate
> this?

These seem to be valid concerns, but I don't see any good way to satisfy
them -- in most cases, when a URI ceases to be valid can't be predicted
until very close to the moment in question.

You might want to look at the TRUU work, which addresses some of these
questions.  You can start with http://www.ietf.org/mail-
archive/web/sip/current/msg12083.html

Dale

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 6 Oct 2005 22:33:12 +0200

Christer,

I can think of at least 2 reasons why an 'expires' parameter for a Contact 
header in INVITE would not be that useful:

1. The time period for which a Contact address is valid is (currently at 
least) not under control of the UA (i.e. not known). The UA may propose a 
desired limit on the period for which the Contact is ~used~ by another 
party, but it has no way of enforcing this.

A possible way to remedy this is described here: 
http://www.ietf.org/internet-drafts/draft-jbemmel-sip-truu-01.txt

2. What would the other party do with this information (i.e. when the 
Contact expires)?

As it currently is (and as IMO it should be ) it is up to the UA inserting 
the Contact header to make sure it is valid at least for the lifetime of the 
dialog. If it becomes invalid, the UA must send a new Contact (e.g. through 
UPDATE or re-INVITE); a typical use case is a mobile terminal which changes 
its IP address. In other words, the responsibility is with the UA that 
provides the contact, not with the entity using that contact. This is 
similar to the UA's responsibility to re-register before the registration 
expires.

Regarding a kind of flag to hint the other party that the Contact should not 
be used outside the dialog, like:
Contact: <[email-masked]>;use=dialog

I think that this is what most UAs assume by default anyway (except perhaps 
newer ones that recognise 'Supported: gruu' )

Regards,

Jeroen

----- Original Message ----- 
From: "Paul Kyzivat" <[email-masked]>
To: "Christer Holmberg (JO/LMF)" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, October 06, 2005 3:25 PM
Subject: Re: [Sip] How long is a Contact valid

>> RFC3261 says (also said in the GRUU draft) that a Contact URI shall be 
>> valid for requests outside of the dialog for which the Contact URI was 
>> created.
>>
>> Currently, however, it is not possible for the creator of the Contact URI 
>> to indicate to the other user for how long the URI is valid, since the 
>> "expires" parameter is only allowed in REGISTER requests, and 3xx 
>> responses. So, the remote user of course assume that the URI is valid for 
>> the duration of the current dialog (or until a target refresh is 
>> recieved), but it does now know for how long the URI can be used for 
>> requests outside of the dialog. The GRUU draft DOES say that the URI 
>> ideally should be valid as long as the AOR it's associated to, but that 
>> may not always be the case.
>>
>> My first question is: is there a reason why the "expires" parameter 
>> couldn't be allowed for INVITE requests and 200 responses, to indicate 
>> for how long the value is valid for out-of-current-dialog usage?
>
> Then when sending a REFER, the expiration time would have to be updated in 
> the Refer-To header. And then the recipient of the refer would also have 
> to timestamp it, and recompute the expiration time to decide if it is ok 
> to send an INVITE to it.
>
>> My second question is (assuming the "expirese" parameter could be used in 
>> INVITE/200): I may want the Contact URI to be valid for the duration of 
>> the dialog for which it was created. However, in most cases it is 
>> impossible to know for how long a dialog will last, in order to generate 
>> an "expires" value, so I wonder if it would be possible to define some 
>> kind of a "session" value, which means that the Contact value is valid 
>> only for the duration of the session for which it was generated? Maybe a 
>> zero value could be used to indicate this?
>

---

From: "Dale R. Worley" <[email-masked]>
Date: Fri, 07 Oct 2005 15:00:13 -0400

> newer ones that recognise 'Supported: gruu' )

The whole situation is rather perverse.  In theory, the Contact (a/k/a
target) value was supposed to be globally routable and valid for a long
time.  Even within 3261, it was realized that the Contact might change
during the dialog, and so re-INVITE was admitted.

But as J. Rosenberg says in draft-ietf-sip-gruu-05:

   RFC 3261 mandates that a user agent populate the Contact header field
   in INVITE requests and responses with a URI that is global (meaning
   that it can be used from any element connected to the Internet), and
   that routes to the user agent which inserted it.  RFC 3261 also
   mandates that this URI be valid for requests sent outside of the
   dialog in which the Contact URI was inserted.

   In practice, these requirements have proven very difficult to meet.
   Few endpoints have a hostname that is is present in DNS.  Many
   endpoints have an IP address that is private because the client is
   behind a NAT. [...]

   Because of these difficulties, most clients have actually been
   inserting URIs into the Contact header field of requests and
   responses with the form sip:<IP-address>.  These have the property of
   routing to the client, but they are generally only reachable from the
   proxy to which the user is directly connected.

So in practice, Contact values may easily have a period of validity that
is zero.

Alternatively, if the Contact is a GRUU (indicated by "Supported: gruu"
in the request/response), you know that it will be valid and for a long
time.

TRUUs have their own rules, and are valid for the duration of the dialog
within which they are used.

But in all of these cases, there isn't any particularly useful
*additional* knowledge to be gained by the UA attempting to specify the
time period for which the Contact will be valid.  So I think this
"expires" value is one of those ideas which is useful in a theoretical
sense, but the vicissitudes of real SIP deployments prevent it from
doing much useful in practice.

Dale

---

From: Hisham Khartabil <[email-masked]>
Date: Thu, 13 Oct 2005 17:35:59 +0200

> valid for requests outside of the dialog for which the Contact URI was 

I would say the contact is valid as long as the dialog that it was 
created for is valid.

Hisham

>
> Currently, however, it is not possible for the creator of the Contact 
> URI to indicate to the other user for how long the URI is valid, since 
> the "expires" parameter is only allowed in REGISTER requests, and 3xx 
> responses. So, the remote user of course assume that the URI is valid 
> for the duration of the current dialog (or until a target refresh is 
> ideally should be valid as long as the AOR it's associated to, but 
> that may not always be the case.
>