Asterisk 11 Development: The Motive for chan_motif

By Matt Jordan

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!

Related Posts

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 joined Digium in July of 2011. Since joining Digium, he has served as lead on the Asterisk open source project, as an Engineering Manager, and as Director of Technology. In June 2016, Jordan was named CTO of Digium. In this role, Jordan is responsible for technology and architectural decisions used in the Company’s product and service offerings.Jordan holds a Bachelor of Science degree in Computer Engineering from Michigan Technological University, and a Master of Science degree in Electrical Engineering from Louisiana State University and multiple patents.

See All of Matt's Articles