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

From: "David Cromwell" <[email-masked]>
Date: Thu, 26 Jul 2001 11:47:42 -0400

And here are my comments on the exchange btw Frans and Tom.

David
--
[email-masked]                   Nortel Networks Cable
Telephony Solutions, Inc. 
Tel:   919-991-8870  (esn 351)                     35 Davis Dr
Fax:  919-991-4088                                    RTP, NC 27709

> 	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.
> 
> 
> 	[<dcc>]  Typically the value is not provisioned and is supplied at
> runtime.  However we also see value in provisioning the value of a
> variable if that value is known in advance and will not change at runtime.
> 
> 
> 	We ruled out overriding variables with a provisioned values due to
> the potential complexity in resolving variables.  Let's say that there are
> five variables in a sequence.  Variables 1 and 3 have provisioned values.
> Variables 2, 4, and 5 do not  have provisioned values.  The MGC supplies
> three variable values.  The first value could override variable 1, the
> second could be applied to variable 2, and the third could override
> variable three.  Or maybe the first value could apply to variable 2, the
> second could override variable three, and the third value could apply to
> variable 3.  Or perhaps the values could apply to variables 2, 4, and 5
> with none of the variables with provisioned values being overwritten.  I
> suppose you could make some rules to handle these ambiguities, but that
> introduces an additional level of complexity that in my view is
> unwarranted.
> 
> 	If we go this way we should make it clear in the spec that
> overriding variables with provisioned values is not allowed. 
> 
> 
> 
> 	Comment e11, e12:
> 	------------------
> 
> 	You questioned the need for the speed and volume parameters in
> playCollect and playRecord.  David, do you want to comment
> 
> 	[<dcc>]  The use case for volume is the type of payphone that has a
> button that the user can press to increment the volume.  Pressing the
> button multiple times increments the volume multiple times.  Apparently
> this is for people who are hard of hearing.  It is also useful if there
> were a lot of ambient noise, e.g. traffic.
> 
> 	Speed is commonly used in voicemail systems to speed up playback of
> a message.  Each time you press a certain key the message is played back a
> little faster.
> 
> 
> 	.
> 
> 	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? 
> 
> 	[<dcc>]  In the past we've had at least one Telco request for this
> feature.  Let's say you have a department store, maybe Sears, which has a
> standard greeting, e.g. "Welcome to Sears.  Our hours are from 10:00 am to
> 9:00 pm. .........".  A telco could provide a feature whereby someone at
> Sears could call up and override this default announcement, e.g. "Welcome
> to Sears.  Due to the bad weather Sears is closing today at 5:00 pm."
> The customer could also use the override to plug sales events or to have a
> seasonal greeting, e.g. "Merry Christmas!  Welcome to Sears, your
> headquarters for Christmas shopping......"
> 
> 	 <<TD-51_Comments.doc>>