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

From: Adam Roach <[email-masked]>
Date: Tue, 08 Sep 2009 17:45:59 -0500

Just a quick reminder that we discussed this vigorously in Stockholm 
without reaching any conclusion. To help spur things along, here's a 
summary of the arguments made during that discussion:

http://www.ietf.org/proceedings/75/minutes/sipcore.html#Issue%201:%20AOR%20tag

Please resume discussion on the list, and see if we can reach any sort 
of rough agreement.

/a

---

From: Dean Willis <[email-masked]>
Date: Tue, 8 Sep 2009 18:27:11 -0500

On Sep 8, 2009, at 5:45 PM, Adam Roach wrote:

> Please resume discussion on the list, and see if we can reach any  
> sort of rough agreement.

AORs might be used as targets for initial requests that are rerouted  
or retargeted by contact routing or tabular translation. AORs might be  
the identity bindings attached to GRUUs (see sections 1, 3, and 5  of  
draft-ietf-sip-gruu-15). AORs might or might not be human-readable and  
likley to appear on business cards. None of these definitions  
effectively differentiates AORs from other URIs.

I propose instead that an AOR is a SIP URI for which it is reasonable  
to expect that an authentication service would issue an identity  
certification, should an authentication service be in operation for  
the domain in question. This might include RFC 4474 authentication,  
DIGEST authentication at a registrar, proxy, or gateway, P-Asserted- 
Identity as in RFC 3325 and IMS, or any similar certification of  
identity arranged through an enrollment process.

One might argue that in a simplistic non-authenticating proxy- 
registrar that the registration action (which associates a Contact  
with the To: URI of the request) forms the minimal identity  
certification needed for this definition. Correspondingly, a systems  
configuration with similar effect that statically configures a  
rerouting or retargeting destination relative to an input URI forms a  
comparable minimal identity certification. Further, acceptance of an  
AOR as a terminal value at a SIP UA selected through conventional  
routing (as in RFC 3263) resolution mechanisms would constitute a  
minimal identity certification.

Another wording would make an AOR the input member of any (input,  
output) tuple wherein a SIP transformation operation transforms  
(either reroutes or retargets) the input URI such that the output URI  
is selected, OR where an authentication operation is performed on the  
input member (and especially where the two operations are combined)..  
The output URI may also be an AOR, but only if it participates as an  
input member into a transformation or authentication operation.

We might do well to speak of the "strength" of an AOR as a product of  
the strength of the identity certification. For example, an an AOR for  
which RFC 4474 identity certification is available would be "stronger"  
than one resolved strictly through RFC 3263 resolution. This doesn't  
affect the definition of an AOR, but might affect how one would react  
to that AOR within an authorization system.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Sep 2009 00:12:34 -0400

Its really interesting that this term, which has been ubiquitous in the 
sip world for so long should turn out to be so hard to define 
thoroughly. :-(

I kind of like Dean's idea of tying this to authentication, though as he 
is exploring below, the precise definition of what constitutes 
*sufficient* authentication to warrant use of the term AOR remains a bit 
elusive.

	Thanks,
	Paul

Dean Willis wrote:
> AORs might be used as targets for initial requests that are rerouted or 
> retargeted by contact routing or tabular translation. AORs might be the 
> identity bindings attached to GRUUs (see sections 1, 3, and 5  of 
> I propose instead that an AOR is a SIP URI for which it is reasonable to 
> expect that an authentication service would issue an identity 
> certification, should an authentication service be in operation for the 
> domain in question. This might include RFC 4474 authentication, DIGEST 
> authentication at a registrar, proxy, or gateway, P-Asserted-Identity as 
> in RFC 3325 and IMS, or any similar certification of identity arranged 
> through an enrollment process.
> 
> One might argue that in a simplistic non-authenticating proxy-registrar 
> that the registration action (which associates a Contact with the To: 
> URI of the request) forms the minimal identity certification needed for 
> this definition. Correspondingly, a systems configuration with similar 
> effect that statically configures a rerouting or retargeting destination 
> relative to an input URI forms a comparable minimal identity 
> certification. Further, acceptance of an AOR as a terminal value at a 
> SIP UA selected through conventional routing (as in RFC 3263) resolution 
> mechanisms would constitute a minimal identity certification.
> 
> output) tuple wherein a SIP transformation operation transforms (either 
> reroutes or retargets) the input URI such that the output URI is 
> selected, OR where an authentication operation is performed on the input 
> member (and especially where the two operations are combined).. The 
> output URI may also be an AOR, but only if it participates as an input 
> member into a transformation or authentication operation.
> 
> 
> affect the definition of an AOR, but might affect how one would react to 
> that AOR within an authorization system.
> 
> -- 
> Dean_______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 9 Sep 2009 18:41:15 -0500

I guess the summary is that we are kind of stalled on some of the issues, in
particular the aor tag issue. It seems that a significant fraction of people
do not believe that an AOR is deterministic construct that is worthy of
being tagged as such.

In my background (which is an Enterprise software/telephony background),
"users" have accounts. An AOR is the series of addresses
corresponding to these accounts, along with any aliases (such as phone 
numbers expressed in SIP/TEL format). To me, AORs are not this fluffy
concept that others on the list have made it up to be. 

But in any case, I don't think we'll be able to reach a concensus on it.

I believe that we need to step back and find a different way to skin this cat.

Going back to the requirements of WHAT we are really trying to solve at the
UAS:

1) Tagging the last address (including parameters) that was used in
   a Request-URI before being replaced by the Contact.
   i.e., the target-uri problem
	1a) It has been argued that sometimes with the target-uri problem
	    you may actually be looking for the first address (and parameters)
	    as opposed to the last one.

2) Tagging addresses that represents a DIFFERENT user/resource, as a
   result of re-targeting.
   i.e., the re-targeting problem (voicemail, IVR, etc.)

We could potentially solve those two by having tags for
"mapped" and "contacts", and use a pointer to the index
of what it is mapped from (I guess we could do 
forward pointing instead of backward pointing, but then
forking would be more cumbersome).

Having the tag pointing to the index would remove ambiguity
if entries are removed by a proxy, etc. 

So, if I take a specific example of a call to bob
being redirected to carol, the HI would look like 
this:

     History-Info: <sip:[email-masked]>;index=1;
     History-Info: <sip:[email-masked]?Reason=SIP;cause=302>;\
                   index=1.1;rc=1
     History-Info: <sip:[email-masked]>;index=2;mp=1
     History-Info: <sip:[email-masked]>;index=2.1;rc=2

For problem 1 (target-uri), the UAS would look at the last rc tag which is
it's registered contact, and see what it points to (i.e., index 2). Index 2 is therefore
the last target-uri.

For problem 2 (redirection), the UAS looks for the last mp tag (it points to index 1).
Index 1 (bob) is therefore the "redirecting" number. Alternatively, the UAS may look for
the FIRST retargeting (many voicemail work with the first one).

Anyways, this is just brainstorming (and it notably doesn't solve - I think - the 
Freephone/1-800 number problem). 

Ideas?

> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]] 
> Sent: Tuesday, September 08, 2009 15:46
> To: [email-masked]
> Cc: Hadriel Kaplan; Audet, Francois (SC100:3055); Keith 
> Drage; Jon Peterson; Elwell, John; Robert Sparks; Jonathan 
> Lennox; Dean Willis
> Subject: Re: [sipcore] rfc4244bis: what is an AoR?
> 
> Just a quick reminder that we discussed this vigorously in 
> Stockholm without reaching any conclusion. To help spur 
> things along, here's a summary of the arguments made during 
> that discussion:
> 
>    
> Please resume discussion on the list, and see if we can reach 
> any sort of rough agreement.
> 
> /a
>

---

From: Shida Schubert <[email-masked]>
Date: Thu, 10 Sep 2009 13:24:09 +0900

I think the following could work for Freephone(toll-free), AFAIK
all is needed for freephone was the mp tag and some
guidance on where to look for a toll-free.

  I believe that solving the problem of toll-free is really
determining the current target of the request, which I believe
is what mp is trying to address. Generally if the incoming
request is delivered via toll-free, then an entry before
the last mp(mapped-to) is likely to be a toll-free number
(mapped-from).

Although, without globally deterministic way to mark the
toll-free, it's hard for it to work across countries as different
countries have different toll-free prefixes.
(Here in Japan, it's 0120-xxx and not 1-800).

  We could though, possibly define a service URN or some tags for
typical services that are out there and tag HI-entry representing
such service with service URN that we define.

     History-Info:  
< 
sip:DirectoryAssistance 
@example.com>;index=1;service=urn:service:directory-assistance
     History-Info: <sip:[email-masked]>;index=1.1;mp=1
     History-Info: <sip:[email-masked]>;index=1.1.1;rc=1
     History-Info: <sip:[email-masked]>;index=1.1.2;rc=2

  Regards
   Shida

On Sep 10, 2009, at 8:41 AM, Francois Audet wrote:

> _______________________________________________
> sipcore mailing list
> [email-masked]

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 10 Sep 2009 12:06:16 -0500

Ok, thanks.

Let's wait for more input on this before we go for another rev of the
draft. 

> From: Shida Schubert [mailto:[email-masked]] 
> Sent: Wednesday, September 09, 2009 21:24
> To: Audet, Francois (SC100:3055)
> Cc: Adam Roach; [email-masked]; Jonathan Lennox; Hadriel 
> Kaplan; Dean Willis; Elwell, John; Keith Drage
>   I think the following could work for Freephone(toll-free), 
> AFAIK all is needed for freephone was the mp tag and some 
> determining the current target of the request, which I 
> believe is what mp is trying to address. Generally if the 
> incoming request is delivered via toll-free, then an entry 
> before the last mp(mapped-to) is likely to be a toll-free 
> number (mapped-from).
> 
> toll-free, it's hard for it to work across countries as 
> different countries have different toll-free prefixes.
>   We could though, possibly define a service URN or some tags 
> for typical services that are out there and tag HI-entry 
> representing such service with service URN that we define.
> 
>      History-Info:  
> <
> sip:DirectoryAssistance
> > I guess the summary is that we are kind of stalled on some of the 
> > issues, in particular the aor tag issue. It seems that a 
> significant 
> > fraction of people do not believe that an AOR is deterministic 
> > construct that is worthy of being tagged as such.
> >
> > In my background (which is an Enterprise software/telephony 
> > background), "users" have accounts. An AOR is the series of 
> addresses 
> > But in any case, I don't think we'll be able to reach a 
> concensus on 
> > it.
> >
> > I believe that we need to step back and find a different 
> way to skin 
> > this cat.
> >
> > Going back to the requirements of WHAT we are really trying 
> to solve 
> > at the
> > UAS:
> >
> "mapped" and 
> > "contacts", and use a pointer to the index of what it is 
> mapped from 
> > (I guess we could do forward pointing instead of backward pointing, 
> > but then forking would be more cumbersome).
> >
> > So, if I take a specific example of a call to bob being 
> redirected to 
> > carol, the HI would look like
> > this:
> >
> > For problem 1 (target-uri), the UAS would look at the last rc tag 
> > which is it's registered contact, and see what it points to (i.e., 
> > index 2).
> > Index 2 is therefore
> > the last target-uri.
> >
> > Index 1 (bob) is therefore the "redirecting" number. Alternatively, 
> > the UAS may look for the FIRST retargeting (many voicemail 
> work with 
> > the first one).
> >
> > Anyways, this is just brainstorming (and it notably doesn't 
> solve - I 
> > think - the Freephone/1-800 number problem).
> >
> > Ideas?
> >
> >
> >> Cc: Hadriel Kaplan; Audet, Francois (SC100:3055); Keith Drage; Jon 
> >> Peterson; Elwell, John; Robert Sparks; Jonathan Lennox; Dean Willis
> Stockholm

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 10 Sep 2009 13:50:03 -0500

Your second definition is similar to the one that is actually
used in RFC 3261/section 6:

      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. 

Which is what I've been arguing for a while now.

It says the following things:
- Tel URIs are not AORs
- Only the target domain can know for sure if it's an AOR (which is why
  I said earlier that something is an AOR when the target domain says it's
  an AOR).
- Typically, the location service is populated through registration.
- AOR are the "public" address of the user (i.e., the reachable address).

Now, the problem with this definition is that taken at face value, 
lots of things could be considered AORs. Perhaps too much to consider
an AOR tag to be useful. I believe this is what many were saying in Stockholm.

Therefore my other email on trying a different angle to solve the target-uri
and redirection-number problems for History-Info.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dean Willis
> Sent: Tuesday, September 08, 2009 16:27
> To: SIPCORE
> Subject: [sipcore] [DW] What is an AoR?
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 23 Sep 2009 15:23:56 +0200

If we want to find specific things like freephone numbers, I think they do need to be explicitly marked, perhaps along the lines that Shida has suggested.
- Example 1: Call from A to B, which is forwarded to freephone number C, which resolves to D, which resolves to contact E.
- Example 2: Call from A to freephone number B, which resolves to C, which is then forwarded to D, which resolves to contact E.

These two examples illustrate that the freephone URI cannot be found at any fixed place in the sequence, so explicit marking would seem to be necessary.

John

> [mailto:[email-masked]] On Behalf Of Francois Audet
> Sent: 10 September 2009 18:06
> To: Shida Schubert
> Cc: Jonathan Lennox; [email-masked]; Hadriel Kaplan; Dean 
> Willis; Elwell, John; Keith Drage
> > > For problem 2 (redirection), the UAS looks for the last 
> mp tag (it 
> > > points to index 1).
> Drage; Jon

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 23 Sep 2009 16:08:26 -0500

Can you give me an example of how the tags would look like?

Also, and you clarify what you mean by "forward" vs "resolve"?

I am assuming you are using "forward" in the traditional
"telephony" way, i.e., it is retargeted to another user, as opposed
to "request forwarding" which what you used for "resolving". Is this
correct?

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Wednesday, September 23, 2009 06:24
> To: Audet, Francois (SC100:3055); Shida Schubert
> Subject: RE: [sipcore] rfc4244bis: what is an AoR?
> 
> If we want to find specific things like freephone numbers, I 
> think they do need to be explicitly marked, perhaps along the 
> lines that Shida has suggested.
> - Example 1: Call from A to B, which is forwarded to 
> freephone number C, which resolves to D, which resolves to contact E.
> - Example 2: Call from A to freephone number B, which 
> resolves to C, which is then forwarded to D, which resolves 
> to contact E.
> 
> These two examples illustrate that the freephone URI cannot 
> be found at any fixed place in the sequence, so explicit 
> marking would seem to be necessary.
> 
> John
> 
> 
> > Cc: Jonathan Lennox; [email-masked]; Hadriel Kaplan; Dean Willis; 
> > Elwell, John; Keith Drage
> > > Cc: Adam Roach; [email-masked]; Jonathan Lennox; 
> Hadriel Kaplan; 
> > > Dean Willis; Elwell, John; Keith Drage
> > > all is needed for freephone was the mp tag and some guidance on 
> > > where to look for a toll-free.
> > > 
> > > determining the current target of the request, which I believe is 
> > > what mp is trying to address. Generally if the incoming 
> request is 
> > > delivered via toll-free, then an entry before the last 
> mp(mapped-to) 
> > > is likely to be a toll-free number (mapped-from).
> > > 
> toll-free, 
> > > it's hard for it to work across countries as different countries 
> > > have different toll-free prefixes.
> <sip:[email-masked]>;index=1.1;mp=1
> > > > 	    you may actually be looking for the first 
> address (and
> > > > parameters)

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 24 Sep 2009 08:22:18 +0200

> From: Francois Audet [mailto:[email-masked]] 
> Sent: 23 September 2009 22:08
> To: Elwell, John; Shida Schubert
[JRE] Without an explicit indication of freephone, all URIs from B onwards would be tagged as mapped, except E, which is registered contact. So without the explicit indication of freephone, how does the UAS know which is the freephone number?

> to "request forwarding" which what you used for "resolving". Is this
[JRE] Yes.

John

> believe is

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 24 Sep 2009 10:50:17 -0500

So, your proposal is that we have a "mapped" tag and a "freephone" tag?

Is this correct?

Perhaps just having an explicit "label" (as opposed to a "tag") is the
way to go. Perhaps us trying to make it more complicated than it really
is ain't a good idea after all.

The "label" would be a string that allows us to describe the 
address. "mapped", "freephone", maybe others, would be the 
values we would define. 

Other views?

> Sent: Wednesday, September 23, 2009 23:22
> [JRE] Without an explicit indication of freephone, all URIs 
> from B onwards would be tagged as mapped, except E, which is 
> registered contact. So without the explicit indication of 
> freephone, how does the UAS know which is the freephone number?
> 
> > 
> "telephony" 
> > way, i.e., it is retargeted to another user, as opposed to "request 
> > forwarding" which what you used for "resolving". Is this correct?
> [JRE] Yes.
> 
> John
> 
> 
> > 
> > > If we want to find specific things like freephone 
> numbers, I think 
> > > they do need to be explicitly marked, perhaps along the 
> lines that 
> > > Shida has suggested.
> > > - Example 1: Call from A to B, which is forwarded to freephone 
> > > number C, which resolves to D, which resolves to
> > contact E.
> resolves to C, 
> > > which is then forwarded to D, which resolves to contact E.
> > > 
> > > These two examples illustrate that the freephone URI 
> cannot be found 
> > > at any fixed place in the sequence, so explicit marking 
> would seem 
> > > to be necessary.
> > > 
> > > John
> > > 
> > >

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 24 Sep 2009 20:27:15 +0200

I thought 4244bis was to be about generic mechanism. Findin g the
adressed target may result in obtaining the Freephone number, but also
any other addressed target like for example a premium number. However
a freephone tag is service specific. Im surprised we are looping back
i thought we passed that stage.
/hans erik

-- 
Von meinen Mobilgerät aus gesendet

/Hans Erik van Elburg

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 24 Sep 2009 13:37:53 -0500

Oh, I'm not surprised at all... This is the IETF after all!
:-) 

In any case, it was pretty loud in clear in Stockholm that people didn't like
the idea of using an AOR tag. 

The mapped tag would be quite generic. It's really "freephone" that seems to
be a weird corner case that people seem to think it's worth solving. 

> From: Hans Erik van Elburg [mailto:[email-masked]] 
> Sent: Thursday, September 24, 2009 11:27
> To: Audet, Francois (SC100:3055); Elwell, John; Shida 
> Schubert; Jonathan Lennox; [email-masked]; Hadriel Kaplan; 
> I thought 4244bis was to be about generic mechanism. Findin g 
> the adressed target may result in obtaining the Freephone 
> number, but also any other addressed target like for example 
> a premium number. However a freephone tag is service 
> specific. Im surprised we are looping back i thought we 
> passed that stage.
> /hans erik
> 
> > way to go. Perhaps us trying to make it more complicated than it 
> > really is ain't a good idea after all.
> >
> > The "label" would be a string that allows us to describe 
> the address. 
> > "mapped", "freephone", maybe others, would be the values we would 
> > define.
> >
> > Other views?
> >
> >> [JRE] Without an explicit indication of freephone, all URIs from B 
> >> onwards would be tagged as mapped, except E, which is registered 
> >> contact. So without the explicit indication of freephone, how does 
> >> the UAS know which is the freephone number?
> >>
> >> >
> <sip:[email-masked]>;index=1.1.1;rc=1
> <sip:[email-masked]?Reason=SIP;cause=302>;\
> >> > > > > >                   index=1.1;rc=1

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 24 Sep 2009 20:47:42 +0200

Yes got that, but that does not justify a service specific tag in  4244bis.
/hans erik

/Hans Erik van Elburg

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 24 Sep 2009 13:48:49 -0500

Other idea?

(I really don't care personally about "freephone"...) 

> Sent: Thursday, September 24, 2009 11:48

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 24 Sep 2009 21:52:58 +0200

Just to be clear, I do not have a specific requirement for finding the freephone number. I was merely pointing out that it seems very difficult to solve using a generic mechanism.

I think the latest proposal for just indicating mp or rc is more feasible than the earlier AOR-based proposal. Whether it is sufficiently robust (deterministic) I am not sure.

John

> Sent: 24 September 2009 19:48
> To: Francois Audet; Elwell, John; Shida Schubert; Jonathan
> Lennox; [email-masked]; Hadriel Kaplan; Dean Willis;
> > In any case, it was pretty loud in clear in Stockholm that
> people didn't
> > like
> >> >> > > From: Elwell, John
> [mailto:[email-masked]]
> <sip:[email-masked]>;index=1.1.2;rc=2
> >> >> > > > >
> >> >> > > > >   Regards
> >> >> > > > >    Shida
> >> >> > > > >
> >> >> > > > > > corresponding to these accounts, along with
> any aliases
> >> >> > > > > (such as phone
> >> >> > > > > > numbers expressed in SIP/TEL format). To me,
> AORs are not
> >> >> > > > > this fluffy
> >> >> > > > > > 1) Tagging the last address (including
> parameters) that
> >> >> > > > was used in
> >> >> > > > > > (I guess we could do forward pointing instead
> of backward
> >> >> > > > pointing,
> >> >> > > > > > which is it's registered contact, and see
> what it points
> >> >> > > > to (i.e.,
> >> >> > > > > > index 2).
> >> >> > > > > > Index 2 is therefore
> >> >> > > > > > the last target-uri.
> >> >> > > > > >
> >> >> > > > > >> Peterson; Elwell, John; Robert Sparks;
> Jonathan Lennox;
> >> >> > > > Dean Willis
> >> >> > > > > >> Please resume discussion on the list, and
> see if we can
> >> >> > > > reach any
> >> >> > > > > >> sort of rough agreement.
> >> >> > > > > >>
> >> >> > > > > >> /a
> >> >> > > > > >>

---

From: Dean Willis <[email-masked]>
Date: Thu, 24 Sep 2009 16:09:47 -0500

On Sep 24, 2009, at 2:52 PM, Elwell, John wrote:

> Just to be clear, I do not have a specific requirement for finding  
> the freephone number. I was merely pointing out that it seems very  
> difficult to solve using a generic mechanism.

My general philosophy is that if something is appearing to be hard to  
solve, perhaps we're going about it entirely the wrong way.

For example: Perhaps freephone routing shouldn't be handled by SIP  
retargeting or rerouting mechanisms like contact-routing. Perhaps it  
could be handled entirely by SIP rerouting operations.

There are a lot of forms this can take. One might be in the area of  
doing something analogous to REGISTER that registers a "route", not a  
"contact". Such a "route registration" might be wildcard prefixable,  
which would also handle the "domain registration" case being raised by  
Alan Johnston and Richard Shockey. Further, it could eliminate much of  
the unanticipated respondent problem of contact routing (as we have no  
current way to determine whether contact-routing is rerouting or  
retargeting). Oddly enough, this solution also preserves URI  
parameters of all sorts . . .

The difference between "contact routing" and just "routing" in a proxy  
is straightforward. If the next-hop URL is a "contact", we use RFC  
3261 contact-routing procedures, replacing the request-URI with the  
registered contact. If however the next-hop URL is a "route", we use  
RFC 3261 loose-route procedures and push the URL onto the route stack  
and ship out the request with an unmodified request URI. Net result,  
the request is delivered to the next hop with an unmodified URL,  
ostensibly including the freephone number.

If the next hop is terminal (the UAS), it of course needs to be able  
to recognize the freephone number as belonging to it, but that seems  
to be a requirement of all the things that require looking for a  
freephone number in the H_I stack anyhow. Handling freephone  
termination on legacy contact-registering devices would require  
fronting them with a "routing-aware" B2BUA, which seems imminently  
doable.

The simplest approach might be a flag on the contact-value in a  
REGISTER request that indicates the thing being registered is a route,  
not a contact. Or a new header field could be used instead of  
Contact.  This does raise some interesting questions about route  
authorization/authentication, but there should be a lot of work we  
could fall back on here.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Sep 2009 20:41:02 -0400

Dean,

IIUC you have just reinvented Jonathan's loose routing registration 
proposal.

	Thanks,
	Paul

Dean Willis wrote:
>> Just to be clear, I do not have a specific requirement for finding the 
>> freephone number. I was merely pointing out that it seems very 
> retargeting). Oddly enough, this solution also preserves URI parameters 
> of all sorts . . .
> 
> is straightforward. If the next-hop URL is a "contact", we use RFC 3261 
> contact-routing procedures, replacing the request-URI with the 
> registered contact. If however the next-hop URL is a "route", we use RFC 
> 3261 loose-route procedures and push the URL onto the route stack and 
> ship out the request with an unmodified request URI. Net result, the 
> request is delivered to the next hop with an unmodified URL, ostensibly 
> including the freephone number.
> 
> If the next hop is terminal (the UAS), it of course needs to be able to 
> recognize the freephone number as belonging to it, but that seems to be 
> a requirement of all the things that require looking for a freephone 
> number in the H_I stack anyhow. Handling freephone termination on legacy 
> contact-registering devices would require fronting them with a 
> "routing-aware" B2BUA, which seems imminently doable.
> 
> The simplest approach might be a flag on the contact-value in a REGISTER 
> request that indicates the thing being registered is a route, not a 
> contact. Or a new header field could be used instead of Contact.  This 
> does raise some interesting questions about route 
> authorization/authentication, but there should be a lot of work we could 
> fall back on here.
> 
> 
> -- 
> Dean
>

---

From: Dean Willis <[email-masked]>
Date: Mon, 28 Sep 2009 22:50:30 -0500

> IIUC you have just reinvented Jonathan's loose routing registration  

Well, I'm trying to take a slightly different approach to it,  
primarily by applying it to the wildcard registration problem. I think  
I've also eliminated all the guesswork on subcases, making proxy  
behavior arguably more deterministic than it might have been in  
Jonathan's original proposal. And the  questionable usage of Supported  
and Requires for negotiation is right out. There's also no need for  
confusing discussion of GRUU minting in the UA.

The cleanest approach, in my current humble opinion (IMCHO), is to add  
a new SIP method that registers a route (or maybe multiple routes)"  
instead of registering a contact. We might think of this as analogous  
to BGP UPDATE route advertisements. I propose the RUPDATE method name  
for SIP.

So, IIUC, I'd say "reprised" rather than "reinvented". But yeah, it  
owes a lot to JDR's work on ua-loose-route.

Any benefit we get in terms of parameter delivery, retention of URI's  
etc. is actually just side-effect from cleaning up the semantic model  
of message routing.

--
Dean