Subject: Re: Questions on V16.

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 13 Apr 2000 21:14:25 -0400

It doesn't look like these questions have been answered, so I'll have a go.

> -----Original Message-----
> From: Shalini Philip [SMTP:[email-masked]]
> Sent: Wednesday, March 29, 2000 7:37 AM
> To:   [email-masked]
> Subject:      Questions on V16.
>
> Hello all,
>
>     I have a few questions on the V16 Draft of MEGACO.
>
> 1. How does an MGC know how many streams can be created on a
> termination? Is it from the packages supported by the termination?
        [PTT]
        Good question, but I suspect the answer is that every termination
can support an arbitrary number of streams.  The number that can be
simultaneously active is another matter, and depends both on the transport
type associated with the termination and the capabilities of the MG.  This
is aside from what media types are supported.

        Multiple simultaneously active media streams on a termination
require a multiplex.  The possible types of multiplex depend on the
transport technology.

> 2. Refer to Last paragraph of Sec 7.1.7.
> A new setting of Local Control Descriptor replaces the last setting."
> Does this change the default value of ReserveGroup & ReserveValue also,
> i.e., if RG and RV are set true in one command, then in the subsequent
> command if RG and RV are not specified, then MG would take their value
> as TRUE or FALSE?
        [PTT]
        My interpretation of that troublesome "unspecified mandatory
parameters" clause in 7.1.1 is that it applies here, so ReserveGroup and
ReserveValue retain their previously-set values.  There was a suggestion
that we tabulate the list of parameters behaving like this.  Maybe the trick
is to classify the possible behaviours, then specify for each parameter at
the appropriate point in the document which class it falls into.

> 3. Refer to last paragraph of Sec 7.1.7.
> How can MG delete some information from an existing descriptor? All the
> properties in the descriptor would have some default values.
        [PTT]
        Your point is well taken; the paragraph seems to contradict 7.1.1.
We need to straighten this out, and 7.1.1 is part of the problem.

> 4. Section 7.1.8, pt (a) talks about the possibility of no previously
> specified value, in which case the descriptor is ignored in further
> processing of the command.
> How can there be "no previously specified value"? All the properties in
> Local and Remote Descriptor would have some default value.
        [PTT]
        Actually they wouldn't necessarily have any default value.  What is
the default medium?  What is the default network type?  Address?

> Thanks & Regards,
>
> Shalini Philip
> Ficon Technology
> E-Mail : mailto:[email-masked]
> Web    : http://www.ficon-tech.com

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 14 Apr 2000 15:30:36 -0400

> is aside from what media types are supported.

You can certainly audit a termination and find out!

I don't really agree that a termination can support an arbitrary
number of streams.  That would be a big burden on an MG implementation.
I suspect rather that it is strictly a function of the capability of
the "physical" terminations.  Now, streamID should be arbitrary, so
if an audio termination had 5 channels of sound, which stream is what
ID should be arbitrary.  Might want to have a reasonable default for
the default audio (=1) stream.

Now, a real interesting question is whether there are circumstances where an
ephemeral termination actually has more than one stream.  For RTP,
the answer is No.  In fact, so far, I can't think of a case where
it is possible.  I see no reason to legislate that however.

> ReserveValue retain their previously-set values.
I agree

> There was a  suggestion

---

From: Tom-PT Taylor <[email-masked]>
Date: Sat, 15 Apr 2000 21:30:49 -0400

Again, to have multiple streams you need a multiplex or you need to
alternate activity between them.  I could conceive of alternating text and
voice on the same ephemeral termination, for example, but this is a
modeller's choice.  I knocked H.225.0 (which uses RTP as its multiplex
mechanism) off our list of possible multiplexes because I figured the more
straightforward way of using RTP worked and people were happy with it.

> From: Rosen, Brian [SMTP:[email-masked]]
> Sent: Friday, April 14, 2000 3:31 PM
        [PTT]  ...