Subject: [p2p-sip] What are we doing, question 2

From: ksankar at cisco.com (Krishna Sankar (ksankar))
Date: Mon, 5 Jun 2006 10:21:40 -0700

Agreed. If we, in-principle, see the need for the
p2psip:<username>[@<dhtname>@[<bootstrap>]], we can make it as harmless
as possible - a set of header elements or a set of URI parameter is an
excellent choice. 

I like header element better - something like :
Additional-Format:P2P
P2P-DHTName:<some name>,<some other name>,...
P2P-BootStrap:<some bootstrap stuff>,...

Cheers
<k/>

> -----Original Message-----
> From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On 
> Behalf Of David A. Bryan
> Sent: Monday, June 05, 2006 10:09 AM
> To: Krishna Sankar (ksankar)
> Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu
> Subject: Re: [p2p-sip] What are we doing, question 2
> 
> If we have a p2psip: address, what does a non-P2P SIP 
> endpoint do with it? On the otherhand, a regular sip: address 
> can go from a UA to a proxy that is more likely to be able to 
> do something useful (forward it to a p2p domain)? See the 
> draft Enrico and I did
> (draft-marocco-sipping-p2p-scenarios-00.html) for details.
> 
> We can use maybe use something else in the messages -- a URI 
> param or a header perhaps -- to distinguish P2P from regular 
> SIP where needed, but I think we should ensure that a URI is 
> as backward compliant as possible.
> 
> --David Bryan
> 
> On 6/5/06, Krishna Sankar (ksankar) <ksankar at cisco.com> wrote:
> > David,
> >
> >         You have a valid point making p2p-sip explicit for all than 
> > implicit in the UAs who understand it.
> >         a)      I mulled it over and do not see any other 
> way, as a 1.0
> > requirement. i.e. we do need a p2p-sip protocol designator 
> somewhere 
> > to make it explicit. But not necessarily in one's vcard.
> >         b)      We could make the client responsible for trying the
> > generic <sipAddress> and then p2p:<sipAddress>.
> >         c)      Going back to putting p2psip in one's 
> vcard, what does
> > "p2psip" in one's SIP address signify anyway ? Signifies 
> that one will 
> > be part of a p2psip as and when available ?
> >         d)      Isn't p2psip situational ? i.e. when one is 
> at home, may
> > be, one will be part of the p2psip provided by the service 
> provider or 
> > even the home network; but when one is at work, one becomes 
> part of a 
> > server based larger sip substrate.
> >                 What about an emergency worker who moves between 
> > different p2psip and sip networks ?
> >
> >                 What about a mobile worker who wanders from 
> Starbucks 
> > network to airport network to .. All might have different p2psip 
> > mechanisms or even a combination of p2psip and server based sip.
> >
> >         May be I got it all wrong (mice crunching cats are 
> the norm of 
> > the day than galloping stallions) - very possible ...
> > Cheers
> > <k/>
> >
> > > -----Original Message-----
> > > From: p2p-sip-bounces at cs.columbia.edu 
> > > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of 
> David Barrett
> > > Sent: Monday, June 05, 2006 8:58 AM
> > > To: 'David A. Bryan'; 'Henning Schulzrinne'
> > > Cc: p2p-sip at cs.columbia.edu
> > > Subject: Re: [p2p-sip] What are we doing, question 2
> > >
> > > Ok, I'll totally agree that it'd be nice to hide the details of 
> > > P2PSIP behind a standard "sip:" address (expressed or 
> implied).  I 
> > > just haven't envisioned how to accomplish this in 
> conjunction with 
> > > the other requirements, and I'm trying to avoid proposing what I 
> > > can't figure out how to build.
> > >
> > > The problem I see isn't one of technology, but usability issues 
> > > caused in the adoption period.  Clearly, P2PSIP isn't going to 
> > > happen overnight.
> > > There will be period of years where it is slowly rolled 
> out to SIP 
> > > UAs.  And during this period, I think it's important for a UA to 
> > > differentiate between invalid SIP addresses, and P2PSIP addresses 
> > > that it doesn't know how to handle.
> > >
> > > For example, let's assume I put my P2PSIP address on a 
> business card 
> > > as "sip:dbarrett at quinthar.com" (or just 
> "dbarrett at quinthar.com" with 
> > > the "sip:"
> > > implied).  A P2PSIP-aware UA might first look for a 
> traditional SIP 
> > > proxy at "quinthar.com" and then, not finding one, use some 
> > > DHT-based mechanism.  I love that idea.
> > >
> > > But a P2PSIP-unaware UA will just break.  It'll say the 
> address is 
> > > valid and supported, but broken.  I don't love this idea.
> > >
> > > Thus I'm proposing, at least at the start while P2PSIP is getting 
> > > its legs, we use "p2psip:<something>".  A P2PSIP-aware UA 
> will work, 
> > > and a P2PSIP-unaware UA can clearly say "I don't support this 
> > > address type".  The blame is placed on the UA (where it 
> should be), 
> > > rather than the address.
> > >
> > > Maybe in the future, once P2PSIP is more established, UAs would 
> > > automatically retry all failed "sip:<something>"
> > > addresses on some P2PSIP framework, and then the two 
> addresses would 
> > > converge down the road.
> > >
> > > But I'm not sure how we can start out converged without just 
> > > confusing the user and, ultimately, hurting the SIP 
> community as a 
> > > whole -- P2P and otherwise.
> > >
> > > Have I missed something?  Can you see a way to roll out 
> P2PSIP atop 
> > > a standard "sip:<something>" address without appearing totally 
> > > broken throughout the deployment period?
> > >
> > > -david
> > >
> > > > -----Original Message-----
> > > > From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On
> > > Behalf Of
> > > > David A. Bryan
> > > > Sent: Monday, June 05, 2006 7:29 AM
> > > > To: Henning Schulzrinne
> > > > Cc: David Barrett; p2p-sip at cs.columbia.edu
> > > > Subject: Re: [p2p-sip] What are we doing, question 2
> > > >
> > > > I would agree, and would add a subtly different 
> objection that a 
> > > > traditional SIP UA will be better able to interact with 
> a P2PSIP 
> > > > endpoint if we have a simple "sip:" or "sips:" (however that 
> > > > debate hashes out).
> > > >
> > > > David
> > > >
> > > > On 6/5/06, Henning Schulzrinne <hgs at cs.columbia.edu> wrote:
> > > > > > I'd prefer not to debate the specifics at this point --
> > > if we can
> > > > > > agree that there's some kind of "p2psip:<something>"
> > > address type,
> > > > > > I think that's as deep as we need to get agreement 
> on the big 
> > > > > > picture.
> > > > >
> > > > > I think this is a fundamentally bad idea. I shouldn't
> > > have to change
> > > > > my address (and business card) just because I'm changing
> > > some low-
> > > > > level technical detail of how signaling requests are
> > > routed. In any
> > > > > event, just like many web pages are simply listed as 
> > > > > www.something.com (instead of http://www.something.com), I 
> > > > > expect that many business cards and directories will simply 
> > > > > contain alice at something.com.
> > > > >
> > > > > It's the role of protocols to make these resolution details 
> > > > > transparent to the user. This isn't terribly 
> difficult in this 
> > > > > particular case.
> > > > >
> > > > > Henning
> > > > > _______________________________________________
> > > > > p2p-sip mailing list
> > > > > p2p-sip at cs.columbia.edu
> > > > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
> > > > >
> > >
> > > _______________________________________________
> > > p2p-sip mailing list
> > > p2p-sip at cs.columbia.edu
> > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
> > >
> >
>

---

From: dbarrett at quinthar.com (David Barrett)
Date: Mon, 5 Jun 2006 15:32:10 -0700

Again, I love the idea of having a single "sip:" address that "just works"
for both CS and P2P SIP.  Please help me understand your proposal better.

Will I be able to print my combined CS/P2P SIP address on a business card,
hand it to you, and have you type it into your SIP UA and get an expected
result (a valid connection, if it's P2PSIP aware, or a message saying
"unsupported address type" if not)?  If so, what might that address look
like?

I've proposed your business card might say:

	sip:<username>@<domainname>

Or

	p2psip:<username>[@<dhtinfo>]     [1]

If instead we only use the first format, how does a UA figure out which DHT
the address is registered with, and how does it connect to that DHT?  I can
imagine URI attributes:

	sip:<username>@<domainname>[?dht=<dhtinfo>]

And I think this is a great solution.  But I don't understand how a human
would input "header elements" to a UA.  Am I misunderstanding the proposal?

-david

[1] I've proposed <dhtinfo> is <dhtname>[@<bootstrap>], and that it's
optional (defaulting to some global DHT if unspecified).  But the precise
syntax is unimportant.  What is important is that the address contain
whatever information is necessary to connect to a given DHT. 

> From: Krishna Sankar (ksankar) [mailto:ksankar at cisco.com]
> Sent: Monday, June 05, 2006 10:22 AM
> To: David A. Bryan
> Subject: RE: [p2p-sip] What are we doing, question 2
>

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Mon, 05 Jun 2006 19:01:08 -0400

The domainname should be able to lead to the proper DHT.
If the domain is your local domain, it is done.
If the domain is a remote domain, DNS is used to find the remote
domain's proxy that is participating in the DHT of the domain and the
INVITE message is sent to the proxy.

This approach makes it transparent to the user whether the underling
location lookup is based on a central server (C/S SIP) or a DHT within
each domain (P2PSIP).

Thanks.

Eunsoo

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 5 Jun 2006 16:31:20 -0700

----- Original Message ----- 
From: "Eunsoo Shim" <eunsoo at research.panasonic.com>
To: "David Barrett" <dbarrett at quinthar.com>
Cc: <p2p-sip at cs.columbia.edu>; "'David A. Bryan'" <bryan at ethernot.org>
Sent: Monday, June 05, 2006 4:01 PM
Subject: Re: [p2p-sip] What are we doing, question 2

> INVITE message is sent to the proxy.

what if the remote domain is also p2p, ie. proxyless??

---

From: dbarrett at quinthar.com (David Barrett)
Date: Mon, 5 Jun 2006 17:10:00 -0700

Ah, thanks, I think that makes sense.  Correct me if I misunderstand, but
are you're proposing that every DHT have at least one persistent node that
does two tasks:

1) Helps P2PSIP-aware UAs join the DHT (ie, bootstrap)
2) Handles INVITE requests from P2PSIP-unaware UAs

Once you're a member of the DHT, then you needn't talk with DHT proxy node
ever again.  And if you can't or don't want to use the DHT, just send a
normal INVITE to the DHT proxy and it'll return as if it's a standard CS
proxy.

Is this right?  If so, I think I like it.

One problem is it means we're not totally decentralized, because every DHT
needs a persistent bootstrapping server.  (Though this neatly allows for any
number of DHTs to exist in parallel, and assuming "sip:dbarrett at 192.168.0.1"
is a valid address, then we can operate in environments without DNS.)

Pure decentralization could be hacked into this with some kind of
"pseudodomain" like "sip:dbarrett at quinthar.dht", and the UA might do (for
example) an IP multicast to find other nodes participating in the "quinthar"
DHT.  Clearly that would fail miserably for a P2PSIP-unaware UA, but that
strikes me as acceptable.

Anyway, am I understanding your proposal correctly?

-david

> From: Eunsoo Shim [mailto:eunsoo at research.panasonic.com]
> To: David Barrett
> Cc: 'Krishna Sankar (ksankar)'; 'David A. Bryan'; p2p-sip at cs.columbia.edu

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Mon, 5 Jun 2006 17:36:09 -0700

Some of the proposal so for have come up with ways to make sip:  
addresses work and make things interoperable with more traditional  
sip. Clearly having interoperate would be a nice property if  
possible. However, I am still lost on what we are trying to  
accomplish, much less what the solutions is or if it needs a  
different URL.

---

From: karstbj at yahoo.com (Karst Bjorgson)
Date: Mon, 5 Jun 2006 21:45:45 -0700 (PDT)

> accomplish, much less what the solutions is or if it

We seem to be oscillating between two different ideas,
that I would name "distributed proxy" and "cruise
ship".

In the "distributed proxy" scenario, the UA in a SIP
domain conspire to resolve names through a distributed
process, e.g. a DHT. The names are probably of the
form:
   sip:<user>@<subdomain>.<domain>
The "domain" is common to all UA participating in the
scheme. "User" and "subdomain" are used to identify
specific UA within that domain. The domain selects a
distribution method, e.g. a specific DHT technology.
The domain somehow provides a set of proxies for
communicating with CS-SIP.

In the "cruise ship" scenario, UA that happens to be
on an isolated network use a local discovery mechanism
to establish sessions, even though their respective
gateways are unreachable. They use the same URL they
would use in CS-SIP, e.g. "sip:user at example.com" or
"sip:karstbj at yahoo.com". P2P is a fallback mechanism.
The UA just happen to be at the same place, and are
not configured to use a specific technology. We need
to standardize a common discovery mechanism, either a
DHT or possibly something very simple like SDP.

In both cases, we want to use plain "sip:" URL. In the
"distributed proxy" scenario, use of plain "sip:" URL
allows for easy interconnect with CS-SIP. In the
"cruise ship" scenario, use of plain "sip:" URL allow
for reuse of existing names.

Of course, we could choose to only address one of
these two scenarios...

-- Karst

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: dbarrett at quinthar.com (David Barrett)
Date: Mon, 5 Jun 2006 22:43:25 -0700

Ah, interesting -- thanks for capturing this distinction:

- "distributed proxy" UAs construct and use a P2P SIP proxy, without any CS.
- "cruise ship" UAs use CS SIP proxies when on the internet, or P2P if not.

What other core ideas are floating around?  Can we define then and give them
names?

-david

> From: Karst Bjorgson [mailto:karstbj at yahoo.com]
> Sent: Monday, June 05, 2006 9:46 PM
> To: Cullen Jennings; David Barrett
> Cc: p2p-sip at cs.columbia.edu; 'David A. Bryan'

---

From: dbarrett at quinthar.com (David Barrett)
Date: Mon, 5 Jun 2006 23:00:48 -0700

Well, what I'm trying to accomplish is enunciate a vision for how the
product works for a user.  Once we agree upon what P2PSIP is supposed to do
for the user, then I think we can more easily discuss how to make that
happen.

With this in mind, here's an updated story for my vision of what a P2PSIP
1.0 UA does:

You and I each install a P2PSIP-enabled UA while sitting on the same LAN.  I
click the "Create a new network" button on my UA, and give it the name
"quinthar".  [1] It asks me what my name is on this network, and I say
"dbarrett". [2] Your UA detects this and lists "quinthar" as one of the
known networks, and "dbarrett at quinthar" as a known user. [3] You choose the
"quinthar" network and click "Join network", then specify that your name is
"fluffy". [4] On my UA, I see "fluffy at quinthar" is listed in as a known
user.  I double click on "fluffy at quinthar", and initiate a VoIP call. [5]

[1] For 1.0, anyone can create a network; later it might be tied to public
key encryption.
[2] For 1.0, anyone can choose any name when joining a network; later each
network might have an administrator.
[3] For 1.0, UAs broadcast their network affiliation using IP multicast.
Later there might be global network registries, special bootstrapping
servers, or even a global DHT set aside to publish networks.
[4] For 1.0, anyone can join any network they've discovered, or by entering
the IP:port of a node on the network.
[5] We've created identities, discovered each other, and initiated a SIP
call -- all without ever touching a single server.

Does this story basically capture the same product that you want to enable
with P2PSIP?  If not, can you follow the pattern above and lay out your own
story?

-david

> From: Cullen Jennings [mailto:fluffy at cisco.com]
> Sent: Monday, June 05, 2006 5:36 PM
> To: David Barrett

---

From: henry at pulver.com (Henry Sinnreich)
Date: Tue, 6 Jun 2006 08:02:00 -0500

>With this in mind, here's an updated story for my vision of what a P2PSIP

Excellent scenario, except it need to be on the same LAN, just on the
Internet.

Henry

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David Barrett
Sent: Tuesday, June 06, 2006 1:01 AM
To: 'Cullen Jennings'
Cc: p2p-sip at cs.columbia.edu; 'David A. Bryan'
Subject: Re: [p2p-sip] What are we doing, question 2

-david

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Tue, 20 Jun 2006 21:33:46 -0400

> "unsupported address type" if not)?  If so, what might that address  

David:

Here are two ways in which I see that this might work:

1) I happen to work for Avaya. If the entire Avaya phone system was  
converted to
     P2PSIP technology, then one or more of the peers could be  
elected to register
     themselves in DNS as proxy servers for resolving addresses of  
the form
     "sip:xxx at avaya.com". When they received an Invite, they could  
use PIPSIP
     mechanisms to resolve an AOR of the form "xxx at avaya.com" into a  
specific
     contact URI, and then forward the INVITE to that phone.
     In other words, those peers are acting as gateways between the  
internal Avaya
     network (assumed here to be a P2PSIP network) and the global CS- 
SIP network.

2) Say I got together with some friends to form a P2PSIP network, and  
say that we all
     had SIP AORs of the form  xxx at ourprovider.com. Then our little  
P2PSIP network
     could elect one or more peers to register all of our AORs with  
the Registrar of ourprovider.com
     Then an incoming call from the outside world to me would first  
come to the Registrar
     of myprovider.com (a classic CS Registrar), be forwarded to one  
of peers in our little
     P2PSIP network, and finally get forwarded to me.

Of course, you are probably saying "what if my friends use different  
service providers --
then what?" In this case, I think your P2PSIP network can be used for  
internal calls between
peers, but each of the UAs in the network must separately register  
with the Registrar for
its own domain. That is, each UA acts both as a P2PSIP UA and a CS- 
SIP UA.
Phone calls to other peers go through the P2PSIP network, but phone  
calls to/from the
outside do not.

If you and I have joined the same P2PSIP network, and (1) and (2) do  
not apply,
then can I call you using dbarrett at quinthar.com and have it go  
through the P2PSIP network?
That is a good question. I believe Henning and his students have  
investigated this a bit,
but I am not up on the details.

- Philip