VoIP-Forum

During the last week, I’ve been discussion upgrading Asterisk on the asterisk-user’s mailing list. I asked the community on what the problems was with upgrading to 1.4, asking for success stories as well as reasons not to upgrade. I’ve learned a lot from the feedback.As a developer, I spend too much time in the bug tracker, working with particular bugs, so I often wonder howon earth anyone can use this buggy platform for anything business-like…With that background, it really feelsgood to get reports on people successfully using our software and meetAsterisk users who just love the product and handle tons of callsevery hour with it.And as a developer, everything is of course more simple and you live inthe future, moving forward to new features, new functions all the timebasedon customer requirements or feature requests in the mailing list or thebug tracker…

Summary of the feedback

Now over to a summary of the feedback. I’m not going deeper intobugs reported, those will be handled separately.

DON’T TOUCH MY ASTERISK PBX

For a lot of users there’s simply no reason toupgrade a PBX everytime we release a new Asterisk.Existing installations that work should not be touched unless there’s a very good reason to, like a new feature that makes business sense.Just upgrading for the cause of upgrading is a feature of the non-open software industry that gets a lot of revenue from upgrades.We developers has to accept that people appreciate our work, but decide not to upgrade every installation at every release. We might have to reconsider our support policy in the Asterisk.org project, where wedevelopers abandoned 1.2 this summer. We might need another team that runs 1.2 support in the bug tracker.

MAKE UPGRADING EASIER

Another issue is to make the upgrade much smoother. We can’t anticipate that people upgrade from 1.0 to 1.2 to 1.4 and readall the docs for every release. They can jump from 0.8 to 1.4. Or 1.0 to the future release of 1.6. We need to assist that and haven’t made a good effort in doing so.But even for upgrades from 1.2 to 1.4, we need to be more clear about changes that are required, especially for 1.2installations that already was upgraded from 1.0 and still use the 1.0 configuration syntax. They are going to havea broken configuration in 1.4 and this is the first time that happens in Asterisk.We need to make clear that Asterisk admins need to go through the log files in 1.2 and check all deprecation warnings. These needsto be fixed before even testing 1.4.

USE ASTERISK 1.4 FOR NEW INSTALLATIONS, PLEASE

My personal goal would be to get the community to start using 1.4 for all new installations. We need to produce informationto help this upgrade path. It’s not about upgrading systems, since we’re talking about new installations. It’s about upgrading the Asterisk admins and installers - human beings.

The success stories reported to me personally and on the list indicates that 1.4 is indeed ready for production and it’s a great product.

With that, I’m now changing my focus from SIP invite states, RTP sessions and video formats to Christmas ham purchasing, baking Christmas bread (julvört) and decorating the Christmas tree. Of course, you understand that there’s an Asterisk asterisk on top of all those trees, right?After Christmas, I’m running the new Asterisk SIP Masterclass together with Daniel Mierla here in Stockholm. He’s one of the core OpenSER developers and it’s going to be a great class. I’m sure we will locate a set of new interesting bugs in svn trunk during that week. I’m really looking forward to that training. (Hint: We still have a few open seats… )Greetings from a dark and cold place in Sweden, without a decentamount of snow…Have a wonderful, merry and cheerful Christmas!/Olle

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