Subject: Re: Default Stream Number For Audio

From: Chip Sharp <[email-masked]>
Date: Tue, 19 Oct 1999 00:39:20 -0400

I'm a little late on this thread, but I don't see any benefit for nailing a
streamID to a media type.  The last time I read the spec if the streamID
was not present, it was assumed to be 1, no matter what media type was
included.

The way it is now worded, the only media type that doesn't have to include
streamID is audio.  This means that all data calls have to have a streamID.

Chip

At 04:34 AM 9/8/99 -0400, Brian Rosen wrote:
>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)
> >

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------

---

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 20 Oct 1999 00:21:25 -0500

What I meant by default streamId was that if it was unspecified, it could be
inferred from the medium being carried.  I did not intend to reserve
streamIds for specified media -- you could assign streamId 1 to video if you
so chose, but would then lose the benefit of not having to specify streamId
for audio.  Because of the vagueness of "data" (is this really an SDP medium
type?) I wouldn't recommend assigning a default streamId for it.

> From: Chip Sharp [SMTP:[email-masked]]
> Sent: Tuesday, October 19, 1999 12:39 AM
> To:   [email-masked]