Methods For Support of H.320/H.324
Tom-PT Taylor
taylor at NORTELNETWORKS.COM
Mon Apr 26 16:10:10 EDT 1999
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 at nortelnetworks.com (internally Tom-PT Taylor)
Tel.: +1 613 736 0961 (ESN 396-1490)
FAX: same number by prior arrangement (manual answer).
More information about the sg16-avd
mailing list