Subject: RE: Context/Termination/Stream configurations.

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 16 Mar 2001 15:42:52 -0500

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

> -----Original Message-----
> From: Willy Reheul [mailto:[email-masked]]
> Sent: Friday, March 16, 2001 4:16 PM
> To: Yang, Margaret H (Margaret); Rosen, Brian
> Cc: [email-masked]
> Subject: RE: Context/Termination/Stream configurations.
> 
> 
> 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]
> > Subject: RE: Context/Termination/Stream configurations.
> >
> >
> > 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: Thu, 22 Mar 2001 18:17:40 +0100

Well....there is something, but of minor importance.

It is still my belief that there is no point in doing inter-stream
synchronization within terminations if there are ONLY TWO terminations
in a context (which is the case in my trancoder example). The fact that
synchronization is done in such connection configuration confused me,
and -because I cannot think on one reason to do inter-stream
synchronization except that it is done because also mixing needs to be
done- I then <<incorrectly, I must say>> concluded that subject
connection configuration behaved like an 'RTP mixer'. 
I now learned that the one has nothing to do with the other, ie :
/1/.the distinction between RTP translator and RTP mixer is made by
"CONTEXT" only -as also explained in Christian's reply-, and 
/2/.inter-stream synchronisation within terminations is "ALWAYS" done
-whether needed or not-.

On the other hand, I must admit that 'always doing inter-stream
synchronization' doesn't harm either, except......(in the transcoder IMG
case) it enlarges transmission delay through the network. Anyway, -if
felt important- one can avoid the latter by setting up configuration #1
or #2.
Thanks, Willy.