Subject: [Sip] RE: Abstraction: SIP instance identifiers requirements

From: "Brian Stucker" <[email-masked]>
Date: Tue, 17 Feb 2004 12:37:21 -0600

I think that your list is missing the opportunity to define this instance 
ID in such a way that it can be used to identify a particular endpoint 
for other operations beyond simply routing. The reuse potential seems 
very good if we don't lock the instance identifier down to simply
routing operations, and instead open it up for other general-purpose
operations.

That is at the heart of my draft. Don't limit yourself to one application
when with a small amount of work we can use this to solve other problems
both current and future. Likewise, don't exclude routing operations from
making use of the instance identifier either.

Are you concerned that opening this up to having the instance identifier
transported (in addition to the registered contact) outside of the 
registered contact is really going to be that complex? 

Regards,

Brian

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Tuesday, February 17, 2004 12:11 PM
> To: Cullen Jennings
> Cc: Stucker, Brian [NGC:B617:EXCH]; Jonathan Rosenberg; [email-masked]
> Subject: Abstraction: SIP instance identifiers requirements
> 
> 
> 
> Based on the discussion of "routing" based on instance identifiers, I 
> think we may be getting involved in triggerwork that may become more 
> complex than is actually required, because we're all reasoning from 
> secondary positions. So I'd like to take a step back and 
> consider how we 
> got here, and what we think we're trying to accomplish.
> 
> I see four high-level cases around request routing that illustrate 
> different aspects of this discussion.
> 
> 1) General case: We wish to address a request to an AOR, such 
> that any 
> contact at that AOR might respond. This is basic 2543-type 
> routing behavior.
> 
> 2) Capability case: We wish to address a request to an AOR, such that 
> any contact capable of satisfying the request in a way that we like 
> might respond. This behavior is brought out in callee-caps and 
> caller-preferences and the accept/supported/required syntax of 3261.
> 
> 3) Followups to a specific instance: We have previously done 
> something 
> (such as case 1 or 2) such that the operation of interest has 
> resolved 
> to a specific contact instance associated with an AoR, and we wish 
> subsequent operations (for example, a transfer) to reach that same 
> specific contact instance, even if that specific contact instance is 
> hidden behind an indirection layer (firewall, anonymizer, etc.). As I 
> understand it, this is the heart of the GRUU concept.
> 
> 4) Selection of a specific instance in an initial request: We have a 
> request that we wish to reach one specific instance of a contact 
> associated with an AoR. It has been proposed that we 
> accomplish this by 
> binding some sort of instance tag to the AoR. It has been 
> proposed that 
> we use some sort of URI convention (like the msuri), +based 
> subaddressing, or that we use a header convention for binding the 
> instance tag to the AoR. To my knowledge, we haven't really described 
> the requirement or use case for reaching a specific instance on an 
> initial request, but I can think of several offhand 
> (including diagnostics).
> 
> It seems evident that there is a huge overlap between the 
> requirements 
> of 3 and 4. Indeed, I think #3 (GRUU) came out of early ideas 
> I had on 
> using a REGISTER-response extension to assign an instance-AoR to a 
> Contact. It would appear that IF each contact for an AoR were 
> to have an 
> associated GRUU, and that knowledge of those GRUU assigments were 
> available to a requestor, that the requester could use the 
> target-specific GRUU to achieve the use cases I currently 
> imagine for #4.
> 
> 
> What am I missing here?
> 
> --
> Dean
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 17 Feb 2004 13:16:36 -0600

> routing operations, and instead open it up for other general-purpose

So you see a requirement to uniquely identify a specific SIP endpoint 
OUTSIDE of the domain of SIP routing, such that this identification can 
support further applications?

Use cases here might include:

1) billing -- "Alice called Bob from phone ID000001 through gateway 
ID3344555 on Tuesday, March 1, 2011"

2) Debugging -- "This request was responded to by node IDYIYIOHIHIUH, 
which is a Barfia model 9995 phone running Finux 21.05A and the Vocal 
user agent release 89.6"

This begs the question of identity namespace.

> registered contact is really going to be that complex?

No, I'm concerned that solving the general 
device-identity-representation problem, including such aspects as 
nonrepudiability, may be outside the scope of SIP/SIPPING. At what point 
does this become HIP (Host Identity Payload)?

One way to bound this to a manageable scope is to consider the 
"identity" being represented as simply informational and 
not-to-be-relied upon, except to the extent supported by basic SIP 
security constructs. Like "To:" and "From:" . . .

Another approach is to limit the expression of identity herein to that 
subset of identify which is expressly describable using SIP, which makes 
it analogous to the SIP routing mechanisms underlying the concepts of 
AoR, asserted identity, and verified/vouchsafed identity in the various 
documents that touch on those concepts. In other words, we restrict 
ourselves to the namspace of SIP AoRs.

--
Dean

_______________________________________________
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: Rohan Mahy <[email-masked]>
Date: Wed, 18 Feb 2004 05:30:21 -0800

On Feb 17, 2004, at 10:37 AM, Brian Stucker wrote:

> for other operations beyond simply routing.

For example please?  Your draft jumps straight into mechanism.

thanks,
-rohan

> The reuse potential seems

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 19 Feb 2004 18:01:05 -0800

I don't think this unique instance identifier thing had much to do with
billing or debugging. I'm imagine a case something like the following:

I have two offices, one on the west side of the building and one of the
east. They both have phones registered as fluffy. Because it is better for
lounging in the Sun, I spend the morning in the East office and afternoon in
the West. Right now I can't write a proxy that forward to the correct one.

If I was using SUBSCRIBE to support event notification of provisioning
changes, I would not be able to identify which phone was subscribing.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 28 Feb 2004 01:48:10 -0500

> the West. Right now I can't write a proxy that forward to the correct one.

Sure you can! Thats what callerprefs is for. You would define a new 
callee-caps parameter, "exposure" with values of east, west, north and 
south. The two devices would each include a +sip.exposure contact header 
field parmeter indicating which one is on which side. Then, a caller 
wanting to reach the east side would do this:

INVITE sip:[email-masked]
Accept-Contact: *;+sip.exposure="east"

which would do preferential routing to the east side.

Note, of course, that caller prefs provides no guarantees. Things still 
work if you fork the call to both. It is this unreliability for routing 
tha made it unsuitable for the problem of getting a request to a 
specific instance.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 29 Feb 2004 17:08:40 +0900

This just pushes the problem around but does not solve it. When both the
phone boot, how do they know if they registers with the exposure set to east
or west? We need something that makes one phone different from the other
phone and configuration does not really help much because when the phones
first boot they have no configuration.