Subject: [p2p-sip] Draft: Requirements for SIP-basedPeer-to-PeerInternetTelephony

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Tue Nov 1 02:43:15 2005

Hi, Suresh,

Thanks for the information about draft-ford-behave-app-01.txt.
I realize we should closely look into BEHAVE WG documents about NAT traversal.

Please let us think about how to incorporate your suggestions on section 7.1.

Regards,

Eunsoo

----- Original Message -----
From: Pyda Srisuresh <[email-masked]>
Date: Monday, October 31, 2005 5:08 pm
Subject: RE: [p2p-sip] Draft: Requirements for SIP-based Peer-to-PeerInternetTelephony

> First off, good requirements set. Thanks for putting them 
> together. Couple of
> comemnts on the draft.
> 
> 1. I would suggest including the <draft-ford-behave-app-01.txt> 
> draft as a
> reference in the context of firewall/NAT traversal. The 
> recommendation in the
> draft about how P2P apps could adapt to traverse NATs would be 
> directlyrelevant here. Also talked in the draft are security 
> concerns with P2P NAT
> traversal.
> 
> 2. Usage Scenarios - Please expand on section 7.1 with a diagram - 
> specificallydescrbing a P2P SIP setup as opposed to a traditional 
> SIP. What
> servers/services are prevalent in traditional SIP setup vs a P2P 
> SIP setup.
> 
> Additional comments in line below.
> 
> regards,
> suresh
> 
> --- Salman Abdul Baset <[email-masked]> wrote:
> 
> > Thanks for your comments. Please see my comments inline:
> > 
> > > > 4.5.  NAT and Firewall Traversal
> > > >    R1.  The peer-to-peer system SHOULD distribute the 
> functionality of
> > > >    NAT and firewall traversal servers to the end-points.
> > >
> > > I don't see why this must be a requirement. Your other 
> requirements talk
> > > about being flexible on where services are located (i.e. 
> centralized or
> > > distributed). Given this flexibility, which I agree with, why 
> require> > that
> > > a certain service be distributed? Why not leave the choice up 
> to the
> > > builder of
> > > the particular P2P overlay network? If that builder wants to 
> provide a
> > > centralized NAT and Firewall Traversal scheme, why not let him?
> > 
> 
> [suresh] I too disagree with the requirement, but for a different 
> reason. I
> beleve, the requirement is that P2P nodes should be able to 
> traverese the
> FW/NAT devices enroute. Why should the functionality of 
> NAT/firewall traversal
> servers be distributed to the end-points? And, why is this a 
> requirement?
> I do not see why services required for P2P shoudl be mandated as 
> part of P2P
> end nodes.
> 
> > I agree that the choice should be left to the bundler of the P2P 
> overlay> network for deciding which services should be centralized 
> and which should
> > be distributed. However, at some point the P2P bundler will need 
> to decide
> > whether the overlay network it is building has degenerated into 
> a typical
> > SIP-based network and still being marketed as P2P:)
> > 
> 
> [suresh] I think, it woudl be a good idea to draw a picture to 
> contrast between
> a traditional SIP network and a P2P SIP network. Endpoint Identity 
> and location
> of P2P nodes (and the associated service) is the key distinction, 
> in my
> opinion. 
> 
> > > On the other hand, I would agree that the design should 
> SUPPORT making
> > > the NAT and
> > > Firewall Traversal distributable, but I think you have already 
> covered> > that in 4.1.
> > 
> > We think that distributed NAT and firewall traversal is one of 
> the key
> > motivations to build a P2P overlay, so we decided to keep it as 
> a seperate
> > requirement. 
> 
> [suresh] I agree, NAT and firewall traveral is a key requirement 
> for P2P
> overlay.
> 
> >              There are two requirements in this section. I think one
> > option is to delete R1 and keep R2 which says:
> > 
> > "A peer with NAT and firewall traversal capabilities SHOULD be 
> selected> such that it does not introduce significant delay 
> between the
> > communicating peers."
> > 
> 
> [suresh] The above requirement is disctinct from R1, in my 
> opinion. I woudl not
> suggest eliminating R1. R2 above is similar to Req-3 in
> <draft-ford-behave-app-01.txt>, which talks about design 
> guidelines for P2P
> applications in the context of NAT traversal.  
> 
> > The other option is to include this section as a subsection of 4.1.
> > 
> 
> [suresh] Please see my comment earlier about rewording R1.
> 
> > >
> > > > 5.4.1.  Centralized Lookup
> > > >    Value-added services such as reliable voicemail storage 
> can be
> > > >    provided by a central authority in a P2P network.  The system
> > > SHOULD
> > > >    allow the peers to efficiently locate the centralized service
> > > >    providers or resources.
> > >
> > > This is just a minor comment. The first sentence seems to 
> imply that
> > > voicemail
> > > is preferably implemented as a centralized service. I disagree 
> with that
> > > implication, and suggest that the first sentence be reworded 
> or simply
> > > removed.
> > >
> > > I DO agree with the requirement in the second sentence.
> > 
> > The sentence says '...reliable voicemail storage can be 
> provided...'. I
> > guess the 'can' should be changed to 'might'.
> > 
> 
> [suresh] That sounds good.
> 
> > 
> > > > 6.1.  Support for different DHTs
> > > >    Any protocol specification SHOULD be able to incorporate 
> different> > >    DHT algorithms based on the P2P service provider 
> requirements.> >
> > > Isn't this the same as requirement 4.3??
> > 
> > We wanted to emphasize that a 'P2P Protocol Spec' must support 
> multiple> DHTs. Since this requirement fell under 'Architecture' 
> and 'Protocol Spec
> > Requirements', we decided to keep it in both. I think cross-
> referencing> the sections will be helpful.
> > 
> > regards,
> > --
> > Salman Baset
> > 
> 
> regards,
> suresh
> 
> > 
> > >
> > > - Philip Matthews
> > >   Nimcat Networks (now a part of Avaya)
> > >
> > > PS. Please note that my e-mail address has recently changed to
> > >        [email-masked]
> > >     Mail sent to my old address ([email-masked]) will
> > >     be forwarded for a period, but will eventually be returned.
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [[email-masked]] On Behalf Of Salman Abdul Baset
> > > Sent: October 28, 2005 13:16
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject: [p2p-sip] Draft: Requirements for SIP-based Peer-to-Peer
> > > InternetTelephony
> > >
> > > We have attempted to compile the requirements for SIP-based 
> peer-to-peer
> > > Internet telephony in a draft. It is available at:
> > > http://www1.cs.columbia.edu/~salman/drafts/draft-baset-sipping-
> p2preq-00
> > > .txt
> > >
> > > Title: Requirements for SIP-based Peer-to-Peer Internet Telephony
> > > Abstract:
> > > This document defines requirements for designing peer-to-peer 
> voice,> > text, and real-time multimedia communication system 
> protocols.> >
> > > Comments are requested.
> > >
> > > Regards,
> > > Salman, Henning, Eunsoo, Kishore
> > > _______________________________________________
> > > p2p-sip mailing list
> > > [email-masked]
> > > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip
> > >
> > >
> > _______________________________________________
> > p2p-sip mailing list
> > [email-masked]
> > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip
> > 
> 
> 
> 
> _______________________________________________
> p2p-sip mailing list
> [email-masked]
> http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip
>