Asterisk H324M

Asterisk as 3G-H.324M ? SIP Gateway

Update to this page:

A new Wiki page is created to collect compatibility information about app_h324m: Asterisk app_h324m compatibility

Update to this page:

As with 2008-01-16 (and long before), H324M calls work with Asterisk. By using app_h324m from sip.fontventa.com and lib324m you can receive incoming H324M calls and make outgoing h324m calls. You can either forward the video call to other channels (e.g. SIP - make sure AMR codec is installed/patched) or record and playback video. DTMF works too.

Update to this page:

As with 2007-09-01, incoming H324M calls work with Asterisk. By using app_h324m from sip.fontventa.com you can receive incoming H324M calls and can for example stream back .3gp video files. Even AMR transcoding is working.

Update to this page:

As with 2007-03-19 there is existing code for H.324M for Asterisk. There are 2 different projects working on H.324M. (None of the code is included in Asterisk. Thus, you have to install the additional applications yourself)

1. app_h324m

This project can be found at http://sip.fontventa.com/. Note: you also have to install pwlib (OpenH323 at sourceforge). There are reports that the gateway functionality works with mpeg4 videos and with AMR codec.

2. lib3gpph324m

This project can be found on http://sourceforge.net/projects/lib3gpph324m/. There code is in the sourceforge SVN repository. There are no reports about its functionality and it lacks documentation.

Note: If you want to test H.324M with Asterisk please read the asterisk-dev mailing list archive and read the recent threads (Feb, March 2007) about h.324, app_mp4 and AMR.

Original page:

3G-H.324M is the standard used in UMTS 3G phones to enable video calls between UMTS users. But H.324M is not bound to the UMTS networks, but also works on ISDN channels. So, why not extend asterisk to act as H.324M-SIP Gateway? This way you could receive video calls from mobile terminals on your favorite video client (Windows Messenger, eyebeam, kphone ...). That was my idea behind this project.

First of all the bad news: There is no code available! I stalled the project because of its complexity and time limitations. However, after some postings on the asterisk mailing list, several people asked me about my efforts and offered to do some work. Therefore, I created this page to give you all the information I know on how to do it yourself. You are also welcome to post your opinions and extend this page with useful information.

H.324M, like its predecessor H.324 is a complex protocol suite. You can find a good introduction to H.324M at: http://www.dilithiumnetworks.com/news/Media%20Coverage/IEEE_Multimedia_04July.pdf (link now broken)
Article is still available through the IEE if you are a subscriber, or if you pay: http://www.computer.org/portal/web/csdl/magazines/multimedia#4

You can buy all the relevant ITU-T standards from the ITU homepage. Unfortunately, they are not available freely. But if you know some technical guys from the Telco, ask them for the standards. They will probably have the complete collection on DVD.

If you are using H.324M in the PSTN, it uses a 64kBit data channel. Thus, ISDN Q.931 signaling will be used to setup a B-channel prior to any H.324M activity. When the ISDN signaling is done (the B-channel between the H.324M devices), the setup procedure will proceed in the established B-channel. H.223 will be used to multiplex the various logical channels (audio, video, control) over the B-channel. One logical channel will be established implicitly for enabling call control using H.245. Depending on the mobile level of H.223, the H.223 packets will be delimited using HDLC flags (01111110) (mobile level 0), 16 bit flags (level 1), or more complex flags (level 2 and 3).

Immediately after establishing the B-channel, the 2 clients have to agree on a H.223 mobile level. Therefore they are consecutively sending the flags to indicate their mobile level capabillities. Simultaneously the clients are analyzing the received flags to identify the mobile level of the remote client. If the mobile levels differ, the clients have to fall back to a mobile level supported by both clients.

Practical H.324M
To distinguish H.324M calls from normal voice calls, the "User information layer 1" will be used: (btw: the debug output of asterisk is wrong - it should be "H.324M" instead of "G.7xx 384k Video")

> pri debug span 1
< Bearer Capability (len= 3)
Ext: 1 Q.931 Std: 0 Info transfer capability:
Unrestricted digital information (8)
Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16)
Ext: 1 User information layer 1: G.7xx 384k Video (38)

Usually, you will translate SIP to ISDN call control (D-channel) and the RTP stream into the ISDN B-channel.


Here it is different. SIP must be translated to H.245 and the RTP stream into the respective codec (AMR, MPEG4), and all of them will be multiplexed into the B-channel.


This rises the first question: Should it be implemented as channel or application? IMO it is a channel on top of an existing PSTN channel (zaptel, capi ...) which will be bridged to an VoIP channel (SIP, H.323). I do not know the internals of asterisk, thus I do not know if it is possible to implement a channel on another channel. It could also be integrated in the zaptel channel, but this bad as incoming calls can also arrive on other PSTN channels, e.g. CAPI. Thus, the PSTN ?transport channel? (zaptel, capi) has to analyze the ?user information layer 1? data and activate the H.324M channel if incoming video is signalled.

So, what have I done yet?
Up to now I wrote s small application which uses f=ast_read(chan); to read a frame from the B-channel and later dumps the data to a file (for analyzing the received bit stream). Is there a better way to retrieve the unmodified stream from the B-channel? Is the order of bytes/bits in f->data the same as received on the B-channel? (I'm currently having some byte sex and byte order problems).
I tried to find the bit-patterns of the flags (= frame delimiters) defined in H.223 Annex A and C in the dumped bitstream. Sometimes, I could find some patterns after changing the byte sex of the dump file but I couldn't reproduce the handshake for the mobile capability level.

The better mobile levels use a Golay (24,12) code to be resistant against bit errors. Googling revealed several Golay(23,12) coder/decoder, and one for (24,12).
There is an implementation of a fast C algorithm for Golay(24,12) at http://wireless.nmsu.edu/hf/papers/Golay_Codec.pdf.
For the H.223 multiplexer, we probably can reuse some code/ideas from the ?UCLA/Samsung H.223 Multiplex Simulator? at http://www.icsl.ucla.edu/~wireless/. (Downloading the code was a PITA as their java based download site is buggy. If it also does not work for you, you can bypass it).

The application is called zapdump and it just receives the stream and write it into a file. I don't know if the applications are fine - I couldn't find any docs about the zap-frame structure. Thus I'm not sure if the applications write the correct stream (the plain bits received on the B-channel) into the file. Just call the application from extensions.conf like a normal application and specify the location of the file - e.g.:
exten => 103,1,ZapDump(/tmp/zapdump)

I've collected some zapdumps and ISDN signaling logs.

Some information in endian and byte sex problem can be found in here:
Clarification of the bit-order for transmission of 3G-324M: http://www.imtc.org/activity_groups/act_3g324m/docs/LiaisionStatement-SA4-030122.pdf

Once the H.223 part is done, we need to implement H.245 for call control. H.245 is also used in H.323, thus maybe we can share code from the h323 channels or other H.323 projects.

The mobile phones use AMR as audio codec and H.263 as video codec (MPEG4 is also defined but I was told that current handsets only use H.263). There are 2 ways to bring the media to the SIP client:

1. Send the received media frames without transcoding to the SIP client. Therefore, the SIP client has to support the AMR codec and H.263. (Is there any SIP client that supports AMR?). Probably, asterisk has to do some framing/buffering to adopt the media stream and send it via RTP.
2. Asterisk talkes AMR and H.263 and transcodes the media to an other format. This is more complex but enables media sessions with dumb clients.

The AMR codec is patented (like G.729), thus transcoding will end up with license issues like with G.729. Neverthless, there is source code for an AMR codec available from 3GPP. Refer to:

If you have comments feel free to extend this page. You can contact me at: klaus dot darilion at nic dot at
For implementation discussion, the Asterisk Developers Mailing List <asterisk-dev@lists.digium.com> will be more suitable.

Some comments I received from other developers

Hi Klaus!
I'm in the middle of an H.223 implementation at the moment, and your zapdump files have provided a useful (initial) set of test data. You probably know this already, but the repeating sequence of (87 b2 00 00 00) is a bit-reversed Annex A framed PDU.

Within the PDU, the header is 00, so MC = 0, HEC = 0, PM = 0.

(DK - this isn't correct. This is - I think - a three byte header (see B.3.2.1) which encodes a zero-length PDU, and is specified somewhere in H.223 Annex B as the thing to send if you're marking time.)

Multiplex Code 0 refers to the Logical Channel 0, which is the H.245 control channel. I'm assuming the two-byte zero SDU encodes an empty H.245 packet, which just says "I'm alive and I speak Annex A"!

> > The H.324 spec figure I.2/H.324 on page 65 shows ML0 octets
> > being bit swapped before transmission
> yes, that's true. haven't seen this yet. This explains why the zapdump
> files have wrong bytesex.

I wrote a noddy program to bit swap the whole file.

  1. include <tiffio.h>
  2. include <stdio.h>

int main() {
unsigned char octet[1];
while(fread( &octet, 1, 1, stdin) == 1){
TIFFReverseBits(&octet, 1);
fwrite( &octet, 1,1,stdout);

gcc -o mytest -ltiff -lm mytest.c

./mytest < zapdump-A1_Mobilkom_Nokia_6630_3.45.113.bin > zapdump-A1_Mobilkom_Nokia_6630_3.45.113.bsw

od -t x1 zapdump-A1_Mobilkom_Nokia_6630_3.45.113.bsw > zapdump-A1_Mobilkom_Nokia_6630_3.45.113.txt

The only MUX-PDUs I could find in both files were 'e1 4d 00 00 00'. Which appear to be ML1 but with blank header octet and two blank trailing payload octets.

ITU-T recommendations:

3GPP documents (freely available from http://www.3gpp.org/ftp/Specs/html-info/)
TS 26.110
TS 26.111
TS 26.112 (Withdrawn and transferred into TS 24.008)

3G-H.324M Tutorials:
Diploma thesis about ?Real Time Video Transmission in UMTS?: http://siving.hia.no/ikt01/ikt6400/fohansen/Real_Time_Video_Transmission_in_UMTS.doc
Created by: klaus3000, Last modification: Mon 23 of Apr, 2012 (22:35 UTC) by admin
Please update this page with new information, just login and click on the "Edit" or "Discussion" tab. Get a free login here: Register Thanks! - Find us on Google+