VoIP-Forum

Garret Smith writes some thoughtful words about WiFi phones in his blog:

Infonetics Research released a report that showed WiFi ip phone sales increase 60% in 2007, with 682,000 units were sold worldwide. The report cited “increased vendor support” as the primary reason for the growth. 

[…]

While some people seem to like WiFi phones, they aren’t for the faint at heart, especially if your aren’t technically savvy. My advice, if you want to go wireless, is to pickup a DECT based solution. A little more expensive, but it works…for everyone. 

I still haven’t met a WiFi SIP phone I liked and used more than a couple of days…  

Asterisk 1.4 delivers many new features. In regards to call state subscriptions, there are many news for you. Call state subscriptions are what makes the lamps blink on your phone when your collegue’s phone rings. In 1.4, you can make it blink based on activity in parking lots and meetme conferences as well. Read on! (more…)

During one and a half year I’ve had a great oppurtunity to work with Asterisk development and evangelisation thanks to the Voop team, Thorsten Lockert, Gunnar Helliesen, Morten Reistad and the rest of the Voopers. They’ve paid part of my time so I could focus on long-term Asterisk issues and development, working in the bug tracker and starting the chan_sip3 (Codename Pineapple) project.

I think this sponsorship has made them the largest Asterisk corporate sponsor outside of the US. They have themselves contributed many patches, like the res_snmp module made by Thorsten and a number of fixes to the IAX2 channel.

Now, the contract is ending and I am looking for a new company to work with. If you are interested in sponsoring my work in the Asterisk project, making sure that I can dedicate part of my time to support the project, please contact me at oej (at) edvina.net for an open discussion. The sponsorship has also included my participation in the SIP interoperability events, SIPit.

A huge thank you to the Voop team!

/Olle

The draft SIP Multiple REFER describes a way to send a call transfer (REFER) indicating setup of a new call to multiple destinations, i.e. initiating a conference. This could be handy between two Asterisk servers, a way to set up a conference on a different server, optimized for conferences.

RFC 3261 (SIP) [RFC3261] is extended by RFC 3515 [RFC3515] with aREFER method that allows a user agent to request a server to send a request to a third party. Still, a number of applications need torequest a server to initiate transactions towards a set of destinations. In one example, the moderator of a conference may wantthe conference server to send BYE requests to a group of participants. In another example, the same moderator may want the conference server to INVITE a set of new participants. We define an extension to the REFER method so that REFER request can be used to refer servers to multiple destinations. In addition, this mechanism uses the suppression of the REFER method implicit subscription specified in RFC 4488 to suppress REFER’s implicit subscription.

The world of realtime technologies on IP networks and the Internet is cooking with ideas, solutions and innovation. Combining it with social networks, and even more is happening. Protocols like SIP, XMPP/Jabber, SIMPLE, Jingle and Open Source solutions like Asterisk, OpenSER, Ekiga, Sofia-SIP, ReSIProcate and others are changing the landscape. It’s high time to get a helicopter view of what’s going on as well as detailed information about the building blocks for this new service delivery network.

Edvina.net is gathering leading experts in this area to the conference The IP Communications Technology Summit 2008 in Stockholm, April 2-4. Tutorials, hands-on labs, conference and user group meetings. Book this date in your almanac today! More information coming soon. If you have an idea or a talk proposal, send e-mail to me, Olle E. Johansson, at oej@edvina.net today!

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

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