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

From: ksankar at cisco.com (Krishna Sankar (ksankar))
Date: Tue, 6 Jun 2006 08:38:44 -0700

Yep, works for me at higher level. Comments ...

> [3] For 1.0, UAs broadcast their network affiliation using IP
multicast.
<KS>
	We also need to add that discovery would be done thru IP
multicast. 
	Can we say we will leverage existing DNS mechanism -
specifically use the mDNS primitives for this ? That way we do not have
to work on another multicast format, port number and associated
mechanisms. 
	We also need to specify couple of DNS record types and
appropriate formats. May be we can leverage the currently available
record types and formats.

	Still prefer the URI
sip:<username>@<domainname>[?dht=<dhtinfo>]. May be we will say, the FQN
for fluffy at quinthar is actually
sip:fluffy at quinthar[<dhtname>[@<bootstrap>]]

	Should add some form of security mechanism - at least a key
substrate as a trust bootstrap and encryption as needed. May be TLS is
enough.
</KS>
> -----Original Message-----
> From: David Barrett [mailto:dbarrett at quinthar.com] 
> Sent: Monday, June 05, 2006 11:01 PM
> To: Cullen Jennings (fluffy)
> Cc: Krishna Sankar (ksankar); 'David A. Bryan'; 
> p2p-sip at cs.columbia.edu
> Subject: RE: [p2p-sip] What are we doing, question 2
> 
> 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
> 
> > -----Original Message-----
> > From: Cullen Jennings [mailto:fluffy at cisco.com]
> > Sent: Monday, June 05, 2006 5:36 PM
> > To: David Barrett
> > Cc: 'Krishna Sankar (ksankar)'; 'David A. Bryan'; 
> > p2p-sip at cs.columbia.edu
> > Subject: Re: [p2p-sip] What are we doing, question 2
> > 
> > 
> > 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.
> > 
> > 
> > On Jun 5, 2006, at 3:32 PM, David Barrett wrote:
> > 
> > > 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.
> > >
> > >> -----Original Message-----
> > >> From: Krishna Sankar (ksankar) [mailto:ksankar at cisco.com]
> > >> Sent: Monday, June 05, 2006 10:22 AM
> > >> To: David A. Bryan
> > >> Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu
> > >> Subject: RE: [p2p-sip] What are we doing, question 2
> > >>
> > >> 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
> > >>>>>
> > >>>>
> > >>>
> > >
> > > _______________________________________________
> > > 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: Tue, 6 Jun 2006 10:26:46 -0700

Cool.  So if this story is used as the scope for P2PSIP v1.0, it means we're
targeting the following definitions and use cases:

P2PSIP v1.0 Scope
- A "P2PSIP proxy" is constructed by UAs using P2P techniques
	. P2PSIP v1.0 supports one type of P2PSIP proxy, based on a DHT
	. Future versions of P2PSIP will support non-DHT proxies

- A "P2PSIP UA" is capable of:
	. Creating a new P2PSIP proxy and assigning it a name
	. Registering itself with a named P2PSIP proxy
	. Advertising its named P2PSIP proxies to neighboring peers
		o P2PSIP v1.0 supports IP multicast broadcasts
		o Future versions will support other broadcast techniques
	. Discovering named P2PSIP proxy advertisements from neighboring
peers
	. Joining named P2PSIP proxies
	. Resolving "sip:" addresses to P2PSIP UAs using P2PSIP proxies

And really, that's about it.  I'd say that future versions include:

P2PSIP v2.0+ Scope
- A "P2PSIP Gateway" interfaces between P2PSIP proxies and CS SIP UAs
	. This is what lets CS UAs contact P2PSIP UAs

- A "P2PSIP Bootstrapping Server" joins and advertises P2PSIP proxies
	. This is what prevents P2PSIP proxies going "dark"
	. This also helps rendezvous P2PSIP UAs outside advertisement range

- P2PSIP UAs look for both P2P and CS proxies for each "sip:" address
	. This is what lets P2PSIP UAs contact CS UAs

- All P2PSIP components incorporate secure authentication, TLS, and so on

- Variants of P2PSIP proxies using other DHTs (or other P2P algorithms)

- Variants of P2PSIP proxy advertisement using zeroConf, mDNS, etc.

Basically, I propose we circle the wagons *very* tightly around a very small
set of functionality (the smallest possible set that satisfies our use
cases), and focus on that exclusively for P2PSIP v1.0.  Once that has been
nailed down, then we open up the floor to discuss bigger topics.

Does this sound like a reasonable plan?  Do you endorse us following it?

-david

> Sent: Tuesday, June 06, 2006 8:39 AM
> To: David Barrett; Cullen Jennings (fluffy)
> Cc: David A. Bryan; p2p-sip at cs.columbia.edu

---

From: mbhatia at 3clogic.com (Medhavi Bhatia)
Date: Tue, 6 Jun 2006 19:15:16 -0400

Hi Dave,

Maybe I am chiming in a bit late, but your wording sounds a little
confusing. I think at the last IETF meeting we discussed the need for
standardizing the protocol between SIP UAs and any DHT for the lookup
and registration etc. Does that fit into one of your scope items
below?

-Medhavi.

---

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 6 Jun 2006 22:49:15 -0700

Yes, my vision statement isn't intended to conflict with that, but rather
illustrate the v1.0 scope from another perspective (through high-level
end-user use cases).

In other words, "standardizing the protocol between SIP UAs and any DHT for
the lookup and registration" is one of many things that will need doing in
order to satisfy my listed use cases.

Does this answer your question?

-david

> From: medhavib at gmail.com [mailto:medhavib at gmail.com] On Behalf Of Medhavi
> Bhatia
> Sent: Tuesday, June 06, 2006 4:15 PM
> To: David Barrett
> Cc: Krishna Sankar (ksankar); Cullen Jennings (fluffy); p2p-
> sip at cs.columbia.edu; David A. Bryan

---

From: mbhatia at 3clogic.com (Medhavi Bhatia)
Date: Wed, 7 Jun 2006 09:45:45 -0400

Hi Dave,

Another set of clarifications:

Why do we need the notion of a P2P SIP Proxy if we all agree the SIP
UA to DHT protocol exists? The SIP Proxies can exist and continue to
be used as it is in the SIP protocol specs.

Another one: Why do we need a P2PSIP UA? Do you propose to change the
SIP state machines at the UA or any of the ways SIP will be used
between UAs in the P2P world? The only thing I forsee is the tinkering
of RFC 3263.

-Medhavi.

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Wed, 07 Jun 2006 11:03:51 -0400

My comments are inline.

> 	. Future versions of P2PSIP will support non-DHT proxies
Is a P2PSIP proxy a (logical) node or just a service realized using the DHT?

> 	. Advertising its named P2PSIP proxies to neighboring peers
Why should P2PSIP UAs advertise its P2PSIP proxies?
> 		o P2PSIP v1.0 supports IP multicast broadcasts
If we assume IP multicast or broadcast is available among all the peers,
we don't need DHT or any P2P network.
> And really, that's about it.  I'd say that future versions include:

Here is what I think.
- Nodes with P2PSIP UA and possibly other nodes form a P2P network.
     . Some of them form a DHT and the rest establish associations with
those participating in the DHT.
     . The DHT does not require IP multicast or broadcast.
- There is at least one SIP Proxy in the P2P network (that is called
P2PSIP Proxy), which is registered in the DNS for the domain.
     . The P2PSIP proxy may be one of user devices or a dedicated device
setup by some authority of the domain. Registration of the proxy with
the DNS requires authorization.
- A P2PSIP UA constructs a location record and places it in the P2P
network. (This is equivalent to registration and/or advertisement.)
- The P2PSIP UAC (the calling UA) resolves "sip:" address into the IP
address (and port number) by retrieving the location record of the
P2PSIP UAS (the called UA) in the P2P network.
     . If the UAC is a node participating in the DHT, the node initiates
the DHT GET procedure.
     . If the UAC is not in the DHT, the node sends the lookup request
to its associated node in the DHT that initiates the DHT GET procedure.
- Once the address resolution is done, the rest of the call setup
procedure follows RFC3261.
- If the caller is in the remote domain or a C/S SIP UA, it follows
RFC3261 and 3263 to locate the SIP Proxy of the domain the UAS belongs.
- A P2PSIP Proxy receives an INVITE message destined to a UA in the
local domain, it resolves the destination "sip:" address from the P2P
network. After that, it follows RFC3261.

Is this close to your story?
Thanks.

Eunsoo

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Wed, 7 Jun 2006 10:17:00 -0700

some q's inline. 3q!

> P2PSIP Proxy), which is registered in the DNS for the domain.

[pp]: shouldn't hardcoded ip should be more recommended than dns to minimize
p2psip's dependency on server?

> network. (This is equivalent to registration and/or advertisement.)

[pp]: the registration/advertisement between on-sn and sn-sn seems likely
different. could you elaborate the details of p2psip in this aspect?

> procedure follows RFC3261.

[pp]: are you sure that the thing is then as so simple as the session
initiation in c/s environment where there is usually sbc or special
proxy/b2bua to manipulate firewall penetration, not to mention most desired
supplementary call features?

peter

---

From: bryan at ethernot.org (David A. Bryan)
Date: Wed, 7 Jun 2006 13:28:12 -0400

At risk of having one David answer on behalf of another ;)

My opinion is that we will need to avail ourselves of the ICE-family
tools to do NAT traversal since as you point out, we are not likely to
have SBCs in the picture. The odds are that using the ICE stuff will
be far more critical for P2P systems than CS where things like SBCs
can be used as band aids for the problem.

As far as features, a few comments. Some I think will work quite
transparently with P2PSIP -- transfers of various types, redirects on
busy/unavailable, call forward. Some others are likely to be far more
challenging -- obviously VM being one -- but features like this aren't
always specified in the protocols anyway -- look at SIP where many are
not specified directly in the protocol. Forking (so multiple
appearance) is another that will be interesting and I can imagine may
need to be treated differently in a P2P than CS scenario.

In my vision for this, if a feature works as is or can be made to work
with essentially no changes, P2P should not reinvent the wheel. Only
do that for features that are truly dependent on servers in
traditional CS SIP.

David Bryan

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Wed, 07 Jun 2006 14:10:24 -0400

My comments are inline.

> do that for features that are truly dependent on servers in
I agree to the above answer.
When I said "follows RFC3261", I meant basic call features that can be
implemented with RFC3261.

>> p2psip's dependency on server?

Hardcoding or manual configuration is always possible and I guess it
should be used or supported as the base method.
But I think it is really recommended to register the SIP Proxy in the
DNS so that UAs in the remote domain can find the SIP Proxy as well.
If you want to run an isolated P2PSIP network, you don't need the SIP
Proxy to be registered in the DNS.

>> different. could you elaborate the details of p2psip in this aspect?
ON-SN interaction is basically exchange of requests replies for GET/PUT.
SN-SN interaction deals with GET/PUT requests and replies, JOIN/LEAVE
requests and replies, and routing of all those messages.
I think GET and PUT just deal with keys (or target (resource)record
names as just byte strings) and values no matter whether the message
exchange occur and they are independent of the semantics of the values.

Registration/advertisement is nothing but the PUT operation for the user
location record. Therefore, except the possible syntax difference
between GET/PUT messages on ON-SN and SN-SN, the PUT messages or the
registration/advertisement are almost the same on both ON-SN and SN-SN.

Did I answer your question?

Thanks.

Eunsoo

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Wed, 7 Jun 2006 11:14:27 -0700

3q for the comfort.

----- Original Message -----
From: "David A. Bryan" <bryan at ethernot.org>
To: "Peter Pan" <huang-ming.pan at comcast.net>
Cc: "Eunsoo Shim" <eunsoo at research.panasonic.com>; "David Barrett"
<dbarrett at quinthar.com>; <p2p-sip at cs.columbia.edu>
Sent: Wednesday, June 07, 2006 10:28 AM
Subject: Re: [p2p-sip] What are we doing, question 2

> always specified in the protocols anyway -- look at SIP where many are

[pp]: Yes or no, imo.

The reasons why sip seemingly cover all scenarios so far without twisting
itself are, among others:

* There are trucks of "informative" drafts and RFCs to supplement RFC3261;
these informative specs are helpful but also bring "informative"
incompatibilities among existing SIP systems or service networks.
* Usually it is the "feature" servers (like those b2bua based call managers
by broadsoft/sylantro/avaya/nortel/...) in c/s softswitch systems that
bridge the incompleteness of rfc3261 by means of the primitives defined in
rfc3261 and other RFCs. In p2psip territory, there seems no more such
"manipulators". The manipulation will likely be done by p2psip nodes alone.

> do that for features that are truly dependent on servers in
[pp]: Do you have kindly something persuasive other than vision and promise
which can ease this long-term concern (backward compitibility of incremental
p2psip protocol) of mine, for example, technical paper or open-source
reference implementation (that has been able to add most well-known call
features without changing architecture/protocol/implementation too much)? I
will really appreciate it since i've been always believing that p2psip is
not initiated for basic session initiation only.

peter

---

From: dbarrett at quinthar.com (David Barrett)
Date: Wed, 7 Jun 2006 11:44:27 -0700

> From: Eunsoo Shim

Service realized using the DHT.  I believe Dean's document called it an
"overlay"; that's a better name.

> we don't need DHT or any P2P network.

Clearly.  I've proposed multicast as an overlay advertisement scheme just
for v1.0.  Bootstrapping servers and DNS would be other ways to learn of and
connect to overlays, but to minimize scope I've left them out of v1.0.

Basically, I feel the goal of P2PSIP is to work without *any* servers
(including DNS), thus v1.0 scope reflects this.  Naturally if servers are
available (DNS, bootstrapping, etc) it'll use those too, but those are
essentially optimizations (and thus v2.0 and beyond).

> ...

I largely agree with you, but I disagree in the timing.

I'm proposing we first build a solution that works on the worst-case network
(two laptops in the middle of the desert connected by a crossover cable),
and then improve upon that.  This is reflected in my proposal for v1.0
scope.

I believe you present great options for "eventually", but it seems like a
big bite to swallow all at once.

-david

---

From: dbarrett at quinthar.com (David Barrett)
Date: Wed, 7 Jun 2006 11:55:05 -0700

> From: medhavib at gmail.com
> 
> Hi Dave,
> 

I think this comes back to the question of whether the P2PSIP proxy (or, I
prefer Dean's terminology, the P2PSIP overlay network) is built using
extensions to SIP or using a new protocol.  I'm proposing the former (we
build the overlay using extensions to SIP messages between UAs).

> between UAs in the P2P world? The only thing I forsee is the tinkering

In short, yes, I propose the state machine and messages of a P2PSIP UA will
be different than those of a normal SIP UA.  Clearly, the goal is to keep
them as similar as possible, but they do different things and thus will need
to differ:

- A P2PSIP UA will have logic and messages to resolve "sip:" addresses using
a DHT.

- A traditional SIP UA will have messages and logic to resolve "sip:"
addresses using a client-server SIP proxy.

The long-term goal will to have UAs capable of speaking both languages
(using both a P2PSIP overlay network as well as traditional client-server
SIP proxies), but I'm proposing this is not tackled in v1.0.

-david

---

From: matthew at matthew.at (Matthew Kaufman)
Date: Wed, 7 Jun 2006 12:37:23 -0700 (PDT)

> and then improve upon that.  This is reflected in my proposal for v1.0

That isn't "worst case" at all, since they can easily find one another
via link-level broadcast or multicast.

There are clearly two orthogonal problems that need solving, but which are
solved in different ways:
  (and I know this has been brought up on the list before, but calling
   the above the "worst case" seems to demonstrate that the orthogonality
   isn't fully clear)

  1) Everyone who wants to call each other is on a network that is
     not attached to the larger Internet (so, for instance, DNS roots
     are unavailable and PKI must be local)

     This has subproblems:
     1a) Those people are all on a network that has link-level connectivity
         sufficient that multicast or broadcast can be used to find neighbors
         (easy)
     1b) Those people are on a routed WAN that has inter-node connectivity
         incapable of supporting multicast (hard, may only be solvable with
         manual entry of rendezvous node(s) or neighbor(s))

  2) Everyone who wants to call each other is on a network that *is*
     attached to the larger Internet, but for {political, economic, other}
     reasons do not want to use SIP proxies run by other parties or run
     their own individual SIP proxies associated with their own DNS name(s).

     An obvious driver for this is the case where you want to run a network
     with tens of millions of registered users and millions of simultaneous
     online users, but you don't want to deploy the SIP proxy infrastructure
     that would be required.

The "worst case" for part 1 is probably the "1b" scenario. The "worst case"
for part 2 is probably when an attacker decides to see if they can corrupt
your (published protocol) distributed lookup system, unless scaling or churn
limits get you first.

Matthew Kaufman
matthew at matthew.at
http://www.amicima.com