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

From: fwmiller at cornfed.com ([email-masked])
Date: Mon, 5 Jun 2006 13:20:21 -0500

While the arguments for some explicitness may be enticing, I for one would argue for as complete transparency as possbile.  For example, we should strive have no modifications to session establishment messaging if possible.

I would propose the model be that we just rely on the ability of a UAC to talk directly to a UAS and have the registrations and presence information associated with a UA "trick" the UAC into talking directly to the UAS.  What I mean is, you register your UA as normally as possible (i.e. minimal changes to the REGISTER messages and then as new headers only so they are transparent).  To find another UA, you query using existing presence mechanisms (i.e. SUB/NOT with PIDF and/or XCAP again with minimal changes to these messages as possible).  The actual session establishment is then no different than existing SIP, right down to the UAS challenging the UAC for authentication if the UAS thinks that is necessary.

In this approach, the P2P infrastructure just looks like a SIP registrar and presence servers to the UAs which maximizes both backward compatibility and flexibility in the implementation of the P2P infrastructure.

FM

------------------------------------------------
On Mon, 5 Jun 2006 10:03:20 -0700, "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
>