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

From: threelions0916 at yahoo.com.cn (threelions)
Date: Wed Nov 2 22:40:51 2005

I noticed that section 7.1 mentioned "A global P2P telephony VoIP system which allows its users located in   different regions and countries to communicate with each other." ,but there was no suggestion on the infrastructure of gloable p2p voip system, In my opnion, a hierarchical p2p system must be built to achieve the goal of high scalability, for there may be millions of nodes in a global p2p voip system, and the heterogeneity of variant nodes determined the system must be hierarchical.

In a hierarchical system, it's very natural that NAT and Firewall Traversal could be distributed among the super nodes,because the super nodes can provide the more bandwidth、more cpu power and longer lifetime.

some other comments listed below.

regards
Michael Liu

----- Original Message ----- 
From: "Matthews, Philip (Philip)" <[email-masked]>
To: "Salman Abdul Baset" <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, October 29, 2005 6:35 AM
Subject: RE: [p2p-sip] Draft: Requirements for SIP-based Peer-to-PeerInternetTelephony

> [I am posting this to the P2P-SIP mailing list only (and not SIPPING),
> since it is my belief that that list provides the most appropriate
> discussion forum.]
> 
> I think this is a great start on the requirements discussion.
> My thanks to the authors for producing this.
> 
> Here are some quick comments. Hope to generate some more in-depth
> comments next week.
> 
> > 4.3.  DHT Changeability
> >    The protocol(s) for maintaining the peer-to-peer network SHOULD be
> >    flexible to accommodate different DHT algorithms.
> 
> I totally agree with this. From my limited investigation of the DHT
> world,
> I see things just changing too fast to have any hope that today's DHT
> will
> still be tomorrow's DHT of choice.
> 

I agree with that.it's very important. 

> 
> > 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?
> 
> As I see it, a centralized service is one that is located on just a
> small number
> of peers, while a distributed service is one that is located on a large
> number
> of peers. The same lookup scheme could be used for both, so an arbitrary
> peer doesn't
> really need to know whether a service is centralized or distributed. So
> why say that
> a certain service must be distributed?
> 
> 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.
> 

I think in the global p2p voip network, we must distribute the functionality of  NAT and firewall traversal servers to the super node, and in a local network it's prefered to distribute the functionality of NAT and firewall travesal server to the end nodes, but a centralized server can works well too.
as for the Emergency /ad-hoc scenario, functionality of NAT and firewall travesal must be distribute to the end nodes.

> 
> > 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.
> 
> 
> > 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??
> 
> 
> - 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]
> [mailto:[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
���������������������������������������b��j(�������������������������������������m���r�j)�ɨh��(���

---

From: srisuresh at yahoo.com (Pyda Srisuresh)
Date: Thu Nov 3 09:41:30 2005

Folks,

I agree with Michael that NAT traversal is a key requirement of P2P
telephony/voip. Prior to initiating data (media) transfer, end nodes must be
able to a) learn peer's endpoint identities, and b) determine the NAT traversal
technique that is appropriate for the pair of nodes.

Of these, item a) is a direct part of P2P SIP and item b) is not. Item b) is a
P2P NAT traversal inependent of the protocol used for discovering the peer and
its endpoints. However, I believe, both these items (P2P-SIP and P2P-NAT) ought
to be part of the proposed new WG charter (P2P VOIP ?) charter. 

Has anyone used ICE and/or TURN for NAT traversal in the context of P2P
telephony? If so, what sort of delays(i.e., latencies) were noticed in setting
up the data session? I ask this because P2P telephony is very sensitive to
latencies.

cheers,
suresh  

--- threelions <[email-masked]> wrote:

> I noticed that section 7.1 mentioned "A global P2P telephony VoIP system
> which allows its users located in   different regions and countries to
> communicate with each other." ,but there was no suggestion on the
> infrastructure of gloable p2p voip system, In my opnion, a hierarchical p2p
> system must be built to achieve the goal of high scalability, for there may
> be millions of nodes in a global p2p voip system, and the heterogeneity of
> variant nodes determined the system must be hierarchical.
> 
> In a hierarchical system, it's very natural that NAT and Firewall Traversal
> could be distributed among the super nodes,because the super nodes can
> provide the more bandwidth???more cpu power and longer lifetime.
> 
> To: "Salman Abdul Baset" <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>
> I think in the global p2p voip network, we must distribute the functionality
> of  NAT and firewall traversal servers to the super node, and in a local
> network it's prefered to distribute the functionality of NAT and firewall
> travesal server to the end nodes, but a centralized server can works well
> too.
> as for the Emergency /ad-hoc scenario, functionality of NAT and firewall
> travesal must be distribute to the end nodes.
> 
> > 
???????????????????????????????????????b??j(?????????????????????????????????????m???r?j)???h??(???

---

From: afisk at speedymail.org (Adam Fisk)
Date: Thu Nov 3 11:39:48 2005

I've used ICE and TURN for p2p SIP, although not specifically for 
telephony. This system is not yet widely deployed, though, so our 
architecture of basically just using available non-firewalled peers as 
SIP proxies and as TURN servers has not been tested as thoroughly as 
would be nice. I don't see the latencies as being particularly crucial, 
though, simply because you're not dealing with much data in the call setup.

The TURN case for actual media transfer is the tough one. One option 
would be to incorporate locality optimizations such as those that the 
"closestnode" folks implement at:

http://www.closestnode.com/

As far as I understand it, this system works specifically in a p2p 
context. It might be interesting to leave room for enhancements that 
would allow nodes to choose nodes closest to them on the network using a 
system like this. This could easily result in media sessions that 
perform better than typical SIP scenarios because you can use more 
optimized network routes, albeit more bandwidth-limited ones in most cases.

Of course, the TURN for media transfer case should be avoided at all 
costs, but it's necessary as a fall back. That's really the only case 
where I see the network latencies being a serious concern, unless a pair 
of nodes get unlucky and are using sluggish proxies from opposite sides 
of the globe. Might be worth taking some preventative steps against this.

Along these lines, though, clearly each node should implement STUN on 
the both the client and the server side. They should probably implement 
STUN for TCP (STUNT) as well, although that's not standardized. It is 
really necessary for TCP nat traversal, though, so should be implemented.

I would imagine that all non-firewalled nodes would act as SIP proxies, 
TURN, and STUN servers, but you guys have probably already discussed 
that. I think UPnP is also pretty crucial here to make as many nodes as 
possible available as "non-firewalled". In fact, I think there are few 
enough non-firewalled nodes out there that it might be necessary to have 
UPnP support at something like SHOULD strength for a system like this to 
work in the real world. I have no experience authoring RFCs, though, so 
I'll let others decide issues like that.

This is getting lengthy, but I'd also like to make a pitch to stay true 
to SIPs roots as a generalized system that's not specific to telephony. 
Implementing the TCP side of life is more important in this context, for 
example.

-Adam

Pyda Srisuresh wrote:

>>provide the more bandwidth、more cpu power and longer lifetime.
>>