Subject: Re: Default Stream Number For Audio

From: Brian Rosen <[email-masked]>
Date: Wed, 8 Sep 1999 10:34:27 -0400

If we define stream 2 as video, and you say m=audio with
streamID=2, that is an error.

If we define stream 3 as data, then we have to be careful
to decide if that includes text, or it just includes T.120
data, or whatever.  If there are defined interworking
mechanisms between m=something and the default streamID
meaning, interwork is asked for.

Limiting to 1,2 and 3 limits interwork possibilities.
There is no video to audio interwork.  I have always been
somewhat confused about "data".  When it explicitly means
T.120, I understand, but when it means something else, I
get confused.  There is no defined interwork between
T.120 and audio or video.

The interesting case is not stream=3, it is stream=1,
m=text.  That is the request for speech to text interwork.

Let's get back to the original proposal - define default
StreamIDs to video and data, as in H.323.

In principal, I have no problem.  In practice, the only
thing it can do is cause error messages.  You can default
streamID=2 or streamID=3, if you don't specify streamID,
it is assumed to be 1.  So, the only thing the default
video=2 can do is generate an error when you say
Stream=3{"m=audio...  What I would not want to do is to
allow the short hand notation (Local/Remote descriptors
in Media, with no Stream Descriptor) for m=video or m=data.
That, I think, is too confusing.

Brian

Brian

> -----Original Message-----
> From: Paul Sijben [mailto:[email-masked]]
> Sent: Wednesday, September 08, 1999 10:04 AM
> To: [email-masked]
> Subject: Re: Default Stream Number For Audio
>
>
> Ok this makes sense.
>
> Now I return to your original proposal. The MG should be
> smart enough to
> recognise that if I open a stream with encoding G.711 and do
> not specify a
> streamID I want it to be stream ID 1. If I would specify a
> stream ID of 3,
> the MC could bark that it does not understand it or should do
> a text to
> speech. Right?
>
> Paul
>
> Tom-PT Taylor wrote:
> >
> > For the second and subsequent streams of the same type, the
> MGC would have
> > to specify the StreamID explicitly.
> >
> > Stream type is basically a consistency requirement on the
> "m=" headers of
> > the Local and Remote descriptors for each stream, for each
> termination
> > present in the context.  I'd like to leave room for the
> voice-to-text
> > operation I originally proposed, where the conversion is
> requested simply by
> > assigning both text and voice flows to the same stream.
> Clearly the MG
> > would have to detect such implicit conversion requests and
> decide whether it
> > could handle them.
> >
> > > -----Original Message-----
> > > From: Paul Sijben [SMTP:[email-masked]]
> > > Sent: Wednesday, September 08, 1999 5:01 AM
> > > To:   Taylor, Tom-PT [CAR:B901-I:EXCH]
> > > Cc:   [email-masked]
> > > Subject:      Re: Default Stream Number For Audio
> > >
> > > Tom,
> > >
> > > this seems like a sensible approach for the simple cases.
> > > Do you have an idea how you want to handle multiple
> streams of the same
> > > media type?
> > >
> > > Browsing through the latest syntax description I could
> not find a way to
> > > explicitly describe the type of a stream. Of course this
> can be partially
> > > be deduced from the media properties (so encoding etc.).
> If this is the
> > > way
> > > we want to do it, we are probably going to need to text
> to that respect.
> > >
> > > Paul
> > >
> > > Tom-PT Taylor wrote:
> > > >
> > > > We currently have two forms of the stream portion of
> media descriptor
> > > for a
> > > > termination:
> > > >
> > > >    stream = (streamParms / streamList)
> > > >
> > > >    streamList = streamDescriptor *(COMMA streamDescriptor)
> > > >
> > > >    streamDescriptor = StreamToken EQUAL StreamID
> > > >                                        LBRKT streamParms RBRKT
> > > >
> > > > In other words, the form is either
> > > >   localDescriptor, remoteDescriptor, localControlDescriptor
> > > > or a list of stream entries of the form
> > > >   "Stream" "="
> > > >       <StreamID> {localDescriptor, remoteDescriptor,
> > > localControlDescriptor}
> > > >
> > > > The real intent of keeping the first form is to
> simplify the syntax for
> > > the
> > > > audio-only case.
> > > >
> > > > There is a theoretical possibility that terminations
> configured with the
> > > > first form could become involved in associations where
> some of the
> > > > terminations are described using the form involving
> explicit StreamID
> > > > values.  To make this as simple as possible, I would
> propose that we
> > > have
> > > > default StreamID values at least for audio, and
> possibly also for other
> > > > media.  I propose the following defaults (using the
> medium types defined
> > > in
> > > > RFC 2327):
> > > >
> > > >     Medium          Default StreamID
> > > >
> > > >     Control                      0
> > > >     Audio                        1
> > > >     Video                        2
> > > >     Application                3
> > > >
> > > > H.323 people will recognize the consistency between
> these proposals and
> > > the
> > > > recommended logical channel number assignments in H.323.
> > > >
> > > > Tom Taylor
> > > > Advisor -- IPConnect Standards
> > > > E-mail: [email-masked] (internally, Tom-PT Taylor)
> > > > Phone and FAX: +1 613 736 0961
> > >
> > > --
> > > Paul Sijben              Tel:+31 35 687 4774
> > > Lucent Technologies      Fax:+31 35 687 5954
> > > Forward Looking Work     mailto:[email-masked]
> > > Huizen, The Netherlands  http://voip.nl.lucent.com/sijben
> (internal)
>
> --
> Paul Sijben              Tel:+31 35 687 4774
> Lucent Technologies      Fax:+31 35 687 5954
> Forward Looking Work     mailto:[email-masked]
> Huizen, The Netherlands  http://voip.nl.lucent.com/sijben (internal)
>

---

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 8 Sep 1999 10:37:38 -0400

See below.

> Cc:   [email-masked]; John Segers
> Now I return to your original proposal. The MG should be smart enough to
> recognise that if I open a stream with encoding G.711 and do not specify a
> streamID I want it to be stream ID 1.
        [[TomT]]
        The MG doesn't have to key on G.711 to figure that out -- it can get
it from the "m=audio" header.

> If I would specify a stream ID of 3,
> the MC could bark that it does not understand it or should do a text to
> speech. Right?
        [[TomT]]
        No.  You can assign any streamID you want, so long as you're not
inconsistent.  If you assign streamID=3 to an audio stream, that means the
default meaning for the stream is lost.  The business about assigning text
and voice to the same stream is independent of which streamID is used -- you
could do it on stream 1.

> Paul
>
> Tom-PT Taylor wrote:
> >
> > For the second and subsequent streams of the same type, the MGC would
> have
> > Stream type is basically a consistency requirement on the "m=" headers
> of
> > the Local and Remote descriptors for each stream, for each termination
> > present in the context.  I'd like to leave room for the voice-to-text
> > operation I originally proposed, where the conversion is requested
> simply by
> > assigning both text and voice flows to the same stream.  Clearly the MG
> > would have to detect such implicit conversion requests and decide
> whether it
> > could handle them.
> >
> > > Do you have an idea how you want to handle multiple streams of the
> same
> > > media type?
> > >
> > > Browsing through the latest syntax description I could not find a way
> to
> > > explicitly describe the type of a stream. Of course this can be
> partially
> > > be deduced from the media properties (so encoding etc.). If this is
> the
> > > way
> > > we want to do it, we are probably going to need to text to that
> respect.
> > >
> > > Paul
> > >
> > > Tom-PT Taylor wrote:
> > > >
> > > > We currently have two forms of the stream portion of media
> descriptor
> > > for a
> > > > termination:
> > > >
> > > > The real intent of keeping the first form is to simplify the syntax
> for
> > > the
> > > > audio-only case.
> > > >
> > > > There is a theoretical possibility that terminations configured with
> the
> > > > first form could become involved in associations where some of the
> > > > terminations are described using the form involving explicit
> StreamID
> > > > values.  To make this as simple as possible, I would propose that we
> > > have
> > > > default StreamID values at least for audio, and possibly also for
> other
> > > > media.  I propose the following defaults (using the medium types
> defined
> > > in
> > > > RFC 2327):
> > > >
> > > >     Medium          Default StreamID
> > > >
> > > >     Control                      0
> > > >     Audio                        1
> > > >     Video                        2
> > > >     Application                3
> > > >
> > > > H.323 people will recognize the consistency between these proposals
> and
> > > the

---

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 8 Sep 1999 10:52:02 -0400

As I mentioned in my previous note to Paul, basically I see things working
slightly differently.  The MGC has total flexibility to assign any StreamID
it wants to a given stream, just so long as it is consistent.  The defaults
are only there to cover situations where no explicit StreamID is assigned
(the alternate form of the syntax) and the StreamID is not already in use.

As for "data": I'd suggest we follow the SDP list of media types.  T.120
would be covered under media type "application".

> From: Brian Rosen [SMTP:[email-masked]]
> Sent: Wednesday, September 08, 1999 10:34 AM
> To:   'Paul Sijben'; Taylor, Tom-PT [CAR:B901-I:EXCH];
> [email-masked]
> Subject:      RE: Default Stream Number For Audio
>

---

From: Brian Rosen <[email-masked]>
Date: Wed, 8 Sep 1999 11:09:46 -0400

Do you propose that:
    T=1276{C=223{Add=?{Media{Local{"m=video.....
implying Stream=2 be acceptable syntax?
I'm not in favor of that.

The Stream syntax is most appropriate in multimedia
gateways.  The optimization for simple audio-only should
remain just that.  No streamID implies Stream=1.

Brian

> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Wednesday, September 08, 1999 10:52 AM
> To: Brian Rosen; 'Paul Sijben'; [email-masked]
> > > > > >                                        LBRKT
> streamParms RBRKT

---

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 8 Sep 1999 10:10:54 -0500

I'm easy on the scope of the default.  Looking back at my original note, I
see that I phrased it to suggest a default for audio, and possibly for other
media types.

> Sent: Wednesday, September 08, 1999 11:10 AM
> To:   Taylor, Tom-PT [CAR:B901-I:EXCH]; 'Paul Sijben';