Subject: RE: Context/Termination/Stream configurations.

From: "Yang, Margaret H (Margaret)" <[email-masked]>
Date: Wed, 14 Mar 2001 18:37:50 -0600

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]
> Subject: 	RE: Context/Termination/Stream configurations.
> 
> 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.
>> 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.
> 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.  
>> 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.

> 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.
>> 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: "Willy Reheul" <[email-masked]>
Date: Fri, 16 Mar 2001 21:15:56 -0000

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

> -----Original Message-----
> From: [email-masked]
> [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]

---

From: Christian Groves <[email-masked]>
Date: Mon, 19 Mar 2001 10:52:54 +1100

Willy,

A lot of text to diseminate below.

In a one context/2 termination configuration a would say the SSRC is
kept intact, so yes to your final question. 3 terminations and as you
mentioned below you get mixer functionality.

H.248/Megaco is quiet on the RTP issue because its transport
independent. 

Christian