Subject: RE: [Sip] Re: I-D ACTION:draft-idnani-sip-contact-timestamp-00.tx t

From: Idnani Ajaykumar-AIDNANI1 <[email-masked]>
Date: Thu, 3 Oct 2002 15:32:10 -0500

Paul,

My comments are inline.

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Thursday, October 03, 2002 2:19 PM
To: [email-masked]
Subject: [Sip] Re: I-D ACTION:draft-idnani-sip-contact-timestamp-00.txt

The general concept here seems interesting, but I have some issues with the details:

The idea seems to be to provide enough information so that different UAs representing the "same" device can cooperate to minimize multiple registrations of that device. But while the "created" timestamp is helpful for this purpose, it doesn't seem sufficient. For a UA to use the created timestamps for this purpose, it must assume that multiple contacts registered for the same Address of Record do in fact represent the "same" device. But this need not be the case. It could be that other things are also registered, as alternatives providing voicemail support, or to support other media, or whatever.

[Ajay says] You are right, the "created" parameter only provides a means of identifying the time at which the contact addresses were created. The UA is completely free as to what it does with that information. In the case I have listed in the draft the UA knows that the device can have only one contact address. But you are right if there are multiple contact addresses then we would need a mechanism to identify the contact addresses from the same device.

To achieve your purpose, I think you need something else, such as a deviceid parameter, that can be used by multiple UAs representing the same device to indicate the identity of that device. With that, a UA making a registration would want to check for the existence of another registration with a newer timestamp and the same deviceid before deciding to unregister itself. (Conceivably you could use the user part of the sip address for this purpose. But doing so presumes that all UAs representing the device agree on how to represent the name of the device as a user part in the url. This is probably not a good assumption.)

[Ajay says] A "deviceid" parameter with the contact address is a good idea. There used to be a SIP draft which talked about a "tag" parameter with contact addresses, which solved the same purpose, however the Registrar behavior for handling the tag parameter was to replace the contact address with the new one.

Another issue is that your technique for assigning timestamps assumes that the timestamp is assigned by the registrar only when a REGISTER with a new callid is received. That assumes that subsequent REGISTER messages under the same callid are only refreshes of the same contact address. This need not be the case. It is quite legal for subsequent REGISTERs to add new contact addresses. In this case, the newly added contact addresses should receive new timestamps. 

[Ajay says] Yes. I guess I really meant when a new contact address is added. I was just trying to simplify the process by looking at the CSeq and check if it is 1 REGISTER. But in the case where more contact addresses are added through subsequent REGISTER messages, then these contact addresses should also receive new timestamps.

Finally, you haven't said what should happen if a Contact header in a REGISTER message happens to contain a "created=" parameter. This is currently legal, as an extension parameter. Should this be an error, should the registrar accept the parameter and avoid assigning its own, or should it replace the value with the timestamp it assigns? 

[Ajay says] In the case where the "created" parameter is found on the REGISTER message the parameter should be ignored. The idea was to have a central authority record the timestamp, rather than the UA, in which case we would need to deal with the case of clocks being out of sync.

Thank you for your inputs.
- Ajay

	Paul
_______________________________________________
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: Idnani Ajaykumar-AIDNANI1 <[email-masked]>
Date: Fri, 4 Oct 2002 15:12:22 -0500

Jonathan, Paul,

Thank you for your comments. My comments are inline....

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, October 04, 2002 8:00 AM
To: Jonathan Rosenberg
Cc: [email-masked]
Subject: Re: [Sip] Re: I-D ACTION:draft-idnani-sip-contact-timestamp-00.txt

Jonathan Rosenberg wrote:
> 
> Paul Kyzivat wrote:
>  > To achieve your purpose, I think you need something else, such as a
>  > deviceid parameter, that can be used by multiple UAs representing the
>  > same device to indicate the identity of that device. With that, a UA
>  > making a registration would want to check for the existence of
>  > another registration with a newer timestamp and the same deviceid
>  > before deciding to unregister itself. (Conceivably you could use the
>  > user part of the sip address for this purpose. But doing so presumes
>  > that all UAs representing the device agree on how to represent the
>  > name of the device as a user part in the url. This is probably not a
>  > good assumption.)
> 
> Actually, I think its the right assumption.
> 
> If you eliminate the gateways which are assumed in the draft, and the
> UA's were pure SIP UA, how would this work? When the UA roams, it
> acquires a new IP address. So, it needs to unregister the old one. It
> can do that directly because it still remembers the URI with which it
> registered previsously, and so can unregister it.
> 
> I would argue that, in the case of a gatewayed system, it should work
> identically. It would be the responsibility of the gateways to extract a
>   consistent identity from the devices in order to properly identify the
> old registration in order to remove it. Using some kind of identifier in
> the user part of the URI is the right way to do it.
> 
> This would probably be one of several mapping functions that would be
> needed to properly build this gateway function. It seems better to push
> all these things into a gateway specification rather than burden SIP
> with them. We already have a way to identify a device - using the URI.

[Ajay says] I seem to agree with you Jonathan. Anyway how the device is
identified is not in the scope of the draft. It is assumed that the gateway
UA is intelligent enough to deduce that using one of the several ways like
userid, some parameter on the contact / From / To address - like tag, or
some other mechanism. The only new thing the draft suggests is a "created"
parameter for the contact address. How the UA uses this information is
completely up to the UA. It could use it to deregister an old address or it
could ignore it, in which case we could have INVITEs being sent / forked to
multiple contacts.

I don't have any particular vested interest in this, so I am satisfied to
defer to those that do, if this makes sense to them. 

Perhaps I misunderstand the use case. In the draft the issue was managing
the transition between 

	Contact: sip:[email-masked]
and	Contact: sip:[email-masked]

where both are registered to:

	sip:[email-masked]

Presumably this should also apply if the transition was between 

	Contact: sip:[email-masked]
and	Contact: sip:[email-masked]

The trouble with using the user part is that the user part is supposed to be
uninterpretted by all except those within the domain part. So
proxyUA1.cellprovider1.com has no business ascribing any particular meaning
to the user part of sip:[email-masked].

It *may* be acceptable for proxyUA1.visited.com to presume to know something
about the user part of sip:[email-masked]. 

I suppose it may be ok in the cellprovider1/cellprovider2 case if they have
some specific business agreement. But I doubt one could reasonably expect to
expect IETF to standardize this kind of assumption.

[Ajay says] I don't think I understand completely what you are trying to say
here. But if the visited domain is a cellprovider, then there is a
possibility that the user part could be / carry a cell#. Yes! The cell
providers may need some business agreement in such a case.  In the worst
case if the user address cannot be used to uniquely identify a user across
cell providers than you would end up with more than one contacts, which
would only make the SIP servers / UACs to send / fork INVITEs to more than
one contacts. 

In any case, it seems that minimally the spec should say what kind of
matching of contacts is required before deciding that one should defer to
another.

[Ajay says] Again I think this is out of scope for the draft. What
techniques are used by the contact to identify the user uniquely and should
there be some matching criteria for the contacts is totally dependent on how
the gateway is implemented.

Hope I answered your questions. Feel free to comment if you find any more
issues with the draft.

Thanks
- Ajay

	Paul