<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>

<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2232.0">
<TITLE>RE: H.320 gateways</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I'm in favor of the second approach.</FONT>
</P>

<P><FONT SIZE=2>You could have a termination class H.320 with H.320/audio</FONT>
<BR><FONT SIZE=2>H.320/video and H.320/T.120.  There would be 3 contexts, </FONT>
<BR><FONT SIZE=2>each with different media.  There is a slight ugliness where </FONT>
<BR><FONT SIZE=2>the termination class would define all the parameters for </FONT>
<BR><FONT SIZE=2>all of the streams as one big list, and each of the </FONT>
<BR><FONT SIZE=2>terminations would have all of them.  Unfortunate, but it </FONT>
<BR><FONT SIZE=2>works.</FONT>
</P>

<P><FONT SIZE=2>Christian did not want to infer anything from the name.  </FONT>
<BR><FONT SIZE=2>We would need to have some way for the MG to know which </FONT>
<BR><FONT SIZE=2>media was on which termination if we couldn't infer it from </FONT>
<BR><FONT SIZE=2>the name.</FONT>
</P>

<P><FONT SIZE=2>I like this approach because from the MGC, whether the three </FONT>
<BR><FONT SIZE=2>streams are on one gateway, or multiple gateways, it operates </FONT>
<BR><FONT SIZE=2>on them the same way, only the names are changed (to protect </FONT>
<BR><FONT SIZE=2>the innocent).  The MG is built differently in these cases, </FONT>
<BR><FONT SIZE=2>but I don't see any way around that.</FONT>
</P>

<P><FONT SIZE=2>BTW, the H.320 stream could be multi-ported, so you could have</FONT>
<BR><FONT SIZE=2>H.320/7/video.</FONT>
</P>

<P><FONT SIZE=2>> -----Original Message-----</FONT>
<BR><FONT SIZE=2>> From: John Segers [<A HREF="mailto:jsegers@lucent.com">mailto:jsegers@lucent.com</A>]</FONT>
<BR><FONT SIZE=2>> Sent: Tuesday, March 30, 1999 10:27 AM</FONT>
<BR><FONT SIZE=2>> To: megaco@BayNetworks.COM; ITU-SG16@mailbag.cps.intel.com</FONT>
<BR><FONT SIZE=2>> Subject: H.320 gateways</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> People,</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> In yesterday's conference call, the subject of H.320 GWs was raised</FONT>
<BR><FONT SIZE=2>> briefly. In my opinion, the connection model and protocol </FONT>
<BR><FONT SIZE=2>> should be able</FONT>
<BR><FONT SIZE=2>> to deal with H.320.  I would like to continue discussion on it on the</FONT>
<BR><FONT SIZE=2>> mailing list.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> H.320 allows a user to have a session with both audio and video on a</FONT>
<BR><FONT SIZE=2>> single 64 kbit/s channel such as an ISDN B-channel.  The same channel</FONT>
<BR><FONT SIZE=2>> carries some signalling information (frame alignment, bitrate</FONT>
<BR><FONT SIZE=2>> allocation).  To a MG supporting H.320, this means that on a single</FONT>
<BR><FONT SIZE=2>> endpoint, three streams can come in, carrying different types </FONT>
<BR><FONT SIZE=2>> of media. </FONT>
<BR><FONT SIZE=2>> The current connection model of megaco/H.gcp does not cater </FONT>
<BR><FONT SIZE=2>> to this.  I</FONT>
<BR><FONT SIZE=2>> see two possible solutions:</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> The first is to allow multiple media in one context and to </FONT>
<BR><FONT SIZE=2>> describe for</FONT>
<BR><FONT SIZE=2>> terminations the logical streams they carry.  In a picture:</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>>                       +----------+</FONT>
<BR><FONT SIZE=2>>                       |          |</FONT>
<BR><FONT SIZE=2>>                       |          +--------- signalling (FAS, BAS)</FONT>
<BR><FONT SIZE=2>>                       |          |</FONT>
<BR><FONT SIZE=2>> B-channel   ==========+          +--------- audio (16 kbit/s)</FONT>
<BR><FONT SIZE=2>>                       |          |</FONT>
<BR><FONT SIZE=2>>                       |          +--------- video (46.4 kbit/s)</FONT>
<BR><FONT SIZE=2>>                       |          |</FONT>
<BR><FONT SIZE=2>>                       +----------+</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> The second solution is to have separate terminations for the different</FONT>
<BR><FONT SIZE=2>> streams.  They would all "connect to" the same physical endpoint.  In</FONT>
<BR><FONT SIZE=2>> order to properly identify the terminations, it is necessary to have</FONT>
<BR><FONT SIZE=2>> logical names for them.  The physical endpoint they connect </FONT>
<BR><FONT SIZE=2>> may have the</FONT>
<BR><FONT SIZE=2>> hierarchical name proposed in the megaco document.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Another example of a H.320 session is the case of two B-channels being</FONT>
<BR><FONT SIZE=2>> used for an audiovisual call.  The following frame structure is then</FONT>
<BR><FONT SIZE=2>> possible.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>>    +--------------------------++-----------------------+</FONT>
<BR><FONT SIZE=2>>    | Channel 1                || Channel 2             |</FONT>
<BR><FONT SIZE=2>>    +-----+--+--+--+--+--+--+--++--+--+--+--+--+--+--+--+</FONT>
<BR><FONT SIZE=2>>    |Bit 1|B2|B3|B4|B5|B6|B7|B8||B1|B2|B3|B4|B5|B6|B7|B8|</FONT>
<BR><FONT SIZE=2>>    +-----+--+--+--+--+--+--+--++--+--+--+--+--+--+--+--+</FONT>
<BR><FONT SIZE=2>> 1  | a1  |a2|a3|a4|a5|a6|v1|F ||v2|v3|v4|v5|v6|v7|v8|F | </FONT>
<BR><FONT SIZE=2>> 2  | a7  |a8|a9|a |a |a |v9|F ||v |v |v |v |v |v |v |F |</FONT>
<BR><FONT SIZE=2>> 3  | a   |a |a |a |a |a |v |F ||v |v |v |v |v |v |v |F |</FONT>
<BR><FONT SIZE=2>> 4  | a   |  |  |  |  |a |v |F ||v |              |v |F |</FONT>
<BR><FONT SIZE=2>> 5  | a   |  |  |  |  |a |v |F ||v |              |v |F |</FONT>
<BR><FONT SIZE=2>> 6  | a   |  |  |  |  |a |v |F ||v |              |v |F |</FONT>
<BR><FONT SIZE=2>> 7  | a   |  |  |  |  |a |v |F ||v |              |v |F |</FONT>
<BR><FONT SIZE=2>> 8  | a   |  |  |  |  |a |v |F ||v |              |v |F |</FONT>
<BR><FONT SIZE=2>>    +---------------------------------------------------+</FONT>
<BR><FONT SIZE=2>> 9  | a   |  |  |  |  |a |v |B ||v |              |v |B |</FONT>
<BR><FONT SIZE=2>> 10 | a   |  |  |  |  |a |v |B ||v |              |v |B |</FONT>
<BR><FONT SIZE=2>> 11 | a   |  |  |  |  |a |v |B ||v |              |v |B |</FONT>
<BR><FONT SIZE=2>> 12 | a   |  |  |  |  |a |v |B ||v |              |v |B |</FONT>
<BR><FONT SIZE=2>> 13 | a   |  |  |  |  |a |v |B ||v |              |v |B |</FONT>
<BR><FONT SIZE=2>> 14 | a   |  |  |  |  |a |v |B ||v |              |v |B |</FONT>
<BR><FONT SIZE=2>> 15 | a   |  |  |  |  |a |v |B ||v |              |v |B |</FONT>
<BR><FONT SIZE=2>> 16 | a   |  |  |  |  |a |v |B ||v |              |v |B |</FONT>
<BR><FONT SIZE=2>>    +---------------------------------------------------+</FONT>
<BR><FONT SIZE=2>> 17 | a   |  |  |  |  |a |v |v ||v |              |v |v |</FONT>
<BR><FONT SIZE=2>>  .</FONT>
<BR><FONT SIZE=2>>  .</FONT>
<BR><FONT SIZE=2>>  .</FONT>
<BR><FONT SIZE=2>> 80 | a   |  |  |  |  |a |v |v ||v |              |v |v |</FONT>
<BR><FONT SIZE=2>>    +---------------------------------------------------+</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> (a=audio, v=video, F=FAS, B=BAS).</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> We see that the video stream is split up over two channels.  </FONT>
<BR><FONT SIZE=2>> In order to</FONT>
<BR><FONT SIZE=2>> cater to this, it seems we have to allow terminations to receive media</FONT>
<BR><FONT SIZE=2>> from and send it to multiple physical endpoints.  The two approaches</FONT>
<BR><FONT SIZE=2>> outlined above can both be extended to allow this. Both </FONT>
<BR><FONT SIZE=2>> extensions will</FONT>
<BR><FONT SIZE=2>> lead to the introduction of logical names for terminations.  In the</FONT>
<BR><FONT SIZE=2>> first approach there will be one termination "containing" two </FONT>
<BR><FONT SIZE=2>> B-channels</FONT>
<BR><FONT SIZE=2>> on one side and three logical streams on the other.  In the second</FONT>
<BR><FONT SIZE=2>> approach there will be three terminations, the one for the </FONT>
<BR><FONT SIZE=2>> video stream</FONT>
<BR><FONT SIZE=2>> referencing both B-channels, the ones for signalling and audio</FONT>
<BR><FONT SIZE=2>> referencing only channel 1.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> The second approach allows us to keep separate contexts for different</FONT>
<BR><FONT SIZE=2>> media types.  It is then easy to delete, for instance, the </FONT>
<BR><FONT SIZE=2>> video part of</FONT>
<BR><FONT SIZE=2>> a session (session used loosely to desribe the contexts for the audio</FONT>
<BR><FONT SIZE=2>> and video).</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> The first approach groups the streams coming from/going to one user,</FONT>
<BR><FONT SIZE=2>> making it possible to remove a user from a context more easily.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Personally, I can't decide which approach I would prefer.  </FONT>
<BR><FONT SIZE=2>> How do others</FONT>
<BR><FONT SIZE=2>> feel about these ideas? </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Regards,</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> John Segers</FONT>
<BR><FONT SIZE=2>> -- </FONT>
<BR><FONT SIZE=2>> John Segers                                  email: jsegers@lucent.com</FONT>
<BR><FONT SIZE=2>> Lucent Technologies                                        Room HE 344</FONT>
<BR><FONT SIZE=2>> Dept. Forward Looking Work                      phone: +31 35 687 4724</FONT>
<BR><FONT SIZE=2>> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954</FONT>
<BR><FONT SIZE=2>> </FONT>
</P>

</BODY>
</HTML>