Re: [Sip] SIP instance identifiers

[Paul Kyzivat <[e-mail]>]

Jonathan,

I like using a callee-cap feature tag in a registration. OTOH, I can see 
validity in Brian's desire to have it in a header of its own, 
potentially in any message. I don't see those usages as conflicting.

The only potential conflict would be in REGISTER, but that isn't a real 
conflict - a Guid header would describe the entity sending the REGISTER 
message, while the +sip.instance tag on a contact would describe the 
endpoint being registered. Often they would be the same, but not 
necessarily.

Regarding the form of guids, I don't think any single scheme works in 
all cases. My preference is to:

- represent the instance id as a URI

- make it the responsibility of the endpoint to select a URI
   that is unique

- Recommend that a URN be used.

- Define a couple of new URN namespaces that are especially
   suitable for this purpose. (I have in mind urn:mac:xxx for
   mac addresses, and possibly urn:random:xxx for random numbers
   in some large range.)

A couple of other comments:

Section 7.1 says:

    The combination of a UA instance ID and an AOR is referred to as an
    instance ID/AOR pair. There is a one-to-one mapping between such a
    pair and a GRUU; ...

And figure 2 shows the corresponding 1:1 relationship. But it isn't 
necessarily 1:1. It should be 1:0..1 because it is possible to have an 
instance ID/AOR Pair that doesn't have a GRUU. (Instance IDs are 
valuable in their own right.)

This 1:0..1 relationship imposes another error condition on registrars. 
If an attempt is made to register a contact with an instance id in use 
by some other contact of the same AOR, the registrar will have to refuse 
it. This needs to be spelled out somewhere, and a suitable error 
identified. (I don't know if any of the existing responses works for 
this. At the least, a new Reason code is likely to be needed.)

	Paul

Jonathan Rosenberg wrote:
> Folks,
> 
> We have three drafts this round that all propose a way to define an 
> instance identifier for a UA:
> 
> 
> http://www.jdrosen.net/papers/draft-ietf-sip-gruu-01.txt
> http://www.ietf.org/internet-drafts/draft-jennings-sipping-instance-id-00.txt 
> 
> http://www.ietf.org/internet-drafts/draft-stucker-sip-guid-00.txt
> 
> all three are similar. Mine uses a contact header field parameter, and 
> uses the callee capabilities framework to enable caller preferences 
> routing based on instance iDs. Cullen also uses a contact parameter, but 
> not within the callee caps framework. Brian defines a header field.
> 
> I think we generally understand the requirement here, though it would 
> probably be good to obtain use cases to be sure. The design choice is 
> where to include this parameter, and this represents the difference 
> between the three approaches.
> 
> I tend to prefer a Contact URI parameter over a header. My main reason 
> for that is REGISTER requests. If a register request has multiple 
> contacts, which contact does the instance identifier apply to? As a 
> header field, it would be hard to know. If you make it a contact header 
> field parameter, its no problem. Those header field parameters could 
> also then be used in the Contact in INVITE/200 SUB/NOT, etc.
> 
> Then, the question is whether to use a regular Contact header field 
> parameter as Cullen has done, or a callee cap parameter as I have done? 
> The callee cap approach allows for caller preferences to be applied to 
> routing to a specific instance. Now, a good question is whether such a 
> thing is needed or even a good idea, if we have GRUU as the ideal way to 
> route to a UA instance. I can go either way, but welcome thoughts on the 
> topic.
> 
> Thanks,
> Jonathan R.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip