Subject: MEGACO draft review - sections 6-11

From: Abdallah Rayhan <[email-masked]>
Date: Tue, 2 Nov 1999 12:34:26 -0500

Brian, John,

Please find our editorial comments of the draft. This review
is up to Section 11. The red (and quoted) text is from the draft.
The rest is ours.

regards
Abdallah & Nancy

Section 6.1:

"If the MGC does not specify an existing Context to which the
Termination is to be added, the MG creates a new Context."

There is one case for this which is CHOOSE. If Context uses
CHOOSE ......

"A Termination may be removed from a Context with a Subtract
command, and a Termination may be moved from one Context to
another with a Move command."

Move and Add are not equivalent. However, the statement could
mean Move can be used to move a termination from the null context
into some context or vice versa, and this is not how Move should be used.
Please add the sentence: A termination is taken out of the null context into a
new context using an Add command.

Section 6.1.1:

"ContextID, a 32 bit integer ..."

unsigned integer.

Section 6.2:

"A Termination is a logical entity on a MG that sources and/or
sinks media and/or control streams."

Do we have control streams ?

"Ephemeral Terminations are created by means of an Add command."

Please add a sentence that says: Move or Modify shall not be used to
subtract terminations!

Section 6.2.4:

"The default value of a property of a physical Termination
can be changed by setting it to a different value when the
Termination is in the null Context."

Do ephemeral terminations have default values ? How is that handled ?

"These properties are referred to by a name consisting of the
PackageName and a PropertyId."

PropertyId is called ItemID in the ABNF.

"When a physical Termination is Subtracted from a Context,
properties are reset to the values they had just prior to
the most recent Add command."

Does that mean the default values ? Yes, I think - so the text should say
so. While a termination is in the null Context, its default values can be
changed,
for example, the SignalsDescriptor and EventsDescriptor can be changed -  we
want to return that termination to its default valuesm NOT the values it had
just before it went into a Context.

Also add to the text: When a Terminatoin is moved from one Context to another,
it shall retain the same values for properties.

Section 7:

"8. ServiceChange. The ServiceChange Command allows the Media Gateway
to notify ..."

Small caps for Command. Inform/send would better words than notify since
notify is a command. Notify appears twice in the paragraph.

Section 7.1.1:

"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."

Not clear ! Add an example.

Section 7.1.3:

V.75 is not defined in the ABNF. Is it in or out ? It was added in Berlin.

"Mux {H221, MyT3/1/2, MyT3/2/13, MyT3/3/6, MyT3/21/22}"

The example is not correct. It should had been
Mux = H221 {MyT3/1/2, MyT3/2/13, MyT3/3/6, MyT3/21/22}

Section 7.1.5:

"The Termination State Descriptor contains the ServiceStates
parameter, the BufferedEventProcessingMode ..."

BufferedEventProcessingMode is not there any more. It appears
twice in the section.

Section 7.1.7

"Mode set to delete is used to remove a stream from a termination."

No need for a new paragraph.

Section 7.1.9:

In the table of EventActions:
AccumulateByDigitMap is called just DigitMap. This needs to be updated
in more than once place of the section.

"Events=1139 { dt/d0 {ACTION=AccumulateByDigitMap{GenMap} } }"

Should be :
Events=1139 { dt/d0 {ACTION {DigitMap = GenMap}}}

"An EventsDescriptor received by a media gateway replaces any
previous Events Descriptor."

How do we clear an event ?

Section 7.1.12:

"The ServiceChangeDescriptor contains the following parameters:
· ServiceChangeMethod
· ServiceChangeReason
· ServiceChangeAddress
· Delay
· Version
· MGCIdToTry"

use ServiceChangeDelay instead of delay,
Profile instead of Version, and add extension.

Section 7.2.1

"For convenience, if a Multiplex Descriptor is present in
an Add command and lists any Terminations that are not
currently in the Context, such Terminations are added to
the context as if individual Add commands listing the
Terminations were invoked."

This is not a clean way of adding terminations.
We need to specialize commands not cross their
functionality.

Section 7.2.2

We need something along the lines:
Modify can not be used to move a termination from
one context into another!

Section 7.2.4

We need something along the lines:
Move can not be used a substitute to Subtract, e.g.,
you can not use Move to move a termination from some
context into the NULL context.

Section 7.2.5

"ObservedEvents returns a list of events in the EventBuffer
PackagesDescriptor returns a list of packages realized by
the Termination."

Full stop after EventBuffer. I wonder if EventBuffer is still in !

Section 7.2.7

"The ObservedEventsDescriptor contains the RequestID and a
list of events that the Media Gateway detected in the order
that they were detected. If the BufferedEventProcessingMode
parameter ...."

We dont have BufferedEventProcessingMode anymore. The paragraph
needs to be rewritten.

Section 7.2.8

"The Media Gateway Controlle may indicate that terminations/s
shall be taken out of or returned to service."

termination(s) instead of terminations/s. Controller rather than Controlle.

"The ServiceDescriptor contains the following parameters as required:
· ServiceChangeMethod
· ServiceChangeReason
· ServiceChangeDelay
· ServiceChangeAddress
· Profile
· MGCIdToTry"

add extension.

"2. Forced - indicates that the specified Terminations
were taken abruptly out of service and any established
connections associated with them were lost. The effect
is equivalent to a Subtract of the Termination from any
Context it may have been in."

This could lead to confusing subtract with servicechange.
Subtract has audit, this does not.  Should add: When a Termination
is forced out of service, no statistics are available for it.

Add 6. which is extension, allowing the list of methods to be extended.

Section 7.3

What is the difference between
"420 - No such Event or signal in this package"

and

"450 - No such property in this package
451 - No such event in this package
452 - No such signal in this package
453 - No such statistic in this package"
 ?
It seems repetitive !

"510 - Insufficient resources"
and
"526 - Insufficient bandwidth"
imply the same thing !

Section 8

"Transactions guarantee ordered Command processing.
That is, Commands within a Transaction are executed
sequentially. Ordering of Transactions is NOT guaranteed -
transactions may be executed in any order, or simultaneously."

How about Actions ? Are they executed in order ?

Section 8.1.2

"1. The "null" Context, which is used to refer to a
Termination that is currently not associated with a
Context.
2. The "unspecified" Context, which is used to request
that the Media Gateway create a new Context."

"null" is "NULL" and "unspecified" is "CHOOSE"

Section 8.2.3

"TransactionPending(TransactionID { } )"

We have TimeNotation between {}.

How do we set "(normalMGExecutionTime)" and
"(normalMGCExecutionTime)" ?

Section 9

"The initial ServiceChange message should be sent to
port ???? if using TCP and port ???? if using UDP."

Use the same port for both. Operating systems allow this. If you are
in the UDP mode, then it is UDP session. If you are
in the TCP mode, it is a TCP session. UDP and TCP will
be in listening mode. When you receive a request on either
one, you would use it for that session.

Section 11.2

"If the MGC accepts the MG, it will send a Transaction Accept,
with the MGCIdToTry set to itself."

This is redundant. It should be implied by the absence of this
parameter that the current MGC is assumed for further communications.

---

From: John Segers <[email-masked]>
Date: Thu, 4 Nov 1999 13:43:20 +0100

Abdallah, Nancy,

See my comments below.

And thank you for many fine comments!

John

> There is one case for this which is CHOOSE. If Context uses

Section 6.1.1 offers clarification.  But I agree that the explanation
can be improved.

> new context using an Add command.

I propose "The Add command shall be used to take a Termination out of
the null Context and into another Context." to be added to section
7.2.1, the section on the Add command.

> "ContextID, a 32 bit integer ..."

Ok.

> Do we have control streams ?

Not in the main protocol.  But we do have requirement implying that it
should be possible to terminate H.245 at the MG.  One could define an
H.245 package to do this.  By disallowing control streams in the base
protocol, this option disappears.

> Please add a sentence that says: Move or Modify shall not be used to

As with Add/Move, I propose to add text to the sections on Move and
Subtract.  How can Modify be used to remove Terminations?

> Do ephemeral terminations have default values ? How is that handled ?

We could have done better here by having templates, but that's a passed
station.  As it stands, the default values of ephemeral terminations
cannot be changed.  If a property has a default value, it has to be
specified in the document or in the package that contains the property.

> PropertyId is called ItemID in the ABNF.

Will change PropertyID to ItemID in main text.

> so. While a termination is in the null Context, its default values can
> be changed,

Personally, I think we didn't too good a job on the default values, how
they are set/restored etc., especially now that properties may come from
packages.  Is the default values the one defined in the package, or the
value that was last set in the null Context? Anyway, in my understanding
the text you quote is accurate, but superfluous  The last sentence of
the first paragraph of section 6.2.4 says the same.

> it shall retain the same values for properties.

Instead, I propose to add a sentence to say that Move may include
parameters to change property values of the Termination is operates on.

> notify is a command. Notify appears twice in the paragraph.

Brian and I have different sets of (implicit) rules on when to use
capitals; I'm sure there are more inconsistencies in this respect.  I'll
make a note on the use of "notify"

> V.75 is not defined in the ABNF. Is it in or out ? It was added in

It's worse than that: the text should have read V.76.  I'll add the
parameter to the ASN.1 and ABNF.

> Mux = H221 {MyT3/1/2, MyT3/2/13, MyT3/3/6, MyT3/21/22}

Ok.

> BufferedEventProcessingMode is not there any more. It appears

It is there.  The ASN.1 and ABNF use a different name, processCtrl. 
I'll change that.

> No need for a new paragraph.

But it doesn't harm either.

> in more than once place of the section.

I'll update the ASN.1 and ABNF and leave the text (the ASN.1 and ABNF
aren't translated in the ITU process, so this is a less costly change).

> Events=1139 { dt/d0 {ACTION {DigitMap = GenMap}}}

The example has to be updated.  It doesn't mention the right package
name either.

> How do we clear an event ?

Send an empty eventsdesriptor.

> Profile instead of Version, and add extension.

Agreed on Delay.  Version is worth some discussion.  The current syntax
has a mandatory profile element in service change.  Does every MG and
MGC have to implement a profile of the protocol?  If so, we should have
a way to express the profile that identifies the base protocol with the
options present.

> We need to specialize commands not cross their

Too big a change to make now.
 
> one context into another!

I'd rather add a sentence to Move, saying that it is the only command
that can refer to a termination that is currently in a different context
than the one specified by the action in which the command occurs.

> context into the NULL context.

Yes.

> Full stop after EventBuffer. I wonder if EventBuffer is still in !

Yes, and yes it is.

> We dont have BufferedEventProcessingMode anymore. The paragraph

We do have it.

> is forced out of service, no statistics are available for it.

ServiceChange does not allow statistics as parameters, so I don't think
we have to add this.

> Add 6. which is extension, allowing the list of methods to be

Ok.

> 453 - No such statistic in this package"

It does, doesn't it.  Let's remove 420.

> "526 - Insufficient bandwidth"

510 is supposed to refer to internal gateway resources.

> How about Actions ? Are they executed in order ?

The commands within a transaction are grouped into actions.  Since
commands are executed in order, so are actions.

> "null" is "NULL" and "unspecified" is "CHOOSE"

Editing required in this section: ALL, CHOOSE and UNSPECIFIED are
allowed according to the ABNF.  The ASN.1 allows these three and NULL.

> "(normalMGCExecutionTime)" ?

Good question.  I think they should be properties defined in the root
package (which we do not have yet, but do need).

> one, you would use it for that session.

If the same port numbers are assigned, that will show here.

> parameter that the current MGC is assumed for further communications.

Doesn't harm, so I'll leave it as is.

-- 
John Segers                                  email: [email-masked]
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954

---

From: Harpreet Singh Anand <[email-masked]>
Date: Thu, 4 Nov 1999 18:47:22 +0530

> Send an empty eventsdesriptor.

This would clear all the events in the event descriptor. Is there a mechanism
for clearing a particular event that has been set in an earlier event descriptor
?

Regards,
Harpreet

_________________________________
Harpreet Singh Anand
Ficon Technology
E-mail :  mailto:[email-masked]
Web    :  http://www.ficon-tech.com

---

From: John Segers <[email-masked]>
Date: Thu, 4 Nov 1999 16:42:13 +0100

Harpreet,

You can do that by sending a new eventsdescriptor that contains only the
events that you want to retain, omitting the one(s) that you want to
clear.

John