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

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Tue, 06 Jun 2006 07:10:50 -0400

David Barrett wrote:

>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
>
>  
>
Yes. The two tasks can be done by different nodes, though. Logically
each can be called 'Bootstrap Server' and 'P2P SIP Proxy (or P2P CS SIP
Gateway)' respectively.

>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.
>
>  
>
That is right.

>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.)
>
>  
>
Bootstrapping can be done in many ways. As you said below, multicast
based search is one way even though it works only in limited
environments. Therefore, it is up to the deployment scenario whether a
persistent bootstrap server will be installed.

The P2P SIP Proxy (or P2P CS SIP Gateway) is necessary if there is need
to support session establishment with non-P2P SIP UAs or UAs in the
remote domains. If you want to run an isolated P2PSIP network, you don't
need it.

>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?
>
>  
>
I think so.

Thanks.

Eunsoo

>  
>
>>-----Original Message-----
>>From: Eunsoo Shim [mailto:eunsoo at research.panasonic.com]
>>Sent: Monday, June 05, 2006 4:01 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
>>
>>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
>>
>>
>>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: huang-ming.pan at comcast.net (Peter Pan)
Date: Tue, 6 Jun 2006 08:39:24 -0700

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

Me am afraid NOT RIGHT, unless validity of at least one SN (or DHT proxy) in
cached SN list can be guaranteed (which usually cannot be, unless networks
install persist fault-tolerant SNs).

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Tue, 06 Jun 2006 11:46:37 -0400

> install persist fault-tolerant SNs).

I think the above was based on assumption that some of the neighbors are
online.
If the neighbors in the DHT routing table and the peers in the cache are
all offline, now the peer is back to the point where it needs to do
bootstrapping from scratch. If the peer needs to talk to the Bootstrap
Server for bootstrapping, it got to do so.
Thanks.

Eunsoo

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Tue, 6 Jun 2006 08:50:37 -0700

> Server for bootstrapping, it got to do so.

In quality service networks for commercial purpose, the assumption seems
risky :)