Subject: Re: Questions About MEGACO/H.248 Version 16

From: Sachin Mittal <[email-masked]>
Date: Mon, 6 Mar 2000 10:42:28 +0530

See Comments below.

Xiuping Qiu <[email-masked]> on 02/29/2000 03:16:31 PM

Please respond to Xiuping Qiu <[email-masked]>

To:   [email-masked]
cc:    (bcc: Sachin Mittal/HSS)

Subject:  Questions About MEGACO/H.248 Version 16

Hi,All

I meet some questions when reading MEGACO/H.248 Version 16.

1. In Appendix A

Step 23: "  The MGC now sets up both MG1 and MG2 to be ready to detect the next
off-hook event. See step 1. Note that this could be the default state of a
termination in the null context, and if this were the case, no message need be
sent from the MGC to the MG. Once a termination returns to the null context, it
goes back to the default termination values for that termination.  "

I wonder how to implement the  default state, e.g. request MG to detect the
offhook event. And even if this were the case,I suppose messages also need be
sent from the MGC to the MG to ask MG to detect offhook event because the
RequestID now is different from the previous one.
[SM]
The default state is modified in NULL Context in step 3.
I don't understand the confusion, The RequestID used in Notify will be the same
as that used in Modify in NULL.
So the Notify everytime will be of the form as shown in step 6. (request ID =
2222)
No change in RequestID means no new message.

2. In 7.1.6 Stream Descriptor

" StreamIDs are of local significance between MGC and MG and they are assigned
by the MGC.  Within a context, StreamID is a means by which to indicate which
media flows are interconnected:  streams with the same StreamID are connected  "

I am wondering whether StreamID will conflict  with Topology.

Let's  suppose there are 2 Terminations ( T1 and T2)  in a context . There is
one stream on the 2 Terminations each but the StreamIDs are different. So  the
media flows are not interconnected. But if the Topology Descriptor of the
Context is
Bothway?, What will happen?
[SM]
They are not conflicting. Topology is the rule, and Streams are entities on
which the rules work. If the rule doesn't
apply no problem it may apply on new Streams. It may happen that more streams
will get added to the two terminations
and then the topology rule will apply.
This is true also for the "mode" parameter of the streams that are candidates
for inter-connection.
Say two Streams with same StreamID are to be connected based on topology, but
their "modes" are send-only then
even though Streams are connected nothing is actually going "out of Context" on
both Streams.
There is another twist to this. Since Topology descriptor is optional to
implement and is not implemented
by a vendor then the mode parameter can be used to govern the connection
direction. [But no topology
means both-way connection]

3  In  6.2.5  Root Termination

" Root thus may have properties and events (signals and statistics are not
appropriate for root).  "
?

It is rather easy  to imagine  events of   normal Terminations.  But I cannot
think of  a case of using events for Root.  Can you  give an example ?  And what
events may a Root have ?
[SM]
Till now no event is defined in Base Root Package. but in new packages there can
be events. Like Network interface
going down or coming up if only one is there in each virtual MG. [This is
different from the idea of making NIC as
a termination which was floating sometime back in the mailing list]

4  In  7.1.1  Specifying Parameters

"  Unspecified mandatory parameters (i.e. mandatory parameters not specified in
a descriptor) result in the command responder retaining the previous value for
that parameter.  Unspecified optional parameters result in the command responder
using the default value of the parameter.      Whenever a parameter is
underspecified or overspecified, the descriptor containing the value chosen by
the responder is included as output from the command.  "

Queston:
It seems that "optional" ? here is not the same as that in Annex A defined in
ASN.1.  Will you   expain them in detail? And what's the difference between
"Unspecified Optional"  ? and  "Optional" . ?.And how to identify a unspecified
parameter as mandatory or optional?
[SM]
Parameters are defined optional or mandatory by the text and in package
definitions.
Unspecifed Optional = An optional parameter whose value in a particular use is
not provided.
Optional = A parameter that is defined to be optional.
These two terms seem to confuse if you see only the MGC perspective (optional or
unspecified optional means
the same thing as parameter value not specified) But in terms of MG an optional
parameter has a default value
and unspecifed case of optional parameter specify this value.

When a  Termination is Subtracted from a  Context, the Topology  should be
changed, but how? There is no description in the protocol .

Thanks,
Xiuping Qiu
_______________________________________________

Xiuping Qiu
Huawei Technologies Co., Ltd.
Mail to:   [email-masked]
Tel    :   +86 755 654 4482
Visit  :   http://www.huawei.com.cn
_______________________________________________

---

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 6 Mar 2000 11:22:39 -0600

Responses below.  I started this message quite a while ago, but it got
buried before I got around to sending it.

> -----Original Message-----
> From: Xiuping Qiu [SMTP:[email-masked]]
> Sent: Tuesday, February 29, 2000 4:47 AM
> Step 23: "  The MGC now sets up both MG1 and MG2 to be ready to detect the
> next off-hook event. See step 1. Note that this could be the default state
> of a termination in the null context, and if this were the case, no
> message need be sent from the MGC to the MG. Once a termination returns to
> the null context, it goes back to the default termination values for that
> termination.  "
>
> I wonder how to implement the  default state, e.g. request MG to detect
> the offhook event. And even if this were the case,I suppose messages also
> need be sent from the MGC to the MG to ask MG to detect offhook event
> because the RequestID now is different from the previous one.
        [[TomT]]
        One of the changes made in Geneva was to rule out the idea that a
termination remembers the settings it was last given while in the null
context.  The default settings are therefore either those defined in the
Megaco/H.248 specs. (and there are actually very few of those) or those
established through provisioning.  The passage you quote was written before
this change was made.  In any event, I think you are right in practice -- it
is desirable for the MGC to reestablish the termination's idle state when it
moves it to the null context.  A typical implementation would be to have,
within the same transaction, a Subtract followed by a Modify which sets up a
timed watch for on-hook (assuming that had not already happened), with
embedded event descriptors as follows:
         -- on-hook detected: watch for off-hook
         -- timer expired: notify the MGC and apply receiver off hook
warning tone.

        This suggests to me that one thing we need to add in an extension of
the Generic package is an explicit timer event.  I'd be interested in
others' comments on this one.

> " StreamIDs are of local significance between MGC and MG and they are
> assigned by the MGC.  Within a context, StreamID is a means by which to
> indicate which media flows are interconnected:  streams with the same
> StreamID are connected  "
>
> Let's  suppose there are 2 Terminations ( T1 and T2)  in a context . There
> is one stream on the 2 Terminations each but the StreamIDs are different.
> So  the media flows are not interconnected. But if the Topology Descriptor
> of the Context is
> Bothway", What will happen?
        [[TomT]]
        Topology is sort of a global property -- it defines
inter-termination connectivity regardless of the details of which streams
are flowing.  Streams add a level of detail within that framework: A may
talk to B in general, but B doesn't happen to support the video that A is
prepared to provide.  One could conceive of making topology stream-specific,
but I don't think there's a real requirement for that level of control.

> "
> It is rather easy  to imagine  events of   normal Terminations.  But I
> cannot think of  a case of using events for Root.  Can you  give an
> example ?  And what events may a Root have ?
        [[TomT]]
        The sort of events I imagine are related to resource management
(e.g. transition to/from an overload state).  We have not yet defined any
packages implementing ROOT events.

> "  Unspecified mandatory parameters (i.e. mandatory parameters not
> specified in a descriptor) result in the command responder retaining the
> previous value for that parameter.  Unspecified optional parameters result
> in the command responder using the default value of the parameter.
> Whenever a parameter is underspecified or overspecified, the descriptor
> containing the value chosen by the responder is included as output from
> the command.  "
>
> Queston:
> It seems that "optional" " here is not the same as that in Annex A defined
> in ASN.1.  Will you   expain them in detail? And what's the difference
> between "Unspecified Optional"  " and  "Optional" . ".And how to identify
> a unspecified parameter as mandatory or optional?
        [[TomT]]
        Personally I think this text is going to need a lot of detailed
interpretation.  Let's start by agreeing (I hope) that this statement
applies to the contents of descriptors, not to whether or not the
descriptors themselves are present.  Going on from there, however, it's
pretty tough to sort out what is optional and what isn't.  I have a feeling
we will need a supplementary guide to list the parameters which take on
"previous value" versus those which take on "default value".  I would tend
to play it safe and specify everything.

        An unspecified parameter, whether mandatory or optional, is one
which is simply not present within a particular instance of the descriptor.
This contrasts with UNDERspecification through the use of ranges,
alternatives, or the CHOOSE wildcard.

> changed, but how? There is no description in the protocol .
        [[TomT]]  Isn't that straightforward?  Topology may be viewed as a
series of binary relationships -- between pairs of terminations.  When a
termination is subtracted, all relationships in which it appears are
deleted.