Subject: [Megaco] FW: [Fwd: H.248 Annex M comments]

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 26 Jul 2001 09:16:38 -0400

I am forwarding this exchange to the list as agreed with Frans.  The version
of Annex M.1 on which he based his comments is to be found at
ftp://standard.pictel.com/avc-site/0103_Lau/TD-51.zip

Tom Taylor
[email-masked]
Ph. +1 613 736 0961 (ESN 396 1490)

-----Original Message-----
From: Frans Standaert (ELN) [mailto:[email-masked]]
Sent: Thursday, July 26, 2001 3:45 AM
To: Taylor, Tom-PT [NORSE:B881:EXCH]
Cc: Cromwell, David [NCRTP:B933:EXCH]
Subject: RE: [Fwd: H.248 Annex M comments]

Tom,
 
I agree with the comments listed in your message below, and the additional
comments given by David. Hence, I also agree with forwarding these comments
to the Megaco list. 
 
One minor issue about comment e15: The override package itself is okay, but
the whole size of Annex M1 is to my opinion too large. I think that either
some items has to be left out, or a more modular setup has to be chosen. 
 
best regards,
Frans 

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Tuesday, July 24, 2001 5:16 PM
To: Frans Standaert
Cc: 'Christian Groves'; David Cromwell
Subject: RE: [Fwd: H.248 Annex M comments]

Frans, thanks for your comments on Launceston TD-51.  I've certainly had to
think about them.  I will paraphrase them because I am not sure I understood
all of them.  You can correct me where I am wrong.

By the way, could I forward this entire message to the Megaco list for
further comment? 

Comment e1: 
------------ 

Commenting on the text: 

"For embedded variables, the type and subtype must be provisioned. The value
may be provisioned. If it is not provisioned it must be specified as part of
the variable reference."

You ask what the intention is, mentioning that the "given" definition of
"embedded" stated that the variable is provisioned.  By "given" do you mean
as defined in APC-1855?  In any event, I believe the intention is to allow a
default (provisioned) value for the variable with possibility of MGC
override in exceptional cases.  Mr. Cromwell might wish to comment.

Comment e2: 
------------ 

Commenting on the text: 

"Where a sequence of sets is provisioned, every set in the sequence must be
indexed by the same selector type(s)." 

You ask why the restriction.  It is basically for simplicity.  I would ask
if you see a requirement for pre-provisioned sequences where individual
components are qualified by different selector types, as opposed to
sequences, each with its own selector type, built up dynamically from the
more-restricted sequences specified in this draft. 

Comment e3: 
------------ 

You suggest that in the one-line description of the base package all after
"(ARF)" is redundant.  Agreed. 

Comments e4, e9, e13, e16, e17: 
-------------------------------- 

You note missing sigDuration, sigType parameters.  Agreed -- I will add
them.  I am thinking that in the more complex operations sigType should be
OO rather than TO, and if the latter, sigDuration gives the maximum
permitted duration of the entire operation.

Comment e5: 
------------ 

Syntax for announcement (which allows a sequence of segments, each with its
own URI): you point out an inconsistency with the earlier statement that
every sequence has a unique URI.  I will modify the earlier statement to
indicate that it applies only to provisioned sequences, and distinguish
these from sequences dynamically specified by the MGC.

Comment e6: 
------------ 

You could not find the NAME production in Annex B.  It is in the primitive
section near the bottom, before VALUE and after UINT32.

Comment e7: 
------------ 

Addressing the syntax for productions embed and variable, you make three
points: 
 1) The text should make clear that production "variable" relates to
stand-alone variables.  Agreed. 
 2) The syntax for embed should show the empty string as an explicit
possibility.  Agreed. 
 3) The text should make clear that the values of embedded variables should
be specified at the top level only, in the order they are heard when the
message is played.  I agree with the intent, but the exact wording will
depend on other changes (see e5 above).

Comment e8: 
------------ 

You wonder whether variable types should be standardized, or whether the MG
should download definitions from somewhere.  I would suggest that the debate
should be over whether the proposed set of variable types is required
sufficiently universally that there is a benefit to standardization.  This
one is a subject for more general discussion.

Comment e10, e12: 
------------------ 

You suggest that the different announcements involved in a playCollect or
playRecord operation be specified in a single string, potentially along with
tags indicating their use.  This is an interesting thought, which brings to
mind the use of XML to tie everything together.

I have had another comment on playCollect, to the effect that we should
separate announcements from digit collection, which is already part of the
protocol.  The issue is a parsing one -- the commentator wasn't happy that
the parser had to dig into the signal parameters to find the identity of the
digit map.  All of this means some thinking is required to decide the best
way to request the given function.

Comment e11, e12: 
------------------ 

You questioned the need for the speed and volume parameters in playCollect
and playRecord.  David, do you want to comment?

Comment e14: 
------------- 

Editorial: reference to section 3.3.1 for httpurl syntax in Set Package
(TD-51 section 3.3.1) should now be reference to section 2.3.1.

Comment e15: 
------------- 

You asked whether the Override Package is really needed.  This offers
temporary replacement capability for provisioned segments, so that the
operator does not have to disturb existing provisioning.  Are you saying
that the value of this capability is not enough to justify the additional MG
development it would imply? 

Tom Taylor 
[email-masked] 
Ph. +1 613 736 0961 (ESN 396 1490) 

-----Original Message----- 
From: Christian Groves [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Monday, July 23, 2001 10:29 PM 
To: Taylor, Tom-PT [NORSE:B881:EXCH] 
Cc: Frans Standaert 
Subject: [Fwd: H.248 Annex M comments] 

G'Day Tom, 

An Ericsson colleague of mine has reviewed the output from the 
Launceston SG16 with regards to the Audio Server package. Some of his 
comments may be helpful with your updates. 

I'll be taking a look at it over the next couple of days and get back to 
you on your question about the structuring of the audio server packages. 

Cheers, Christian 
-------- Original Message -------- 
Subject: H.248 Annex M comments 
Date: Fri, 18 May 2001 22:43:34 +1000 
From: "Frans Standaert (ELN)" <[email-masked]> 
To: "Christian Groves (EPA)" <[email-masked]> 

Hello Christian, 

Attached are my comments on Annex M. Furthermore, I'm wondering about 
the necessity of the Advanced Audio Server Set Package and in particular 
the Advanced Audio Server Override Package. Are these packages really 
that important? 

best regards 
Frans 

 <<TD-51_Comments.doc>> 

_______________________________________________
Megaco mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/megaco