Subject: Re: [P2PSIP] More thoughts on clients, peers, and services, and service routing

From: "Bruce Lowekamp" <[email-masked]>
Date: Sat, 1 Dec 2007 07:08:39 -0500

Dean,

On Nov 30, 2007 9:27 PM, Dean Willis <[email-masked]> wrote:
> These are the kinds of things that can happen when we start thinking
> of the overlay as a distributed database, not just as a distributed
> proxy-registrar.

I was with you until I got to this last paragraph.

What I was thinking is that some of the current proposals (I will
speak only for reload since it's the one I'm most familiar with) offer
the ability to implement any of these scenarios you propose, but don't
describe how it would be accomplished.  If we're going to be writing
drafts that describe fairly generic distributed databases, I think we
need to spend more time writing how to implement interesting sip
functionality on top of those systems.  I think at the heart of your
email is that we're not doing that right now.

Take reload.  It offers get/put with usage-defined types and security.
  It supports tunneling application data over the overlay as well as
serving as an intermediary for ICE negotiation and TURN server
location.

These are basic tools that I think are capable of implementing any of
the scenarios you propose.  I haven't thought much about "how would
you locate generic routers using reload" separate from managing
overlay routing, but once you have that routing vector, all you need
is a storage format for it.

For the generic proxy support, the user has to locate a proxy willing
to provide this service.  We can define as part of the usage that all
peers must provide this service, or we can allow the UA to select the
proxy it wishes to use.  I can think of use cases for both scenarios.

Time for my flight, but I think the important point is that we need to
start working out more application details of how these will work
within the proposed frameworks.

Bruce

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 1 Dec 2007 11:01:15 -0800

Dean, I'm following up to this e-mail, but thanks for sending the first one, 
too.

It's very helpful, and goes to the core of the routing discussion. I'll try 
to assimilate it as part of my slides (he said on Saturday :-).

We still haven't talked about use cases/application scenarios for a while 
now, and until we have that conversation, people who are assuming that 
mid-point policy enforcement will happen will not understand people who 
assume that mid-point policy enforcement won't happen, or even that it's not 
possible.

... and this isn't even an attribute in the current application scenarios 
draft. My bad. Maybe it could be, by the end of the week.

I don't see how to move forward here as long as proposals don't have to 
solve the same problem. Picking a direction by voting ("consensing"?) 
proposals off the island isn't likely to be optimal.

Thanks,

Spencer

> On Nov 30, 2007, at 5:00 PM, Paul Kyzivat wrote:
>
>> Dean,
>>
>> Very interesting stuff you wrote below.
>
> Thanks. I think "interesting" is a good adjective. Far more polite  than 
> "deranged", which probably came to mind for at least a few readers.
>
>>
>> A related question:
>>
>> in a regular sip network, UAs often "hide behind" a proxy - the  proxy 
>> acts as a screening device. It also acts as a policy agent  for selecting 
>> which of possibly several UAs for the AOR gets a  call. (It may also do 
>> callerprefs but typically callee policy takes  precedence.)
>>
>> Is any of this behavior in scope for P2PSIP? Is it part of the  finding 
>> function, the routing function, or some new function?
>>
>
> I've been pondering that question for some time.
>
> Either we lose much of the functionality built into SIP proxies  (which 
> includes what you list above along with, to my mind, the far  more 
> important function of hiding the UA's IP address unless proxy  policy lets 
> the request through), or we have to find a new way to  provide those 
> functions.
>
> I think this could take two forms, one novel, one conventional.
>
> In the conventional approach, the "peer" that would be found using a 
> "get" on a AOR resource is a SIP proxy, and once it gets a SIP  request, 
> it applies the usual policy decisions before passing the  request on to 
> the end UA. This "passing on" could be done using  conventional SIP, or it 
> could be done using the overlay. What makes  it work is the same sort of 
> indirection that maps AOR to Contact to  User. We'd just introduce an 
> intermediary resource ID. In effect,  Alice might insert her two phones 
> "[email-masked]" and  "[email-masked]" into the overlay, and her 
> proxy peer might  insert "[email-masked]" and be configured with a 
> policy table that  applies "contact routing" towards the phones. We can 
> even think of  using a SIP REGISTER request, routed over the overlay, to 
> inform the  proxy peer about the downstream bindings. Perhaps there is 
> even a way  to apply CPL in this sort of model.
>
> A more novel approach would be to put the traditional "proxy policy" 
> functions into the overlay.  One approach would be to have a "policy 
> language", and for each AOR, put a policy resource into the overlay. 
> Before sending a message, a peer would first do a "get" on the policy 
> resource, then interpret the policy resource before dispatching the 
> request. For example, the policy resource for "[email-masked]"  might 
> indicate that she's busy next week and all calls should be  retargeted to 
> "[email-masked]". Alice's various devices  (assuming she has 
> more than one) might achieve the effect of SIP  contact-registration by 
> amending Alice's policy resource to add  themselves to the policy.
>
>
> I think the current models rather naively assume "one AOR, one  device" 
> and that any policy enforcement can be done in the  terminating device. 
> There's probably an underlying assumption that  any more complex policy 
> gets handled by something analogous to a  B2BUA, but I don't think it 
> really has to work that way. Indeed, I  expect to see all sorts of 
> policy-driven indirection models working  their way into the overlay once 
> we get the basic functions sorted  out. But that does raise the question 
> of the system being more  effective if we  build these functions in up 
> front.
>
> Here's a nifty use case: Let's say Alice only wants Bob and Charlie  to be 
> able to deduce her location from the overlay. The resource 
> "[email-masked]" might, instead of returning a Contact, instead  return 
> only a policy object. That policy object might contain  sections encrypted 
> with Bob and Charlie's public keys. Each section,  when decrypted, would 
> provide a retargeting to an anonymous resource  ID that Alice minted for 
> temporary use. Bob "calls" alice, "getting"  the resource record 
> "[email-masked]", finds it to be a policy  object that has a section 
> keyed for him, decrypts it, finds that it  contains instructions to 
> retarget to another resource, does a  "connect" on that resource, and is 
> connected to Alice's phone.
>
> These are the kinds of things that can happen when we start thinking  of 
> the overlay as a distributed database, not just as a distributed 
> proxy-registrar.
>
> --
> Dean
>
>
>
>

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 2 Dec 2007 07:44:13 -0800

On Nov 30, 2007, at 6:27 PM, Dean Willis wrote:

> Thanks. I think "interesting" is a good adjective. Far more polite  
> than "deranged", which probably came to mind for at least a few  
> readers.

Thanks - I understand better now what you meant.

---

From: <[email-masked]>
Date: Mon, 3 Dec 2007 07:59:36 +0200

Hi Dean,

In my opinion there is a room for both solutions, however I would opt
for the second one. The good thing about the first solution is that it
allows conventional SIP UAs to use resources of the overlay. The problem
with this approach is that it is limited to the current SIP model (with
its limitations), faces security challenges, and does not allow for
non-SIP applications.

Both solutions can be implemented with P2PP.

Marcin

>-----Original Message-----
>From: ext Dean Willis [mailto:[email-masked]] 
>Sent: 30 November, 2007 18:27
>To: Paul Kyzivat
>Cc: P2PSIP Mailing List
>Subject: Re: [P2PSIP] More thoughts on clients, peers, and 
>services,and service routing
>
>
>Thanks. I think "interesting" is a good adjective. Far more 
>polite than "deranged", which probably came to mind for at 
>least a few readers.
>
>>
>> A related question:
>>
>> in a regular sip network, UAs often "hide behind" a proxy - the  
>> proxy acts as a screening device. It also acts as a policy agent  
>> for selecting which of possibly several UAs for the AOR gets a  
>> call. (It may also do callerprefs but typically callee policy takes  
>> precedence.)
>>
>> Is any of this behavior in scope for P2PSIP? Is it part of the  
>> finding function, the routing function, or some new function?
>>
>
>Either we lose much of the functionality built into SIP proxies  
>(which includes what you list above along with, to my mind, the far  
>more important function of hiding the UA's IP address unless proxy  
>policy lets the request through), or we have to find a new way to  
>provide those functions.
>
>"get" on a AOR resource is a SIP proxy, and once it gets a SIP  
>request, it applies the usual policy decisions before passing the  
>request on to the end UA. This "passing on" could be done using  
>conventional SIP, or it could be done using the overlay. What makes  
>it work is the same sort of indirection that maps AOR to Contact to  
>User. We'd just introduce an intermediary resource ID. In effect,  
>Alice might insert her two phones "[email-masked]" and  
>"[email-masked]" into the overlay, and her proxy peer might  
>insert "[email-masked]" and be configured with a policy table that  
>applies "contact routing" towards the phones. We can even think of  
>using a SIP REGISTER request, routed over the overlay, to inform the  
>proxy peer about the downstream bindings. Perhaps there is even a way  
>to apply CPL in this sort of model.
>
>request. For example, the policy resource for "[email-masked]"  
>might indicate that she's busy next week and all calls should be  
>retargeted to "[email-masked]". Alice's various devices  
>(assuming she has more than one) might achieve the effect of SIP  
>contact-registration by amending Alice's policy resource to add  
>themselves to the policy.
>
>
>I think the current models rather naively assume "one AOR, one  
>device" and that any policy enforcement can be done in the  
>terminating device. There's probably an underlying assumption that  
>any more complex policy gets handled by something analogous to a  
>B2BUA, but I don't think it really has to work that way. Indeed, I  
>expect to see all sorts of policy-driven indirection models working  
>their way into the overlay once we get the basic functions sorted  
>out. But that does raise the question of the system being more  
>effective if we  build these functions in up front.
>
>Here's a nifty use case: Let's say Alice only wants Bob and Charlie  
>to be able to deduce her location from the overlay. The resource  
>"[email-masked]" might, instead of returning a Contact, instead  
>return only a policy object. That policy object might contain  
>sections encrypted with Bob and Charlie's public keys. Each section,  
>when decrypted, would provide a retargeting to an anonymous resource  
>ID that Alice minted for temporary use. Bob "calls" alice, "getting"  
>the resource record "[email-masked]", finds it to be a policy  
>object that has a section keyed for him, decrypts it, finds that it  
>contains instructions to retarget to another resource, does a  
>"connect" on that resource, and is connected to Alice's phone.
>