VoIP-Forum

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

Testing open source code is an eternal problem. People that find bugs in the Asterisk release code complain: \”Did you not test this before release?\”. When we ask people to test code before release we seldom get feedback. If we apply less strict rules for committing new code to the development version, people will complain: \”You destroyed my system, this does not work!\” - even though we clearly say that this is development code. Guess there is no way to make everyone happy.

Important facts: Testing is a very important part of the development process. You can participate actively in the development team without being a developer - testing and documenation are really important too. We do need feedback. Asterisk is very complex, it runs on many operating systems, in combination with many third party libraries and various types of hardware. No single user can test all combinations while developing a new feature or fixing something.

The big question: What to do?

How do we get more people involved in testing? Currently my strategy is make it easier to test. I\’ve compiled a lot of patches from the bug tracker into one super-branch called test-this-branch. A lot of people have already started to test this branch. It includes a lot of stuff that may or may not be included in Asterisk - but without testing it will be very hard to make any decisions or adjustments to the code in there.

Thanks for your time, thank you for contributing, thank you for testing \”test-this-branch\”!

This spring, I will be on tour quite a bit. In February, I am talking about Asterisk and SIP at the SIP International 2006 Conference in Paris. In March, I will be visiting Von 2006 and exhibiting with Digium in the Asterisk partner booth. In April, I am taking Asterisk to SIPit in Tokyo for one week of testing. And between those events, I have trainings in Europe and USA as well as customer meetings and Open Source and Linux user group meetings that invite me as a speaker.

In all of these trips, I will meet Asterisk users and developers in the Asterisk community. Open Source is really about people in addition to the software. By joining the Asterisk open source project, I now have friends all over the globe that I communicate with if not daily, then every week. Even in customer projects, community members help each other out, forming a large business network.

This is much more powerful than any commercial software I have worked with. Because an Open Source software is so much larger than the code itself. By forming a community as well as an business eco system, a piece of software grows extremely strong and is very hard to compete with. In fact, I can accept some problems in the software itself, because the power of the community makes me assured that I can get help almost around the clock.

Well, I have less license fees to pay by using Open Source. The problem is that airlines aren\’t yet Open Source. From my point of view, meeting all my friends and collegues in the community is worth it. See you!

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

With the switch from CVS to subversion as a source code revision control system for Asterisk, a lot of new possibilities was created. One of them was branching. A branch is a copy of a repository where a developer or a team of developers can add new code without affecting the main version of the source. The extra benefit is that a branch maintains a relationship with the main source code. When new features are introduced or bugs fixed in the main source code, the changes are easily imported into the branch. When the development in the branch is done, the resulting changes can easily be merged into the main source code.

Read the rest of this entry »

Testing is important for every software project, commercial or free. We are now working on Asterisk 1.4 development and need your help testing new features that we are working on. A few weeks ago there was complaints about of the lack of testing new releases of Asterisk on this mailing list. Here is your big chance!

I have opened many subversion branches with different patches to chan_sip for testing. Go to the bug tracker, select the SIP category and you will find several interesting patches:

• diversion: Support for the SIP Diversion: header
• videosupport: Support for peer-configurable video support in SIP
• jitterbuffer: Support for a jitterbuffer in chan_sip
• strictrouting: Improved support for strict SIP routing
• sipregister: Improved handling of register= statements
• securertp: Secure RTP support, phase one

Some of these are work in progress, some are finished. All of them need your testing and input now, regardless if you are a user, system manager or a developer.

Help us make better software and more solid releases,
test patches and new code NOW!

Extra benefit: Testers get karma awards nowadays!

Meet you in the Asterisk bug tracker!

/Olle

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.

A bug was found tonight, where Asterisk stopps sending audio across bridged channels - starting tonight! If this is a problem in your system, you need to patch or update:

• The subversion repositories are updated, both the 1.2 branch and trunk (developer)
• A patch is available in the bug tracker

A new release of Asterisk 1.2 will be available on ftp.digium.com as soon as possible.

In the current Asterisk version, there is one parking lot per PBX. This leads to problems when you have multiple user groups in your PBX. With this patch, you can enable multiple parking lots, in order to

• Give each company using a virtual PBX it\’s own parking lot
• Give each department a parking lot
• Give a manager a parking lot that the admin also can access

Please test this patch to Asterisk 1.3 (svn trunk). Check out the multiparking module, compile and read the sample configuration. If you\’re happy, tell me. If you stumble into problems, tell me. The place to give feedback is the bug tracker, bug #6113. Thanks for testing!