H.320 gateways a MEGACO / ITU

Ami Amir amir at RADVISION.RAD.CO.IL
Wed Mar 31 04:14:57 EST 1999


During the last MEGACO conference call - Tom Taylor asked what could hinder
ITU acceptance of the MEGACO work. It is obviously to everybody's interest
that IETF and ITU standards merge. As an example - it would be great if the
MEGACO work could become an ITU SG 16 contribution.

An obvious item is efficient multimedia support (as reflected also in John's

However, I think that one of the even more major difficulties facing us will
be the encoding scheme (ASN.1 vs Text).

There are many who feel that ASN.1 is too heavy and complex for simple
devices, and should be avoided. This was one of the major reasons for the
emergence of SIP.

On the other hand, experience in the ITU H.323 work has shown that since
ASN.1 is the encoding scheme on the PSTN side, the use of ASN cleared the
way for PSTN to IP interoperability. This feature will be extremely
important in hybrid networks that need to provide Intelligent Network (IN)
services (e.g. "800"), while retaining the investment in existing IN,
billing and directory services (411).

Another problem is that if ASN.1 is not chosen, every device that will have
to connect between a MEGACO component and H.323 will need to dis-assemble
and re-assemble (transcode) messages, and hence network performance will
suffer, and those devices will be more complex. A prime example - MGC to GK

I am not promoting a specific approach. I just think that this complex issue
needs to be addressed if we want to be able to be able accept a universal

Do you think this is really a problem?
If so - any ideas on how to bridge the gap?


        -----Original Message-----
        From:   John Segers [SMTP:jsegers at lucent.com]
        Sent:   Tuesday, March 30, 1999 6:27 PM
        To:     ITU-SG16 at mailbag.cps.intel.com
        Subject:        H.320 gateways


        In yesterday's conference call, the subject of H.320 GWs was raised
        briefly. In my opinion, the connection model and protocol should be
        to deal with H.320.  I would like to continue discussion on it on
        mailing list.

        H.320 allows a user to have a session with both audio and video on a
        single 64 kbit/s channel such as an ISDN B-channel.  The same
        carries some signalling information (frame alignment, bitrate
        allocation).  To a MG supporting H.320, this means that on a single
        endpoint, three streams can come in, carrying different types of
        The current connection model of megaco/H.gcp does not cater to this.
        see two possible solutions:

        The first is to allow multiple media in one context and to describe
        terminations the logical streams they carry.  In a picture:

                              |          |
                              |          +--------- signalling (FAS, BAS)
                              |          |
        B-channel   ==========+          +--------- audio (16 kbit/s)
                              |          |
                              |          +--------- video (46.4 kbit/s)
                              |          |

        The second solution is to have separate terminations for the
        streams.  They would all "connect to" the same physical endpoint.
        order to properly identify the terminations, it is necessary to have
        logical names for them.  The physical endpoint they connect may have
        hierarchical name proposed in the megaco document.

        Another example of a H.320 session is the case of two B-channels
        used for an audiovisual call.  The following frame structure is then

           | Channel 1                || Channel 2             |
           |Bit 1|B2|B3|B4|B5|B6|B7|B8||B1|B2|B3|B4|B5|B6|B7|B8|
        1  | a1  |a2|a3|a4|a5|a6|v1|F ||v2|v3|v4|v5|v6|v7|v8|F |
        2  | a7  |a8|a9|a |a |a |v9|F ||v |v |v |v |v |v |v |F |
        3  | a   |a |a |a |a |a |v |F ||v |v |v |v |v |v |v |F |
        4  | a   |  |  |  |  |a |v |F ||v |              |v |F |
        5  | a   |  |  |  |  |a |v |F ||v |              |v |F |
        6  | a   |  |  |  |  |a |v |F ||v |              |v |F |
        7  | a   |  |  |  |  |a |v |F ||v |              |v |F |
        8  | a   |  |  |  |  |a |v |F ||v |              |v |F |
        9  | a   |  |  |  |  |a |v |B ||v |              |v |B |
        10 | a   |  |  |  |  |a |v |B ||v |              |v |B |
        11 | a   |  |  |  |  |a |v |B ||v |              |v |B |
        12 | a   |  |  |  |  |a |v |B ||v |              |v |B |
        13 | a   |  |  |  |  |a |v |B ||v |              |v |B |
        14 | a   |  |  |  |  |a |v |B ||v |              |v |B |
        15 | a   |  |  |  |  |a |v |B ||v |              |v |B |
        16 | a   |  |  |  |  |a |v |B ||v |              |v |B |
        17 | a   |  |  |  |  |a |v |v ||v |              |v |v |
        80 | a   |  |  |  |  |a |v |v ||v |              |v |v |

        (a=audio, v=video, F=FAS, B=BAS).

        We see that the video stream is split up over two channels.  In
order to
        cater to this, it seems we have to allow terminations to receive
        from and send it to multiple physical endpoints.  The two approaches
        outlined above can both be extended to allow this. Both extensions
        lead to the introduction of logical names for terminations.  In the
        first approach there will be one termination "containing" two
        on one side and three logical streams on the other.  In the second
        approach there will be three terminations, the one for the video
        referencing both B-channels, the ones for signalling and audio
        referencing only channel 1.

        The second approach allows us to keep separate contexts for
        media types.  It is then easy to delete, for instance, the video
part of
        a session (session used loosely to desribe the contexts for the
        and video).

        The first approach groups the streams coming from/going to one user,
        making it possible to remove a user from a context more easily.

        Personally, I can't decide which approach I would prefer.  How do
        feel about these ideas?


        John Segers
        John Segers                                  email:
jsegers at lucent.com
        Lucent Technologies                                        Room HE
        Dept. Forward Looking Work                      phone: +31 35 687
        P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687

More information about the sg16-avd mailing list