Subject: Re: Ability To Synchronize Streams

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 23 Nov 1999 08:05:21 -0500

If I have 3 terminations in a context.
        TerminationA in on streams 1 & 2
        TerminationB is on streams 1 & 3
        TerminationC is on streams 2 & 3
Are all three streams synchronized?

What is the difference in functionality between two contexts
each with two terminations, one stream per context, and
one context with 4 terminations, 2 terminations on one stream
and two on the other?

In fact, what prevents me from making an MGC that puts every
termination in the same context and uses streams to differentiate
which gets connected to which?  If I allow streamID on signals and events,
this would actually work pretty well, wouldn't it?

What fails to work if I never put two streams in the same
context other than sync?  Oh, I know, decomposed H.320 gateways
with the mux.

I actually have thought through this very question for really useful
decomposed gateways like - your desktop PC with audio and
video (and T.120).  It every way, it's much cleaner and easier
to never mix the audio context with the video context as long as
you can sync (well, tearing down the call takes two actions
instead of one).

Just what is it that streams do?

I think we should drop all further work on streams.  They are
broken (maybe "not completely worked out" is a nicer way to
say that).  I'd much prefer flushing any reference to streams,
because I think that when we really figure out how to do
multimedia correctly, the current text will get in the way,
and as we have recently been reminded, we are stuck with
backwards compatibility forever.

We can totally fix sync, and streams will still be broken.

Brian

> -----Original Message-----
> From: John Segers [mailto:[email-masked]]
> Sent: Tuesday, November 23, 1999 3:48 AM
> To: [email-masked]
> Subject: Re: Ability To Synchronize Streams
>
>
> Chip,
>
> Apparently you have a different understanding of the Santiago
> model than
> I do.  At the Santiago meeting Tom suggested that a Termination would
> represent a user (or at least the streams to/from a user for one
> session).  The idea was that synchronization would be specified among
> streams (voice synchronized with video, but not with data).  I don't
> remember that we resolved the question whether it would be done at the
> Context level or the Termination level.
>
> The discussions after Santiago led to a rejection of this
> notion that a
> Termination contains the streams to/from one user.  My
> understanding was
> that we have to at least allow multiple streams to be on different
> Terminations.  It seems that we don't have to allow multiple,
> synchronized streams to/from one user on different
> Terminations (except
> when they are multiplexed on to several physical Terminations).
>
> Nevertheless, if we want to consider multimedia with audio, video and
> data, we cannot simply assume all streams in the Context to be
> synchronized.  If I have a session with three streams (audio,
> video-speaker, video-document-camera), I don't necessarily lipsync all
> three.  I think we need to be able to specify which streams to
> synchronize.
>
> Given the time frame and the more important matters (events,
> signals!),
> I propose that we assume for now that 1) streams to be
> synchronized will
> be on one Termination, and 2) all streams on the same Termination are
> synchronized.  (I have to admit that I don't know if 2) makes
> sense if a
> termination uses different types of transport for different streams).
>
> John
>
> Chip Sharp wrote:
> >
> > I agree.  In the RTP case, most likely both streams will go
> to the same IP
> > address with a different port.
> >
> > I had assumed out of Santiago that streams in a context
> were synchronized
> > by default.  Since contexts are an artificial construct anyway this
> > shouldn't be too hard.
> >
> > Are you suggesting that we have a synchronization parameter
> for contexts
> > similar to the topology parameter?
> >
> > BTW,  SDP should be able to provide a session description
> for both audio
> > and video from the same RTP termination.  That would be one
> way of doing it
> > for the SDP encoding.  I don't know about the binary version.
> >
> > Chip
> >
> > At 02:48 PM 11/3/99 +0100, John Segers wrote:
> > >Tom,
> > >
> > >What you say is correct, but does not address the problem
> I referred to.
> > >
> > >Consider an audio/video call.  On the IP side, there would be two
> > >Terminations for the one call: one for audio and one for video.
> > >Synchronization of the streams on these two Terminations could be
> > >desired (lip synch).  I don't see how a rule like the one
> you mention
> > >would achieve this.
> > >
> > >John
> > >
> > > > Tom-PT Taylor wrote:
> > > >
> > > > Streams on different terminations are correlated by
> StreamID: StreamID
> > > > is context-wide.  In the case you describe where there
> is video on one
> > > > termination and audio on the other, there is no
> synchronization to be
> > > > done -- neither termination handles both streams.  Or
> maybe you mean
> > > > to say that one termination is receiveOnly for audio
> while the other
> > > > termination is receiveOnly for video.  Same thing -- no need for
> > > > synchronization until at least one termination changes
> to a mode where
> > > > it is sending out both streams.  At that point, the
> rule that says
> > > > that all streams in a context are synchronized to the
> extent this is
> > > > meaningful assures the required synchronization.
> > > >
> > > >      -----Original Message-----
> > > >      From:   John Segers [SMTP:[email-masked]]
> > > >      Sent:   Monday, November 01, 1999 8:17 AM
> > > >      To:     [email-masked]
> > > >      Subject:        Re: Ability To Synchronize Streams
> > > >
> > > >      Actually, there was an oversight.  In the model
> that came out of
> > > >      Santiago, all streams coming from one user went
> into the same
> > > >      Termination.  The streams within one Termination were
> > > >      synchronised by
> > > >      default.  In the discussion following the Santiago
> meeting, we
> > > >      changed
> > > >      the model for multimedia.  We do not have a
> mechanism to specify
> > > >      that
> > > >      streams on different Terminations have to be synchronised.
> > > >
> > > >      Specifically, if there is an RTP video stream on
> one Termination
> > > >      and an
> > > >      RTP audio stream on another, the protocol currently cannot
> > > >      specify that
> > > >      they have to be synchronised.  We can either add a
> > > >      synchronisation
> > > >      mechanism or mandate that streams that have to be
> synchronised
> > > >      must
> > > >      "pass through" one Termination.
> > > >
> > > >      I would say that a synchronisation mechanism is
> best done at the
> > > >      context
> > > >      level because it involves multiple Terminations
> and because I
> > > >      can't
> > > >      think of a case where you would want to streams to be
> > > >      synchronised for
> > > >      one user, but not for the other.
> > > >
> > > >      John
> > > >
> > > >      > Tom-PT Taylor wrote:
> > > >      >
> > > >      > The thought that streams are all synchronized by
> default may be
> > > >      the
> > > >      > answer.  I confess I had forgotten.  This is
> something the
> > > >      multimedia
> > > >      > specialists will have to think about.
> > > >      >
> > > >      >      -----Original Message-----
> > > >      >      From:   Chip Sharp [SMTP:[email-masked]]
> > > >      >      Sent:   Thursday, October 28, 1999 11:41 AM
> > > >      >      To:     Taylor, Tom-PT [CAR:B904-I:EXCH];
> > > >      >      [email-masked]
> > > >      >      Subject:        Re: Ability To Synchronize Streams
> > > >      >
> > > >      >      It would definitely be easier to put it off.
> > > >      >
> > > >      >      One of the main reasons streams were
> introduced were for
> > > >      >      multimedia which
> > > >      >      requires at least lip-synch.
> > > >      >
> > > >      >      My memory of Santiago was that streams in a
> context were
> > > >      synched
> > > >      >      by
> > > >      >      definition.  I thought that was the main reason for
> > > >      streams.
> > > >      >      Otherwise, we
> > > >      >      could get rid of streams and just have each
> media stream
> > > >      in its
> > > >      >      own context
> > > >      >      with a (synch=ContextID) parameter
> indicating the contexts
> > > >      that
> > > >      >      should be
> > > >      >      synchronized.
> > > >      >
> > > >      >      Chip
> > > >      >
> > > >      >      At 10:09 AM 10/28/99 -0400, Tom-PT Taylor wrote:
> > > >      >      >This is to remind you of an oversight
> arising out of our
> > > >      >      multimedia
> > > >      >      >discussions last spring.  We need a way to
> indicate which
> > > >
> > > >      >      streams are to be
> > > >      >      >synchronized (e.g. synchronization of
> voice with video)
> > > >      on exit
> > > >      >      from the MG.
> > > >      >      >My proposal was that such synchronization would be
> > > >      indicated at
> > > >      >      each
> > > >      >      >termination by including a
> "synch=StreamId" property
> > > >      within one
> > > >      >      stream
> > > >      >      >descriptor to point at another stream to
> which it should
> > > >      be
> > > >      >      bound.  On
> > > >      >      >second thought, it may be that we actually
> want to do
> > > >      this at
> > > >      >      the context
> > > >      >      >level, which means that the whole thing should be
> > > >      deferred for
> > > >      >      version 2
> > > >      >      >like the bridging context property has been.
> > > >      >      >
> > > >      >      >Comments?
> > > >      >      >
> > > >      >      >Tom Taylor
> > > >      >      >Advisor -- IPConnect Standards
> > > >      >      >E-mail: [email-masked]
> (internally, Tom-PT
> > > >      Taylor)
> > > >      >      >Phone and FAX: +1 613 736 0961
> > > >      >
> > > >      >      Support NetAid!  http://www.netaid.org
> > > >      >      --------------------------------------------------
> > > >      >      Chip Sharp                 Consulting Engineering
> > > >      >      Cisco Systems              Telco Bio-region
> > > >      >      Reality - Love it or Leave it.
> > > >      >      --------------------------------------------------
> > > >
> > > >      --
> > > >      John Segers                                  email:
> > > >      [email-masked]
> > > >      Lucent Technologies
>         Room
> > > >      HE 306
> > > >      Dept. Forward Looking Work
> phone: +31 35 687
> > > >      4724
> > > >      P.O. Box 18, 1270 AA  Huizen
> fax: +31 35 687
> > > >      5954
> > >
> > >--
> > >John Segers                                  email:
> [email-masked]
> > >Lucent Technologies
> Room HE 306
> > >Dept. Forward Looking Work                      phone: +31
> 35 687 4724
> > >P.O. Box 18, 1270 AA  Huizen                      fax: +31
> 35 687 5954
> >
> > Support NetAid!  http://www.netaid.org
> > --------------------------------------------------
> > Chip Sharp                 Consulting Engineering
> > Cisco Systems              Telco Bio-region
> > Reality - Love it or Leave it.
> > --------------------------------------------------
>
> --
> John Segers                                  email: [email-masked]
> Lucent Technologies                                        Room HE 306
> Dept. Forward Looking Work                      phone: +31 35 687 4724
> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954
>

---

From: John Segers <[email-masked]>
Date: Tue, 23 Nov 1999 15:02:50 +0100

Brian,

I don't know what the intention of your message is, but I find it highly
confusing.  See my comments below.

John

> Are all three streams synchronized?

According to my proposal, the outgoing streams on TeminationA are
synchronized, as are those on TerminationB and TerminationC.  If you
implement synchronization by buffering outgoing packets per termination
based on RTP time stamp, do you call the three streams then
synchronized?

> one context with 4 terminations, 2 terminations on one stream

Difference in how you tear down the call.  Contexts give you a way to
group terminations that for some reason are associated.  If you are
asking about differences in functionality when not considering this
grouping, the answer is that there are no differences.

> this would actually work pretty well, wouldn't it?

You'll have a hell of a lot of topology information to describe and
tearing down a multipoint session requires larger messages.

> context other than sync?  Oh, I know, decomposed H.320 gateways

And you want to rule those out forever, I guess.

> We can totally fix sync, and streams will still be broken.

Hmm.  I gather that you think that multimedia should be handled by
multiple contexts, right?  Let's not reopen that discussion now, we've
spent enough bandwidth on it already.

I haven't seen an argument convincing me that streams are broken.  Until
I see one, I suggest we leave them unchanged.

---

From: Danny Levin <[email-masked]>
Date: Wed, 24 Nov 1999 10:39:38 -0500

Brian,

Support of multi media is one of the main reasons why vendors  consider to
migrate from MGCP...
(At least this is the input that I got).
Therefore place holders for these features are important.

We can say that streams that share the same termination are synchronized (by
default).
Topology is a place holder for more complex relations among streams in a
context.
It will be enhanced in the upcoming releases...

Danny.

> From: Media Gateway Control (megaco)
> [mailto:[email-masked]]On Behalf Of Rosen, Brian
> Sent: Tuesday, November 23, 1999 8:05 AM
> To: [email-masked]