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

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

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: bryan at ethernot.org (David A. Bryan)
Date: Mon, 5 Jun 2006 13:08:47 -0400

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