Tom,

The problem is well stated.

However, one major problem is only touched. You stated the multi-DS0s may be established using multi-link procedure. To the network, these appear as individual calls. The network will route the call such that it reaches the specified endpoint. The network has no concept of routing multiple independent calls by the same path. Since the gateway is only part of network, by what means can it be determined that the interworking of H.320 to H.323 will have all of the applicable DS0 connection at the same gateway? If they do not use the same gateway, how do the endpoints and gateways handle the connection?

Another problem was not discussed. If a H.320 connection arrives at the gateway, how does the gateway know that H.320 to H.323 interworking is required as opposed to the simple transport of the signal to another egress gateway? As a corollary, how does the gateway know that the signal is not voice, and should be transported as 64Kbps clear?

Bob

------------------------------------------------------------------ Robert Callaghan Siemens Information & Communication Networks Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan@ICN.Siemens.com ------------------------------------------------------------------

-----Original Message----- From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] Sent: Monday, April 26, 1999 4:10 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Methods For Support of H.320/H.324

This note fulfils an action item I had out of the last H.GCP conference call. It presents alternative ways to support H.320/H.324 within a multimedia conference.

Statement Of The Problem ====================

The basic connection model issue when dealing with H.320 and H.324 is how to indicate the fact that multiple DS-0 channels are being spanned by a single user's data. A secondary issue is to indicate exactly how these channels are framed to carry the different streams of media and control signals, but that can be done simply by specifying the multiplexer (e.g. H.221) which is being used.

There are a number of potential complications here. First off, the conferencing mode (H.320, H.323, H.324) is generally not known in advance, and must be determined through negotiation. (ITU-T Rec. V.140 describes the various levels of negotiation involved.) This probably implies a requirement for an event reporting package, so the MGC can be aware of the service being provided.

Another complication is that the complete set of DS-0 channels may all be signalled at once as a wideband service, or they be added one at a time through a multilink procedure. This is not a protocol issue so long as the flexibility to add Terminations individually is maintained. Any implementation should bear in mind that the ordering of the DS-0 channels is significant. That constrains the order of addition of Terminations to a Context, but does not actually constrain the representation of the connection.

The Alternatives On The Table ======================

Three basic methods have been proposed for representing the multiplexed n x DS-0 service: * use a separate Context to represent the relationship between the H.320/H.324 session and the n DS-0s which carry it * allow the n DS-0s to appear directly within the Context(s) to which they contribute, using an UserID parameter to indicate their relationship * define a Termination Class where the Terminations are always ephemeral, with the ability to list multiple supporting circuit bearers as part of the instance descriptor.

Preliminary Assumptions ==================

A number of open issues were identified during the preparation of this discussion, which are not directly related to the immediate question but need resolution before we have a complete protocol specification. To simplify the discussion, specific assumptions have been made, as follows:

Issue: how to specify the Termination Class of a Termination. This issue arises especially for new ephemeral Terminations which, for instance, might be RTP-based or some flavour of ATM-based. As an additional "would be nice" consideration, it should be easy for the MGC to recognize the Termination Class of ANY Termination. The assumption made in this discussion is that Termination Class is indicated by the root component of the TerminationID. Thus a request for a new RTP termination may be represented as "RTP/?", where "?" denotes the "choose one" wildcard.

Issue: constraints on the lowest-order component of a TerminationID where this component is assigned by the MG. There are really two issues here: whether the low-order part of the TerminationID has any meaning, and what conditions are required to assure naming uniqueness. Here are some examples to illustrate the potential problems: * Case 1: we decide that a single-channel DS-0 bearing an H.320 session can appear directly in the audio and video contexts to which it contributes. If the name of the DS-0 is "DS-0/15/6" (e.g. channel 6 on transmission facility 15, but this is a matter of local convention), then what do we call the representative of this circuit which appears in the audio context? One possibility is "DS-0/15/6/audio", another is "DS-0/15/6/C7" where "C7" is the context name, a third is "DS-0/15/6/1" where "1" is an arbitrary value assigned by the MG which ensures that the resulting name is unique. The first form, with the "audio" tag, can probably be discarded because it makes the unnecessary assumption that the same physical termination cannot appear in more than one context carrying the same medium. The second form falsely assumes that the Termination will never be moved to another context. This leaves only the third possibility. * Case 2: the same user has two RTP streams, one for video, one for audio. Should there be any relationship between the names of the TerminationIDs representing flows to and from that user? The assumption made in this discussion is that when the MG assigns the low-order component of the TerminationID, it assigns an arbitrary value which is chosen to guarantee uniqueness of the resulting TerminationID.

Issue: single- versus multimedia contexts. This discussion assumes single-medium contexts, just to keep its size reasonable. The alternative is very relevant to the issue at hand, but should be explored in a separate note.

Issue: how does the MGC determine whether the MG should be looking for an H.320/H.324 conference on a DS-0 channel in the first place? We have to think about this one, but it seems likely to me that the answer comes either from the context of the call (e.g. all calls to an MCU-MG are H.32x conferences) or from signalling (e.g. in the bearer capability element). In this discussion I assume that the MGC knows by some means and can tell the MG to look for the appropriate event.

Exploration Of The Alternatives =======================

1. Separate Context To Represent Multiplexing --------------------------------------------------------------------

This proposal represents an H.320/H.324 session as an ephemeral Termination. The Termination appears in a Context with the DS-0 Terminations which support it. It is then used in place of a physical Termination within other contexts representing the actual multimedia conference. The proposal is illustrated below, where MUX/1 is an ephemeral multiplexed Termination supported by two DS-0s, and C2 and C3 represent the audio and video planes of a conference with two other participants.

Context C1 (Multiplex) Context C2 (Audio) |---------------------| |----------------------| | | | | | MUX/1 | | MUX/1/1 | | | | | | | | DS0/1 ---O--- DS0/2 | | | | | | | O | |---------------------| | / \ | | / \ | | RTP/1 RTP/2 | Context C3 (Video) | | |----------------------| |----------------------| | | | MUX/1/2 | | | | | | | | O | | / \ | | / \ | | RTP/3 RTP/4 | | | |----------------------|

Before looking at the syntax this representation implies, let us examine the nature of Context C1. It has one topological peculiarity: there is no intention of any data interchange between the two DS-0 Terminations. One cannot model this as a property of the respective DS-0s, since in another call they could be playing a different role. Thus it has to be a property of the Context as a whole. It seems reasonable to make this a generic multiplexing capability rather than a conferencing-system-specific property, and associate the details of the multiplex (H.221, H.223, ...) with the termination class.

In our discussions, we have determined that a Context may have media type, mixing type, and possibly linkage attributes. We need some sort of "transparent data" media type to denote the role of Context C1, along the "multiplex" mixing type. It is clear in the present case that any linkage will be at the Termination rather than the Context level.

Having said that, let us consider the syntax required to set up the conference. First the multiplexing Context and Terminations are defined:

MGC->MG: TransactionRequest (TransactionID=1); ContextID=? (Medium=transparent data, Mixing=multiplex); Add( MUX/?, ... ); Add( DS0/1 ..., EventDescriptor=(EventID=1, Observe and report conference mode ))); Add( DS0/2, ... -- Sets up the MG to negotiate the conference mode on the first DS-0 and report the outcome to the MGC. The second DS-0 is also placed into the context with the assumption that the MG can figure out the framing from the control signals coming in on DS0/1. At some point someone is going to have to work out what other parameters should be represented here.

MG->MGC: TransactionAccept (TransactionID=1); ContextID=C1; Add accepted (TerminationID=MUX/1); Add accepted; Add accepted

MG->MGC: TransactionRequest (TransactionID=2); Notify( TerminationID=DS0/1, EventID=1, ConferenceMode=H.324) -- the MG has negotiated an H.324 conference. It could also report details such as whether the DS-0 channels are supporting 56kbs or 64kbs transfer rates.

MGC->MG: TransactionAccept (TransactionID=2); Notify accepted; TransactionRequest (TransactionID=3); ContextID=C1; Modify( MUX/1( Transport=H.223)) -- The MGC indicates that H.223 is the particular multiplex in use.

MG->MGC: TransactionAccept (TransactionID=3); ContextID=C1; Modify accepted

Now, assuming that the necessary H.245 signalling is carried out to make this happen, the audio and video contexts are set up and the participants are added.

MGC->MG: TransactionRequest (TransactionID=4); ContextID=? (Medium=audio); Add( MUX/1/? ...); Add( RTP/? ...); Add( RTP/? ...); -- The MGC asks for the RTP terminations and specifies their parameters in accordance with its outgoing H.245 OLC requests. Notice the suggested syntax for requesting a representative of MUX/1 within this context.

MG->MGC: TransactionAccept (TransactionID=4); ContextID=C2; Add accepted (TerminationID=MUX/1/1, ...); Add accepted (TerminationID=RTP/1, ...); Add accepted (TerminationID=RTP/2, ...)

MGC->MG: TransactionRequest (TransactionID=5); ContextID=? (Medium=video, Mixing=...); Add( MUX/1/? SynchWith=MUX/1/1, ...); Add( RTP/? SynchWith=RTP/1, ...); Add( RTP/? SynchWith=RTP/2, ...); -- The video has to be synchronized with the audio. Assumed here that specification of the corresponding audio TerminationID is sufficient because of uniqueness of naming.

MG->MGC: TransactionAccept (TransactionID=5); ContextID=C3; Add accepted (TerminationID=MUX/1/2, ...); Add accepted (TerminationID=RTP/3, ...); Add accepted (TerminationID=RTP/4, ...)

2. Direct Representation Of Contributing DS-0s In Audio and Video Contexts ---------------------------------------------------------------------------- ----------------------------------

Paul Sijbens suggested that we use this approach along with multimedia contexts. It can also be used with single-media contexts, as illustrated here. There are two key issues to resolve: * How to indicate that the DS-0s are carrying H.320 or H.324 data. One possible answer is to indicate in the LocalDescriptor that the transport type is H.221 or H.223 respectively. * How to indicate that the terminations all represent the same H.320/H.324 session. The answer suggested by Paul Sijben is to introduce a linkage parameter, which he suggested calling the UserID. As we shall see, this intra-context linkage is additional to the cross-context linkage required for lip synchronization. The behavioural implication is that Terminations with the same UserID do not send data to each other.

The contexts set up are illustrated below, using the same basic information as in the previous case.

Context C1 (Audio) Context C2 (Video) |----------------------| |----------------------| | | | | | DS0/1/1 DSO/2/1 | | DS0/1/2 DSO/2/2 | | \ / | | \ / | | \ / | | \ / | | O | | O | | / \ | | / \ | | / \ | | / \ | | RTP/1 RTP/2 | | RTP/3 RTP/4 | | | | | |----------------------| |----------------------|

The syntax required to set up the connections according to this procedure looks something like this:

MGC->MG: TransactionRequest (TransactionID=1); ContextID=? (Medium=audio); Add( DS0/1/?, UserID=5764, ..., EventDescriptor=(EventID=1, Observe and report conference mode ))); Add( DS0/2/?, UserID=5764, ... Add( RTP/? ...); Add( RTP/? ...);

MG->MGC: TransactionAccept (TransactionID=1); ContextID=C1; Add accepted (TerminationID=DS0/1/1, ...); Add accepted (TerminationID=DS0/2/1, ...); Add accepted (TerminationID=RTP/1, ...); Add accepted (TerminationID=RTP/2, ...)

MG->MGC: TransactionRequest (TransactionID=2); Notify( TerminationID=DS0/1/1, EventID=1, ConferenceMode=H.324) -- the MG has negotiated an H.324 conference.

MGC->MG: TransactionAccept (TransactionID=2); Notify accepted; TransactionRequest (TransactionID=3); ContextID=C1; Modify( DS0/1/1( Transport=H.223)) Modify( DS0/2/1( Transport=H.223)) -- The MGC indicates that H.223 is the particular multiplex in use.

MG->MGC: TransactionAccept (TransactionID=3); ContextID=C1; Modify accepted Modify accepted

MGC->MG: TransactionRequest (TransactionID=4); ContextID=? (Medium=video, Mixing=...); Add( DS0/1/?, UserID=5764, (SynchWith=DS0/1/1, DS0/2/1), ...Transport=H.223, ...); Add( DS0/2/?, UserID=5764, SynchWith=(UserID=5764 in Context C1), ...Transport=H.223, ...); Add( RTP/?, SynchWith=RTP/1, ...); Add( RTP/?, SynchWith=RTP/2, ...); -- The video has to be synchronized with the audio. A question here: whether we should show a list of SynchWith terminations as shown in the first Add, or whether it would be sufficient to name the UserID and context as in the second Add. Both methods are shown for the reader to think about.

MG->MGC: TransactionAccept (TransactionID=4); ContextID=C2; Add accepted (TerminationID=DS0/1/2, ...); Add accepted (TerminationID=DS0/2/2, ...); Add accepted (TerminationID=RTP/3, ...); Add accepted (TerminationID=RTP/4, ...)

3. Allow Lists Of Supporting Bearers For Terminations ---------------------------------------------------------------------------- ---

This alternative has much of the logical structure of the first one. The bearer list is a shorthand notation for the separate context set up to indicate the multiplexing relationship. The Termination Class itself is a multiplexing class, with the type of multiplex indicated by the transport parameter. In general, we get a more compact version of the first alternative, with one drawback: the list of bearers has to be repeated (for regularity) for each context in which the multiplexing Termination participates. The contexts set up under this alternative are as follows:

Context C1 (Audio) Context C2 (Video) |----------------------| |----------------------| | | | | | MUX/1 | | MUX/2 | | | | | | | | | | | | | | O | | O | | / \ | | / \ | | / \ | | / \ | | RTP/1 RTP/2 | | RTP/3 RTP/4 | | | | | |----------------------| |----------------------|

The syntax for setting these up is as follows:

MGC->MG: TransactionRequest (TransactionID=1); ContextID=? (Medium=audio); Add( MUX/?, Bearers=(DS0/1, DS0/2), ..., EventDescriptor=(EventID=1, Observe and report conference mode ))); Add( RTP/? ...); Add( RTP/? ...);

MG->MGC: TransactionAccept (TransactionID=1); ContextID=C1; Add accepted (TerminationID=MUX/1, ...); Add accepted (TerminationID=RTP/1, ...); Add accepted (TerminationID=RTP/2, ...)

MG->MGC: TransactionRequest (TransactionID=2); Notify( TerminationID=MUX/1, EventID=1, ConferenceMode=H.324) -- the MG has negotiated an H.324 conference.

MGC->MG: TransactionAccept (TransactionID=2); Notify accepted; TransactionRequest (TransactionID=3); ContextID=C1; Modify( MUX/1( Transport=H.223)) -- The MGC indicates that H.223 is the particular multiplex in use.

MG->MGC: TransactionAccept (TransactionID=3); ContextID=C1; Modify accepted

MGC->MG: TransactionRequest (TransactionID=4); ContextID=? (Medium=video, Mixing=...); Add( MUX/?, SynchWith=MUX/1, ... Bearers=(DS0/1, DS0/2), Transport=H.223, ...); Add( RTP/?, SynchWith=RTP/1, ...); Add( RTP/?, SynchWith=RTP/2, ...); -- It seems most natural to create a separate MUX class Termination for each context.

MG->MGC: TransactionAccept (TransactionID=4); ContextID=C2; Add accepted (TerminationID=MUX/2, ...); Add accepted (TerminationID=RTP/3, ...); Add accepted (TerminationID=RTP/4, ...)

Tom Taylor E-mail: taylor@nortelnetworks.com (internally Tom-PT Taylor) Tel.: +1 613 736 0961 (ESN 396-1490) FAX: same number by prior arrangement (manual answer).