Subject: Context/Termination/Stream configurations.

From: "Willy Reheul" <[email-masked]>
Date: Mon, 12 Mar 2001 20:31:59 -0000

Hi List,

Assume an Interior Media Gateway interworks the 3 media streams (Video1,
Video2 and Audio2) between a calling and a called H.323 terminal. Audio2 is
associated with Video2.
In my opinion, a session controller can think of 3 different ways for the
IMG to handle this:

/1/. 3 contexts with each 2 terminations (Tin & Tout) in it and one stream
(ID=1) on each termination.

                        +------------------C1----------------+
                        !                                    !
           Video1--->---! T1in........streamID1........T1out !------>----
                        !                                    !
                        +------------------------------------+

                        +------------------C2----------------+
                        !                                    !
           Video2--->---! T2in........streamID1........T2out !------>----
                        !                                    !
                        +------------------------------------+

                        +------------------C3----------------+
                        !                                    !
           Audio2--->---! T3in........streamID1........T3out !------>----
                        !                                    !
                        +------------------------------------+

/2/. 1 context with 6 terminations (3 (Tin & Tout)pairs)) in it, and each
pair of Tin-Tout connects 1 stream. StreamID's must be different, else the
context would also mix amongst T1, T2 and T3.

                        +------------------C1----------------+
                        !                                    !
           Video1--->---! T1in........streamID1........T1out !------>----
                        !                                    !
                        !                                    !
           Video2--->---! T2in........streamID2........T2out !------>----
                        !                                    !
                        !                                    !
           Audio2--->---! T3in........streamID3........T3out !------>----
                        !                                    !
                        +------------------------------------+

/3/. 1 context with 2 terminations -one (Tin & Tout)pair, the terminations
connect all 3 streams. (there are of course 3 different transport addresses
associated with each T1)

                        +--------------------C1------------------+
                        !  +----+                        +-----+ !
           Video1--->---!--!    !........streamID1.......!     !-!----->----
           Video2--->---!--!T1in!........streamID2.......!T1out!-!----->----
           Audio2--->---!--!    !........streamID3.......!     !-!----->----
                        !  +----+                        +-----+ !
                        +----------------------------------------+

QUESTION :

Is there any difference between the three configurations ?
I'm in particular interested in Media Processing differences -such as
synchronisation, network jitter treatment, etc......-.
For example what do I have more or different when all 3 streams are
connected to 1 termination (as in configuration /3/) compared to  the other
configurations ?

Thanks,
Willy

---

From: "Yang, Margaret H (Margaret)" <[email-masked]>
Date: Wed, 14 Mar 2001 11:27:48 -0600

Willy/Brian,
My comments below.
Margaret Yang
> ----------
> From: 	Willy Reheul[SMTP:[email-masked]]
> Sent: 	Tuesday, March 13, 2001 2:42 PM
> To: 	Rosen, Brian; [email-masked]
> Subject: 	RE: Context/Termination/Stream configurations.
> 
> So, I think I may conclude that a session controller may choose whatever
> configuration it prefers. It wan't make any difference on HOW media tools
> in
> the gateway process the streams; except that for configuration #3 -where
> one
> termination connects multiple streams- these multiple streams will be
> brought in sync with each other before they leave the termination.
> Do I have that right ?
[MY] 
By choosing one of the three configurations, the session controller in fact
has specified 'how' the MG should handle the streams. That is, #1 ->
translator, #2 -> translator, #3 -> mixer. Why?

a. #3 requires mixing since H.248 stipulates multiple streams within a
termination must be synchronized with each other. 
b. #1 & #2 requires no mixing, and since translator is much cheaper than a
mixer, you don't use a mixer unless it's needed. In fact, most MGs don't
usually have mixer equipped except some special MGs that are designed to
handle conference or other mixing functions.

So Brian's statement "the MG should be able to handle all 3" is true only in
theory. In practice, only a small set of MGs (if any) that are equipped with
mixer would be able to support config 3. That means the session controller
needs to decide what function it expects the MG to perform, for example,
synchronization of multiple streams or not, before it decides which config.
option to use. 

In addition, the session controller needs to know which MG has the
capability to handle mixing if config. 3 is chosen. If config. 3 is sent to
an MG without mixer,  the error scenario would be like this -
The first stream is successfully added to a termination (MG would assume
it's just a simple translator case), then when the second stream is added,
the MG will have to reject the second stream since it has no resource to
handle the mixing.

This points out a problem with H.248v1 (as I mentioned in a different thread
'Megaco relationship to RTP') - 

When allocating a mixer, its resource is allocated in terms of number of
ports. Furthermore, it is necessary to know in advance the maximum number of
ports (i.e., # of streams) the mixer is required to handle. This is not
supported by H.248v1 base protocol and needs to be fixed either in H.248v2
or with a conference/mixer package. Without the fix, you can run into
various problems. For example, as described above, when the request is sent
to an MG without a mixer, the first stream (or first caller) is connected,
but then has to be dropped  later when a new stream is to be added. Another
example, even if the MG can do the mixing, there is no hint a mixer will be
required for this call. The MG will again just allocate a translator for the
first stream. Then, when the request for second stream arrives, it will have
to allocate two ports from a mixer for the first and second stream, and
release the translator resource allocated earlier for the first stream. Yet
another problem, if a mixer DSP is capable of handling 6 ports for example,
of which 4 ports were allocated for other calls, when a new call arrives,
first two streams can be added using the remaining two ports. But if the
call requires to add another stream, what do we do? Move all 3 to a new
mixer and free the ones allocated previously or just reject the new stream?
not a good solution either way.

> If yes, can you also point me to a place in the megaco standard or
> implementation guide where such feature/behaviour of a Termination is
> described.
> 
> ".....I would recommend that you not ever consider #2......." sounds like
> a
> severe warning. I don't think that configuration #2 deserves such strong
> disadvice. In my opinion Topology is not even needed ie "default" Topology
> will do. This is because each Tin-Tout pair has been given a different
> streamID and inside a context there are only connections between equal
> streams. Hence, no danger that for example T1in connects to streamID2 or
> streamID3. Correct ?
> 
> Cheers,
> Willy Reheul
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Rosen, Brian
> > Sent: maandag 12 maart 2001 21:40
> > To: 'Willy Reheul'; [email-masked]
> > Subject: RE: Context/Termination/Stream configurations.
> >
> >
> > The preferred configuration is #3. Note that the media gateway should be
> > able to handle all 3,
> > although the limitation that streams be synchronized leaving the
> > termination
> > would only be of
> > help to you in #3.
> > I would recommend that you not ever consider #2,
> > although with Topology,
> > you can make it work.  Of course, you could have hybrids - say 2
> contexts,
> > each with two
> > terminations, with audio2 and video2 in one and audio 1 in the other.
> I'd
> > still stay with
> > #3, as it most closely maps to the way Megaco is defined.
> >
> > I don't think there are any jitter implications of any configuration, as
> > jitter processing is per
> > stream.
> >
> > >  -----Original Message-----
> > > From: 	Willy Reheul [mailto:[email-masked]]
> > > Sent:	Monday, March 12, 2001 3:32 PM
> > > To:	[email-masked]
> > > Subject:	Context/Termination/Stream configurations.
> > >
> > > Hi List,
> > >
> > > Video2 and Audio2) between a calling and a called H.323 terminal.
> Audio2
> > > is associated with Video2.
> > > connect all 3 streams. (there are of course 3 different transport
> > > addresses associated with each T1)
> > >
> > >
> > > connected to 1 termination (as in configuration /3/) compared to  the
> > > other configurations ?
> > >
> > > Thanks,
> > > Willy
> > >
> >
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 14 Mar 2001 16:51:58 -0500

I don't agree with your analysis.

An H.323 end terminal is required to synchronize the multiple
streams.  If you implemented such a device as a Megaco controlled
MG, you would use #3 with a physical and an ephemeral.  No mixer.

The specific example is a mid-stream gateway (say, AAL2 to IP/UDP/RTP)
It does not need a "mixer", but it might have to do some buffering
to maintain synch.

I also don't think there is any problem with the translator/mixer
problem you raised, although I'll agree we could make things better
in V2.

First of all, all the devices I know that can do translation AND
mixing in one box use common hardware (e.g. DSP), and don't have
any problem evolving a translation function to a mixing function.
Secondly, the terminations and contexts are, for mixing devices,
almost always ephemeral, not physical, so you can remap the hardware
inside the device without changing the terminations.  

Finally, almost all implementations I know have the MGC allocating
resources, not the MG.  So the MGC decides which ports (mix or
translate) to use, not the MG.

Brian

> From: Yang, Margaret H (Margaret) [mailto:[email-masked]]
> Sent: Wednesday, March 14, 2001 12:28 PM
> To: Willy Reheul
> Cc: [email-masked]

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 15 Mar 2001 05:23:30 -0500

I wouldn't use any of your three configurations.  Audio 2 and Video 2 have
to be synchronized.  This means they have to come through a common
termination.  Video 1 is not synchronized with the others, so pass it
through another termination.  These are disjoint connections, so use two
contexts.  Here's my proposed solution:

	                        +------------------C1----------------+
	                        !                                    !
	           Video1--->---! T1in........streamID1........T1out
!------>----
	                        !                                    !
	                        +------------------------------------+

	                        +--------------------C2------------------+
	                        !  +----+                        +-----+ !
	                        !--!    !                        !     ! !

Video2--->---!--!T2in!........streamID1.......!T2out!-!----->----
	           Audio2--->---!--!    !........streamID2.......!
!-!----->----
	                        !  +----+                        +-----+ !
	                        +----------------------------------------+

> To:	megaco
> Video2 and Audio2) between a calling and a called H.323 terminal. Audio2

---

From: Danny Levin <[email-masked]>
Date: Fri, 23 Mar 2001 12:25:47 -0500

Brian,

"Multiple streams exiting a termination shall be synchronized with each
other" , is confusing when there are several voice and video streams (more
than one from each type) within one termination.

What does it mean to sync. 2 voice streams with 2 video streams from the MG
perspective ?

Unless the MG "create" a new stream (i.e.. mixer) the sync. is done by the
receiver of these streams. Therefore this statement is confusing for MG
which only routes the streams.

In addition a Termination shares common descriptors (such as state, events &
signals - not just streams !!!) . Therefore you might want to share a
termination even if the streams should not be sync.

Bottom line we need to clarify this statement in the spec.

Danny.

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Friday, March 16, 2001 3:43 PM
To: 'Willy Reheul'; Yang, Margaret H (Margaret)
Cc: [email-masked]
Subject: RE: Context/Termination/Stream configurations.

Excuse me, but all streams exiting a termination are synchronized.
If the MG puts terminations in a context, then the streams
existing those terminations are synchronized.  If you don't want them
to be synchronized, don't use the same terminations (that was
Tom Taylor's point about putting video 1 in a separate context).

What more is there?

Brian

> Sent: Friday, March 16, 2001 4:16 PM
> To: Yang, Margaret H (Margaret); Rosen, Brian
> Cc: [email-masked]
> I think that I can agree with all of this:
> -Indeed, the receiving H.323 end terminal is required to 
> synchronize the
> multiple streams he receives (there is no need for the IMG to do
> synchronisation);
> -Also, all what is said about DSPs may be a way of 
> implementing things;
> -All the terminations in my example are indeed ephemeral;
> -The MGC may allocate the resources, although in my example 
> MG does that;
> -MGCs can indeed think of plenty more IMG "hybrid" connection 
> configurations
> to support the transcoding which is needed in my example; the 
> different
> streams even can go through different IMGs;
> -Surely DSPs don't have any problem evolving a translation 
> function to a
> mixing function: a simple addition of a third termination in a
> two-termination context must turn the translator into a mixer;
> -etc.............but I'm not really after any of this.
> 
> What I want to know is: WHAT IS THE IMPACT OF A PARTICULAR CONNECTION
> CONFIGURATION IN THE IMG (connection configuration expressed 
> in terms of
> context/termination/stream) ON THE CONTENT OF THE RTP STREAMS 
> ? Suppose we
> could dump/visualise the rtp packets at output of any Tout, 
> would they in
> all cases of IMG configuration look the same, or would the 
> IMG configuration
> #1 process the rtp streams that enter the IMG at any Tin 
> differently than
> configuration #2 and again differently than configuration #3 
> ? This is where
> I would like to have an answer on.
> 
> Why the importance ?
> The sending H.323 terminal has done all the necessary to make 
> sure that the
> receiving H.323 terminal CAN DO lip synchronisation on 
> associated streams.
> The IMG -together with its controlling MGC- therefor BETTER 
> DOES NOT DO
> anything on the rtp streams that obstructs/prevents lip 
> synchronisation by
> the receiving H.323 terminal.
> 
> What would be such obstruction ?
> IMG 'processes' one of the rtp streams (either Video2 or Audio2 in my
> example) in a different way than the associated stream.
> 
> What's the important rtp stream (packet) element -used for lip
> synchronisation- that IMG better does not change differently 
> in associated
> streams ?
> It is the SSRC (synchronisation source). The sending H.323 
> terminal encodes
> and packetizes all its streams using one and the same clock. 
> As long nobody
> along the way through the packet network 're-encodes' this 
> streams (this
> could for example be an IMG to do the required format 
> transcoding) using a
> different clock (this will then be IMG's own clock which is 
> different from
> the sending H.323 terminal's clock), the called H.323 
> terminal will have no
> problem to playback in a lip synchronous way. Problems only 
> start when IMG
> chooses to change the SSRC of the one or the other stream 
> using its own
> clock. The receiving H.323 terminal could then for example receive
> Video2 -packetized/timestamped according the H.323 clock-, and the
> associated Audio2 -(re)encoded/packetized using the IMG clock-. The
> receicing H.323 terminal has now no means anymore to synchronise both
> streams, no matter how deep he buffers.
> 
> Other wording for changing the SSRC is 'mixer behaviour' (means not
> necessarily that multiple streams are mixed). Other wording 
> for keeping the
> SSRC intact is 'translator behaviour'.
> 
> What's now the MGC problem ?
> There is nothing provided in the megaco protocol to control 
> the media tool
> w.r.t. SSRC ie MGC cannot instruct the IMG media tool to act 
> as translator
> or to act as mixer; neither on a stream, nor on a 
> termination, nor on a
> context base. So I assume that IMG chooses whatever he likes 
> to do (??)
> Thus, MGC can by no means ensure that he sets up a connection 
> configuration
> in that IMG that guarantees that a receiving H.323 terminal 
> will be able to
> realise lip synchronisation. This is not a healthy situation.
> 
> Is there a solution ?
> Maybe : although there is no such explicit control for the 
> latter, there may
> be an implicit control (?) In other words, the connection 
> configuration
> (context/termination/stream) itself may determine how rtp 
> packets inside the
> connection configuration are treated: either translator 
> behaviour or mixer
> behaviour.
> If that is the way megaco works (?) the MGC must setup the right
> configuration to have a desired rtp treatment, and may no 
> longer blindly
> choose amongst all 3 basic -and possibly many more hybrid- 
> configurations.
> 
> Now, if I could know how a connection configuration 
> influences rtp packet
> processing I will be able to set the right IMG configuration 
> for my case;
> else I'm not able.
> 
> After last few days discussions in this thread I'm pretty sure that
> configuration #1 and #2 keep streams's SSRC intact 
> (=translator behaviour);
> even when IMG has to source tones in addition to the stream.
> But I have no certainty what configuration #3 does on the SSRC in the
> streams. For sure, multiple streams with different streamID 
> on a termination
> are not mixed. Maybe (?) the termination synchronises these streams ;
> although I would not know why, I also do not find any clause 
> in the megaco
> standard that either states or contradict such behaviour.
> 
> Anyway I think I can narrow my QUESTION to the following : 'does a two
> Terminations context with multiple streams -all having 
> diferent streamID- on
> the terminations keep the SSRC of each stream intact' ?
> Yes or no ?
> Answer 'yes' implies rtp translator behaviour: then MGC must 
> not worry about
> what connection configuration to setup, MGC may even route 
> the different
> streams -including the associated ones- of an H.323 call 
> through different
> IMGs.
> Answer 'no' implies rtp mixer behaviour.
> There are two case now. When ALL the streams on the 
> termination get a new
> SSRC based on IMG clock there is also no problem: then MGC 
> must only ensure
> that (H.323) associated streams are connected to one and the same
> termination in an IMG.
> Else, -multiple streams on a termination are treated 
> differently: some get
> new SSRC, others do not ; so choosen by the IMG- the megaco 
> standard has
> another hole.
> 
> Thanks,
> Willy Reheul
> 
> > [mailto:[email-masked]]On Behalf Of 
> Yang, Margaret H
> > (Margaret)
> > Sent: donderdag 15 maart 2001 0:38
> > To: Willy Reheul; Rosen, Brian
> > Cc: [email-masked]
> > Brian,
> > You are right, config 3 doesn't require a mixer since it still
> > remains 'one
> > in one out'. When I said it requires a mixer, I forgot we are
> > still dealing
> > with 3 separate streams even though they are all in the same
> > termination and
> > thought we need to mix the three inputs for output. I was 
> totally wrong
> > about that.
> >
> > Additional replys to other points you made inserted below.
> >
> > Thanks,
> > Margaret
> > > ----------
> > > From: 	Rosen, Brian[SMTP:[email-masked]]
> > > Sent: 	Wednesday, March 14, 2001 3:51 PM
> > > To: 	Yang, Margaret H (Margaret); Willy Reheul
> > > Cc: 	[email-masked]
> > >> I agree with you that the same hardware (DSP) is used to handle
> > translation
> > >> and mixing, but the software loaded on the DSP are quite 
> different.
> > >> Of the boxes I know, DSPs are configured to perform 
> certain functions
> > >> when the board is initialized. The capacity (i.e, number 
> of channels
> > >> a DSP can support) is determined based on the functions assigned.
> > >> Once a DSP is configured, it performs the specific 
> function only and
> > can't
> > >> be changed until it's reconfigured. Also, of the boxes I know,
> > >> translation and mixing are handled by separate DSPs to 
> better utilize
> > >> the DSP resources in the box.
> > >> I suppose we can remap the hardware (i.e., change from a 
> translator
> > >> to a mixer), but it's not efficient. Plus some box may 
> not allow remap
> > >> to take place without impacting the first stream.
> >
> > >> I am confused! Are you saying there's a way for the MGC to tell
> > >> the MG which DSP port to use? How?
> > >> Also, I don't think we can make the assumption that all 
> implementations
> > >> will have the MGC allcoate resources. In fact, I know of a few
> > >> implementations that have the MG manage its own resources.
> >
> > > Brian
> > >
> > >
> >
>

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 26 Mar 2001 09:32:33 -0500

The statement worked as a first approximation.  I would hope to see a
general refinement of H.248's multimedia capabilities in H.248v2.

> From: Danny Levin [mailto:[email-masked]]
> Sent: Friday, March 23, 2001 12:26 PM
> To: 'Rosen, Brian'; 'Willy Reheul'; Yang, Margaret H (Margaret)
> Cc: [email-masked]