Subject: Re: Default Stream Number For Audio

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 8 Sep 1999 07:52:56 -0500

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)

---

From: Paul Sijben <[email-masked]>
Date: Wed, 8 Sep 1999 16:04:22 +0200

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