We have published results from a performance test of OpenSER V1.3 and RTPproxy V1.0 running on the same host server. The purpose of the test was to understand the relationship between server CPU performance and the maximum number of simultaneous calls. The massive scalability of SIP signaling with OpenSER is well known. For this test the critical component being tested was RTPproxy and the proxying of media.
A quick summary of the test results show that RTPproxy running on a single core of a 2.33 GHz Intel Xeon 5140 CPU can manage up to 750 simultaneous calls. If both cores had been used on both Xeon CPUs, we expect that RTPproxy could have managed 3000 simultaneous calls.
For a summary of the performance test, and to download the complete test plan, go to www.transnexus.com/White Papers/OpenSER_RTPproxy_Benchmark_Test.pdf
We are finalizing a new performance test of Asterisk V1.4 used as a B2BUA. We will present our Asterisk performance test results next week at Astricon.
Showing posts with label OSP. Show all posts
Showing posts with label OSP. Show all posts
Saturday, September 20, 2008
Thursday, April 5, 2007
Secure VoIP Peering
At the Spring VON show in San Jose, CA I had the opportunity to give a presentation on Secure VoIP Peering. The presentation is an overview tutorial on how standard Public Key Infrastructure (PKI) services and the OSP protocol are being used today to enable secure peer to peer VoIP calls.
For those who do not know, OSP is a protocol standard defined by ETSI, the European Telecommunications Standards Institute. ETSI is best known as the standards body that created the global mobile phone standard known as GSM. OSP is a protocol used by a softswitch or session border controller to query and external route server for call routing and then also report call detail records when the call is finished. OSP is a set of data rich XML meesages transported over HTTP so it is a natural fit with SIP and web based services. Further, OSP is designed for routing, authorization, pricing and usage reporting for any IP service, not just VoIP.
To view the Flash version of the Secure VoIP Peering presentation, go to http://www.transnexus.com/Flash/2007_Spring_VON_-_Secure_VoIP_Peering/player.html
For those who do not know, OSP is a protocol standard defined by ETSI, the European Telecommunications Standards Institute. ETSI is best known as the standards body that created the global mobile phone standard known as GSM. OSP is a protocol used by a softswitch or session border controller to query and external route server for call routing and then also report call detail records when the call is finished. OSP is a set of data rich XML meesages transported over HTTP so it is a natural fit with SIP and web based services. Further, OSP is designed for routing, authorization, pricing and usage reporting for any IP service, not just VoIP.
To view the Flash version of the Secure VoIP Peering presentation, go to http://www.transnexus.com/Flash/2007_Spring_VON_-_Secure_VoIP_Peering/player.html
Wednesday, April 4, 2007
VoIP Peering Panel at Spring VON
Spring VON in San Jose was a very good show - the VoIP market is looking very positive. It has taken me two weeks to follow-up on actions items from customer prospects and get back to routine matters such as blogging.
One of the VON sessions I found most interesting was the panel discussion on IP Voice Peering. The panelists came from a good cross section of companies (iBasis, NeuStar, Ag Projects, XConnect and Arbinet) and each had there own unique perspective on peering. Some of the interesting points from the discussion were:
1. Public ENUM is dead. Many in the industry have pushed for the idea that all telephone numbers with SIP access should be included in a public ENUM directory to enable peer to peer calling. This is an appealing idea for VoIP users because it would eliminate telephone companies and enable global peer to peer VoIP calling free of telecom access charges. While the public ENUM concept makes sense, there are too many political and market sources determined to keep it from happening. Perhaps the panel agreed Public ENUM is dead because it is a threat to their business.
2. The SPIDER Registry. No one wants to share their numbers. While everyone in the VoIP world complains that telcos are "Walled Gardens", or closed networks, the reality is that VoIP service providers are just as proprietary with their networks and customers. VoIP service providers do not want to share the telehone numbers of their customers with any third party. So how to you get broader VoIP peering adoptance if VoIP service providers will not disclose their telephone numbers? One well thought out solution appears to be the non-profit SPIDER registery created by Arbinet. VoIP service providers can list their numbers in the SPIDER registry and still maintain control over who can access those numbers. The SPIDER registry acts as a central provisioning mechanism for making VoIP numbers available to selected peering partners. The idea is good, but trust is still an issue. As expected, all the panelists were SPIDER sceptics since it has been created by Arbinet.
3. VoIP peering depends on the "call context". This an interesting new term that means call routing, or peering, depends on who is calling who and when. Ah-ha, so VoIP peering is not just as simple as connecting to VoIP users. VoIP peering depends on a variety of issues such as competition between peers, accounting and settlement, and technical interoperability. The panel agreed that one of the great drawbacks of ENUM is that it cannot convey "call context". ENUM only conveys the called number. To determine peering partners for a call, the calling and called numbers, source IP address, VoIP protocol, service type and many other factors must be known. As the VoIP peering market develops, we expect implementations of the OSP supported VoIP peering will grow since this well established ETSI protocol already addresses all of these "call context" requirements.
One of the VON sessions I found most interesting was the panel discussion on IP Voice Peering. The panelists came from a good cross section of companies (iBasis, NeuStar, Ag Projects, XConnect and Arbinet) and each had there own unique perspective on peering. Some of the interesting points from the discussion were:
1. Public ENUM is dead. Many in the industry have pushed for the idea that all telephone numbers with SIP access should be included in a public ENUM directory to enable peer to peer calling. This is an appealing idea for VoIP users because it would eliminate telephone companies and enable global peer to peer VoIP calling free of telecom access charges. While the public ENUM concept makes sense, there are too many political and market sources determined to keep it from happening. Perhaps the panel agreed Public ENUM is dead because it is a threat to their business.
2. The SPIDER Registry. No one wants to share their numbers. While everyone in the VoIP world complains that telcos are "Walled Gardens", or closed networks, the reality is that VoIP service providers are just as proprietary with their networks and customers. VoIP service providers do not want to share the telehone numbers of their customers with any third party. So how to you get broader VoIP peering adoptance if VoIP service providers will not disclose their telephone numbers? One well thought out solution appears to be the non-profit SPIDER registery created by Arbinet. VoIP service providers can list their numbers in the SPIDER registry and still maintain control over who can access those numbers. The SPIDER registry acts as a central provisioning mechanism for making VoIP numbers available to selected peering partners. The idea is good, but trust is still an issue. As expected, all the panelists were SPIDER sceptics since it has been created by Arbinet.
3. VoIP peering depends on the "call context". This an interesting new term that means call routing, or peering, depends on who is calling who and when. Ah-ha, so VoIP peering is not just as simple as connecting to VoIP users. VoIP peering depends on a variety of issues such as competition between peers, accounting and settlement, and technical interoperability. The panel agreed that one of the great drawbacks of ENUM is that it cannot convey "call context". ENUM only conveys the called number. To determine peering partners for a call, the calling and called numbers, source IP address, VoIP protocol, service type and many other factors must be known. As the VoIP peering market develops, we expect implementations of the OSP supported VoIP peering will grow since this well established ETSI protocol already addresses all of these "call context" requirements.
Subscribe to:
Posts (Atom)
