Asterisk 11 Development: The Motive for chan_motif

By Matt Jordan
Share this:Share on Facebook0Tweet about this on TwitterShare on LinkedIn0Pin on Pinterest0

If you’ve been watching the Asterisk trunk subversion repository lately, you may have noticed a new channel driver suddenly appear: chan_motif. And you may have asked, yourself, “Motif? What’s a motif? What new fangled protocol is that?”

Well, we’re going to explain all that, but first, a bit of history.

Back in 02/04/06, what would become chan_jingle was added to Asterisk. At the time, it serviced both what was expected to be the Jingle protocol, as well as Google Talk. Of course, this soon proved to be problematic: the protocol Google implemented wasn’t conforming to the Jingle draft specification! And so, in a rather prophetic sort of way, chan_gtalk was created. The first commit message for chan_gtalk, all the way back on 8/23/06, is the following:

step one seperate jingle from gtalk as this
will make it easier to keep up and then phase out.

As the past six years have shown, there’s nothing quite so permanent as a temporary solution. During this time, the Asterisk developer community has tried to maintain both channel drivers, keeping up with both additions to the Jingle protocol and the moving protocol target that has been Google Talk. In the end, this has not gone as well as we’d like. Some of this is due to the design and implementation of the channel drivers (for example, the fact that there are two of them!); some of this is due to Google changing the protocol of Google Talk. We here at Digium decided last year to ask the developer community to help and take ownership of the two channel drivers. Unfortunately, neither Digium nor the open source developer community has been able to keep chan_jingle/chan_gtalk maintained to the level that any of us have liked.

And yet, six years later, some things have settled down. The Jingle protocol has a robust and concrete specification to base a channel driver on. Google released the 0.5.x branch of the libjingle library (Google Jingle), which is much closer to the Jingle protocol then the old Google Talk protocol. The differences between Google Talk and the Jingle protocol are much more well understood then they were at the time the original channel drivers were written. All of this has resulted in a state where the rate of change is considerably slower.

After a lengthy period of investigation and research, we decided to resolve the temporary solution and combine the functionality of chan_jingle and chan_gtalk into a single channel driver. This new channel driver would unify support for Jingle, Google Jingle, and Google Talk in a single channel driver. Unfortunately, creating a drop in replacement for chan_jingle would require tying the implementation of the resulting channel driver into some of the same design decisions that limited us initially – and so we opted for a brand new channel driver. And thus was born chan_motif.

The chan_motif channel driver is a replacement for both chan_gtalk and chan_jingle but adds additional features not found in either. This includes:

  1. Full compliance with the Jingle and Google Jingle specifications, as well as compatibility with the Google Talk specification for Google Voice interoperability
  2. Full configuration reload
  3. Full video/codec support
  4. Bidirectional cause code mapping
  5. Hold/Unhold/Ringing indications

The new chan_motif channel driver will be a core supported channel driver in Asterisk. We plan to fix any XEP compliance issues, and hope that this will provide a more robust mechanism for supporting Jingle/Google Jingle/Google Talk.

And now: why chan_motif?

Motif: a perceivable or salient recurring fragment or succession of notes.

Sort of like… a jingle!

There Are 9 Comments

  • SirLouen says:

    Don’t like the name because is too abstract and I you have not read the evolution of this idea, it will be difficult for someone recently introduce to relate it…. For technical regards, I believe that names must be as near to reality as possible. In this case, a name like “chan_jingletalk” could have been even better.

  • Ward Mundy says:

    So it was too difficult to maintain two drivers but, by combining three new drivers into chan_motif, all will be well and easier to maintain. Makes sense to me.

  • @SirLouen well, I won’t go so far as saying: “I don’t like the name” – however, being an old Linux/Unix admin, for me the word Motif says something completely different. When I read the words – chan_motif, I immediately thought: “wow, a way to create an X-Windows Motif application that is tied directly to Asterisk – Crazy, but Cool”.
    After reading the history – considering that I’ve used both chan_jingle and chan_gtalk, I can surely understand why chan_motif suites the purpose – just hope that the people at “The Open Group” don’t get pissed at using the name “motif”.

  • Mark Willis says:

    I thought X-Windows too. Anything that fixes chan_gtalk is welcome.

  • Zohair says:

    Is there any plan to support raw-udp transport?

    Spark’s jisti jingle plugin is using it.

  • Tony Hain says:

    It is nice that the Gtalk problem is understood and there is a solution, but given that 1.8 is the only supported version with an optware build, it would seem appropriate to post a motif driver for 1.8. Call it a feature if you want, but the non-functional existing driver is fundamentally a bug, so ‘supported’ implies that it gets fixed. I understand the reasons for changing to a different driver, but that act only underscores the need to fix the one currently downloadable LTS version.

  • Sanjay says:

    Hi thanks for this update

    Is there a backport to other asterisk versions?

  • Negative. We will not undertake a backport of chan_motif to previous versions of Asterisk.

  • William Howell says:

    Since there are a lot of us using GV & Asterisk before the new channel driver was developed I would think that us “users” would have been taken into consideration and a backport been developed. As it stands now, those of us that have a great working asterisk machine have to up grade in order to continue using GV & Asterisk since it stoped working. Doesn’t settle well with us Asterisk users. Nothing like being left out in the cold.

Add to the Discussion

Your email address will not be published. Required fields are marked *

About the Author

Matt Jordan

Matt Jordan is an Engineering Manager for the Open Source Software team at Digium, working on Asterisk. Matt joined the team in 2011, and since then has been involved in the development of both Asterisk and the Asterisk Test Suite. His background in software development can best be described as "eclectic", having worked in a variety of industries. Uniting the various experiences, however, is a firm belief in good software development practices and methodologies and the effect they have on producing quality software (and keeping software developers from going insane).

See All of Matt's Articles