VoIP-Forum

In the stream of updated drafts for the IETF meeting in december, I found a draft namedReal-time text interworking between PSTN and IP networks.This is work-in-progress in Asterisk svn trunk. We already have support for T.140 realtime text in the SIP channel, and support for US TDD phones in the Zap/PSTN channel driver. During this summer, I’ve assisted a developer who implemented a RTT gateway in Asterisk, so you could call with an old PSTN TDD phone and have a conversation with a modern SIP client with support for realtime text.This code will soon be implemented in Asterisk svn trunk, so Asterisk will become the reference implementation for this draft. How many xOIP acronyms do we have now? FOIP, VOIP, TOIP? I surely missed a few there… :-)From the abstract:

IP networks can support real-time text communication. SIP-based real- time text is called Text-over-IP or ToIP. PSTN networks support real-time text using textphones (or TTYs). When real-timetext is supported by different networks, gateways are needed to provide interoperability. Real-time text capable gateways may also support real-time voice.This specification describes procedures for interworking between ToIP and PSTN textphones using a real-time text capable gateway (RTT gateway). It also describes ways to route calls to RTT gateways for several call scenarios. Procedures that support the phased introduction of RTT gateways and procedures that support the invocation of text channels at any time during the call are included. Interworking of PSTN text phones thatdo not support simultaneity of voice and text with IP User Agents that support simultaneous voice and text is also described.

Josh Colp (file) has started a rewrite of the T.38 passthrough implementation in Asterisk. This is very much needed. The code that was contributed for 1.4 was a bad hack and has caused a large number of issues that Josh and I have been struggling with for a long time - and a large number of bug reports.

At the same time maybe we should sit down and consider the architecture of the SIP channel. After my initial planning on chan_sip3, I’ve worked a lot on video, text telephony (T.140) and other media in SIP. The SIP channel, and Asterisk, is built as a telephony audio-only PBX with some video additions. Adding T.38 (fax over IP), T.140 (text) and enhanced video/audio (like multichannel audio) turns into ugly hacks. And adding TCP has proven to be an ugly hack too. Yes, it’s easy to add a TCP socket, that’s no big issue coding-wise. But to handle the calls properly, the signalling and being able to switch from UDP to TCP midcall - that turns it ugly.

This also leads to a bigger question - what’s a PBX today? If we where about to start an Asterisk 2.0 project - would we handle all kinds of media properly? Presence? Messaging? File transfer? We already have an embedded web server… What’s the limit of a PBX? Or is it really a PBX we’re building? Asterisk 1.0 certainly has a PBX architecture, should that also be the base architecture for Asterisk 2.0?

Anyway, a big thank you to File for starting the re-write. May the code be with you!

The Asterisk Developer Team is proud to announce the Asterisk SPE v1.0 Beta Releasefor immediate download on tftp.digium.com.The SPE has been developed as a joint project between Digium, the Asterisk Company,Voop, the European Asterisk Dialtone provider and the Asterisk community.The Asterisk Service Provider Edition is focused on the needs for the new breedof Telecom companies - the Voice over IP Service Providers. It will be availableboth as a free download in Open Source and as a commercial productcalled Asterisk Commercial Service Provider Edition, ACSPE.

- “We felt the need to focus on being an enabler for this new kind of telco ,making sure that Asterisk fits into their network as well as business modelsin a professional way” says Matt Penser, Asterisk innovator. “The previous versions was more targeted to the needs of the business user, a market where Asterisk already is stronger than any other offering on the marke\”. 

The Asterisk SPE has a number of new features, that makes it the most powerful platform for these companies. No other Open Source package can deliver amatching feature set:

• All the features from Asterisk 1.4 and the business edition
• Asterisk VoipRoute(R) technology for SmartRTP(R) bridging
• Asterisk RateRoute(TM) technology for route selection
• Asterisk SpitWall(R) core for SPIT filtering

These new solutions will enhance Asterisk and will help the VSP’s toleap light years ahead of their competion.

Asterisk VoipRoute(R) SmartRTP(R) Bridging

The VoipRoute SmartRTP bridging technology enhances the Asterisk RTPbridge with a new scheme. In addition to the current RTP bridges - the native bridge,the remote bridge and the hybrid RTP-direct bridge, SmartRTP uses a combinationof the BGP IP routing protocols and the TRIP VoIP routing system to find thebest and fastest way to route calls between IP nodes on the Internet or local network.

- “The SmartRTP bridge system, based on our patented VoipRoute core, makes sure that call latency is minimal. We also enhanced it with a MediaRescue solution that will capture lost media frames and re-insert them in the audio or video stream before it reaches the destination.” says Josua Polk, the Asterisk RTP developer.“This system implements an Asterisk VoipRoute layer on top of the Internet and uses Dundi(TM) to automatically discover new SmartRTP relays and their properties. It practically erases packet loss, jitter and latency from the list of issues for the provider’s support department. We call it SPEake-friendly calls!” 

Asterisk RateRoute(TM) Least Cost Routing

The RateRoute(TM) solution is only available in the ACSPE due to licenses fromother vendors, soon to be disclosed. The RateRoute system analyze the call from fifteen distinct properties and use an external hardware accelerator to find the best route to forward the call, be it PSTN or VoIP channels. By using the hardware accelerator RR520P PCI express card, LCR decisions is now down to microseconds without accessing external databases.

- “We’ve implemented this in our commercial VoIP network during development, and it cut our costs by at least 75% and enhanced call quality. Billing and CDRmediation is much easier, since the RateRoute system always picked one outbound service provider that always matched the fifteen criteria for carrier selection” says Anders Runnstam at PulseVoip in Bergen, Norway. 

Asterisk SPITwall(R) - filtering away tomorrows VoIP spam today!

The SPITwall(R) technology is developed by Olle E. Johansson, a member of the Asterisk developer team and Senior Technical Advisor for Voop in Bergen, Norway - the Asterisk Dialtone provider.

- “I got more and more annoying calls during development, which disturbed me a lot and caused me to loose concentration. On the other hand, it inspired me to develop SPITwall to be able to filter them out.
I have measured up to 95% success rate on call filtering, which is far beyond any similar products on the market. By not bothering with answering the final 5%, I could concentrate on development again and succesfully finish my development projects.” says Olle. 

The SPITwall is built on a shared database and use bayesian techniques to analyze the content of the call. It requires Asterisk ChanSpy to be ableto listen in and warn the callee about ongoing unsolicited calls. The callee can also press certain DTMF sequences during the call to mark the call as SPIT. The voice pattern, SPITwall checksums and call properties will then immediately be stored in the Digium SPITcore repository to be available for all other users.

- “Using the community to build a SPIT-fighting database is natural for an Open Source project. The community is the power of Asterisk and by sharing a resource like this, we can make sure that everyone contributes. The SPITshare(r) analyzer makes sure that companiest hat does not contribute will get older data and more SPIT calls” says Jill Timmer, VP or marketing. 

SPITwall 1.0 is available with English, Norwegian and Swedish language support. Some support for Canadian and southern US dialects is implemented, and will be finished by release time.

In addition to these revolutionary features, Asterisk Service Provider Edition will contain full T.39 faxing (leapfrogging systems that only support up to version 38), the Codename Pomengranade SIP Stack, the Project Okapi IAX3 trunking technology featuring IAX3 over SS7 transport, the VoipVotedigital phone voting system with app_preselect cheating technology and a fully working version of the VirtuAST virtual PBX hosting Asterisk virtualisation core. 

Asterisk SPE v1.0 beta is available for immediate download. At thistime we’re looking for feedback from service providers.Release date for the 1.0 version is to be released, pending beta tests. ACSP Edition will be available with Telco level 24/8 support May 15th, 2007. The RR520 RateRoute hardware accelerator is in distribution through authorized resellers starting April 10th.Asterisk, Digium, SPITwall, SpitShare, VoipRoute, SmartRTP, RateRoute and Dundi are trademarks that may be registered by Digium, Inc.For immediate release, April 1st 2007. On behalf of the Asterisk development team and project 0401/Olle 

One thing I avoided working with for a long time is the Asterisk voicemail code. One module in Asterisk I’ve constantly been naming as one of the worst parts is voicemail. One part of Asterisk that I’ve been kind of avoiding during my trainings is voicemail. And there’s where I’ve spent a lot of time recently… Life is strange.Instead of fixing the current voicemail, I decided to restart. Breakup large apps into small building blocks, allowing Asterisk admins to use the rich dialplan script language or AEL to build a voicemail solution that fits the organization.I’ve named this minivoicemail, which for each addition becomes moreof a bad choice of name for this project. Flexivoicemail could be better… :-)I’ve removed functionality like ODBC and IMAP support, something thatc an be reapplied later. I’ve also not replaced the hooks into other channels for voicemail notification, but that can be done too. I haven’t started replacing voicemailmain(), since I\’ve focused on the need of larger systems where one only supports e-mail notifications of voicemail with audio attached.What I currently have is:Applications

• MinivmGreet: Play voicemail greetings (busy/unavailable/temporary)
• MinivmRecord: Record voicemail message
• MinivmNotify: Notify account owner of message (email, pager)
• MinivmDelete: Delete message

Dialplan functions

• MINIVMACCOUNT() - Get properties of voicemail account

CLI commands

• minivm show settings 
• minivm reload
• minivm show stats
• minivm list accounts
• minivm list templates

New features:

• E-mail and pager templates in variouslanguages.
• All apps are usable without setting up a voicemail “account” for auser.Just run the app with an e-mail address as an argument.

The branch is based on Asterisk 1.2 and can easily be downloaded from svn.digium.com/svn/asterisk/team/oej/minivoicemail I need testers, ideas for new applications and possibly coders that canhelp to complete this.Here’s how you start

• Checkout this branch, compile and install
• Check the minivm.conf.sample for instructions
• Read the top of the source code file for a list of ideas, todo’s and changes

And if you want to encourage me further, paypal to info at edvina.net, thanks!

One of the worst applications in Asterisk is voicemail. It’s a huge application with a lot of un-configurable built-in menus and functions. I think it is much better to build small buildingblocks, like the UNIX operating system’s philosophy. For a long time, I’ve been trying to inspire other developers to build a new voicemail system. Nothing has happened…

So with support from one of my customers, I started development of a stripped-down restricted voicemail system with tiny building blocks. One application to play voicemail prompts, one application to read voicemail and send through e-mail. I named it minivm.

If you want to check into this and help me with suggestions, feedback or code, check out the minivoicemail branch. There are room for many building blocks. Please try it out and tell me what you think!

This week, the Asterisk Video Task Force has had it’s first workshop in Paris. (Nov 20-22, 2006)

First of all, we really have to send a big THANK YOU to Inria, the French research institute, that
hosted the event. They have been great hosts and provided us with both food, power and
network connectivity!
A special thank you to Philippe Sultan at Inria for organizing all of this.

To summarize:

1.4 testing

We started with testing the 1.4 beta. Some notes

• Direct RTP media setup did not work as expected. During the setup,
  the payload types was not copied between the call legs, resulting
  in bad calls with failing media. When answering, the capabilities
  of the callee is not used when sending 200 Ok to the caller. We opened a branch called “earlyrtpfix” to try to fix this. Almost there.
• IAX video is broken. Currently, the capabilities fails and video disappears
  somewhere in the call setup. Even with that fixed, there is a problem with
  not sending the frame sequence number across the bridge, which may
  result in bad resequencing on the other side. Out of order frames will be
  renumbered as they where in perfect order… IAX2 also seems to have
  problems with video frames larger than the MTU and video frames that
  are transported in multiple RTP payloads.
• We could set up calls between several phones. Ojo videophones,
  Aupix, Grandstream, Wooksung, Counterpath Eyebeam, Ekiga
  and Kapanga was tested as well as some unbranded softphones
  in development.
• We do have several problems in the RTP subsystem, that we
  need to look into.

Future things discussed

• Direct transcoding from alaw to ulaw. Module developed during the session by Morten.
• AMR codec support
• Integrations with 3G, support for 3G videocalls in libpri/chan_zap
• Exchange of more complete codec capabilities during call setup
  (branch videocaps)
• T.140 realtime text support
• Development of a contrib/videotoolbox for conversions, ivr video prompts etc
• Integration with remote transcoders
• Integration with OpenMCU videoconferencing
• Neil’s videoconference switch for app_conference
• H.323 video support
• Videolan integration for streaming video - VideoOnHold
• Next meeting in a sunny place
  After discussion, sunny is optional, no rain or snow is mandatory

This meeting was really productive and has moved Asterisk forward. Meeting for a few days really
helps, especially when you have a strong focus - like “video”.

/Olle Johansson

During my recent tests with video phones (thanks Grandstream, Aupix and Foniris!) I have found out that we have a list of things to do. I have also found out that there are a lot of developers out there that have done it already - meetme with selectable video streams, chan_local with video and other
patches that we need to incorporate into Asterisk. Smaller changes now for 1.4, bigger changes for 1.6.

The first batch of changes was included in the development tree today. More will come. As of today, Asterisk will handle calls between audio and video phones a bit better than before. We have also included work by Fredrik Olsson and John Martin to improve our support of RTCP, very important for video phones.

In order to open up a forum for those of you that want to work with Video, SIP and Asterisk, I have set up a mailing list for the AVTF - Asterisk Video Task Force!
I have no knowledge of video codecs, standards and other strange stuff, so I rely on the community there.
I can manage a branch for this work and come with input from a SIP standpoint.

It is ok to discuss IAX2 and Video as well - does it work with the jitterbuffer, does trunking work,
any room for improvements?

See you on the Asterisk-video mailing list! /Olle

One of the most common questions discussed within the Asterisk community is the upper limit for number of calls within a single Asterisk server. John Todd yesterday issued a challenge on the asterisk-dev mailing list. Quoting his mail:

“The subject of load on a single chassis is still the most contentious issue to date. The Signate numbers of >5000 calls per chassis with RTP are impressive, and there are others who claim more vaguely of 1000, 2000, or more calls into a single P4 server (with or without media.) Others say that there are inherent limits in the Asterisk code which prevent more than ~500 calls from being processed with RTP at any one time. Opterons, FreeBSD, custom Linux loads, Solaris, and other operating systems or hardware have been offered as the magic bullets to increase call volumes. Who knows? (1) I will say that extraordinary claims demand extraordinary evidence, which has been pretty thin. I believe that most large call processing facilities still run on distributed systems of some type, as was described in the primary thread of this discussion on asterisk-users. (2)

I know that there are some projects towards testing Asterisk more rigorously to determine these numbers. However, I would suggest that the community at large could benefit from a more open examination of high-end system claims immediately than these (better) long-term tests which are progressing slowly (if at all.) Let’s just look at the “maximum” numbers. Running a big system? Selling a big system? Tell us about it, in detail. What are the limits that have been hit? Be specific. I keep seeing hand-waving, but no programmers have come forward to say “It won’t work because of the way X is implemented in the file blah.c or libFOO.”

To make a bad analogy: I don’t want to see the street rods; I just want to see the top-fuel, rocket-powered dragsters on the line.

Any takers? It sounds like Signate has a contender, but quite a few people have said that it’s impossible without serious modifications to the code. Others have claimed (publicly or privately) that they can match those numbers on different hardware.

Here are the criteria:

• Any O/S
• An unmodified version of Asterisk from SVN (or CVS)
  OR patches must be available for inspection, as per the GPL
  OR you must be a Digium license-holder (patches can be secret)
• All calls are IAX2 or SIP (both in and out)
• No transcoding of any type is required
• All calls are G.711, 20ms OR 30ms packet size

• All O/S documentation, kernel tricks, modules, hacks, patches, or configuration elements should be documented, but proprietary information need not be divulged if that is deemed “secret”
• Testing method must be reasonably documented
• Dialplans must be included
• SIP.conf files must be included
• All hardware must be fully described (part numbers required)

TEST #1:

• All media must be handled by the server. This is for both legs of the call. The “canreinvite=no” for SIP and “notransfer=yes” in IAX2 must be set for all calls.

TEST #2:

• Media may or may not be handled by the server. Native transfers should be allowed in both IAX2 and/or SIP.

(1) I have heard various people saying that it is “impossible” for Asterisk to handle a large number of calls due to architectural issues (no, it’s not just from the people that you’d “expect” to hear this from.) I’ve not been able to validate this one way or the other recently. I am interested to hear what the developer community has as a comment on this topic. I have an Empirix Hammer system at my company, but honestly I just don’t have the time to set it up to do testing due to day job time constraints…

(2) There are so many ways to spread calls across an Asterisk array it makes my head spin, but the question STILL comes down to “how many calls can a single chassis handle?” Even in a farm of servers, there has to be a numerator in that ratio.“

JT

Registering multiple SIP accounts with one SIP provider has been a nightmare in Asterisk. Or, rather, still is. The match-on-IP scheme for peers is a hack to handle registrations, but not a very good hack. If you register for multiple accounts, the incoming calls will all match the same peer. A poor solution.

With the help of Luigo Rizzo, I have started a rewrite of the SIP outbound registration process in Asterisk. You can find the current development code in a subversion branch named sipregister.

In this code, you will soon find the following features:

• Registrations are matched exactly. If you register multiple accounts on the same server, but with different extensions in the register= line, we will match the registrations and send incoming calls to the proper extensions.
• Registrations within a peer declaration. You can now add register=yes to the peer section in sip.conf. This will make Asterisk register that account with an outbound provider. Incoming calls will be matched to the incoming context of the peer.

Asterisk will still try to match inbound calls on IP of the peer, but I doubt if it will be needed in the future. Please help me try this code and find the bugs before we include it in Asterisk trunk.

In response to a large number of questions on the mailing list I’ve
decided to publish a presentation I have been running in the Asterisk
bootcamp - our one-week training class.

This presentation covers many, but does not claim to cover ALL, new
features of Asterisk version 1.2. I hope it will wet your appetite to
help us test the new code.

The presentation is available here:

• http://edvina.net/asterisk1-2/

For information on how you can help with Asterisk 1.2, see here:

• http://www.voip-forum.com/?p=176&more=1

If I’ve forgotten a new feature that you think is important, I’m
grateful for all feedback!