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

From: "Brian Stucker" <[email-masked]>
Date: Mon, 1 Mar 2004 19:49:29 -0600

Different AORs! Heresy! =)

Brian

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Monday, March 01, 2004 7:20 PM
To: Cullen Jennings
Cc: Jonathan Rosenberg; Stucker, Brian [NGC:B617:EXCH]; [email-masked]
Subject: Re: [Sip] Re: Abstraction: SIP instance identifiers
requirements

Cullen Jennings wrote:
> 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.

Personally, I solve this by giving each phone a different registration 
AOR, then use a time-policy routing table on [email-masked] to 
selectively route to the correct phone for the current time of day.

Service invocation via forward knowledge at the proxy. Works like magic. 
It even supports voice mail.

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 03 Mar 2004 06:56:29 +0900

So just to make sure I got this right. I would make a device AOR for each
phone  perhaps [email-masked] for the first phone and
[email-masked], have these phones register with appropriate
credentials for each of these. Then set up time of day forwarding rules for
[email-masked] to these.

I agree it would work for this particular problem but I¹m not a real big fan
of it.

---

From: Dean Willis <[email-masked]>
Date: Tue, 02 Mar 2004 18:50:20 -0600

Cullen Jennings wrote:

> 
> So just to make sure I got this right. I would make a device AOR for 
> each phone – perhaps [email-masked] for the first phone and 
> credentials for each of these. Then set up time of day forwarding rules 
> for [email-masked] to these.

Yes, I believe you understand.

Principles:

1) Every endpoint is a uniquely routable entity.

2) Proxies can programatically reroute requests from any given entity 
with an AOR in their domain to another entity or set of entities.

4) Higher-order or "non-contact" entities (I personally have an AoR, but 
not an IP address) depend on the rendezvous, multiple appearance, and 
capability matching mechansisms of SIP to divert requests targeting 
their AoR to specific devices.

5) registration serves two basic purposes:

a) Associating a device's contact with an AoR having broader routability 
or visibility. The GRUU mechanism is an extension of this function, as 
it transforms a potentially local contact URI into a what is effectively 
a device-specific AoR.

b) Associating the AoR of a "non-contact" entity with the AoR of a 
"contact entity" such that the associated contact entity may receive 
requests originally targeted to the non-contact entity.

> I agree it would work for this particular problem but I’m not a real big 
> fan of it.

It is somewhat philosophically different from the two-layer 
(AoR/Contact) heirarchy that many people seem to use as a reference 
model. This simple model is a good starting point, but until you realize 
that the "routing fabric" is really a referential network, not a simple 
tree, many applications need extensions to make them doable.

As people notice applications that require additional linkages outside 
of the simple tree model, they tend to propose task-specific linking or 
referenceing mechanisms that support the specific application (GRID), or 
propose ways of pushing "application state" into the signaling body 
(History). In general, I think that all of these things generalize into 
the URI-reference model, making a lot of the extension triggerwork not 
really necessary. However, many specific applications are easier to 
explain, understand, and potentially operate when facilitated by routing 
extensions. It's a tradeoff that we really have to consider carefully.

But I think the starting point in every case is to understand how the 
application or service can be implented using the available tools BEFORE 
we propose extension models for achieving equivalent functionality.

_______________________________________________
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: Wed, 03 Mar 2004 02:53:06 -0500

Dean,

If everyone followed your approach then there would be no need for gruus 
to be assigned by REGISTER. The approach is somewhat attractive to me, 
but I have a feeling it won't catch on. For one thing it has more 
administrative cost, as well as some added hassle factor. (If I already 
have my personal AoR, I can fire up a new phone or soft phone, or 
whatever and have it working without getting involved with the 
bureaucracy that assigns new AoRs.

	Paul

Dean Willis wrote:
>> each phone – perhaps [email-masked] for the first phone 
>> and [email-masked], have these phones register with 
>> appropriate credentials for each of these. Then set up time of day 
>> forwarding rules for [email-masked] to these.
> 
> 
>> I agree it would work for this particular problem but I’m not a real 
>> big fan of it.
> 
>

---

From: Dean Willis <[email-masked]>
Date: Wed, 03 Mar 2004 02:32:17 -0600

Paul Kyzivat wrote:

> to be assigned by REGISTER. 

Not at all. The truly magical bit about a GRUU is that it provides for a 
routing element to apply its allegedly greater level of topology 
information to provide a translation between the device's idea of its 
AoR and another AoR which provides superior reachability.

GRUU, in this aspect, is based on the idea that information known to the 
registrar and that communicated to the UA can augment the 
request-routing function.

The Instance ID concept, however, is based on the idea that information 
known to the UA and communicated to the registrar can also augment the 
request-routing function.

I've pointed out here that other information known to the routing 
element, but not communicated to the user agent, can also augment the 
request-routing function, and that it does so sufficiently to meet the 
requirements established by the given use-case WITHOUT requiring any SIP 
extensions.

GRUU and IntanceID overlap in part, as each results in an effectively 
unique contact value for each device associated with an AOR, such that 
each device can be appropriately targeted in those operations that 
require selecting one particular UA from the set of UAs associated with 
a given AOR. Clearly the same result can be applied by simply giving 
each UA associated with an AOR its own unique AOR.

Dynamically-associated subaddressing of the sort proposed in both GRUU 
and Instance ID is simply an optimization of convenience.

 > The approach is somewhat attractive to me,

Ah yes, but using this technique I can route my calls without getting 
involved with the bureacracy that assigns registration authority and 
allowable identities for registration. For example, this exact technique 
allows me to divert calls originally targeting my US desk phone number 
to my SIP AOR, and to then retarget those requests to my Korean mobile, 
without requiring the participation of my US phone operator or the 
Korean mobile provider. If I had to persuade my operator-issued 3GPP Rel 
5 phone (if I had one) to register with an arbitrary third-party 
registrar, I suspect I'd have a problem.

--
Dean