Subject: [sipcore] rfc4244bis: what is an AoR?

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 12 Jul 2009 01:00:28 -0400

Howdy,
This may be from left-field, or already discussed previously - if so please excuse my ignorance.

I see the term "AoR" as being somehow treated as an unambiguous term, knowable to a Proxy of the AoR's domain as being an "AoR" on sight.  It is then used in the draft to identify a specific HI URI as the original-target URI - the identifier to look for when trying to find the "original" request-URI.  Right?

So if the Proxy of the AoR's domain is supposed to indicate a SIP-URI is an AoR, how does it know it?  What is the distinguishing parameter or URI syntax of an AoR, which makes it different from any-old sip:user@domain SIP-URI?

For example, is "sip:[email-masked]" an AoR?  Is "sip:[email-masked];user=phone" an AoR?  Is "sip:[email-masked];gr" an AoR?

I'm not trying to be flippant (well, ok I am) but there is no such distinguishing characteristic, afaik.  It is an abstract concept, and it is just a specific subset of SIP/SIPS-URIs we use to describe something; but it means nothing in particular to a Proxy really, does it?  For example AoR's are not all/only SIP-URI's that are Registered through a SIP REGISTER transaction; they can be statically routed/resolved, or added to a location service via a web page, etc.  In some of our specs we consider an AoR to be the human identity, whereas a contact address is a machine, but really there's nothing that makes it be a human identity - it could be a group identity, a conf room phone, a voicemail box, an alias for anther AoR, etc.

In fact I'm not even sure it's all of the things we need it to be: for example a temp GRUU is not usually considered an AoR, afaik.  Yet identifying the original GRUU from the original request-URI was one of the motivating factors for Jonathan's ua-loose-routing draft which got us here, no?  In fact, we didn't care if it was an "AoR" whatsoever - if the original UAC used a request-URI containing the Contact-URI of a UAS, we wanted to know it; if it used a Tel-URI, we wanted to know that too (and a TEL-URI is not an "AoR", afaik).  Or am I missing something obvious? (could be - my brain's dead)

-hadriel

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 12 Jul 2009 02:00:58 -0500

At 12:00 AM 7/12/2009, Hadriel Kaplan wrote:
>I see the term "AoR" as being somehow treated as an unambiguous 
>term, knowable to a Proxy of the AoR's domain as being an "AoR" on 
>sight.  It is then used in the draft to identify a specific HI URI 
>as the original-target URI - the identifier to look for when trying 
>to find the "original" request-URI.  Right?
>
>So if the Proxy of the AoR's domain is supposed to indicate a 
>SIP-URI is an AoR, how does it know it?  What is the distinguishing 
>parameter or URI syntax of an AoR, which makes it different from 
>any-old sip:user@domain SIP-URI?

isn't an AOR a SIP:URI that doesn't have a contact host on the domain 
side of the URI?

For example,

         [email-masked]  is an AOR
but
         [email-masked] is not an AOR *because*
         of the host part (pc33) to the right of the @

I'm sure this is simplistic

I'm also curious if someone knows the secret sauce to this, if there 
is such an animal...

>For example, is "sip:[email-masked]" an AoR?

I think this one is an AOR

>Is "sip:[email-masked];user=phone" an AoR?

no sure on this one

>  Is "sip:[email-masked];gr" an AoR?

seem like this one is too

>I'm not trying to be flippant (well, ok I am)

BTW - you're always flippant, so you don't need to qualify yourself   ;-)

>but there is no such distinguishing characteristic, afaik.  It is an 
>abstract concept, and it is just a specific subset of SIP/SIPS-URIs 
>we use to describe something; but it means nothing in particular to 
>a Proxy really, does it?  For example AoR's are not all/only 
>SIP-URI's that are Registered through a SIP REGISTER transaction; 
>they can be statically routed/resolved, or added to a location 
>service via a web page, etc.  In some of our specs we consider an 
>AoR to be the human identity, whereas a contact address is a 
>machine, but really there's nothing that makes it be a human 
>identity - it could be a group identity, a conf room phone, a 
>voicemail box, an alias for anther AoR, etc.
>
>In fact I'm not even sure it's all of the things we need it to be: 
>for example a temp GRUU is not usually considered an AoR, 
>afaik.  Yet identifying the original GRUU from the original 
>request-URI was one of the motivating factors for Jonathan's 
>ua-loose-routing draft which got us here, no?  In fact, we didn't 
>care if it was an "AoR" whatsoever - if the original UAC used a 
>request-URI containing the Contact-URI of a UAS, we wanted to know 
>it; if it used a Tel-URI, we wanted to know that too (and a TEL-URI 
>is not an "AoR", afaik).  Or am I missing something obvious? (could 
>be - my brain's dead)
>
>-hadriel
>_______________________________________________
>sipcore mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sipcore

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 12 Jul 2009 03:46:55 -0400

> -----Original Message-----
> From: James M. Polk [mailto:[email-masked]]
> Sent: Sunday, July 12, 2009 3:01 AM
> 

*You* know pc33 is a hostname.  As far as I know, pc33.example.com is a SIP domain.  For example "sip:[email-masked]" is an AoR, but so could "sip:[email-masked]" be. (and furthermore there's nothing to prevent a host from running its own SIP domain, afaik)

Obviously pc33.example.com itself could know, and that was the point of the "aor" param being added by the targeted domain presumably, but my issue is more of a how does even it know? (and secondly, why does it matter if it's an "AoR"?)

For example, if pc33 was a CCM and has an internal static route for "[email-masked]" to be routed to a SIP Trunk, was alice an AoR?

What if "[email-masked]" is actually a test-loopback URI on the CCM itself, or is a specific voicemail box on the CCM (ie, the URI was the contact address)?

> BTW - you're always flippant, so you don't need to qualify yourself   ;-)

Just in case people forget. :)

-hadriel

---

From: Hans Erik van Elburg <[email-masked]>
Date: Sun, 12 Jul 2009 12:10:27 +0200

Well.. definition of AOR per RFC3261:

"Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI
         that points to a domain with a location service that can map
         the URI to another URI where the user might be available.
         Typically, the location service is populated through
         registrations.  An AOR is frequently thought of as the "public
         address" of the user."

The approach taken is that if a proxy determines that a Request-URI on 
an incoming request is for a domain that it is responsible for, it 
performs an abstract-location-server lookup for the URI then this must 
be an AOR and the proxy tags the H-I entry representimg this uri as 
being an AOR.

To me this seems totally deterministic.

BTW a GRUU in this sense is also an AOR.

/Hans Erik

Hadriel Kaplan wrote:
>
> > -----Original Message----- From: James M. Polk
> > [mailto:[email-masked]] Sent: Sunday, July 12, 2009 3:01 AM
> >
> > isn't an AOR a SIP:URI that doesn't have a contact host on the
> > domain side of the URI?
> >
> > For example,
> >
> > [email-masked]  is an AOR but [email-masked] is not an
> > AOR *because* of the host part (pc33) to the right of the @
>
>  *You* know pc33 is a hostname.  As far as I know, pc33.example.com is
>  a SIP domain.  For example "sip:[email-masked]" is an AoR, but so
>  could "sip:[email-masked]" be. (and furthermore there's nothing
>  to prevent a host from running its own SIP domain, afaik)
>
>  Obviously pc33.example.com itself could know, and that was the point
>  of the "aor" param being added by the targeted domain presumably, but
>  my issue is more of a how does even it know? (and secondly, why does
>  it matter if it's an "AoR"?)
>
>  For example, if pc33 was a CCM and has an internal static route for
>  "[email-masked]" to be routed to a SIP Trunk, was alice an
>  AoR?
>
>  What if "[email-masked]" is actually a test-loopback URI on
>  the CCM itself, or is a specific voicemail box on the CCM (ie, the
>  URI was the contact address)?
>
>
>  -hadriel _______________________________________________ sipcore
>  mailing list [email-masked]

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 12 Jul 2009 13:19:37 -0500

At 02:46 AM 7/12/2009, Hadriel Kaplan wrote:

>*You* know pc33 is a hostname.  As far as I know, pc33.example.com 
>is a SIP domain.  For example "sip:[email-masked]" is an AoR, but 
>so could "sip:[email-masked]" be. (and furthermore there's 
>nothing to prevent a host from running its own SIP domain, afaik)

fair point

>of the "aor" param being added by the targeted domain presumably, 
>but my issue is more of a how does even it know?

>(and secondly, why does it matter if it's an "AoR"?)

I believe the answer here is that an AOR can get retargeted without a 
redirection (i.e., a 3XX isn't sent to the UAC), but I might be 
operating on stale info here.

>"[email-masked]" to be routed to a SIP Trunk, was alice an AoR?
>

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 12 Jul 2009 13:24:51 -0500

At 05:10 AM 7/12/2009, Hans Erik van Elburg wrote:
>The approach taken is that if a proxy determines that a Request-URI 
>on an incoming request is for a domain that it is responsible for, 
>it performs an abstract-location-server lookup for the URI then this 
>must be an AOR and the proxy tags the H-I entry representimg this 
>uri as being an AOR.
>

err, how isn't a GRUU an ultimate Contact address?

AORs do not have hostnames in them, and Contact addresses (typically) 
do. The point of a GRUU is *this* instance of a UA that is 
universally routable. That, to me, is a Contact address that has 1 
destination UA in mind.

This might be splitting hairs though, and I await the masters to 
comment (JDR, HS, RS, or Fluffy... :-)

---

From: Hans Erik van Elburg <[email-masked]>
Date: Sun, 12 Jul 2009 23:01:39 +0200

Nope, a GRUU is an AOR like any other, allthough with special property 
that it is targeted at a specific UA instance or restricted set of UA 
instances. That you can use it as a contact in INVITEs and responses is 
not of the essence.

See 5.4, 6.1 of  the GRUU draft 
http://[tools.ietf.org/html/draft-ietf-sip-gruu-15].

/Hans Erik

James M. Polk wrote:
>> on an incoming request is for a domain that it is responsible for, it 
>> performs an abstract-location-server lookup for the URI then this 
>> must be an AOR and the proxy tags the H-I entry representimg this uri 
>> as being an AOR.
>>
> do. The point of a GRUU is *this* instance of a UA that is universally 
> routable. That, to me, is a Contact address that has 1 destination UA 
> in mind.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 12 Jul 2009 21:18:53 -0400

I largely agree with Hans.

For all intents and purposes, a URI is an AoR if the policy of the 
domain of that URI says it is an AoR.

And note that being an AoR and being a Contact are not mutually 
exclusive. An AoR can be both.

Distinguishing based on the value of the host portion of the URI is not 
a reliable technique in general, though there might be heuristics that 
work for a lot of domains. For instance, for some domain x it may be 
that sip:foo@x is an AoR if it is defined at all, and sip:[email-masked] 
is never an AoR.

And AFAIK even if the URI contains an ip address rather than a domain 
name it could still be an AoR.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 12 Jul 2009 22:04:03 -0400

> From: Hans Erik van Elburg [mailto:[email-masked]]
> Sent: Sunday, July 12, 2009 6:10 AM
> 

Afaik, there is no current conceptual field recorded in the abstract location-service by 3261 that defines an entry as an "AoR" vs. just a default route to the PSTN, for example.

For example, when a proxy that is authoritative for example.com receives a request for "sip:[email-masked]" form one of its users, it has the ability to lookup that username in its LS, not find it, change it to "sip:[email-masked]" based on local policies, look it up again, and find a match for that.  So was the original "sip:[email-masked]" an AoR?  Presumably yes.  What if the matching entry's next-hop was from a static route vs. a registered contact?  Also presumably yes.  What if the matching entry's next-hop is actually just a default route to a local PSTN gateway?  Presumably no it's not an AoR, but how does the Proxy distinguish this case from the previous two?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 12 Jul 2009 22:10:55 -0400

> Sent: Sunday, July 12, 2009 5:02 PM
> 

Every time I read that it tells me a GRUU is not an AoR.  It has a relationship with one, but it isn't one itself.  At least in the language the draft uses.  For example:

   ...Every GRUU is associated with a single AOR
   and a single instance ID.  A registrar MUST be able to determine the
   instance ID and AOR when presented with a GRUU.  In addition, the
   GRUU, like an AOR, resolves to zero or more contacts.  While the AOR
   resolves to all registered contacts for an AOR, a GRUU resolves only
   to those contacts whose instance ID matches the one associated with
   the GRUU.  For this reason, a contact with an instance ID is always
   bound to both a GRUU and its AOR, never just an AOR or just a GRUU.

But I'm probably being real nitpicky pedantic.  I'm not even sure it really matters, because I have no idea why we care if a HI entry's URI is an "AoR" or not. (but that's a topic for another thread :)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 12 Jul 2009 22:12:40 -0400

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Sunday, July 12, 2009 9:19 PM
> 

Yes, it's like porn vs. art: you know it when you see it. ;)

> name it could still be an AoR.

Yup.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 12 Jul 2009 22:50:34 -0400

> But I'm probably being real nitpicky pedantic.  I'm not even sure it really matters, because I have no idea why we care if a HI entry's URI is an "AoR" or not. (but that's a topic for another threa…

As another in the cult of nitpicky pedentic people...

A gruu does have a lot in common with an AoR. It shares a domain with 
AoRs, and it is translated using the same location service as an AoR, 
with much the same algorithms.

But in other respects it is not an AoR.

But obviously it doesn't meet all our expectations about what an AoR 
should be.

I'm not sure we can provide a yes/no answer to this question.

	Thanks,
	Paul

_________________________________________

---

From: "Francois Audet" <[email-masked]>
Date: Sun, 12 Jul 2009 20:11:01 -0700

On Jul11 2009 22:00 , "Hadriel Kaplan" <[email-masked]> wrote:

> I see the term "AoR" as being somehow treated as an unambiguous term, knowable
> to a Proxy of the AoR's domain as being an "AoR" on sight.  It is then used in
> the draft to identify a specific HI URI as the original-target URI - the
> identifier to look for when trying to find the "original" request-URI.  Right?
> 
> So if the Proxy of the AoR's domain is supposed to indicate a SIP-URI is an
> AoR, how does it know it?  What is the distinguishing parameter or URI syntax
> of an AoR, which makes it different from any-old sip:user@domain SIP-URI?
> 
> For example, is "sip:[email-masked]" an AoR?  Is

Yes.

> "sip:[email-masked];user=phone" an AoR?  Is

Yes

> "sip:[email-masked];gr" an AoR?

Probably not.

They are long-term addresses. We are using the RFC 3261 definition:

      Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI
         address" of the user.

> I'm not trying to be flippant (well, ok I am) but there is no such
> distinguishing characteristic, afaik.  It is an abstract concept, and it is
> just a specific subset of SIP/SIPS-URIs we use to describe something; but it
> means nothing in particular to a Proxy really, does it?  For example AoR's are
> not all/only SIP-URI's that are Registered through a SIP REGISTER transaction;
> they can be statically routed/resolved, or added to a location service via a
> web page, etc.  In some of our specs we consider an AoR to be the human
> identity, whereas a contact address is a machine, but really there's nothing
> that makes it be a human identity - it could be a group identity, a conf room
> phone, a voicemail box, an alias for anther AoR, etc.

Yes, exactly; they are all that.

Key points are: a proxy doesn't mark as AOR an address in a foreign domain.
Neither does it mark temporary URIs that are not expected to generically
route to a user.

In other words, for the purpose of this draft, if a proxy sees something it
doesn't "own", it doesn't mark it as AOR. If it is an address in its own
domain (e.g., a phone number, an email-looking address, etc.), then it does.

> In fact I'm not even sure it's all of the things we need it to be: for example
> a temp GRUU is not usually considered an AoR, afaik.  Yet identifying the
> original GRUU from the original request-URI was one of the motivating factors
> for Jonathan's ua-loose-routing draft which got us here, no?  In fact, we
> didn't care if it was an "AoR" whatsoever - if the original UAC used a
> request-URI containing the Contact-URI of a UAS, we wanted to know it; if it
> used a Tel-URI, we wanted to know that too (and a TEL-URI is not an "AoR",
> afaik).  Or am I missing something obvious? (could be - my brain's dead)

You are kind of rambling in this paragraph, but I *think* I agree with you.
A temp GRUU is not an AOR.

Let's backtrack a little bit.

It's not like you would just ignore the entries not marked with aor flag. If
you are expecting a temp GRUU, then the aor flag is not terribly relevant.

---

From: "Francois Audet" <[email-masked]>
Date: Sun, 12 Jul 2009 20:13:32 -0700

It's the address you would put on a business card.

---

From: "Francois Audet" <[email-masked]>
Date: Sun, 12 Jul 2009 20:30:12 -0700

Dude, are you arguing there is no such thing as an AOR?

What's your point?

On Jul12 2009 19:04 , "Hadriel Kaplan" <[email-masked]> wrote:

> Afaik, there is no current conceptual field recorded in the abstract
> location-service by 3261 that defines an entry as an "AoR" vs. just a default
> route to the PSTN, for example.
> 
> For example, when a proxy that is authoritative for example.com receives a
> request for "sip:[email-masked]" form one of its users, it has the
> ability to lookup that username in its LS, not find it, change it to
> "sip:[email-masked]" based on local policies, look it up again, and
> find a match for that.  So was the original "sip:[email-masked]" an
> AoR?  Presumably yes.  What if the matching entry's next-hop was from a static
> route vs. a registered contact?  Also presumably yes.  What if the matching
> entry's next-hop is actually just a default route to a local PSTN gateway?
> Presumably no it's not an AoR, but how does the Proxy distinguish this case
> from the previous two?
> 
> -hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Sun, 12 Jul 2009 20:36:35 -0700

Hadriel,

The AOR flag basically means:
1) The proxy is responsible for that domain; AND
2) The proxy recognize the user part as something that it can route.

That's it.

The really important point is really point 1. Foreign domains for example
can't mark as AORs something they don't own.

On Jul12 2009 19:10 , "Hadriel Kaplan" <[email-masked]> wrote:

> Every time I read that it tells me a GRUU is not an AoR.  It has a
> relationship with one, but it isn't one itself.  At least in the language the
> draft uses.  For example:
> 
> But I'm probably being real nitpicky pedantic.  I'm not even sure it really
> matters, because I have no idea why we care if a HI entry's URI is an "AoR" or
> not. (but that's a topic for another thread :)
> 
> -hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 12 Jul 2009 23:41:25 -0400

> From: Francois Audet [mailto:[email-masked]]
> Sent: Sunday, July 12, 2009 11:30 PM
> 
 
My point is that if we need a Proxy to set an "aor" param (though I'm not sure what value there is in setting one), then there needs to be a defined mechanism for how it decides to do so.  Otherwise a domain's Proxy from vendor X will decide foo is an aor, and vendor Y's will decide foo is not one - and a UAS will not act the same way for foo.

In other words, I need some programmatic way for my system to set a param when it should, and not when it should not; so that my TAC does not get support calls complaining it should have done it when it didn't, or didn't do it when it should have.  No?

-hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 13 Jul 2009 11:10:10 -0500

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: Sunday, July 12, 2009 19:13
> To: Paul Kyzivat; Hans Erik van Elburg
> Cc: SIPCORE
> Subject: Re: [sipcore] rfc4244bis: what is an AoR?
> 
> 
> 

This is a bad analogy.

Only the proxy responsible for an AOR knows that it is an AOR. For everybody else, it's
just a URI.

That's why in the procedures in the document, it's only that proxy that can mark an
entry as an AOR.

It basically means "I own this address and will route it accordingly". And then the next entry 
can be a registered contact, or it can be mapped to another URI (for example).

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 13 Jul 2009 12:15:35 -0400

> Sent: Sunday, July 12, 2009 11:11 PM
> 

Right, so what *is* relevant about an "aor" flag?  What is it used/useful for?

I *think* the purpose for it is to let a UAS find the request-URI that was in the message before it got replaced by the registered contact URI.  Is that right?

In other words: along the lines of JDR's original ua-loose-route draft, where the proposal was the req-URI not be changed by a registration resolution process so that a UAS would get what the UAC sent - this 4244bis draft is trying to provide that "original" req-URI by tagging it as "aor", and telling the UAS to find the last instance of this flag.

But that's not really the right thing to flag, because it's not the right thing for the UAS to look for, because:

1) The motivation of the ua-loose-route and target drafts was the UAS cares about what the UAC *sent*, not what the last proxy saw before it was changed.  That may seem like the same thing, but it's not.  If I send a request to "sip:[email-masked]" and it gets resolved to another pseudonym AoR of "[email-masked]" which then is resolved to the UAS contact, the UAS needs to find "sip:[email-masked]" - not the last "aor" flag which would be for "[email-masked]".

2) It is not actually "AoRs" that we care about finding.  It's whatever the request-URI was.  It could have been a tel-URI, a GRUU, a service URN (e.g., sos), etc. 

I *think* the URI that actually needs to be found is the last one with an "mp" param. (or the first one if none have an mp param)  In other words, get the req-URI that the UAC or last retargeter sent.  

There's still a very difficult problem of how one decides if an "mp" mapped flag URI was actually a real re-target forwarding event vs. a pseudonym resolution, but that's a problem any mechanism would have. (And only the UAS would actually know if the target identity changed or not, afaict)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 13 Jul 2009 12:24:05 -0400

> Sent: Monday, July 13, 2009 12:10 PM
> 
> > >

You're right - to make it analogous, it's like porn vs. art, but only art-critics can say which one it is.   In other words, the problem isn't that we can't find someone to tell us what *they* think it is, the problem is two such experts (proxies) will not agree.

In this thread there have already been 5 people with 6 different opinions of what is and is not an "AoR".  That's not a good sign.

If I build a UAS, do I have to guess which vendor made my domain's authoritative proxy, so I can know what types of HI URI's it will and will not flag as "aor"?

-hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 13 Jul 2009 11:28:40 -0500

Hi Hadriel,

The purpose of the AOR flag is to indicate that a location
service can say "I found it!" with regards to a Request-URI.

If you don't have a flag like this, you end-up with many redundant
entries for the same user, and it makes it difficult to distinguish
logical retargets.

I don't believe the main use case is for the target-URI, because,
it's really the last entry before the registered/configured contact that
is important, regardless of the flag.

It's more for the classical redirections cases that it's useful.

And it is more obviously useful when there is "strict routing", it 
which case there are a bunch of entries that have nothing to do with 
the actual target.

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Monday, July 13, 2009 09:16
> To: Audet, Francois (SC100:3055); SIPCORE
> Subject: rfc4244bis: what is "aor" used for?
> 
> 
> 
> > It's not like you would just ignore the entries not marked 
> with aor flag.
> > If
> I *think* the purpose for it is to let a UAS find the 
> request-URI that was in the message before it got replaced by 
> the registered contact URI.  Is that right?
> 
> In other words: along the lines of JDR's original 
> ua-loose-route draft, where the proposal was the req-URI not 
> be changed by a registration resolution process so that a UAS 
> would get what the UAC sent - this 4244bis draft is trying to 
> provide that "original" req-URI by tagging it as "aor", and 
> telling the UAS to find the last instance of this flag.
> 
> But that's not really the right thing to flag, because it's 
> not the right thing for the UAS to look for, because:
> 
> 1) The motivation of the ua-loose-route and target drafts was 
> the UAS cares about what the UAC *sent*, not what the last 
> proxy saw before it was changed.  That may seem like the same 
> thing, but it's not.  If I send a request to 
> "sip:[email-masked]" and it gets resolved to another 
> pseudonym AoR of "[email-masked]" which then is 
> resolved to the UAS contact, the UAS needs to find 
> "sip:[email-masked]" - not the last "aor" flag which would 
> be for "[email-masked]".
> 
> 2) It is not actually "AoRs" that we care about finding.  
> It's whatever the request-URI was.  It could have been a 
> tel-URI, a GRUU, a service URN (e.g., sos), etc. 
> 
> I *think* the URI that actually needs to be found is the last 
> one with an "mp" param. (or the first one if none have an mp 
> param)  In other words, get the req-URI that the UAC or last 
> retargeter sent.  
> 
> There's still a very difficult problem of how one decides if 
> an "mp" mapped flag URI was actually a real re-target 
> forwarding event vs. a pseudonym resolution, but that's a 
> problem any mechanism would have. (And only the UAS would 
> actually know if the target identity changed or not, afaict)
> 
> -hadriel
>

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 13 Jul 2009 11:34:41 -0500

Actually, it would be the content producers, not the art critics... 

> Sent: Monday, July 13, 2009 09:24
> To: Audet, Francois (SC100:3055); Paul Kyzivat; Hans Erik van Elburg
> Cc: SIPCORE
> Subject: RE: [sipcore] rfc4244bis: what is an AoR?
> 
> 
> 
> > Only the proxy responsible for an AOR knows that it is an AOR. For 
> > everybody else, it's just a URI.
> > That's why in the procedures in the document, it's only that proxy 
> > that can mark an entry as an AOR.
> > It basically means "I own this address and will route it 
> accordingly". 
> > And then the next entry can be a registered contact, or it can be 
> > mapped to another URI (for example).
> 
> You're right - to make it analogous, it's like porn vs. art, 
> but only art-critics can say which one it is.   In other 
> words, the problem isn't that we can't find someone to tell 
> us what *they* think it is, the problem is two such experts 
> (proxies) will not agree.
> 
> In this thread there have already been 5 people with 6 
> different opinions of what is and is not an "AoR".  That's 
> not a good sign.
> 
> If I build a UAS, do I have to guess which vendor made my 
> domain's authoritative proxy, so I can know what types of HI 
> URI's it will and will not flag as "aor"?
> 
> -hadriel
>

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 13 Jul 2009 11:56:12 -0500

To me it's crystal clear.

If you are the entity (proxy or redirect server) responsible for 
the URI, and you find the entry in your location service, you mark
as AOR.

That means you will now route based on "rules" you have internally,
e.g., map it to a contact, etc.

If you are a proxy not responsible with this address, you will just
forward it unaltered (if you are using loose routing), or you will
route it but replace the R-URI with an upstream proxy (if you use
strict routing).

> Sent: Sunday, July 12, 2009 20:41
> To: Audet, Francois (SC100:3055); Hans Erik van Elburg
> Cc: SIPCORE
> My point is that if we need a Proxy to set an "aor" param 
> (though I'm not sure what value there is in setting one), 
> then there needs to be a defined mechanism for how it decides 
> to do so.  Otherwise a domain's Proxy from vendor X will 
> decide foo is an aor, and vendor Y's will decide foo is not 
> one - and a UAS will not act the same way for foo.
> 
> In other words, I need some programmatic way for my system to 
> set a param when it should, and not when it should not; so 
> that my TAC does not get support calls complaining it should 
> have done it when it didn't, or didn't do it when it should have.  No?
> 
> -hadriel
>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 13 Jul 2009 19:06:40 +0200

Inline..

/Hans Erik van Elburg

On Mon, Jul 13, 2009 at 5:25 PM, Hadriel Kaplan <[email-masked]>wrote:

>
>
> Sure if you think the set of URI’s which have registered or configured
> contacts are the whole set of AoR’s, such that URI’s which have other AoR’s
> as their resolution are not AoR’s and there are no URI’s which have
> registered or configured contacts which are not AoR’s.
>
> But I don’t think that’s true.
>
>
>
> For example, “sip:[email-masked]<[email-masked]>”
> may resolve to “sip:[email-masked] <[email-masked]>”
> which then resolves to a registered contact – both of those are AoR’s, but
> only the second will pass your test.
>
Both will pass "my" test. The proxy that consults the location service will
tag teh 1st with AOR, the ("next" which might be the same) proxy that
performs the lookup for the 2nd will tag that one as AOR. I did not intend
to restrict the location-service-lookup to only return contacts.

> But “tel:+17813284428” will resolve to “sip:[email-masked]<[email-masked]>”
> as well, but the tel-URI is not an AoR.
>
As far a I know the terminating home proxy will not receive a tel:, but a
SIP URI if the originating proxy could not transform the TEL URL to a SIP
URI it would have to break out to PSTN. I might be wrong. I agree that a TEL
URL is not an AOR.

> And for example when a Service Provider’s proxy receives “
> sip:[email-masked] <[email-masked]>;user=phone”, the
> location service could return a configured next-hop URI of “
> sip:[email-masked] <[email-masked]>”
> (through an ENUM lookup, for example), to route it to the PSTN.  Now it
> turns out that configured next-hop is an AoR, and it’s not really even
> configured for that AoR – it’s a default route for all +1781 area codes.
>  How does the proxy know (1) that it’s a configured next-hop contact and not
> a configured next-hop AoR, (2) that “sip:[email-masked]<[email-masked]>;user=phone”
> was NOT in fact an AoR.
>
Its not an AOR your breaking out for a reason.

>  -hadriel
>
>
>   ------------------------------
>
> *From:* Hans Erik van Elburg [mailto:[email-masked]]
> *Sent:* Monday, July 13, 2009 4:11 AM
> *To:* Hadriel Kaplan
> *Subject:* Re: [sipcore] rfc4244bis: what is an AoR?
>
>
>
> Thats an easy one, if a proxy has arrived in section 16.5/RFC3261 to the
> conclusion that:
> "If the target set for the request has not been predetermined as
>
> described above, this implies that the element is responsible for the
> domain in the Request-URI, and the element MAY use whatever mechanism
> it desires to determine where to send the request. Any of these
>
> mechanisms can be modeled as accessing an abstract Location Service."
>
> If the location service returns registered or configured contacts, then it
> can safely conclude that the Request-URI of the incoming request is an AOR.
>
>
>
> No rocket science.
>
>
>
> /Hans Erik van Elburg
>
>  On Mon, Jul 13, 2009 at 5:41 AM, Hadriel Kaplan <[email-masked]>
> wrote:
>
>
>
> My point is that if we need a Proxy to set an "aor" param (though I'm not
> sure what value there is in setting one), then there needs to be a defined
> mechanism for how it decides to do so.  Otherwise a domain's Proxy from
> vendor X will decide foo is an aor, and vendor Y's will decide foo is not
> In other words, I need some programmatic way for my system to set a param
> when it should, and not when it should not; so that my TAC does not get
> support calls complaining it should have done it when it didn't, or didn't
> do it when it should have.  No?
>
> -hadriel
>
>
>

---

From: Dean Willis <[email-masked]>
Date: Mon, 13 Jul 2009 12:40:37 -0500

Hadriel Kaplan wrote:

> 1) The motivation of the ua-loose-route and target drafts was the UAS
> cares about what the UAC *sent*, not what the last proxy saw before
> it was changed.  That may seem like the same thing, but it's not.  If
> I send a request to "sip:[email-masked]" and it gets resolved to
> another pseudonym AoR of "[email-masked]" which then is
> "sip:[email-masked]" - not the last "aor" flag which would be for
> "[email-masked]".

The real problem is even messier: The goal is to find that which was
sent by the UAC as modified by intermediaries that claim to be
authoritative in doing so.

For example, I might have a speed-dial service implemented in a proxy.
My UAS sends "sip:[email-masked]", which is then translated by my
proxy to be "sip:[email-masked];user=dwillis".

Another proxy might do contact routing, translating
"sip:[email-masked];user=dwillis" into "sip:192.168.2.23"

The voicemail server then needs to find the intermediate translation.

In this case, this just happens to be the parameterized AOR of the
voicemail server, but it certainly doesn't have to be. It could also be
considered as the last mapping operation prior to contact routing, but
again, it doesn't have to be; we can add anotehr layer that makes it the
next-to-last mapping.

> 2) It is not actually "AoRs" that we care about finding.  It's
> whatever the request-URI was.  It could have been a tel-URI, a GRUU,
> a service URN (e.g., sos), etc.
> 
> I *think* the URI that actually needs to be found is the last one
> with an "mp" param. (or the first one if none have an mp param)  In
> other words, get the req-URI that the UAC or last retargeter sent.
> 
> There's still a very difficult problem of how one decides if an "mp"
> mapped flag URI was actually a real re-target forwarding event vs. a
> pseudonym resolution, but that's a problem any mechanism would have.
> (And only the UAS would actually know if the target identity changed
> or not, afaict)

I believe the whole problem is much more readily solved by something
closer to Christer's approach: Put the target URI and parameters into a
separate header field that is NOT used for routing. This header field
might be manipulated by a middlebox (such as my speed-dial service), but
at least it doesn't get accidentally twiddled by a routing operation.

Solving this problem with H-I seems to me to be gross overkill and an
unnecessary exercise in pointless complexity. But that's what we do best
around here.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Jul 2009 13:41:00 -0400

> e.g., map it to a contact, etc.

I think some cases are clear, others not so much:

- If the proxy translates to a contact that it got from a
   location service and that entry was placed there by a REGISTER,
   then the entry should definitely be marked as an AoR

- If the proxy translates to a contact that it got from a
   ocation service, and that entry got there somehow other than REGISTER,
   then I *think* the entry should still be marked as an AoR.

- If the proxy uses some other logic than a "location service"
   to translate the URI, but it might in other cases use the
   location service to translate the URI, then I'm not sure.

- If the proxy never uses a location service for this URI,
   but translates it on some other basis, then again I'm not sure.

One problem here is that the location service is abstract. There are 
things that can be done using it, or in another manner. It seems to me 
that if it *could* have been done with a location service lookup, then 
the result ought to be the same whether it is or not.

	Thanks,
	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 13 Jul 2009 12:45:06 -0500

> Solving this problem with H-I seems to me to be gross 
> overkill and an unnecessary exercise in pointless complexity. 
> But that's what we do best around here.

I don't see how this is overkill.

We have History-info anyways.

Using the 2 header approaches means, well, that we'll have 2 headers doing the same
thing, potentially conflicting with each other.

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 13 Jul 2009 13:39:35 -0500

> Sent: Monday, July 13, 2009 10:41
> To: Audet, Francois (SC100:3055)
> Cc: Hadriel Kaplan; Hans Erik van Elburg; SIPCORE
> > If you are the entity (proxy or redirect server) 
> responsible for the 
> > URI, and you find the entry in your location service, you 
> mark as AOR.
> > 

Agree.

>    then I *think* the entry should still be marked as an AoR.

Yes, agree.

> One problem here is that the location service is abstract. 
> There are things that can be done using it, or in another 
> manner. It seems to me that if it *could* have been done with 
> a location service lookup, then the result ought to be the 
> same whether it is or not.

I think the last two are the same thing.
Things like digit manipulation and so forth.

I didn't want to alter (or second-guess) the definition of AOR (which is 
the realm of RFC 3261), in this draft.

I would think that if the proxy doesn't know that it's an AOR, then it shouldn't mark
it as such. So I would expect mechanical digit manipulation to NOT be marked as AOR.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 13 Jul 2009 16:49:48 -0400

> Sent: Monday, July 13, 2009 12:29 PM
> 

Oooohhhh.  Wow, that's not what I read it as - in the draft it says:
      ...the [aor] parameter indicates that
      the specific hi-targeted-to-uri that was retargeted was an AOR and
      thus the previous information in the request-URI may be "lost".
      Upon receipt of a request or response containing the History-Info
      header, a UA can determine a "lost" target AOR for a request by
      traversing the HI entries in reverse order to find the first one
      tagged with a specific hi-aor parameter.

> which case there are a bunch of entries that have nothing to do with

I thought that in the chain of emails back in June, the claim was there would be no strict routing mixed with HI, because any proxy/uas supporting HI must be 3261-compliant to begin with, not 2543. (I could remember that thread incorrectly though)

But anyway I don't think it's necessary or sufficient for even that purpose.  I'm thinking that the "mp" param is actually sufficient to cull that list down to what's important.  I just can't tell yet if I'm right or wrong about that.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 13 Jul 2009 16:58:25 -0400

> From: Dean Willis [mailto:[email-masked]]
> Sent: Monday, July 13, 2009 1:41 PM
> 
> Hadriel Kaplan wrote:
> 

Yes, that was what I meant later in that email about: "In other words, get the req-URI that the UAC or last retargeter sent."

The caveat for ua-loose-route and Target was that if the request was re-targeted, the "original Req-URI" becomes the new one the retargeter uses.  Unfortunately, it is really really hard for machines to know when something is a re-target vs. just a simple re-route to the same user.

> at least it doesn't get accidentally twiddled by a routing operation.

While I don't disagree the overhead would be a ton less, the actual problem of knowing when a re-target occurs vs. a simple re-route is no easier.  In other words, when should the Proxy leave the Target header alone vs. overwrite it.

-hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 13 Jul 2009 16:07:37 -0500

The email threads for the last few days leads me to believe that we have the
following 2 issues with regards to RFC 4244bis:

1) Do we need the "aor" flag?

2) Do we need the "cc" flag (i.e., "configured contact"). If we did NOT have the configured
   contact, flag, then I would think that we would have instead to use either "registered
   contact" or "mapped", as appropriate. 

Let's think about those two issues.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 13 Jul 2009 18:43:05 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Francois Audet
> Sent: Monday, July 13, 2009 5:08 PM
> 

I'm not sure we even need to care that it is a contact vs. an aor.
The replacement of the AoR in a req-uri to the registered contact is just one among many times it is *not* "mapped", and no "mp" would be added.

I.e., I'm curious if we need anything other than "mp".

-hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 13 Jul 2009 17:46:20 -0500

AOR is orthogonal to rc (and MP actually).

RC is very useful. It tells you that a specific entry is ephemeral 
address that replaced the AOR.

(i.e., it typically tells you can ignore it). 

Otherwise, you don't know that it it's a registered contact.

> Sent: Monday, July 13, 2009 15:43
> Subject: RE: rfc4244bis: Open Issues
> 
> 
> 
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Francois Audet
> >    contact, flag, then I would think that we would have 
> instead to use 
> > either "registered
> The replacement of the AoR in a req-uri to the registered 
> contact is just one among many times it is *not* "mapped", 
> and no "mp" would be added.
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 13 Jul 2009 19:00:23 -0400

> Sent: Monday, July 13, 2009 6:46 PM
> 

Yes I agree - aor was a property describing the type of URI in the HI-entry, whereas all the others are basically reasons the HI-entry's URI changed (or didn't), or the action that caused it to be what it is, if you prefer to think of it that way.  But that wasn't my point - sorry for the confusion.

> Otherwise, you don't know that it it's a registered contact.

It shouldn't matter.  You can ignore anything that doesn't have an "mp" flag, period.  The rest are all just window dressing - req-uri's that were changed or not, for reasons such as strict-routing, registered contact replacement, configured contact replacement, maddr, translations, foobar, etc.  

The change that matters is re-targeting, because the req-uri's that are important are the ones that are created in those cases.  That's what the Target/ua-loose-route concepts cared about; that's what Diversion-redirection info cared about; it's what freephone case cares about; it's what the PSAP emergency-call case cares about, etc.  Right? 
(they don't all happen to care about the same "mp" instance in the HI list, but they all care about "mp" entries)

-hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 13 Jul 2009 18:05:38 -0500

You need to distinguish between "old RFC 4244" and new.

The presence of the tag tells you it's new 4244.

> Sent: Monday, July 13, 2009 16:00
> Yes I agree - aor was a property describing the type of URI 
> in the HI-entry, whereas all the others are basically reasons 
> the HI-entry's URI changed (or didn't), or the action that 
> caused it to be what it is, if you prefer to think of it that 
> way.  But that wasn't my point - sorry for the confusion.
> 
> 
> It shouldn't matter.  You can ignore anything that doesn't 
> have an "mp" flag, period.  The rest are all just window 
> dressing - req-uri's that were changed or not, for reasons 
> such as strict-routing, registered contact replacement, 
> configured contact replacement, maddr, translations, foobar, etc.  
> 
> The change that matters is re-targeting, because the 
> req-uri's that are important are the ones that are created in 
> those cases.  That's what the Target/ua-loose-route concepts 
> cared about; that's what Diversion-redirection info cared 
> about; it's what freephone case cares about; it's what the 
> PSAP emergency-call case cares about, etc.  Right? 
> (they don't all happen to care about the same "mp" instance 
> in the HI list, but they all care about "mp" entries)
> 
> -hadriel
>

---

From: Dean Willis <[email-masked]>
Date: Mon, 13 Jul 2009 18:06:52 -0500

> We have History-info anyways.

H-I is overkill because it 1) does lots of things, not just this URI and
parameter transmission function b) is much bigger than what is required
for URI and parameter transmission, and c) doesn't deterministically
solve the URI and parameter transmission function.

Can you show me a universal algorithm for the UAS to use in figuring out
which HI entry is is supposed to use?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 13 Jul 2009 18:12:46 -0500

Hadriel Kaplan wrote:

>> The real problem is even messier: The goal is to find that which
>> was sent by the UAC as modified by intermediaries that claim to be 
> Yes, that was what I meant later in that email about: "In other
> words, get the req-URI that the UAC or last retargeter sent."

But it's not just a req-URI inserted by a UAC or retarger. A proxy might
legitimately add a parameter to the request URI. This is n't a retarget
-- using that vocabularly, it might be called a non-retargeting
reparameterization.

How does that show up in HI?

> 
> The caveat for ua-loose-route and Target was that if the request was
> re-targeted, the "original Req-URI" becomes the new one the
> retargeter uses.  Unfortunately, it is really really hard for
> machines to know when something is a re-target vs. just a simple
> re-route to the same user.

As I believe you asked, do they NEED to know whether this is a retarget
or re-route for parameter modification?

They clearly need to know whether parameter modification is reequired,
but I'd argue that this is an entirely independent problem.

> 
> 
>> I believe the whole problem is much more readily solved by
>> something closer to Christer's approach: Put the target URI and
>> parameters into a separate header field that is NOT used for
>> routing. This header field might be manipulated by a middlebox
>> (such as my speed-dial service), but at least it doesn't get
>> accidentally twiddled by a routing operation.
> 
> While I don't disagree the overhead would be a ton less, the actual
> problem of knowing when a re-target occurs vs. a simple re-route is
> no easier.  In other words, when should the Proxy leave the Target
> header alone vs. overwrite it.
> 

That's an application-specific question. What function is the proxy here
performing? And in what way is the application invocation entangled with
request routing?

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 13 Jul 2009 18:19:11 -0500

I assume your question is for "target URI" specifically.

You would look at the las entry that is not a "rc/cc/rt".

Bingo.

Now, your question was loaded. You said "universal" but clearly,
it's not Universal because your are strictly looking at solving the
TargetURI problem. Furthermore, you are strictly trying to solve the
LAST targetURI problem. There are applications that do not use the LAST but the
FIRST targetURI (for example). Lots of Voice mail systems, again, for 
example, do this.

Therefore, it's not Universal.

> Sent: Monday, July 13, 2009 16:07
> Cc: Hadriel Kaplan; SIPCORE
> Subject: Re: [sipcore] rfc4244bis: what is "aor" used for?
> 
> Francois Audet wrote:
> >  
> overkill and an 
> >> unnecessary exercise in pointless complexity.
> H-I is overkill because it 1) does lots of things, not just 
> this URI and parameter transmission function b) is much 
> bigger than what is required for URI and parameter 
> transmission, and c) doesn't deterministically solve the URI 
> and parameter transmission function.
> 
> Can you show me a universal algorithm for the UAS to use in 
> figuring out which HI entry is is supposed to use?
> 
> --
> Dean
>

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 13 Jul 2009 18:24:56 -0500

One thing that might really help this debate is to get the target-uri
usecases updated to describe how they will use these new tags. My
understanding as to why we needed to define the discrete tags and "aor"
was to handle a rather unfortunate PSTNish 800 service model - I'll let
Hans and Christer explain that one.  In the end, we tried to just
delineate the different approaches whereby the new target was determined
per section 16.5 of RFC 3261, since that is really the most we can do.
Of course, there's some lack of specificity there which is why we are
where we are.  

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Audet, Francois (SC100:3055)
Sent: Monday, July 13, 2009 6:06 PM
To: Hadriel Kaplan; SIPCORE
Subject: Re: [sipcore] rfc4244bis: Open Issues

> Yes I agree - aor was a property describing the type of URI in the 
> HI-entry, whereas all the others are basically reasons the HI-entry's 
> URI changed (or didn't), or the action that caused it to be what it 
> is, if you prefer to think of it that way.  But that wasn't my point -

> sorry for the confusion.
> It shouldn't matter.  You can ignore anything that doesn't have an 
> "mp" flag, period.  The rest are all just window dressing - req-uri's 
> that were changed or not, for reasons such as strict-routing, 
> registered contact replacement, configured contact replacement, maddr,

> translations, foobar, etc.
> 
> The change that matters is re-targeting, because the req-uri's that 
> are important are the ones that are created in those cases.  That's 
> what the Target/ua-loose-route concepts cared about; that's what 
> Diversion-redirection info cared about; it's what freephone case cares

> about; it's what the PSAP emergency-call case cares about, etc.  
> Right?
> (they don't all happen to care about the same "mp" instance in the HI 
> list, but they all care about "mp" entries)
> 
> -hadriel
>

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 13 Jul 2009 18:26:52 -0500

Exactly - 4244/4244bis are application agnostic - the applications use
what they need. Per my comment in the other thread, it would be really,
really useful to update target-uri use cases to describe how they're
using these tags. 

Mary.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Audet, Francois (SC100:3055)
Sent: Monday, July 13, 2009 6:19 PM
To: Dean Willis
Cc: SIPCORE; Hadriel Kaplan
Subject: Re: [sipcore] rfc4244bis: what is "aor" used for?

Bingo.

Now, your question was loaded. You said "universal" but clearly, it's
not Universal because your are strictly looking at solving the TargetURI
problem. Furthermore, you are strictly trying to solve the LAST
targetURI problem. There are applications that do not use the LAST but
the FIRST targetURI (for example). Lots of Voice mail systems, again,
for example, do this.

> H-I is overkill because it 1) does lots of things, not just this URI 
> and parameter transmission function b) is much bigger than what is 
> required for URI and parameter transmission, and c) doesn't 
> deterministically solve the URI and parameter transmission function.
> 
> Can you show me a universal algorithm for the UAS to use in figuring 
> out which HI entry is is supposed to use?
> 
> --
> Dean
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 13 Jul 2009 19:45:54 -0400

> Sent: Monday, July 13, 2009 7:13 PM
> 
> Hadriel Kaplan wrote:
> 

Can you give me an example?  What would such a thing be used for, that it requires a UAS receiving it in the H-I look at it for some useful purpose?

> How does that show up in HI?

As just another HI URI that can be ignored by the UAS.  And the problem is?

> but I'd argue that this is an entirely independent problem.

I have no idea what you mean by "parameter modification".  A UAS needs to know whether and which req-URI's were created by re-targeting, for it to know what the set of URI's to select from for Target identification, for Original Called Party vs. Redirection information (e.g., for billing or ISUP generation), for filtering, for prioritization, etc.  

> performing? And in what way is the application invocation entangled with

I'm confused - are you actually asking what the use-cases are/were for ua-loose-route, Diversion-Redirection, et al?  You were part of those draft discussions.  The problem of how any proxy would know when an identity actually changed or not was also discussed back then.  

If you buy into the idea that it's application-specific, or that only the UAS would really know, then you can't have Proxies simply putting in *one* Target header, because they'd never know if/when it should be changed before getting to the UAS.  They'd have to create a list of them: one new entry every time they re-targeted (or actually one for every time they did NOT absolutely know they did NOT retarget, if you can follow that crazy logic).

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 13 Jul 2009 20:00:08 -0400

> Sent: Monday, July 13, 2009 7:06 PM
> 

You lost me - the presence of which tag tells you it's old vs. new, and why would you care?  You mean the presence of any tag?  And thus you have tags that are added so that they can be distinguished from non-tagged HI-entries?? [at this point my brain explodes]

-hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 13 Jul 2009 19:13:44 -0500

If there is a tag (anyone), it's 4244bis. 

If there is none, it's 4244.

> Sent: Monday, July 13, 2009 17:00
> You lost me - the presence of which tag tells you it's old 
> vs. new, and why would you care?  You mean the presence of 
> any tag?  And thus you have tags that are added so that they 
> can be distinguished from non-tagged HI-entries?? [at this 
> point my brain explodes]
> 
> -hadriel
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 13 Jul 2009 21:42:41 -0400

> Sent: Monday, July 13, 2009 8:14 PM
> 

Got it.  Hate it, but got it. :)

You're going to hate this idea too, but oh well... the delete key is in easy reach... so here goes:
I suggest an explicit version tag.  The tag appears not in the header field itself, but in something called a "header-name" part of an "extension-header" in ABNF rules per rfc3261.  I suggest a new "header-name" value of "R-History-Info".  You can pretend the "R" is for Retargeted-History-Info, or Reduced-History-Info, or Revisionist-History-Info. :)

This "R-History-Info" extension-header is a multi-instance type, and a Proxy only ever adds to it if it is changing the received req-uri *and* would have set the "mp" flag for the new URI it is adding.  The first RHI entry is added by the first proxy or UAC based on what it received, like in H-I, even though it's not retargeting to that URI.  The extension-header's header-value is the URI being retargeted to.  There are no currently defined header parameters.

This RHI header field is not for troubleshooting - it's for actual processing use.  Therefore, there is no incrementing index param, no embedded Reason header, and no entries created for anything but retargeted events and their new URI's (and the first one).  Privacy does not apply to this on a header-by-header basis, and thus there is no embedded Privacy header either - if Privacy:history was requested, no RHI fields would be created.

Compared with RFC 4244, the RHI header field would produce a smaller subset of header instances.  In some cases significantly smaller.  For example, in the most common case, only a single RHI header field would be in the message, regardless of how many proxies were crossed.  There is also less processing overhead for every node in the message path.

It should be noted that, like RFC 4244, RHI does not produce the smallest list possible of retargets - in some cases an entry is added when the target user Identity has not changed - the URI has changed to a new one, but unbeknownst to the Proxy which added it, the Identity of the human may have remained the same.  For example an entry for "sip:[email-masked]" and a subsequent entry for "sip:[email-masked]" may both have been added, even though they are the same abstract target human.  A proxy cannot know by default that these two targets are the same identity.  Only the UAS would know that, and so it may need to cull the list down further.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 14 Jul 2009 00:01:19 -0400

> Sent: Monday, July 13, 2009 7:19 PM
> 

Which is the set of "mp", no?  

Note though that this set's last member is not *necessarily* the one Target-URI wants - it's the set/list it must walk through (in reverse order of the H-I list of "mp" ones) to find the Target-URI.  As it walks the list, if the local UAS believes it represents the URI, it keeps walking backwards - when it finds one it does not represent, it stops walking up the list and uses the last one it found that it *does* represent.  That one is the "Target-URI".

The UAS knows it "represents" one if it either (a) Registers that URI, or (b) learned it through P-Associated-URI, or (c) it learned or created a GRUU for itself, or (d) has some provisioned knowledge that it also represents that URI.

> Therefore, it's not Universal.

Right it's not universal, and no universal algorithm can find the right URI for all application uses.  But I think we can (and should) document what algorithms should be used for the most common applications, so that there's no confusion on the part of different implementations? (or even just to provide guidance?)

For example, a Voicemail system would NOT use the FIRST "mp" entry in the list, nor the LAST.  It needs to walk the list backwards to find the closest "mp" to the end that it can use.  Otherwise, a retarget from Alice to Bob will go to Alice's voicemail, when it should have gone to Bob's.  No?

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Jul 2009 09:41:33 -0400

Francois,

Maybe we can puzzle this out by examining more use cases.
You focused on digit manipulation, which is surely one. But there are 
others.

To spell out the digit manipulation case in more detail:

A proxy receives a request with sip R-URI in the domain it is 
responsible for. It sees that the user part is all digits. (E.g 
sip:[email-masked]) It then applies some sort of digit map it has 
been provisioned with (possibly per-caller, possibly per-domain) to 
transform that into some other more globally unique URI - perhaps an 
E.164 number in its own domain or some other domain, or a TEL URI. (E.g. 
sip:[email-masked];user=phone.) It does the translation and 
then proceeds based on the result. I agree in this case it is wrong to 
call the incoming R-URI an AOR.

A different case is synonyms or aliases:

A proxy responsible for example.net receives a request with R-URI 
sip:[email-masked]. This is not in its location service. But it has a 
provisioned alias table that says phk is a synonym for paul.kyzivat, so 
it translates the R-URI to sip:[email-masked]. It then 
proceeds to process that, which turns out to be in its location service, 
so it translates it again to sip:[email-masked].
Again, I don't think sip:[email-masked] is an AoR in this case.

Another case, for forwarding:

A proxy responsible for example.net receives a request with R-URI of 
sip:[email-masked]. There is a location service with an entry 
registered for sip:[email-masked], but there is also 
provisioning independent of the location service that says to 
unconditionally forward all calls to this URI to sip:[email-masked]. 
This is accomplished by R-URI translation. (To ensure that the request 
will not be rejected as mis-addressed.)

In this case I think that sip:[email-masked] *is* an AoR.

And one final forwarding case:

A proxy responsible for example.net receives a request with R-URI of 
sip:[email-masked]. Alice used to work for Example Co, but she 
no longer does, so her URI is "out of service". But the proxy has been 
provisioned to translate the R-URI of Alice's calls to her old boss' 
URI: sip:[email-masked]. There will never be an entry in the 
location service for alice, registrations are not permitted.

In this case, in spite of there being no location service involved, I 
still think sip:[email-masked] is an AoR.

So, IMO the bottom line is that whether a URI is an AoR is a policy 
decision within the domain of the URI.

	Thanks,
	Paul

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 14 Jul 2009 09:22:13 -0500

We did consider a version tag (slightly different approach than what you
suggest), but in the end the current approach is far simpler than what
you suggest and far more inline with the basic extensibility mechanism
that was put in 4244.  Your proposal takes us back to day one and just
defining a new header altogether.

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hadriel Kaplan
Sent: Monday, July 13, 2009 8:43 PM
To: Audet, Francois (SC100:3055); SIPCORE
Subject: Re: [sipcore] rfc4244bis: Open Issues

You're going to hate this idea too, but oh well... the delete key is in
easy reach... so here goes:
I suggest an explicit version tag.  The tag appears not in the header
field itself, but in something called a "header-name" part of an
"extension-header" in ABNF rules per rfc3261.  I suggest a new
"header-name" value of "R-History-Info".  You can pretend the "R" is for
Retargeted-History-Info, or Reduced-History-Info, or
Revisionist-History-Info. :)

This "R-History-Info" extension-header is a multi-instance type, and a
Proxy only ever adds to it if it is changing the received req-uri *and*
would have set the "mp" flag for the new URI it is adding.  The first
RHI entry is added by the first proxy or UAC based on what it received,
like in H-I, even though it's not retargeting to that URI.  The
extension-header's header-value is the URI being retargeted to.  There
are no currently defined header parameters.

This RHI header field is not for troubleshooting - it's for actual
processing use.  Therefore, there is no incrementing index param, no
embedded Reason header, and no entries created for anything but
retargeted events and their new URI's (and the first one).  Privacy does
not apply to this on a header-by-header basis, and thus there is no
embedded Privacy header either - if Privacy:history was requested, no
RHI fields would be created.

Compared with RFC 4244, the RHI header field would produce a smaller
subset of header instances.  In some cases significantly smaller.  For
example, in the most common case, only a single RHI header field would
be in the message, regardless of how many proxies were crossed.  There
is also less processing overhead for every node in the message path.

It should be noted that, like RFC 4244, RHI does not produce the
smallest list possible of retargets - in some cases an entry is added
when the target user Identity has not changed - the URI has changed to a
new one, but unbeknownst to the Proxy which added it, the Identity of
the human may have remained the same.  For example an entry for
"sip:[email-masked]" and a subsequent entry for
"sip:[email-masked]" may both have been added, even though they
are the same abstract target human.  A proxy cannot know by default that
these two targets are the same identity.  Only the UAS would know that,
and so it may need to cull the list down further.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Jul 2009 10:38:11 -0400

> Therefore, it's not Universal.

IMO the above is a hack to get a desired effect in the wrong way - a way 
that only works in certain restricted circumstances.

Specifically, it only works of the VM system used by the final target is 
the same one as used by the first target. So, with such an algorithm, if 
I forward my (work) calls to Jonathan and he isn't there then they would 
have a good chance to end up in my mailbox. But if I forward my calls to 
you, and you aren't there, then they will not end up in my mailbox.

When the call is retargetted, it should be marked as "no voicemail" so 
that if it isn't answered the proxy for the first target gets to decide 
alternative handling.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Jul 2009 11:08:25 -0400

> Note though that this set's last member is not *necessarily* the one Target-URI wants - it's the set/list it must walk through (in reverse order of the H-I list of "mp" ones) to find the Target-URI…

Why would it want the first of those it represents, not the last?

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 14 Jul 2009 11:08:54 -0400

> From: Mary Barnes [mailto:[email-masked]]
> Sent: Tuesday, July 14, 2009 10:22 AM
> To: Hadriel Kaplan; Francois Audet; SIPCORE
> Subject: RE: [sipcore] rfc4244bis: Open Issues
> 

Yup, that's exactly what it suggests.  Press Reset.  Let the few that want to do H-I the old way do it (for troubleshooting?), but do Target, Redirection, 800-service, etc. using R-H-I.

The current 4244bis approach is in no way, shape, or form "simpler" than what I am suggesting.  It's just lets you carry the old baggage - which is both good and bad.

Unless you think this:
History-Info: <sip:[email-masked]>;index=1;mp
History-Info: <sip:[email-masked]>;index=1.1;rt
History-Info: <sip:[email-masked]>;index=1.1.1;rt
History-Info: <sip:[email-masked]>;index=1.1.1.1;rt;aor
History-Info: <sip:[email-masked]>;index=1.1.1.1.1;rt;aor
History-Info: <sip:[email-masked]>;index=1.1.1.1.1.2.1;mp
History-Info: <sip:[email-masked]>;index=1.1.1.1.1.2.1.1;rt
History-Info: <sip:[email-masked]>;index=1.1.1.1.1.2.1.1.1;rt;aor
History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D300>;index=1.1.1.1.1.2.1.1.1.1;rt;aor
History-Info: <sip:[email-masked]>;index=1.1.1.1.1.2.1.1.1.1.1;rt;aor
History-Info: <sip:[email-masked]>;index=1.1.1.1.1.2.1.1.1.1.1.1;rc
History-Info: <sip:[email-masked]>;index=1.1.1.1.1.2.1.1.1.1.1.1.1;rt

Is simpler than this:
R-History-Info: <sip:[email-masked]>
R-History-Info: <sip:[email-masked]>

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 14 Jul 2009 11:20:20 -0400

> Sent: Tuesday, July 14, 2009 11:08 AM
> 
> Hadriel Kaplan wrote:
> > Note though that this set's last member is not *necessarily* the one
> Target-URI wants - it's the set/list it must walk through (in reverse
> order of the H-I list of "mp" ones) to find the Target-URI.  As it walks
> the list, if the local UAS believes it represents the URI, it keeps
> walking backwards - when it finds one it does not represent, it stops
> walking up the list and uses the last one it found that it *does*
> represent.  That one is the "Target-URI".
> 

You mean the "first" in the list being the oldest from the UAS's point of view (and the first in the actual list order)?

Because proxies adding retargeted-to URI's are making a guess - they're assuming the retargeted to URI is a true retarget; i.e., when they add "mp", they could be wrong.  The only one who knows what URI's it is really the same identity for is the UAS.  So the UAS goes backwards in the list to find the oldest one in the chain that it represents, because that is the point of actual retargeting.

For example, if alice sends a request to "sip:[email-masked]", which gets sent to "sip:[email-masked]" and Bob's UAS receives it after that, the H-I list of ALL "mp" tagged entries will be this:

H-I: <sip:[email-masked]>;mp
H-I: <sip:[email-masked]>;mp

>From a Target-URI perspective, the Target-URI is actually the first one "sip:[email-masked]", because it's a pseudonym for the second - the second "mp" entry was NOT a real retarget, unbeknownst to the proxy which generated it. (only Bob's UAS could know this in general, although a Proxy may sometimes know it too in specific circumstances)

Alice actually called Robert.Khaled, so for example bob's UAS may well want to use a different ring or whatever for Robert.Khaled than for bob.  That was the gist of the Target-URI problem - we wanted to know what req-URI Alice generated, unless Alice's request was truly retargeted to a different identity.

-hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 14 Jul 2009 10:51:19 -0500

You are right, I do hate it :-)

We did consider it, but versioning is not something we do in SIP. 
We are still on SIP/2.0...

> Sent: Monday, July 13, 2009 18:43
> I suggest an explicit version tag.  The tag appears not in 
> the header field itself, but in something called a 
> "header-name" part of an "extension-header" in ABNF rules per 
> rfc3261.  I suggest a new "header-name" value of 
> "R-History-Info".  You can pretend the "R" is for 
> This "R-History-Info" extension-header is a multi-instance 
> type, and a Proxy only ever adds to it if it is changing the 
> received req-uri *and* would have set the "mp" flag for the 
> new URI it is adding.  The first RHI entry is added by the 
> first proxy or UAC based on what it received, like in H-I, 
> even though it's not retargeting to that URI.  The 
> extension-header's header-value is the URI being retargeted 
> to.  There are no currently defined header parameters.
> 
> This RHI header field is not for troubleshooting - it's for 
> actual processing use.  Therefore, there is no incrementing 
> index param, no embedded Reason header, and no entries 
> created for anything but retargeted events and their new 
> URI's (and the first one).  Privacy does not apply to this on 
> a header-by-header basis, and thus there is no embedded 
> Privacy header either - if Privacy:history was requested, no 
> Compared with RFC 4244, the RHI header field would produce a 
> smaller subset of header instances.  In some cases 
> significantly smaller.  For example, in the most common case, 
> only a single RHI header field would be in the message, 
> regardless of how many proxies were crossed.  There is also 
> less processing overhead for every node in the message path.
> 
> It should be noted that, like RFC 4244, RHI does not produce 
> the smallest list possible of retargets - in some cases an 
> entry is added when the target user Identity has not changed 
> - the URI has changed to a new one, but unbeknownst to the 
> Proxy which added it, the Identity of the human may have 
> remained the same.  For example an entry for 
> "sip:[email-masked]" may both have been added, even 
> though they are the same abstract target human.  A proxy 
> cannot know by default that these two targets are the same 
> identity.  Only the UAS would know that, and so it may need 
> to cull the list down further.
> 
> -hadriel
> 
>

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 14 Jul 2009 10:56:48 -0500

Yes, absolutely.

This was indeed one of the reason for the "aor" flag.

It's very common for Phones to use "raw" digits in 
Requests-URIs, with dialling prefixes and other garbage 
(which is clearly wrong according to standard).

Then the proxy "fixes" the request-URI by translating to 
a proper tel-derived SIP URI (for example), removing
extraneous dialing prefixes that means nothing the the
other end, adding ;user=phone, "+" or phone-context
as appropriate.

The beauty of the ;aor tag is that the entry that is
valid will be tagged with ;aor, but not the "garbagy" one
at the begining.

When trying to figure out "redirection", this is quite
useful. Otherwise, the "garbagy" one at the begining may
be falsy interpreted as a redirecting number, when it was not.
This is useful for a lot of services.

(Now, I will agree that we may be able to do that without a
specific aor tag). 

> Sent: Tuesday, July 14, 2009 06:42
> You focused on digit manipulation, which is surely one. But 
> there are others.
> 
> sip:[email-masked]) It then applies some sort of digit map 
> it has been provisioned with (possibly per-caller, possibly 
> per-domain) to transform that into some other more globally 
> unique URI - perhaps an
> sip:[email-masked];user=phone.) It does the 
> translation and then proceeds based on the result. I agree in 
> this case it is wrong to call the incoming R-URI an AOR.
> 
> A proxy responsible for example.net receives a request with 
> R-URI sip:[email-masked]. This is not in its location 
> service. But it has a provisioned alias table that says phk 
> is a synonym for paul.kyzivat, so it translates the R-URI to 
> sip:[email-masked]. It then proceeds to process 
> that, which turns out to be in its location service, so it 
> translates it again to sip:[email-masked].
> A proxy responsible for example.net receives a request with 
> R-URI of sip:[email-masked]. There is a location 
> service with an entry registered for 
> sip:[email-masked], but there is also 
> This is accomplished by R-URI translation. (To ensure that 
> the request will not be rejected as mis-addressed.)
> 
> A proxy responsible for example.net receives a request with 
> R-URI of sip:[email-masked]. Alice used to work for 
> Example Co, but she no longer does, so her URI is "out of 
> service". But the proxy has been provisioned to translate the 
> R-URI of Alice's calls to her old boss' 
> URI: sip:[email-masked]. There will never be an 
> entry in the location service for alice, registrations are 
> not permitted.
> 
> In this case, in spite of there being no location service 
> involved, I still think sip:[email-masked] is an AoR.
> 
> So, IMO the bottom line is that whether a URI is an AoR is a 
> policy decision within the domain of the URI.
> 
> 	Thanks,
> 	Paul
> 
> 
> Francois Audet wrote:
> >  
> > 
> manner. It 
> >> seems to me that if it *could* have been done with a 
> location service 
> >> lookup, then the result ought to be the same whether it is or not.
> > 
> > I didn't want to alter (or second-guess) the definition of 
> AOR (which 
> > is the realm of RFC 3261), in this draft.
> > 
> > I would think that if the proxy doesn't know that it's an 
> AOR, then it 
> > shouldn't mark it as such. So I would expect mechanical 
> digit manipulation to NOT be marked as AOR.
> > 
> > 
>

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 14 Jul 2009 10:59:15 -0500

> Specifically, it only works of the VM system used by the 
> final target is the same one as used by the first target. So, 
> with such an algorithm, if I forward my (work) calls to 
> Jonathan and he isn't there then they would have a good 
> chance to end up in my mailbox. But if I forward my calls to 
> When the call is retargetted, it should be marked as "no 
> voicemail" so that if it isn't answered the proxy for the 
> first target gets to decide alternative handling.

You can certainly implement the behavior you describe with 
history-info (and it HAS been done already, I can assure you).

That was the point of my other email.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 14 Jul 2009 11:01:07 -0500

> Why would it want the first of those it represents, not the last?

Because of the VM example of your previous email.

You call me, I'm forwarded to my admin (I wish). Admin doesn't answer.

You get forwarded to my voicemail, not my admin.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 14 Jul 2009 11:02:02 -0500

This is obviously totally against anything anything we've ever done in SIP
(and SDP actually), so I can't take it seriously.

> Sent: Tuesday, July 14, 2009 08:09
> To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); SIPCORE
> > We did consider a version tag (slightly different approach 
> than what 
> > you suggest), but in the end the current approach is far 
> simpler than 
> > what you suggest and far more inline with the basic extensibility 
> > mechanism that was put in 4244.  Your proposal takes us back to day 
> > one and just defining a new header altogether.
> 
> Yup, that's exactly what it suggests.  Press Reset.  Let the 
> few that want to do H-I the old way do it (for 
> troubleshooting?), but do Target, Redirection, 800-service, 
> etc. using R-H-I.
> 
> The current 4244bis approach is in no way, shape, or form 
> "simpler" than what I am suggesting.  It's just lets you 
> carry the old baggage - which is both good and bad.
> 
> Unless you think this:
> History-Info: 
> <sip:[email-masked]?Reason=SIP%3Bcause%3D300>;inde
> x=1.1.1.1.1.2.1.1.1.1;rt;aor
> History-Info: 
> <sip:[email-masked]>;index=1.1.1.1.1.2.1.1.1.1.1;rt;aor
> History-Info: 
> <sip:[email-masked]>;index=1.1.1.1.1.2.1.1.1.1.1.1;rc
> History-Info: 
> <sip:[email-masked]>;index=1.1.1.1.1.2.1.1.1.1.1.1.1;rt
> 
> Is simpler than this:

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 14 Jul 2009 11:05:42 -0500

> For example, if alice sends a request to 
> "sip:[email-masked]", which gets sent to 
> "sip:[email-masked]" and Bob's UAS receives it after 
> that, the H-I list of ALL "mp" tagged entries will be this:
> 

Actually, no. Absolutely not. You'd get:

History-Info: <sip:[email-masked]>;aor;index=1
History-Info: <sip:[email-masked]>;aor;mp;index=1.1
History-Info: <sip:[email-masked]>;rc;index=1.1.1

And that is assuming that Robert.Khaled and bob are not known
to be the same user by the proxy.

If the proxy knows there are the same user (e.g, they are "aliases"),
then it would be:
History-Info: <sip:[email-masked]>;aor;index=1
History-Info: <sip:[email-masked]>;aor;rt;index=1.1
History-Info: <sip:[email-masked]>;rc;index=1.1.1

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 14 Jul 2009 10:46:58 -0500

> Sent: Monday, July 13, 2009 21:01
> To: Audet, Francois (SC100:3055); Dean Willis
> Cc: SIPCORE
> Subject: RE: [sipcore] rfc4244bis: what is "aor" used for?
> 
> 

No, it's the one BEFORE that. It will actually be labelled as "aor".

mp is "the one that is mapped to" not "mapped from". 

Last "aor" is the last called address, and "mp" is the address representing
a different user it was retargeted to.

> Right it's not universal, and no universal algorithm can find 
> the right URI for all application uses.  But I think we can 
> (and should) document what algorithms should be used for the 
> most common applications, so that there's no confusion on the 
> part of different implementations? (or even just to provide guidance?)

I agree. Once we agree on the tags (presumably in Stockholm), I think
we should describe the algorithm for the sample applications we cover
in the draft.

The main ones will be:
(1) target URI, 
(2) last redirecting-to-other-user-number-and-reason.

> For example, a Voicemail system would NOT use the FIRST "mp" 
> entry in the list, nor the LAST.  It needs to walk the list 
> backwards to find the closest "mp" to the end that it can 
> use.  Otherwise, a retarget from Alice to Bob will go to 
> Alice's voicemail, when it should have gone to Bob's.  No?

No.

The way most voicemail system work is that it would TRY to go
to Alice's voicemail, and if it is not possible, it will go to 
Bob's. This is certainly the case for Enteprise voicemail systems,
and I believe for service providers as well.

The reason I say "try", is that if the redirection information 
is not present for the first hop, it may not be able to do it. This
happens when there is a large number of hops (in PSTN) or when the
information is stipped off (e.g., when redirecting outside the enterprise).

(Really).

Of course, I'm not saying that voicemail systems *should* be necessarily
designed like this. I'm just saying that's how most of them work today,
and the protocol should allow makeing it possible to retain that behavior.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 14 Jul 2009 12:17:13 -0400

> Sent: Tuesday, July 14, 2009 12:02 PM
> 
> This is obviously totally against anything anything we've 
> ever done in SIP (and SDP actually), so I can't take it seriously.

Ummm... What is totally against anything we've done in SIP?  Created new headers?
I was being facetious about the extension-header header-name field being a "version tag".  I was trying to say: don't try to fix H-I to do this stuff; create a new header (and everytime we create new header(s), they're based on the extension-header ABNF entry in 3261 technically, afaik).

-hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 14 Jul 2009 11:15:35 -0500

In the current draft, we have opted to be "more precise" instead of "more simple"
with regards with tagging the H-I entries....

As eloquently said by Hadriel, what we really need to know is "what this
a redirection (to a different user) or not"?

One alternative to having the rc / cc / mp / rt (and nil) tags would be to only
have (say), "mp" (mapped to a different user), "rt" (routed to same user) and
of course "nil" (i.e., no tag because it's a legacy 4244 proxy, or because the
proxy doesn't know). "rc" & "cc" would be included in "rt". 
This is something that we considered during the development of the draft, but it
seems people at the time preferred more precise tags. 

I'd like feedback on what are people's views:

Option A)

	As per draft: i.e., rc / cc / mp / rt

Option B)

	Simplified: i.e., mp / rt

PS: This says nothing of the "aor" issue, which, as Mary said, related to other
use cases, in particular the Freephone case.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Jul 2009 12:28:14 -0400

> You get forwarded to my voicemail, not my admin.

So, rather than your admin's VM acting as your VM, you have your admin's 
proxy forwarding to your VM rather than your admin's VM.

Its still wrong, because there is no particular reason the forward 
target, or the proxy for the target, should know anything about your VM. 
(Maybe in case of your admin it will, but that is just a coincidence.)

The point is that to get the right behavior, the server that is doing 
the retargeting needs to make a *choice* of whether the downstream 
things should map again if the target isn't available, or should just 
give up and let the upstream server deal with it.

The H-I isn't the right mechanism for expressing choices like that.

Callerprefs is intended for things like that, though of course there are 
many issues with it too.

I never liked H-I much, and this whole discussion is confirming my 
feelings. A long time ago the programming community realized that it was 
bad practice to have a function behave differently depending upon who 
called it, or why. But we haven't assimilated that here.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 14 Jul 2009 13:07:41 -0400

> Sent: Tuesday, July 14, 2009 11:47 AM
> 

Yup, that I knew.

> a different user it was retargeted to.

I was confused why you were saying this, because this is not the semantic that the original target drafts actually wanted.  They wanted what the UAC or re-targeted actually *sent*, not what the Registrar-Proxy received.  But then I saw there's a new target-uri-delivery draft, which I see now is where this mapped/aor thing came from; and it changed the semantic, even though it is self-contradictory in the text itself.  But I will move that discussion to another thread for that draft.
:)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 14 Jul 2009 13:47:48 -0400

> Sent: Tuesday, July 14, 2009 12:06 PM
> 
> that, the 
> > H-I list of ALL "mp" tagged entries will be this:
> > 

Sorry that was a typo - I meant all the "mp" tagged and the original req-uri from Alice would be:

H-I: <sip:[email-masked]>;aor
H-I: <sip:[email-masked]>;mp

> History-Info: <sip:[email-masked]>;rc;index=1.1.1

...in the list I'm describing, because that is not "mp" tagged - it's in the full H-I list sure, but if you weed-out/cull the list to the first entry and all "mp" tagged ones, you'd get those two.
 
-hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 14 Jul 2009 12:51:53 -0500

So you are proposing something that is not backward compatible then.

We did talk about the "weeding out" (as opposed to marked) earlier, and
decided to "mark" instead of weeding out. In fact, it was in my
presentation in San Francisco.

The problem with many IETF groups is we keep going in circle. Once we 
decide something, we should stick to it. Otherwise, it's impossible to
make progress. 

> Sent: Tuesday, July 14, 2009 10:48
> To: Audet, Francois (SC100:3055); Paul Kyzivat
> Cc: Dean Willis; SIPCORE
> ...in the list I'm describing, because that is not "mp" 
> tagged - it's in the full H-I list sure, but if you 
> weed-out/cull the list to the first entry and all "mp" tagged 
> ones, you'd get those two.
>  
> -hadriel
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 14 Jul 2009 13:54:28 -0400

> Sent: Tuesday, July 14, 2009 11:57 AM
> 
> The beauty of the ;aor tag is that the entry that is valid 
> will be tagged with ;aor, but not the "garbagy" one at the begining.
> useful. Otherwise, the "garbagy" one at the begining may be 
> falsy interpreted as a redirecting number, when it was not.

I figured that was why the "aor" tag was trying to be clever, and why target-uri changed the semantic from what Alice sent, to what Bob's registrar-proxy received, but man is that a slippery-slope.  Request-URI's usernames and domains are changed a LOT, and people add params, and params get lost, during that translation.  (for example in ENUM routing params usually go bye-bye, and ones get swapped in trunk-group routing, etc.)

How do you know if the one sent by Alice was wrong, vs. the one the registrar received?

This thing is going to be a tech-support nightmare. :(

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 14 Jul 2009 13:59:06 -0400

No I think you mis-understand me.
Or maybe I misunderstand you. :)

I assume that H-I creates, and the UAS will receive ALL entries. (well, I don't really believe that, but for sake of this IETF discussion I do)

I further assume that a receiving UAS will only look at some of the entries - effectively reducing the list to smaller set - based on these tags, in some way or other.  Is that a dangerous assumption?  If the tags can't be used to reduce the list, to let a given application focus on particular entries, why are there tags?

-hadriel

> Sent: Tuesday, July 14, 2009 1:52 PM
> To: Hadriel Kaplan; Paul Kyzivat
> Cc: Dean Willis; SIPCORE
> We did talk about the "weeding out" (as opposed to marked) 
> earlier, and decided to "mark" instead of weeding out. In 
> fact, it was in my presentation in San Francisco.
> 
> The problem with many IETF groups is we keep going in circle. 
> Once we decide something, we should stick to it. Otherwise, 
> it's impossible to make progress. 
> 
> > Sorry that was a typo - I meant all the "mp" tagged and the 
> original 
> > req-uri from Alice would be:
> > 
> weed-out/cull the 
> > list to the first entry and all "mp" tagged ones, you'd get 
> those two.
> >  
> > -hadriel
> > 
>

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 14 Jul 2009 13:06:21 -0500

Why?

How do you substantiate what you are saying?

The AOR flag is telling what the location service actually USED for 
routing by the target domain. It can't get more deterministic than that.

The fact that SBCs in the middle (or other do-gooders) muck around
with addresses is irrelevant, because those guys' don't put the
aor flag. And utimately, what you need is the actual URI that 
was used IN REALITY for the location look-up. Not semi-bogus
addresses in between.

> Sent: Tuesday, July 14, 2009 10:54
> Cc: Hans Erik van Elburg; SIPCORE
> > The beauty of the ;aor tag is that the entry that is valid will be 
> > tagged with ;aor, but not the "garbagy" one at the begining.
> > When trying to figure out "redirection", this is quite useful. 
> > Otherwise, the "garbagy" one at the begining may be falsy 
> interpreted 
> > as a redirecting number, when it was not.
> I figured that was why the "aor" tag was trying to be clever, 
> and why target-uri changed the semantic from what Alice sent, 
> to what Bob's registrar-proxy received, but man is that a 
> slippery-slope.  Request-URI's usernames and domains are 
> changed a LOT, and people add params, and params get lost, 
> during that translation.  (for example in ENUM routing params 
> usually go bye-bye, and ones get swapped in trunk-group routing, etc.)
>

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 14 Jul 2009 13:18:08 -0500

Yes, the tags are looked exactly for that. Reducing the list.

Target-URI scenario look at last aor.

Voicemail would look at first AOR (typically).

Some other applications look at mp in entry after AOR to determine if there
was a change of logical user (i.e., Freephone).

I can't imagine anyone looking at the last entry (the cc/rc). However,
it is still there because you never that the last hop is the last hop.
Specifically, the phone could send, e.g., a 302. Surely, we need to capture
that because an end-user done redirection is just a real as a proxy done
redirection, so we can't prune it.

The problem with TODAY's implementation of HI is precisely what you
are trying to do, i.e., prune out stuff that YOU personally don't think
is useful. You have a specific application in mind. But you may be breaking
somebody else's application by "pruning out" the part the other guy needs.
This is EXACTLY what is wrong with current version of RFC 4244.

> Sent: Tuesday, July 14, 2009 10:59
> I assume that H-I creates, and the UAS will receive ALL 
> entries. (well, I don't really believe that, but for sake of 
> this IETF discussion I do)
> 
> I further assume that a receiving UAS will only look at some 
> of the entries - effectively reducing the list to smaller set 
> - based on these tags, in some way or other.  Is that a 
> dangerous assumption?  If the tags can't be used to reduce 
> the list, to let a given application focus on particular 
> entries, why are there tags?

---

From: Dean Willis <[email-masked]>
Date: Tue, 14 Jul 2009 13:39:27 -0500

On Jul 13, 2009, at 6:45 PM, Hadriel Kaplan wrote:

> Can you give me an example?  What would such a thing be used for,  
> that it requires a UAS receiving it in the H-I look at it for some  
> useful purpose?
>

Let's take this out of the context of "request URI" and into  
"application parameter set", which relieves us of the need to discuss  
(for this example) where the application parameter set is encoded in  
the request.

Perhaps a variation of the speed-dialer application will serve to  
illustrate the use case:

Assume Alice's mobile operator like to minimize device configuration,  
instead putting user-specific information, as much as is possible,  
into a database accessible by its proxies and application servers.

Alice calls her voicemail server by pressing and holding "1" on her  
mobile device. The mobile device (like every other mobile device from  
this carrier) has been factory configured to invite "sip:[email-masked] 
" in response to pressing and holding "1".

Alice's proxy knows that this is a call from Alice to her voicemail  
service. It knows she has been authenticated and is authorized to  
access that service. It also knows that Alice's current preferred  
language is Esperanto, and that she prefers expedited menus from the  
voice mail server, that the voice mail server either lacks access to  
or doesn't understand the per-user configuration database and needs  
this information encoded into the INVITE request, and that Alice's  
mobile device did not encode the needed information into the request.

Consequently, Alice's proxy needs to add her language and menu  
preferences to the INVITE. Assuming we're using the currently-approved  
model of R-URI encoding, the proxy can do this by adding appropriate  
parameters to the request URI. It hasn't changed the target of the  
request "sip:[email-masked]" (although that might get done by  
the voicemail load-balancing  proxy further down the pipe). All it is  
doing is adding a couple of parameters.

> As just another HI URI that can be ignored by the UAS.  And the  

Was it a retarget? If so, what kind of two-letter code gets applied?

> I have no idea what you mean by "parameter modification".  A UAS  
> needs to know whether and which req-URI's were created by re- 
> targeting, for it to know what the set of URI's to select from for  
> Target identification, for Original Called Party vs. Redirection  
> information (e.g., for billing or ISUP generation), for filtering,  
> for prioritization, etc.
>

Ah. But the UAS also needs to know what application parameters are  
being sent to it from the upstream, including the UAC. They might be  
encoded in a URI that was stored in an H-I entry, but if so, which one?

> I'm confused - are you actually asking what the use-cases are/were  
> for ua-loose-route, Diversion-Redirection, et al?  You were part of  
> those draft discussions.  The problem of how any proxy would know  
> when an identity actually changed or not was also discussed back then.
>

No, I'm saying that we've gotten the delivery of parameters to  
applications hopelessly intertangled with the routing of the request  
to the application. This is something like the "locator/identifier"  
split problem of DNS/IP, but about a thousand times worse.

> If you buy into the idea that it's application-specific, or that  
> only the UAS would really know, then you can't have Proxies simply  
> putting in *one* Target header, because they'd never know if/when it  
> should be changed before getting to the UAS.  They'd have to create  
> a list of them: one new entry every time they re-targeted (or  
> actually one for every time they did NOT absolutely know they did  
> NOT retarget, if you can follow that crazy logic).

Possibly. I think the change rule could be written more simply. As we  
do with proxies and header fields: If you don't both 1) know what it  
is and 2) have a specific reason for changing it, then copy it forward.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 14 Jul 2009 13:20:51 -0500

> Dean said:

> Therefore, it's not Universal.

The TargetURI problem was also slightly mis-stated, which is why I  
believe we as a working group have been confused about what we're  
trying to accomplish for a long, long time (and why I pushed back on  
Christer's draft at the time).

I really don't care whether the application uses the "first target  
URI" or the "last target URI".

What I care about is whether or not it finds and understands the  
parameters it needs to get its job done. Let's talk about what  
"getting the job done" here means; strictly speaking, it means the  
application can find the information in the request needed to perform  
the application's function. The possible presence of that information  
in a request URI is a historical accident that'll I'll go into  
momentarily.

Your assumption that it matters as to which URI the application uses  
points to the heart of the problem.

In HTTP, there was only ONE URI, and the parameters were in that URI.   
Hence, HTTP applications can use the request-URI for parameter delivery.

  We started down a path of trying to re-use HTTPs technique, but  
screwed up our protocol design so that there are now MANY URIs, and it  
becomes impossible (in a general way) for an application to guess  
which one it should be using.

Alt 1) So the application has to run back up the stack of URIs until  
it finds one with a parameter it likes, then use that one. This  
assumes we have a stack of such URIs which is what you are trying to  
accomplish with rfc4244bis).

Alt 2) JDR's "ua-loose-routing" draft tried to restore the "one and  
only one request-URI" property, thereby letting us use the HTTP model  
for parameter delivery, but we seem to have found that too radical for  
SIP 2.0. Fine, let's either fix the problem and move on to SIP 3.0,  
since it is the best technical answer, or abandon the idea of R-URI  
encoded parameters entirely.

Alt 3) Another model is to use header fields for application parameter  
delivery. Applications can find header fields easily enough. They can  
be escaped and pushed into a URI, and we could write text about how  
any retargeting proxy takes escaped header fields out of the URI and  
transforms them into "normal" header fields before retargeting the  
URI, but in our past infinite wisdom we have decided that Header Field  
Names are Sacred and Require an RFC. This means that every time some  
application needs to pass parameters "legally" using header fields,  
the author has to get an RFC passed through our rather long alimentary  
canal before using it. You may recall I pushed back against this  
particular piece of process at the time, too.

Alt 4) Christer was headed towards an alternate solution: rather than  
staying with HTTP's parameterization model, we would use Yet Another  
Header Field (Target), which would be defined so as to allow user- 
defined parameter-value strings to be passed without requiring an RFC.  
This works, mostly, except for the cases where we need to be able to  
write the parameters along with the base URI on a single line.  
Christer MOSTLY solved this: We initially populate the Target using a  
Request-URI, then a retargeter copies the old URI into a new Target.  
But IIRC, that draft  didn't go into the "passing forward rules"  
necessary to preserve parameters across retargets when those  
parameters need to be preserved. One model is to presume that each  
retargeting replaces the parameter set, so that any needed  
preservation is selectively performed by a retargeter, but I don't  
think we got into that.

This all leads back to the heart of the discussion:

I believe that the group of folks working on RFC 4244 are so caught up  
in the enormity of their task that they don't see its essential  
uselessness in the one case that we're actually chartered to work on:  
application parameter passing. Sure, History-Info is  a great  
diagnostic tool, but using it for solving the parameter-passing  
problem is like using that other diagnostic toll, "MRI",  to check for  
a fever: not only is it a very expensive procedure, it doesn't  
actually answer the question being asked. Yes, we can redesign  
applications so that they can get their parameters this way, but doing  
so is rather like redesigning the human body so that its temperature  
can be read using an MRI by embedding an MRI-readable thermometer in  
every abdomen. It can be made to work, but it is an overly costly and  
invasive approach with probable side-effects that we have not begun to  
consider.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 14 Jul 2009 15:06:03 -0500

> decide something, we should stick to it. Otherwise, it's impossible to

I disagree.

The most severe problem is that once we have made a mistake and  
recognized the mistake, we keep making the same mistake again and  
again. That's how we built our current towering edifice of complexity,  
confusion, and regret.

Admittedly, there may be fine lines between convention, tradition, and  
dogma.  We, however, have leapt over all such lines and buried our  
collective heads in the sand wherein old dogma has been left to  
fossilize.

To rephrase using an experience I had last week: When a scorpion  
stings you on the bottom, first move elsewhere, then kill the  
scorpion. Just wiggling and then sitting on it again to see if the  
experience improves is not a good idea. Fortunately I learned after  
the second sting, which is something our working group usually doesn't  
manage to do. Also fortunately, it wasn't a particularly dangerous  
scorpion ;-).

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 14 Jul 2009 16:08:50 -0500

I frankly don't think that the "original parameter" passing
from one URI to another makes much sense.

The meaning of these parameters could be different accross 
different URIs. E.g., on one URI a token as a Username could be used
as a parameter in another one. 

Or to take one example that was sent on the list earlier,
some "dialling code"@domain.com ([email-masked]) could
be translated to NETAN-type parameters ([email-masked];
play=hadriel_ann.mp3).

It could be even worst: one proxy may use a parameter
x=blabla to mean something, and another proxy along
the way may use the same parameter x=blabla to mean
something else. It's not far fetched at all: I've seen
a lot of parameter names from different vendors that
look very close.

At least with H-I, the original parameters WILL be there
associated with the proper entry, if you ever need to use
them.

> Sent: Tuesday, July 14, 2009 13:42
> > Sent: Tuesday, July 14, 2009 2:06 PM
> > 
> > Why?
> I was thinking of it from the original use-case scnarios for 
> target-uri.  Target-uri was not originally meant to (only) be 
> an improved replacement for P-Called-Party-ID.  It was 
> supposed to allow parameters from the original req-uri 
> created by Alice to be received all the way at Bob. (Dean 
> seems to think it was meant to let any middle-proxy add to 
> those as well, but I don't recall that)  But I definitely 
> like the property that you get when it's what the Registrar 
> saw, because it avoids the translations problem; so I think 
> I'll just have to give up on the param-passing idea.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 14 Jul 2009 16:15:19 -0500

The rc / cc / rt are the ones I would call "fluff".

If I was a proxy, and I was trying to do pruning, those
are the ones I would drop.

Since we can't count on this necessarily happening (especially
with older proxies conforming to 4244 only), it's important
that the ones who DO matter are labelled properly. That means
aor and mp.

If we decide to "consolidate" the fluff together,
(say, fluff = rt | rc | rt) then it's even more obvious.

At this point, I'd rather we mark them as fluff
for completeness. Before we actually remove anything, I'd
really want to do a thorough review of the backward compatibility
implications.

> Sent: Tuesday, July 14, 2009 13:56
> > Sent: Tuesday, July 14, 2009 2:18 PM
> > 
> > are trying to do, i.e., prune out stuff that YOU personally don't 
> > think is useful. You have a specific application in mind. 
> But you may 
> > be breaking somebody else's application by "pruning out" 
> the part the 
> > other guy needs.
> I don't think so - or at least I'm consciously trying to 
> avoid that. :) 
> 
> I believe that if you reduce the number of params, when to 
> set them, etc., you will improve interoperability. (and 
> possibly even improve *operability* and brittle-ness)
> 
> I also hope there are some entry types that are not going to 
> be useful to any application; because I have a high degree of 
> confidence not all of them will make it to a UAS in many 
> cases, in my world.  
> 
> So I'm trying to find which subset are actually sufficient 
> for all reasonable applications, and which are fluff.
> 
> -hadriel
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 14 Jul 2009 16:41:42 -0400

> The AOR flag is telling what the location service actually 
> USED for routing by the target domain. It can't get more 
> deterministic than that.

I was thinking of it from the original use-case scnarios for target-uri.  Target-uri was not originally meant to (only) be an improved replacement for P-Called-Party-ID.  It was supposed to allow parameters from the original req-uri created by Alice to be received all the way at Bob. (Dean seems to think it was meant to let any middle-proxy add to those as well, but I don't recall that)  But I definitely like the property that you get when it's what the Registrar saw, because it avoids the translations problem; so I think I'll just have to give up on the param-passing idea.

> The fact that SBCs in the middle (or other do-gooders) muck 
> around with addresses is irrelevant, because those guys' 
> don't put the aor flag. And utimately, what you need is the 
> actual URI that was used IN REALITY for the location look-up. 
> Not semi-bogus addresses in between.

As much as one would think that's the case, it ain't, afaict.  The SBC's don't just muck around with addresses, because (surprise) they can implement a "location-service lookup", are authoritative for a domain, etc.  Not in the simple case of Alice and Bob being in the same domain, registering, using email-style addresses, etc.  But in the inter-domain case, with E.164's and such - everything described for the logic which requires setting the aor flag would be true (or at least not deterministically false).  But I think you're right, we wouldn't set the aor flag, even if all the criteria are true.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 14 Jul 2009 16:55:56 -0400

> The problem with TODAY's implementation of HI is precisely 
> what you are trying to do, i.e., prune out stuff that YOU 
> personally don't think is useful. You have a specific 
> application in mind. But you may be breaking somebody else's 
> application by "pruning out" the part the other guy needs.

I don't think so - or at least I'm consciously trying to avoid that. :) 

I believe that if you reduce the number of params, when to set them, etc., you will improve interoperability. (and possibly even improve *operability* and brittle-ness)

I also hope there are some entry types that are not going to be useful to any application; because I have a high degree of confidence not all of them will make it to a UAS in many cases, in my world.  

So I'm trying to find which subset are actually sufficient for all reasonable applications, and which are fluff.

-hadriel

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 14 Jul 2009 17:46:35 -0500

I agree this this solution isn't ideal, but we are working from what we
have with RFC 3261 (and to a lesser extent RFC 4244 for backwards
compatibility).   There are organizations (SDOs and vendors) that need a
common building block upon which to build their services.  I think this
solution is far less dangerous than trying to define something uniquely
for each service AND having every vendor implement services differently.

I think folks are making this far more complex than what it is. 

And, following on your analogy, if we're just dealing with some small
scorpion bites, then we're not doing too bad. It's when we start
encountering the rattlers, copperheads and water mocasins that we should
be getting really worried. And, the reality is that in Texas, you will
come across those things and you just have to deal with them - there is
just no way to avoid those critters sometimes.  And, I don't think any
of us are so stupid that we are stepping on the same scorpion over and
over again. 

So, back to 4244bis, we're just trying to deal with what we have to work
with in terms of RFC 3261 - we're being pragmatic and not perfectionist.
I don't think any of us has on rose colored glasses that this is ideal.
Until we go to SIP 3.0 (or perhaps better yet "four oh"), this is what
we have to work with. 

Regards,
Mary.

-----Original Message-----
Behalf Of Dean Willis
Sent: Tuesday, July 14, 2009 3:06 PM

I disagree.

The most severe problem is that once we have made a mistake and
recognized the mistake, we keep making the same mistake again and again.
That's how we built our current towering edifice of complexity,
confusion, and regret.

To rephrase using an experience I had last week: When a scorpion stings
you on the bottom, first move elsewhere, then kill the scorpion. Just
wiggling and then sitting on it again to see if the experience improves
is not a good idea. Fortunately I learned after the second sting, which
is something our working group usually doesn't manage to do. Also
fortunately, it wasn't a particularly dangerous scorpion ;-).

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 15 Jul 2009 13:43:26 +0200

This is like the Target header we proposed a while ago, but with a change of
keeping all the retargets that would qualify for "mp". (
http://tools.ietf.org/html/draft-holmberg-sip-target-uri-delivery-01)

I thought that the wg came to consensus that this needs to be resolved with
History-Info. If not...

/Hans Erik van Elburg

On Tue, Jul 14, 2009 at 3:42 AM, Hadriel Kaplan <[email-masked]>wrote:

> I suggest an explicit version tag.  The tag appears not in the header field
> itself, but in something called a "header-name" part of an
> "extension-header" in ABNF rules per rfc3261.  I suggest a new "header-name"
> value of "R-History-Info".  You can pretend the "R" is for
> would have set the "mp" flag for the new URI it is adding.  The first RHI
> entry is added by the first proxy or UAC based on what it received, like in
> H-I, even though it's not retargeting to that URI.  The extension-header's
> header-value is the URI being retargeted to.  There are no currently defined
> header parameters.
>
> embedded Reason header, and no entries created for anything but retargeted
> events and their new URI's (and the first one).  Privacy does not apply to
> this on a header-by-header basis, and thus there is no embedded Privacy
> header either - if Privacy:history was requested, no RHI fields would be
> created.
>
> Compared with RFC 4244, the RHI header field would produce a smaller subset
> of header instances.  In some cases significantly smaller.  For example, in
> the most common case, only a single RHI header field would be in the
> message, regardless of how many proxies were crossed.  There is also less
> processing overhead for every node in the message path.
>
> It should be noted that, like RFC 4244, RHI does not produce the smallest
> list possible of retargets - in some cases an entry is added when the target
> user Identity has not changed - the URI has changed to a new one, but
> unbeknownst to the Proxy which added it, the Identity of the human may have
> remained the same.  For example an entry for "
> sip:[email-masked] <[email-masked]>" and a
> subsequent entry for "sip:[email-masked]<[email-masked]>"
> may both have been added, even though they are the same abstract target
> human.  A proxy cannot know by default that these two targets are the same
> identity.  Only the UAS would know that, and so it may need to cull the list
> down further.
>
> -hadriel
>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 15 Jul 2009 14:19:28 +0200

On Tue, Jul 14, 2009 at 3:41 PM, Paul Kyzivat <[email-masked]> wrote:

> A proxy receives a request with sip R-URI in the domain it is responsible
> for. It sees that the user part is all digits. (E.g sip:[email-masked]<[email-masked]>)
> It then applies some sort of digit map it has been provisioned with
> (possibly per-caller, possibly per-domain) to transform that into some other
> more globally unique URI - perhaps an E.164 number in its own domain or some
> other domain, or a TEL URI. (E.g. sip:[email-masked]<[email-masked]>;user=phone.)
> It does the translation and then proceeds based on the result. I agree in

What property does this not make an AOR?
How does it matter whether there are multiple translation steps in a domain?
What matters that if I sent something to:
sip:[email-masked]<[email-masked]> that
it will be delivered to the intended party. In this sense this is an AOR. I
could put this on my business card for example.

> sip:[email-masked] <[email-masked]>. This is not in its location
> service. But it has a provisioned alias table that says phk is a synonym for
> paul.kyzivat, so it translates the R-URI to sip:[email-masked]<[email-masked]>.
> It then proceeds to process that, which turns out to be in its location
> service, so it translates it again to sip:[email-masked]<[email-masked]>
> .
> Again, I don't think sip:[email-masked] <[email-masked]> is an AoR
> in this case.
>

I do think this is an AOR allright. The alias mapping can well be performed
by an abstract-location-service.
What property does this not make an AOR?
How does it matter whether there are multiple translation steps in a domain?
What matters that if I sent something to:
sip:[email-masked]<[email-masked]> that
it will be delivered to the intended party. In this sense this is an AOR.
You could put this on your business card for example.

> sip:[email-masked] <[email-masked]>. There is a
> location service with an entry registered for
> sip:[email-masked] <[email-masked]>,
> but there is also provisioning independent of the location service that says
> to unconditionally forward all calls to this URI to sip:[email-masked]<[email-masked]>.
> This is accomplished by R-URI translation. (To ensure that the request will
> not be rejected as mis-addressed.)
>
> In this case I think that sip:[email-masked]<[email-masked]>*is* an AoR.
>

Yes.

> sip:[email-masked] <[email-masked]>. Alice used to
> work for Example Co, but she no longer does, so her URI is "out of service".
> But the proxy has been provisioned to translate the R-URI of Alice's calls
> to her old boss' URI: sip:[email-masked]<[email-masked]>.
> There will never be an entry in the location service for alice,
> registrations are not permitted.
>
> In this case, in spite of there being no location service involved, I still
> think sip:[email-masked] <[email-masked]> is an
> AoR.
>

Yes, the abstract-location-service returns the address of betty. But this IS
really a border case that makes me wonder.

> decision within the domain of the URI.

It is unclear to me what definition of AOR you are using.

>>> From: Paul Kyzivat [mailto:[email-masked]] Sent: Monday, July 13,
>>> 2009 10:41
>>> things that can be done using it, or in another manner. It seems to me that
>>> if it *could* have been done with a location service lookup, then the result
>>> ought to be the same whether it is or not.
>>>
>>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 15 Jul 2009 14:40:51 +0200

In this case you would better rely on the last aor tagged entry.

/Hans Erik van Elburg

On Tue, Jul 14, 2009 at 6:01 AM, Hadriel Kaplan <[email-masked]>wrote:

> For example, a Voicemail system would NOT use the FIRST "mp" entry in the
> list, nor the LAST.  It needs to walk the list backwards to find the closest
> "mp" to the end that it can use.  Otherwise, a retarget from Alice to Bob
> will go to Alice's voicemail, when it should have gone to Bob's.  No?
>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 15 Jul 2009 15:05:15 +0200

I agree with your fluff consolidation proposal.
It would resolve issues.

/Hans Erik van Elburg

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 15 Jul 2009 09:08:37 -0500

After thinking about this some, I'd still prefer to keep Option A. as I
recall there was a good reason for the more precise values, although
that may have been before we had the "aor" tag. 

On the surface, simpler might be better although in terms of
implementation if "rc" and "cc" are handled the same then it's really no
big deal.  And, the "rc" and "cc" do provide a bit more information for
the debug use case.

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Audet, Francois (SC100:3055)
Sent: Tuesday, July 14, 2009 11:16 AM
To: SIPCORE
Cc: Hadriel Kaplan
Subject: [sipcore] rfc4244bis: Do we need rt / mp / rc / cc

In the current draft, we have opted to be "more precise" instead of
"more simple"
with regards with tagging the H-I entries....

One alternative to having the rc / cc / mp / rt (and nil) tags would be
to only have (say), "mp" (mapped to a different user), "rt" (routed to
same user) and of course "nil" (i.e., no tag because it's a legacy 4244
proxy, or because the proxy doesn't know). "rc" & "cc" would be included
in "rt". 
This is something that we considered during the development of the
draft, but it seems people at the time preferred more precise tags. 

Option A)

Option B)

PS: This says nothing of the "aor" issue, which, as Mary said, related
to other use cases, in particular the Freephone case.
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Jul 2009 10:12:13 -0400

Inline.

[Note that somewhere along the way my original examples got mangled by 
something that expanded url-looking things into <mailto...> links. I've 
whacked those out where I have caught them.]

Hans Erik van Elburg wrote:
> 
> 
> On Tue, Jul 14, 2009 at 3:41 PM, Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Francois,
> 
>     You focused on digit manipulation, which is surely one. But there
>     are others.
> 
>     sip:[email-masked]) It then
>     applies some sort of digit map it has been provisioned with
>     (possibly per-caller, possibly per-domain) to transform that into
>     some other more globally unique URI - perhaps an E.164 number in its
>     own domain or some other domain, or a TEL URI. (E.g.
>     translation and then proceeds based on the result. I agree in this
>     case it is wrong to call the incoming R-URI an AOR.
> 
> 
> What matters that if I sent something to: sip:[email-masked] 
> that it will be delivered to the 
> intended party. In this sense this is an AOR. I could put this on my 
> business card for example.

Its really questionable whether you could put this on your business card 
or not. It depends on the mechanics of the translation.

For instance, a large company with many branches may have dial plans 
that allow short digit strings for numbers in the branch, longer digit 
strings for numbers at other branches, and even longer, or at least 
different, dial strings for e.164 numbers.

In particular, the short, branch-specific, dial strings are ambiguous 
within the domain of the enterprise. They can be rendered unambiguous in 
multiple ways:
- they can be put into a uri with a branch-specific (or dial plan
   specific) domain name.
- they can be encoded with a phone-context that indicates the branch
   or dial plan
- they can be put into a uri with a company-wide domain name, which
   then is ambiguous. The proxy can then resolve the ambiguity based
   on the source of the request.

The first two cases could potentially be considered AoRs, but the latter 
one cannot not. Even the first two may not be valid on business cards if 
the company chooses not to recognize such addresses from outside its domain.

>     A proxy responsible for example.net receives a
>     request with R-URI sip:[email-masked]
>     This is not in its location service.
>     But it has a provisioned alias table that says phk is a synonym for
>     paul.kyzivat, so it translates the R-URI to
> I do think this is an AOR allright. The alias mapping can well be 
> performed by an abstract-location-service.

That is part of my issue. The proxy may use a location service as part 
of its processing, but can perform other logic as well. And the location 
service can be updated by REGISTER, but can also have entries come/go in 
other ways.

So, is something an AoR because the proxy gets the translation from the 
location service? Or is it because the translation it performs *could* 
have come from a location service? Or is it because the proxy has a 
policy that says "this URI in my domain is an AoR".

> What matters that if I sent something to: sip:[email-masked] 
> that it will be delivered to the intended 
> party. In this sense this is an AOR. You could put this on your business 
> card for example.

I agree it *could* be an AoR. But I don't know that it MUST be an AoR.

>     A proxy responsible for example.net <http://example.net> receives a
>     request with R-URI of sip:[email-masked].
>     There is a location service
>     with an entry registered for sip:[email-masked],
>     but there is also
>     unconditionally forward all calls to this URI to
>     sip:[email-masked]. This is
>     accomplished by R-URI translation. (To ensure that the request will
>     A proxy responsible for example.net <http://example.net> receives a
>     request with R-URI of sip:[email-masked].
>     Alice used to work for
>     Example Co, but she no longer does, so her URI is "out of service".
>     But the proxy has been provisioned to translate the R-URI of Alice's
>     calls to her old boss' URI: sip:[email-masked].
>     There will never be an entry
>     in the location service for alice, registrations are not permitted.
> 
>     In this case, in spite of there being no location service involved,
>     I still think sip:[email-masked] is an AoR.
> 
> Yes, the abstract-location-service returns the address of betty. But 
> this IS really a border case that makes me wonder.
> 

I am taking at face value that AoR (Address of *Record*) is based on a 
*record* of the domain, which almost by definition is a matter of policy.

And I am pointing out that we don't have a definition of AoR that both 
useful operationally and that meets every day expectations.

>             From: Paul Kyzivat [mailto:[email-masked]
>             <mailto:[email-masked]>] Sent: Monday, July 13, 2009 10:41
>                 That means you will now route based on "rules" you have
>                 internally, e.g., map it to a contact, etc.
> 
>             manner. It seems to me that if it *could* have been done
>             with a location service lookup, then the result ought to be
>             the same whether it is or not.
> 
> 
>         I didn't want to alter (or second-guess) the definition of AOR
>         (which is the realm of RFC 3261), in this draft.
>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 15 Jul 2009 17:09:15 +0200

(sip:[email-masked] <[email-masked]> --> (example.net proxy
instance 1) -->
sip:[email-masked]<[email-masked]>;user=phone
(example.net proxy instance 2) --> contact)

Ok, your point is whether a number belonging to a private number plan is
also an AOR right?

Then the question is if the proxy-instance-1 that translates this to a
globally routable URI should tag this as an aor. I think it does not really
matter in this case whether it tags the entry or not. What is important is
that proxy-instance-2 that receives the request targeted at the domain that
it is responsible for tags the entry as aor.

But I still think that it would not do any harm if the proxy instance 1
would mark the entry with aor, allthough this might be counterintuitive in
some very peculiar cases.

/Hans Erik van Elburg

On Wed, Jul 15, 2009 at 4:12 PM, Paul Kyzivat <[email-masked]> wrote:

>> On Tue, Jul 14, 2009 at 3:41 PM, Paul Kyzivat <[email-masked]<mailto:
>> [email-masked]>> wrote:
>>
>>    Francois,
>>
>>    sip:[email-masked] <[email-masked]>) It then
>>    sip:[email-masked] <[email-masked]>;user=phone.)
>> It does the
>> What matters that if I sent something to: sip:[email-masked]<[email-masked]>that it will be delivered to the intended party. In this sense this is an
>> AOR. I could put this on my business card for example.
>>
>
> Its really questionable whether you could put this on your business card or
> not. It depends on the mechanics of the translation.
>
> For instance, a large company with many branches may have dial plans that
> allow short digit strings for numbers in the branch, longer digit strings
> for numbers at other branches, and even longer, or at least different, dial
> strings for e.164 numbers.
>
> one cannot not. Even the first two may not be valid on business cards if the
> company chooses not to recognize such addresses from outside its domain.
>
>>    request with R-URI sip:[email-masked] <[email-masked]>
>>    sip:[email-masked] <[email-masked]>. It then
>> proceeds to process
>>    translates it again to sip:[email-masked]<[email-masked]>
>> .
>>    Again, I don't think sip:[email-masked] <[email-masked]> is an
>> AoR in this case.
> That is part of my issue. The proxy may use a location service as part of
> its processing, but can perform other logic as well. And the location
> location service? Or is it because the translation it performs *could* have
> come from a location service? Or is it because the proxy has a policy that
> says "this URI in my domain is an AoR".
>
>> What matters that if I sent something to: sip:[email-masked]<[email-masked]>that it will be delivered to the intended party. In this sense this is an
>> AOR. You could put this on your business card for example.
>>
>
>>    request with R-URI of sip:[email-masked]<[email-masked]>
>> .
>>    with an entry registered for sip:[email-masked]<[email-masked]>
>> ,
>>    but there is also
>>    sip:[email-masked] <[email-masked]>. This is
>>    request with R-URI of sip:[email-masked]<[email-masked]>
>> .
>>    Alice used to work for
>>    calls to her old boss' URI: sip:[email-masked]<[email-masked]>
>> .
>>    I still think sip:[email-masked]<[email-masked]>is an AoR.
>>
>> Yes, the abstract-location-service returns the address of betty. But this
>> IS really a border case that makes me wonder.
>>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 15 Jul 2009 11:19:46 -0500

Yes, we did.

________________________________

	From: Hans Erik van Elburg [mailto:[email-masked]] 
	Sent: Wednesday, July 15, 2009 04:43
	To: Hadriel Kaplan
	Cc: Audet, Francois (SC100:3055); SIPCORE
	Subject: Re: [sipcore] rfc4244bis: Open Issues

	This is like the Target header we proposed a while ago, but with a change of keeping all the retargets that would qualify for "mp". (http://tools.ietf.org/html/draft-holmberg-sip-target-uri-delivery-01)

	I thought that the wg came to consensus that this needs to be resolved with History-Info. If not...

	/Hans Erik van Elburg

		

		

		
		It should be noted that, like RFC 4244, RHI does not produce the smallest list possible of retargets - in some cases an entry is added when the target user Identity has not changed - the URI has changed to a new one, but unbeknownst to the Proxy which added it, the Identity of the human may have remained the same.  For example an entry for "sip:[email-masked] <mailto:[email-masked]> " and a subsequent entry for "sip:[email-masked] <mailto:[email-masked]> " may both have been added, even though they are the same abstract target human.  A proxy cannot know by default that these two targets are the same identity.  Only the UAS would know that, and so it may need to cull the list down further.

		-hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 15 Jul 2009 14:48:52 -0500

I think indeed the aor; flag may actually solve the issue.
But yes, let's think about it.

In earlier versions, the "mp" flag was representing the
"mapped from" address instead of the mapped to address", and
there was no "aor".

Then we switched it around to have the "aor" mean "I've found
this address in my location service as my own".

The reason we need something like this is that most algorithm
work by looking at the previous target of significance. This is
why we have the aor flag now: it marks the proper target.

The problem with logic like "look at the previous target" instead
of using a marking is that the previous target may be wrong. It may
be one of those "fluff" entries. This is a big problem with current
4244.

If we were to package all the fluff together, then the combination
of aor (previous target) and then the the "map" (on the next target is
useful). Everything else (i.e., the fluff) implies the same user.

An alternative would be to have only a flag for the previous target,
i.e., "aor-mp" and "aor-same", and then everything else is fluff.

> From: Barnes, Mary (RICH2:AR00) 
> Sent: Wednesday, July 15, 2009 07:09
> Subject: RE: [sipcore] rfc4244bis: Do we need rt / mp / rc / cc
> 
> After thinking about this some, I'd still prefer to keep 
> Option A. as I recall there was a good reason for the more 
> precise values, although that may have been before we had the 
> "aor" tag. 
> 
> implementation if "rc" and "cc" are handled the same then 
> it's really no big deal.  And, the "rc" and "cc" do provide a 
> bit more information for the debug use case.

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 15 Jul 2009 16:55:25 -0400

Yup, and I also thought it would be good to try to solve it with an already-existing mechanism (ie, H-I).
But if in the end we find doing that is really complicated or confusing, it's not like we can't change our minds.
Right now though, I'm not sure if doing it in a new header is any easier than incorporating it into H-I.  Clearly it would be a lot more verbose (there'd be a lot more fluff) in H-I, but if a machine can programmatically/deterministically reduce it to the same set of info a new header would have had without a lot of processing effort or room for error, then that's fine with me.

-hadriel

________________________________
From: Hans Erik van Elburg [mailto:[email-masked]]
Sent: Wednesday, July 15, 2009 7:43 AM
To: Hadriel Kaplan
Cc: Francois Audet; SIPCORE
Subject: Re: [sipcore] rfc4244bis: Open Issues

/Hans Erik van Elburg
On Tue, Jul 14, 2009 at 3:42 AM, Hadriel Kaplan <[email-masked]<mailto:[email-masked]>> wrote:

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 15 Jul 2009 16:33:05 -0500

Mary, Hans and I have consulsted, and we have
the following position on this topic:

1) We need the separate "aor" flag 
2) We need the "mp" flag
3) We have no particular preference on the "fluff" versus "cc / rc / rt" issue

Others?

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 15 Jul 2009 17:55:52 -0400

> Sent: Wednesday, July 15, 2009 5:33 PM
> 

Yup.

> 2) We need the "mp" flag

Probably.

> 3) We have no particular preference on the "fluff" versus "cc / rc / rt"

Dunno yet.  I think if it's clearly spelled out as ONLY useful for manual/human troubleshooting purposes (like a Response's reason-phrase), then it'd be safer.

-hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 15 Jul 2009 16:57:13 -0500

All right!

Looks like are on same wavelength! 

> Sent: Wednesday, July 15, 2009 14:56
> Cc: Barnes, Mary (RICH2:AR00); Barnes, Mary (RICH2:AR00); 
> Hans Erik van Elburg; Christer Holmberg
> > Mary, Hans and I have consulsted, and we have the following 
> position 
> > on this topic:
> > 
> > 3) We have no particular preference on the "fluff" versus 
> "cc / rc / rt"
> > issue
> 
> Dunno yet.  I think if it's clearly spelled out as ONLY 
> useful for manual/human troubleshooting purposes (like a 
> Response's reason-phrase), then it'd be safer.
> 
> -hadriel
>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 15 Jul 2009 16:01:22 -0500

If [email-masked] is globablly routable, sure, it can be an AOR. And YES the proxy example.net could flag it as such.
 
In this case, you'd get
History-Info: <sip:[email-masked]>;index=1;aor;rt, <sip:[email-masked] <mailto:[email-masked]> ;user=phone>;aor;rt, etc.

But if it's not because [email-masked] is NOT an alias for sip:[email-masked] <mailto:[email-masked]> ;user=phone, then it's not an AOR.

	From: Hans Erik van Elburg [mailto:[email-masked]] 
	Sent: Wednesday, July 15, 2009 08:09
	To: Paul Kyzivat
	Cc: Audet, Francois (SC100:3055); Hadriel Kaplan; SIPCORE
	Subject: Re: [sipcore] rfc4244bis: what is an AoR?

	(sip:[email-masked] <mailto:[email-masked]>  --> (example.net proxy instance 1) --> sip:[email-masked] <mailto:[email-masked]> ;user=phone (example.net proxy instance 2) --> contact)

	Ok, your point is whether a number belonging to a private number plan is also an AOR right?

	Then the question is if the proxy-instance-1 that translates this to a globally routable URI should tag this as an aor. I think it does not really matter in this case whether it tags the entry or not. What is important is that proxy-instance-2 that receives the request targeted at the domain that it is responsible for tags the entry as aor. 

	But I still think that it would not do any harm if the proxy instance 1 would mark the entry with aor, allthough this might be counterintuitive in some very peculiar cases.

	/Hans Erik van Elburg

		Inline.
		
		[Note that somewhere along the way my original examples got mangled by something that expanded url-looking things into <mailto...> links. I've whacked those out where I have caught them.] 

			On Tue, Jul 14, 2009 at 3:41 PM, Paul Kyzivat <[email-masked] <mailto:[email-masked]>> wrote:
			
			   Francois,

			
			   sip:[email-masked] <mailto:[email-masked]> ) It then
			   sip:[email-masked] <mailto:[email-masked]> ;user=phone.) It does the

			What property does this not make an AOR?
			How does it matter whether there are multiple translation steps in a domain?
			What matters that if I sent something to: sip:[email-masked] <mailto:[email-masked]>  that it will be delivered to the intended party. In this sense this is an AOR. I could put this on my business card for example.

		Its really questionable whether you could put this on your business card or not. It depends on the mechanics of the translation.
		
		For instance, a large company with many branches may have dial plans that allow short digit strings for numbers in the branch, longer digit strings for numbers at other branches, and even longer, or at least different, dial strings for e.164 numbers.
		
		In particular, the short, branch-specific, dial strings are ambiguous within the domain of the enterprise. They can be rendered unambiguous in multiple ways:
		
		The first two cases could potentially be considered AoRs, but the latter one cannot not. Even the first two may not be valid on business cards if the company chooses not to recognize such addresses from outside its domain. 

			   A proxy responsible for example.net receives a
			   request with R-URI sip:[email-masked] <mailto:[email-masked]> 
			   This is not in its location service.
			   But it has a provisioned alias table that says phk is a synonym for
			   paul.kyzivat, so it translates the R-URI to
			   sip:[email-masked] <mailto:[email-masked]> . It then proceeds to process
			   that, which turns out to be in its location service, so it
			   translates it again to sip:[email-masked] <mailto:[email-masked]> .
			   Again, I don't think sip:[email-masked] <mailto:[email-masked]>  is an AoR in this case. 
			I do think this is an AOR allright. The alias mapping can well be performed by an abstract-location-service.

		That is part of my issue. The proxy may use a location service as part of its processing, but can perform other logic as well. And the location service can be updated by REGISTER, but can also have entries come/go in other ways.
		
		So, is something an AoR because the proxy gets the translation from the location service? Or is it because the translation it performs *could* have come from a location service? Or is it because the proxy has a policy that says "this URI in my domain is an AoR". 

			What property does this not make an AOR?
			How does it matter whether there are multiple translation steps in a domain?
			What matters that if I sent something to: sip:[email-masked] <mailto:[email-masked]>  that it will be delivered to the intended party. In this sense this is an AOR. You could put this on your business card for example.

			

			   request with R-URI of sip:[email-masked] <mailto:[email-masked]> .
			   There is a location service
			   with an entry registered for sip:[email-masked] <mailto:[email-masked]> ,
			   but there is also
			   provisioning independent of the location service that says to
			   unconditionally forward all calls to this URI to
			   sip:[email-masked] <mailto:[email-masked]> . This is
			   accomplished by R-URI translation. (To ensure that the request will
			   not be rejected as mis-addressed.)
			
			   In this case I think that sip:[email-masked] <mailto:[email-masked]> 
			   *is* an AoR. 
			Yes.
			     And one final forwarding case:

			   request with R-URI of sip:[email-masked] <mailto:[email-masked]> .
			   Alice used to work for
			   Example Co, but she no longer does, so her URI is "out of service".
			   But the proxy has been provisioned to translate the R-URI of Alice's
			   calls to her old boss' URI: sip:[email-masked] <mailto:[email-masked]> .
			   There will never be an entry
			   in the location service for alice, registrations are not permitted.
			
			   In this case, in spite of there being no location service involved,
			   I still think sip:[email-masked] <mailto:[email-masked]>  is an AoR.
			
			Yes, the abstract-location-service returns the address of betty. But this IS really a border case that makes me wonder.

		I am taking at face value that AoR (Address of *Record*) is based on a *record* of the domain, which almost by definition is a matter of policy.
		
		And I am pointing out that we don't have a definition of AoR that both useful operationally and that meets every day expectations. 

			          Thanks,
			          Paul

			   Francois Audet wrote:

			           -----Original Message-----

			           Francois Audet wrote:

			
			           responsible for the

			           mark as AOR.

			
			           - If the proxy translates to a contact that it got from a
			             location service and that entry was placed there by a
			           REGISTER,
			             then the entry should definitely be marked as an AoR

			       Agree.
			
			           - If the proxy translates to a contact that it got from a
			             ocation service, and that entry got there somehow other
			           than REGISTER,
			             then I *think* the entry should still be marked as an AoR.

			       Yes, agree.

			           - If the proxy never uses a location service for this URI,
			             but translates it on some other basis, then again I'm not
			           sure.

			
			
			       I would think that if the proxy doesn't know that it's an AOR,
			       then it shouldn't mark
			       it as such. So I would expect mechanical digit manipulation to
			       NOT be marked as AOR.