Here are some of my thoughts on how to make (or save) money with P2P-SIP.
There are two points to note: (1) an end-user doesn't know (or care) whether he communicates using client-server or peer-to-peer as long as he gets all the features (audio, video, text, conferencing, offline message, etc), security and speed. (2) unlike service infrastructure where the provider can make money out of user base (either charging per call or per minute as in Skype-out or via advertisements as in youtube?), there is no solid business model for P2P-SIP. Since it is open protocol, anyone can develop a client and break free from the provider. This of it as a email client technology -- how many vendors make money selling email clients?
There are some alternatives to this ideal view of P2P-SIP though. For example, one could control the user base -- keep the enrollment of the user controlled by the provider and allow communication among the clients of the same provider. This requires that the implementation be proprietary (at least the security and validation part), otherwise anyone may write an alternate implementation to bypass the validation. Thus the protocol doesn't remain open and is not P2P-SIP.
Alternatively, one could build a server-farm of SIP proxies using P2P technology so that the maintenance cost of the servers is reduced. However, this still requires dedicated set of servers (electricity, bandwidth, call centers, etc), hence the cost saving is very low. Even though you may be using P2P-SIP you won't save much money.
Thirdly, one could build and sell P2P-SIP software, e.g., for enterprises, that doesn't require expensive call managers or central servers. This works well, but has one problem. People have come to expect that communication, at least PC to PC, is free. Unless the client software provides tons of new features, which cannot be easily done by another vendor, selling such a client software is also difficult.
So, how do you make money? You don't. Instead, you can save money.
You can save money that you would otherwise be spend on maintaining the server infrastructure or you can enable new businesses that were earlier not possible because of close systems. Most of the current communication mechanisms have evolved in a tightly controlled environment, e.g., Mobile phones, Skype, Yahoo, etc. Instead what we need is an open mechanism similar to emails and web. An email client is not tied to a single server. A web client (browser) is not tied to a single server or web site. A communication client should not be tied to a single provider.
Consider an open system where anyone can call anyone else without paying to a provider beyond the Internet connection fees. This opens door for a whole new set of businesses. For example a small time vendor, consultant or topic expert can lend his service in real-time for a small fee without going through the hassle of setting up agreement with a provider. Existing systems such as social network sites or content distribution networks can have additional feature that allows a user to interact with his friends, or other users on the same site, or other users watching the same content, irrespective of the attachment of the user to the provider. There is a huge potential for innovations in the communication client space, similar to how web browsers have evolved.
So, who can do this? I don't think it will come from existing businesses who have large user base -- this includes the likes of Yahoo, MSN, AIM, or Skype. The reason is that they wouldn't want to open up their users to others. I also don't think it will come from existing businesses that are targeted for selling advertisements -- the likes of Youtube, Google, etc.
The question to ask is who benefits from ubiquitous P2P-SIP? Media companies and content owners should invest in making P2P-SIP ubiquitous so that their existing system is improved or becomes more appealing to end users. Such companies can probably sponsor open source projects for P2P-SIP. If there is a better and free communication infrastructure, all sorts of new innovations are possible. For example, people would like to talk with their friends while watching a TV series online, a cricket match online or a movie online.
In conclusion, I feel that big companies that can benefit from real-time communication, but don't have an existing solution to work with, should invest in open-source P2P-SIP technologies. If you are interested in talking about it, feel free to drop me an email.
Articles on technology, Internet, Protocols, Web, Open Source, VoIP, P2P, SIP, RTMP and WebRTC.
Data format and interface for external P2P mode
Last month, Henning and I submitted an internet-draft on "Data format and interface to an external peer-to-peer network for SIP location service". The text and HTML version are available. The idea is to use an interoperable XML format for accessing the DHT (which is based on OpenDHT's interface) and an XML format for storing user location data such as contact address, cryptographic keys and certificates, offline messages, presence watcher information, etc.
Structured vs unstructured P2P or Why we chose DHT for P2P-SIP?
One of the questions that people ask me is 'whether structured or unstructured P2P works better for SIP-based Internet telephony?'. My answer is that structured P2P such as distributed hash table (DHT) works better because of the following reason.
Unstructured P2P networks usually rely on caching and replication to improve the lookup performance and reliability. In the case of file-sharing application, once the file named "matrix-II.mpg" is uploaded in a P2P network such as Kazaa, the content of the file remains the same (un-mutable). Thus, for reliability the file may get replicated at multiple places. Intermediate nodes in the download path may cache the file locally to improve download performance by other downstream nodes. On the other hand, a phone's contact location or IP address uploaded under the resource named "bob@home.com" may change often (i.e., mutable), e.g., if bob changes his device or the device's IP address is changed. This makes all the randomly replicated and cached copy of the resource content useless. Thus, random caching and replication is not useful.
In unstructured P2P network, any replica of the file "matrix-II.mpg" is good enough, whereas in Internet telephony you want to reach only "bob@home.com" but not some replica of Bob. You can not replicate Bob's phone. The only thing that can be replicated is the mapping between Bob's identifier and his phone's IP address. However, to allow frequent updates and consistent view of the mapping, it is desired that the mapping is replicated in a structured manner so that both Bob can easily update the mapping and any prospective caller can easily query the up-to-date copy of this mapping. This means given the resource name, we can know where the resource should be present in the P2P network. Thus, it is structured.
Unstructured P2P is suitable for random or blind search and allows wild-card search. For example, you can search for a file name containing "matrix" keyword. On the other hand, in Internet telephony most calls are made to the known destination (phone number or destination user identifier). Hence, hash table interface that allows lookup based on a key is good enough. Distributed hash table (DHT)-style P2P algorithms such as Pastry, Chord, Bamboo provide ideal platform for such lookups.
Skype is believed to be unstructured among the super-node, but I think there may be some form of structure in how the data is stored among the super-nodes. Plus, there is no guarantee on upper bound on lookup cost which means it might be falling back to some centralized lookup if the number of hops in search exceed some limit. Since Skype is proprietary, we do not know how exactly it does lookups.
Unstructured P2P networks usually rely on caching and replication to improve the lookup performance and reliability. In the case of file-sharing application, once the file named "matrix-II.mpg" is uploaded in a P2P network such as Kazaa, the content of the file remains the same (un-mutable). Thus, for reliability the file may get replicated at multiple places. Intermediate nodes in the download path may cache the file locally to improve download performance by other downstream nodes. On the other hand, a phone's contact location or IP address uploaded under the resource named "bob@home.com" may change often (i.e., mutable), e.g., if bob changes his device or the device's IP address is changed. This makes all the randomly replicated and cached copy of the resource content useless. Thus, random caching and replication is not useful.
In unstructured P2P network, any replica of the file "matrix-II.mpg" is good enough, whereas in Internet telephony you want to reach only "bob@home.com" but not some replica of Bob. You can not replicate Bob's phone. The only thing that can be replicated is the mapping between Bob's identifier and his phone's IP address. However, to allow frequent updates and consistent view of the mapping, it is desired that the mapping is replicated in a structured manner so that both Bob can easily update the mapping and any prospective caller can easily query the up-to-date copy of this mapping. This means given the resource name, we can know where the resource should be present in the P2P network. Thus, it is structured.
Unstructured P2P is suitable for random or blind search and allows wild-card search. For example, you can search for a file name containing "matrix" keyword. On the other hand, in Internet telephony most calls are made to the known destination (phone number or destination user identifier). Hence, hash table interface that allows lookup based on a key is good enough. Distributed hash table (DHT)-style P2P algorithms such as Pastry, Chord, Bamboo provide ideal platform for such lookups.
Skype is believed to be unstructured among the super-node, but I think there may be some form of structure in how the data is stored among the super-nodes. Plus, there is no guarantee on upper bound on lookup cost which means it might be falling back to some centralized lookup if the number of hops in search exceed some limit. Since Skype is proprietary, we do not know how exactly it does lookups.
Labels:
Bamboo,
Chord,
DHT,
Kazaa,
P2P-SIP,
Skype,
Structured,
Unstructured
New internet-drafts
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.
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.
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)