Subject: RE: [Sip] How long is a Contact valid

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 6 Oct 2005 10:08:56 -0400

Can't a Contact be "de-Registered" at any time?  (Register with
Expires=0)

If so, then any assertion prior to that becomes false.  Then it doesn't
really matter what you try to tell a remote node, there is a chance it
is false.  So, why bother?  Or, put another way, why is this needed?

Mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Paul Kyzivat (pkyzivat)
> Sent: Thursday, October 06, 2005 9:25 AM
> To: Christer Holmberg (JO/LMF)
> Cc: [email-masked]
> Subject: Re: [Sip] How long is a Contact valid
> 
> 
> 
> Christer Holmberg (JO/LMF) wrote:
> > 
> > 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?
> 
> 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 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?
> 
> IMO this is a solution looking for a problem. Do we have a 
> problem where we need to know when Contacts expire?
> 
> 	Paul
> 
> > 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
> > 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Fri, 7 Oct 2005 09:05:25 +0200

Hi,

>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.

[CHH] I don't think the issue is when the Contact is used within the dialog. Also, in that case it is possible (as you also indicate) to update it using an UPDATE/re-INVITe. The issue is when it's used outside the dialog.
 
>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' )

[CHH] GRUU is what I had in mind, eventhough I believe 3261 does not forbid a "normal" Contact to also be use outside the dialog.

Regards,

Christer

> ----- 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
> URI shall be 
> >> valid for requests outside of the dialog for which the 
> Contact URI was 
> >> created.
> >>
> 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.
> >>
> 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?
> >
> > 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.
> >
> > 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.
> >
> 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: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 13 Oct 2005 17:45:55 +0200

Hi,

>>URI shall be valid for requests outside of the dialog for which the 
>>Contact URI was created.
> 
>I would say the contact is valid as long as the dialog that it was 
>created for is valid.

The issue behind this discussion is that a contact may be valid also after the dialog has been terminated.

Regards,

Christer

> 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 
> URI is valid 
> > for the duration of the current dialog (or until a target 
> refresh is 
> used for 
> > 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 
> 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
> >