Last week, there were some new I-Ds on p2p-sip.
draft-matthews-p2psip-nats-and-overlays-00.txt
The draft analyzes various issues with NAT in the context of P2P-SIP and presents some important conclusions: (1) partial mesh of peers is more suited than ring or full mesh connections, for example; (2) connections can remain mostly static for maintenance of p2p; (3) structured p2p is more suited because of bounded connection count; (4) symmetric P2P (such as Kademlia?) is more suited because the connections across NAT are bidirectional; and (5) use of superpeers where all peers behind a common NAT can elect a small number of superpeers which handle connections across the NAT. The basic idea is to understand the NAT limitations such as number of pinholes allowed and timeout, and apply these for a deployable architecture.
draft-shim-sipping-p2p-arch-00.txt
The basic idea is to use the SIP-using-P2P architecture. There is some overlap with my 'external DHT' technical report. Some points of contentions are: the draft proposes P2P lookup first, and then fall back to DNS (RFC3263) which has a negative effect on performance since P2P lookup is slower. The format of the record can reuse the SIP Contact header instead of specifying individual terms such as TCP80, UDP5060, etc. The login server is clearly undesirable. But the draft is a good starting point. We will need more maturity in areas of security, authentication, and data format.
draft-mayrhofer-enum-domainkeys-00.txt
It proposes to use telephone numbers instead of email like user@domain format because one can validate that the number owner actually owns the telephone. The main problem is that phone numbers are too rigid and tied to physical port or line, thus we cannot have identifiers for virtual users or devices, e.g., sip:lamp@cs.columbia.edu belongs to an electric X10 controlled lamp in our lab. Secondly, phone numbers are hard to remember, thus needs address book. Thus it doesn't make much difference whether we use phone number or email as long as we know the remote's public key. The main problem to be solved is the distribution of public key in p2p. A certificate-based approach can be used instead.
draft-quittek-p2p-sip-middlebox-00.txt
It tries to list various requirements for NAT traversal in P2P-SIP. Not much new value. Ignores some of the existing NAT traversal schemes such as ICE.
In conclusion, there are still a lot of open issues in P2P-SIP, most notably in security, authentication and NAT/firewall traversal. Any solution for P2P-SIP must reuse the SIP's NAT traversal schemes such as ICE. There is a new version of best practices draft for NAT traversal in SIP.
Articles on technology, Internet, Protocols, Web, Open Source, VoIP, P2P, SIP, RTMP and WebRTC.
Thunderbird as a deployment vehicle
One of the reasons for success of Skype is that they already had a deployment vehicle in the form of KaZaA file sharing network. I believe that for mass deployment of any P2P VoIP tool including open standard based P2P-SIP we need free software availability and a deployment vehicle.
Deployment vehicle is just a mechanism or tool that already exists and is widely used, e.g., tools for email, web, file sharing, or something more basic as Windows OS. For example, someone can add P2P-SIP support in popular email clients such as Microsoft Outlook Express or Mozilla Thunderbird. The latter is easier since it is open source.
Project description: the Thunderbird client can be extended to also serve as a (peer-to-peer) voice and IM client. IM buddies would appear in the Thunderbird address book, allowing to display buddies and their online status. IM transcripts might be saved and searched in the same way that messages are saved. This work can leverage a SIP project, http://www.croczilla.com/zap/, and might build on the Cockatoo project at http://cockatoo.mozdev.org.
One issue is that not many people use Thunderbird compared to Microsoft product (although I believe that will change in future). Alternatively, a web interface similar to Gmail and google-talk can be provided that can be easily accessed from any web browser. The challenge is to use P2P instead of central web server.
Deployment vehicle is just a mechanism or tool that already exists and is widely used, e.g., tools for email, web, file sharing, or something more basic as Windows OS. For example, someone can add P2P-SIP support in popular email clients such as Microsoft Outlook Express or Mozilla Thunderbird. The latter is easier since it is open source.
Project description: the Thunderbird client can be extended to also serve as a (peer-to-peer) voice and IM client. IM buddies would appear in the Thunderbird address book, allowing to display buddies and their online status. IM transcripts might be saved and searched in the same way that messages are saved. This work can leverage a SIP project, http://www.croczilla.com/zap/, and might build on the Cockatoo project at http://cockatoo.mozdev.org.
One issue is that not many people use Thunderbird compared to Microsoft product (although I believe that will change in future). Alternatively, a web interface similar to Gmail and google-talk can be provided that can be easily accessed from any web browser. The challenge is to use P2P instead of central web server.
Email based identity in P2P-SIP
Our p2p-sip architecture (see the previous 'external DHT' post) suggests using email address as user identity for SIP. In particular, our web CGI script (as a certifying authority, CA) generates the user certificate verifying that the user owns the identifier, say bob@example.net, and send this to the email address bob@example.net.
This serves two purposes: (1) no login server: unlike Yahoo/MSN/Skype that need to connect to 'login server' on every login attempt, our p2p-sip uses the (central) CA only for first time use. The user certificate also gets stored in the P2P network, thus no need to connect to the 'login server' again. (2) any identity provider: unlike Yahoo/MSN/Skype/G-Talk that tie the identifier to a particular provider (i.e., @yahoo.com for Yahoo users), we can allow any user identifier as long as the identifier belongs to him.
To avoid use of a single identity (service) provider, one option is to use user's email address as his SIP user id. Thus, identity verification just involves making sure that his user id is a valid email address that belongs to him, and that user has a certificate that proves this.
Our web CGI script generates user certificate, where the user public key and certificate request is supplied by the user (automatically by sipc, on first time use). But to make sure that the user id is his email address, the certificate is sent in the email. This prevents you from using user id "bill@microsoft.com" because you can't get a certificate from our CA unless you own this email address. But if you have an email address say "bob@yahoo.com" or "Robert@msn.net" you can use this as your SIP identifier in p2p-sip, thus not tied to a single provider.
Sending in email is just one of the ways. Alternatively, if a group of users already have user certificates from other trusted entity such as verisign, they don't need to do email based certificates. Another possibility for future work is to also allow 'tel:' identity if the user can call from that telephone number (with caller id) to our VoiceXML service script that verifies that the user owns this telephone number and issues a new certificate (by directly storing in the DHT). This way other friends who know his phone number instead of email address, can also reach him on p2p-sip. Making an outbound call to tel: (similar to sending outbound email) for identity verification is probably not a good idea, unless user somehow pays for the call.
Identity protection (no one else can steal your identity) and verification (others can verify that you own this identity) is just one part of the P2P-SIP security. And using an email-based identity moves the problem of identity issuance and protection from P2P-SIP to your email provider.
This serves two purposes: (1) no login server: unlike Yahoo/MSN/Skype that need to connect to 'login server' on every login attempt, our p2p-sip uses the (central) CA only for first time use. The user certificate also gets stored in the P2P network, thus no need to connect to the 'login server' again. (2) any identity provider: unlike Yahoo/MSN/Skype/G-Talk that tie the identifier to a particular provider (i.e., @yahoo.com for Yahoo users), we can allow any user identifier as long as the identifier belongs to him.
To avoid use of a single identity (service) provider, one option is to use user's email address as his SIP user id. Thus, identity verification just involves making sure that his user id is a valid email address that belongs to him, and that user has a certificate that proves this.
Our web CGI script generates user certificate, where the user public key and certificate request is supplied by the user (automatically by sipc, on first time use). But to make sure that the user id is his email address, the certificate is sent in the email. This prevents you from using user id "bill@microsoft.com" because you can't get a certificate from our CA unless you own this email address. But if you have an email address say "bob@yahoo.com" or "Robert@msn.net" you can use this as your SIP identifier in p2p-sip, thus not tied to a single provider.
Sending in email is just one of the ways. Alternatively, if a group of users already have user certificates from other trusted entity such as verisign, they don't need to do email based certificates. Another possibility for future work is to also allow 'tel:' identity if the user can call from that telephone number (with caller id) to our VoiceXML service script that verifies that the user owns this telephone number and issues a new certificate (by directly storing in the DHT). This way other friends who know his phone number instead of email address, can also reach him on p2p-sip. Making an outbound call to tel: (similar to sending outbound email) for identity verification is probably not a good idea, unless user somehow pays for the call.
Identity protection (no one else can steal your identity) and verification (others can verify that you own this identity) is just one part of the P2P-SIP security. And using an email-based identity moves the problem of identity issuance and protection from P2P-SIP to your email provider.
Using an external DHT as a SIP location service
In Dec last year, I added support for an external DHT in my SIPpeer application, i.e., the SIP-using-P2P model. A technical report describes the details. In particular I used OpenDHT and built signing and encryption on top of it to allow secure P2P SIP with identity protection. The advantage of using a managed external P2P network is that we can safely assume that OpenDHT nodes are trusted in the sense that they perform DHT routing correctly. Thus the security problem is partly solved, and the identity protection can be done by issuing a certificate to the user if he/she has an email address.
Then in Jan and Feb this year, I wrote a Tcl based SIPpeer connector for OpenDHT, and with the help of Xiaotao Wu, added it to our SIP user agent, sipc. We are trying to see if we can make it opensource or at least freely downloadable for non academic use also. But first I will need to fix some of the usability issues. I will keep the current status posted here on time to time.
Then in Jan and Feb this year, I wrote a Tcl based SIPpeer connector for OpenDHT, and with the help of Xiaotao Wu, added it to our SIP user agent, sipc. We are trying to see if we can make it opensource or at least freely downloadable for non academic use also. But first I will need to fix some of the usability issues. I will keep the current status posted here on time to time.
SIP-using-P2P vs P2P-over-SIP
I recently saw the video of IETF 64, P2P-SIP Ad hoc meeting. Some of the interesting points from the "SIP based vs DHT based approaches" are as follows: There are two components in P2P+SIP, namely Maintenance (of P2P/DHT) and Lookup (for sending SIP message). In the first SIP-based approach, both the components use SIP, whereas in DHT-based approach, both the components are done using the P2P protocol directly. The first approach just requires resolver-like library in the application, and usage of SIP is incidental. In the second, SIP is overloaded with additional functionality of maintaining the DHT/P2P network.
An intermediate approach is much better, where the DHT maintenance is done using the DHT/P2P protocol (instead of overloading SIP with that), and the lookup is done using SIP (by sending the call request to the next hop node in the P2P network). This gives rise to a P2P-SIP proxies model where the SIP proxies use P2P algorithm to locate the user and proxy the SIP request to the next hop based on the P2P lookup. This differs slightly from the first approach in that this doesn't require the caller node to lookup the user on P2P network before sending the SIP call request. The caller uses its local structures (such as finger table for Chord), locates the next hop and proxies the call request to the next hop. The intermediate approach takes the advantage of SIP-based model, as well as preseves the simplicity of DHT-based approach.
An intermediate approach is much better, where the DHT maintenance is done using the DHT/P2P protocol (instead of overloading SIP with that), and the lookup is done using SIP (by sending the call request to the next hop node in the P2P network). This gives rise to a P2P-SIP proxies model where the SIP proxies use P2P algorithm to locate the user and proxy the SIP request to the next hop based on the P2P lookup. This differs slightly from the first approach in that this doesn't require the caller node to lookup the user on P2P network before sending the SIP call request. The caller uses its local structures (such as finger table for Chord), locates the next hop and proxies the call request to the next hop. The intermediate approach takes the advantage of SIP-based model, as well as preseves the simplicity of DHT-based approach.
2 P2P or Not 2 P2P?
I read an interesting paper on whether P2P is appropriate for an application or not. Although the paper is based on file sharing work, it seems to suggest (see chart on page 8, and conclusions at the end) that P2P may not be appropriate for global Internet telephony kind of applications where participants do not trust each other and the resources are of low relevance (since individual phone number/user identifier in p2p-sip are not interesting to many peers; unlike popular files). The reason being, too much overhead due to distrust, and over due to non-natural p2p network evolution if the resources are not popular.
However, if the trust problem can be solved in p2p-sip, I believe that p2p-sip will be useful because it can provide serverless VoIP at different scale -- small organizations, to global Internet. The current skype model may fit as an appropriate application for p2p because the protocol is closed, which makes the different clients to trust each other to some extent (i.e., the application is not malicious).
However, if the trust problem can be solved in p2p-sip, I believe that p2p-sip will be useful because it can provide serverless VoIP at different scale -- small organizations, to global Internet. The current skype model may fit as an appropriate application for p2p because the protocol is closed, which makes the different clients to trust each other to some extent (i.e., the application is not malicious).
First post: initial set of references
The recent news is that I am back from a long stay in India of about five months. I decided to start a new blog to put together my findings and readings on P2P-SIP and VoIP in general. If you would like to be added a team member for this blogger please drop me an email and I will add you!
I will start with references to my work. You can see a brief overview of our P2P-SIP design as a short paper, a more detailed architecture document or an extended overview paper. I also have an implementation running on Linux. The implementation report describes the details of the implementation so that others can also implement similar system.
There are many other papers on the p2p-sip website, including the original SoSIMPLE technical report, and internet drafts by Alan Johnston, Nimcat Networks and College of William and Mary.
I will start with references to my work. You can see a brief overview of our P2P-SIP design as a short paper, a more detailed architecture document or an extended overview paper. I also have an implementation running on Linux. The implementation report describes the details of the implementation so that others can also implement similar system.
There are many other papers on the p2p-sip website, including the original SoSIMPLE technical report, and internet drafts by Alan Johnston, Nimcat Networks and College of William and Mary.
Subscribe to:
Posts (Atom)