Subject: Questions on MEGACO/H.248 v16 - More

From: Xiuping Qiu <[email-masked]>
Date: Tue, 7 Mar 2000 20:26:41 +0800

Hi, all

Thanks for those who reponses me.
Also thanks for you who reads my questions.

1.    When ReserveValue and ReserveGroup are true , how the parameters
 of Value  and Group are matched?
And if ReserveValue and ReserveGroup are true, will it return large
numbers of info? For example,if ReserveValue is true,and there is a
"m=audio $ RTP/AVP 0 " line in Local Descriptor,then should MG return
all possible port numbers to MGC?

2.  In 7.1.8  Local and Remote Descriptors

(a)     An unspecified Local or Remote descriptor is considered to be
 a missing mandatory parameter. It  requires the MG to use whatever
was last specified for that descriptor. It is possible that there was
 no previously-specified value, in which case the descriptor concerned
is ignored in further processing of the command.

It seems that the above conflicts with the Example of  Appendix  A.

3. “ If the Mode property of the LocalControl descriptor is RecvOnly or
SendRecv, the MG must be prepared to receive media encoded according to
any of the alternatives included in its response to the MGC. “

Question :What exact alternative does MG use to receive media? e.g. When
the peer MG has sent media encoded in one of the alternatives,how does the
prepared MG know what type is the encoding?

4.  E.6.2  Events

Original:
Termination Method
ParameterID:    Meth (0x0003)
Type: enumeration
Possible values:
	"UM" (0x0001) Unambiguous match
	"PM"  (0x0002) Partial match, completion by timer expiry or unmatched event
	"FM"  (0x0003) Full match, completion by timer expiry or unmatched event
Description: indicates the reason for generation of the event.  See the procedures in section .

Question £º
While dialing the MG detects  the onhook events,  then will it happen the
DigitMapCompletion event?  If  it happens,  what  the kind of Termination Method is ?
And,  Which event happens first ? Onhook or DigitMap Completion? 

5.   7.1.9  Events Descriptor

Question:
In  Case 1, EventBufferControl = LockStep £¬EventBuffer is empty£¬Will  EventDescriptor
and  EventBufferDescriptor  both work  ?  If  they both work, suppose one event exists
in both Descriptors,  Then how to deal with it ?

6. Question:

Before replaced by a new one, can an EventDescriptor be used to detect specified events
more than once? I.e.  One EventDescriptor  contains an EventID dt , after detected once,
if event dt happened again , and the EventDescriptor is not replaced. Will the MG Notify
the event?

Thanks,
Xiuping Qiu
_______________________________________________

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

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 7 Mar 2000 22:25:42 -0600

Thank you for the questions.  I do wonder if we have to write a new document
collecting all the explanations.  Maybe a list of frequently asked questions
(FAQ).

My responses below.

> -----Original Message-----
> From: Xiuping Qiu [SMTP:[email-masked]]
> Sent: Tuesday, March 07, 2000 7:27 AM
> To:   [email-masked]
> Subject:      Questions on MEGACO/H.248 v16 - More
>
> Hi, all
>
        [[TomT]]
        I'm not clear what you mean by "matched".  Do you mean matching of
alternatives selected in Local against alternatives selected in Remote?

> all possible port numbers to MGC?
        [[TomT]]
        Remember to start with that the MG is reserving resources.  These
resources will therefore be unavailable to serve other calls until the MGC
releases them by being more selective in its requests.  In our
interpretation of the different syntactic possibilities and how the MG
should react to them, we should be looking for principles that lead to
reasonable behaviour.

        Now, what are the syntactic possibilities for any parameter?  In
text-encoded terms, they are:

        (a) "$" also known as CHOOSE.  The most reasonable interpretation,
particularly in the light of your example, is that "$" always asks the MG to
choose a single value for the parameter concerned.  Again, for your
particular example, if there are multiple session descriptions and
ReserveGroup is TRUE, it would make sense for the MG to reserve the same
port for audio in every session description it returns, since the assumption
is that only one of these session descriptions will be chosen in the end.

        (b) A comma-separated list of values enclosed within brackets.  Here
the assumption should be that the values are listed in descending order of
preference, and subject to that ordering the MG should reserve resources to
cover as many of the values as possible.  ("Cover" means that it is prepared
for the MGC or the far end to select that value to be the one actually
used.)  We have a problem here: SDP does not support the same syntax for a
list of alternatives, so how does the MG provide a response which is
properly-formed SDP?  The brute force answer is to use SDP mechanisms for
the purpose where they exist, and otherwise spell out alternatives in
multiple session descriptions.  The problem with the latter is that the
required number of session descriptions will grow exponentially with the
number of parameters for which alternatives are supplied.  Perhaps someone
can think of a more clever answer.

        (c) A bracket-enclosed range of values.  It is harder here to think
that the ordering implicit in the range represents any sort of order of
preference.  Instead, I propose that the intent is that the MG be prepared
to support as many values as possible within that range.  If it weren't for
the rule that the MG must respond with proper SDP syntax, the MG would
respond either with a range which may be a subset of the original or with a
list of individual values selected from the range.  The brute force means of
conforming to SDP syntax is even more difficult than in the previous case.
Help!

        (d) An inequality constraint.  The same logic that applies to ranges
also applies to inequalities.

> It seems that the above conflicts with the Example of  Appendix  A.
        [[TomT]]
        Which step?

> 3. ?If the Mode property of the LocalControl descriptor is RecvOnly or
> any of the alternatives included in its response to the MGC. ?
>
        [[TomT]]
        It's shown by the payload type in the RTP header.

> Question :
        [[TomT]]
        The usual case would be that the EventsDescriptor changes as a
result of on-hook.  If this doesn't happen, DigitMapCompletion will come
about as a result of timer expiry, and thus will generally follow some time
after the on-hook.

> In  Case 1, EventBufferControl = LockStep ,EventBuffer is empty,Will
> EventDescriptor
        [[TomT]]
        Events are never screened against both EventDescriptor and
EventBufferDescriptor at the same time.  In the case you give, the next
arriving event will be screened against the EventDescriptor only, reported
if it is matched, and discarded if it is not matched.  If it is matched,
subsequent events will be screened against the EventBufferDescriptor and
placed in the EventBuffer until a new EventDescriptor is activated.

> if event dt happened again , and the EventDescriptor is not replaced. Will
        [[TomT]]
        This will happen if EventBufferControl = "off".

---

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 10 Mar 2000 16:25:06 -0500

Resend.

> From: Taylor, Tom-PT [CAR:B904:EXCH]
> Sent: Tuesday, March 07, 2000 11:25 PM
> To:   'Xiuping Qiu'; 'Megaco'
> Subject:      RE: Questions on MEGACO/H.248 v16 - More
>
> Thank you for the questions.  I do wonder if we have to write a new
> document collecting all the explanations.  Maybe a list of frequently
> asked questions (FAQ).
>
> My responses below.
>
> particularly in the light of your example, is that "$" always asks the MG
> to choose a single value for the parameter concerned.  Again, for your
> port for audio in every session description it returns, since the
> assumption is that only one of these session descriptions will be chosen
> in the end.
>
> (b) A comma-separated list of values enclosed within brackets.  Here the
> assumption should be that the values are listed in descending order of
> preference, and subject to that ordering the MG should reserve resources
> to cover as many of the values as possible.  ("Cover" means that it is
> prepared for the MGC or the far end to select that value to be the one
> actually used.)  We have a problem here: SDP does not support the same
> syntax for a list of alternatives, so how does the MG provide a response
> which is properly-formed SDP?  The brute force answer is to use SDP
> mechanisms for the purpose where they exist, and otherwise spell out
> alternatives in multiple session descriptions.  The problem with the
> latter is that the required number of session descriptions will grow
> exponentially with the number of parameters for which alternatives are
> supplied.  Perhaps someone can think of a more clever answer.
>
> (c) A bracket-enclosed range of values.  It is harder here to think that
> the ordering implicit in the range represents any sort of order of
> to support as many values as possible within that range.  If it weren't
> for the rule that the MG must respond with proper SDP syntax, the MG would
> respond either with a range which may be a subset of the original or with
> a list of individual values selected from the range.  The brute force
> means of conforming to SDP syntax is even more difficult than in the
> previous case.  Help!
>
> (d) An inequality constraint.  The same logic that applies to ranges also
> applies to inequalities.
>
>
> The usual case would be that the EventsDescriptor changes as a result of
> on-hook.  If this doesn't happen, DigitMapCompletion will come about as a
> result of timer expiry, and thus will generally follow some time after the
> on-hook.
>