Subject: Re: I-D posted: Megaco IP Phone MG 01

From: Peter Blatherwick <[email-masked]>
Date: Thu, 2 Sep 1999 16:06:00 -0400

Steve:  See comments in line below.

-- Peter Blatherwick

> -----Original Message-----
> From: Steven Magnell [SMTP:[email-masked]]
> Sent: 30 Aug, 1999 23:29
> To:   Blatherwick, Peter [CAR:AT14:EXCH]
> Cc:   [email-masked]; 'TIA Mailing List'
> Subject:      Re: I-D posted: Megaco IP Phone MG 01
>
> Peter,
>
> A couple of nits on the softkey package.
>
> The keyUp event does not contain the softKeyId, whereas the keyDown event
> and both keyUp and keyDown events in the function key package include id
> as
> well as name.
>
Oops!  Thanks for catching that.  Will fix in next update of Megaco IP Phone
and in Generic Packages document.

> The setting of the softkey nameStr to null as a means of inactivating a
> softkey seems non-intuitive since there is a separate command "display"
> that actually sets the displayed text. It would seem that clearing the
> display associated with the softkeyId should be the inactivation
> mechanism.
> The nameStr seems to be an optional identifier associated with the id.
> That
> also seems true for the indication and function key packages.
>
Agree this is a bit odd, and not very well in line with the way Function Key
works.  Might be a mistake too.  I don't remember the rationale for this, so
will have to look back in notes of the May TR-41.3.4 meeting.  I think I
agree, this should change to use the displayed string (not key name) to
de-activate the softkey, i.e. use softkey Display command.  Another approach
would be to collapse both SetName(..) and Display(..) into Activate(skID,
nameStr, displayStr) and Deactivate(skId, nameStr).  Will consider for next
update and in Generic Packages.  Comments?

> The description of the softkey display command is not entirely clear. Does
> the softkeyId refer to an individually addressable display, identified by
> the softkeyId or does it reference the string, indexed by row and column
> within a physical display that may contain text from multiple softkey
> "display" commands? If it is the former, then perhaps a clearDisplay
> command, like that for the text display package should be added. Also, the
> same attributes should be available for the softkey display as are defined
> for the text display.
>
A softkey element (hence softkeyId) refers to a separate logical softkey,
however the designer chooses to implement softkeys.  From the view of the
protocol, its a combination of a button with associated display.  Just how
they are implemented is a product-specific tradeoff, and there are many
possibilities.  Could be, for example, a physically separate piece of
display with hard key, a separate sub-region of the main display with an
associated button, a touchable region in a touch display, or a
managed/shared piece of the main display (MG device would internally manage
visibility of softkeys and sharing of main display area in the latter case).
From the protocol's perspective, it might not even be a display and key
combination at all, as long as its controlled that way (speech input/output?
mind meld interface?)  Will see if we can better describe how this is
intended to work in next updates.

> steve magnell
> Dialogic

---

From: Steven Magnell <[email-masked]>
Date: Fri, 3 Sep 1999 16:01:41 -0400

>Steve:  See comments in line below.
...

>update and in Generic Packages.  Comments?

Activation and Deactivation commands are not needed. That is what events
are for. To deactivate a softkey, a modify transaction that clears the
display associated with the key and whatever key events are set is all that
is necessary.
>intended to work in next updates.

This, of course, gets me back to the point I tried to make at the TR41.3.4
meeting (and Brian Rosen also points out in his comments). If a soft key is
merely a "combination of a button with associated display", why not just
have buttons and displays (or indicators). An indicator light is just a
display that maps all non-empty strings to "lit".

steve magnell
Dialogic, an Intel Company

---

From: Peter Blatherwick <[email-masked]>
Date: Mon, 6 Sep 1999 11:08:43 -0500

Brian:

OK, lets take this one at a time.  Response to individual comments is
below...

Regards,
Peter Blatherwick

> From: Brian Rosen [SMTP:[email-masked]]
> Sent: Thursday, September 02, 1999 17:59
> To:   Blatherwick, Peter [CAR:AT14:EXCH];
> [email-masked]
> Subject:      RE: I-D posted: Megaco IP Phone MG 01
>
> I've reviewed the latest draft, and have the following comments:
>
> The big one is that I am opposed to defining an IPPhone as
> a subset of MEGACO protocol.  The elements you describe as
> optional appear to me to be very small effort to implement,
> and zero cost in production.  Unless you could show that it
> added real cost, you should implement the protocol as
> specified.
>
Of course, I don't share this concern, and see it the other way around.  I
think what we are primarily seeing here is a difference of viewpoint --
large MG vs small MG.  IP Phone is definitely a very small MG.

I believe some profiling is highly desirable for specific applications of
the protocol, especially those which require low complexity/cost solutions
and that don't need to make use of all the protocol options.  IP Phone is
definitely such an application.  This class of device is, and always will
be, extremely cost sensitive, so ANY incremental cost is a bad thing.

The approach we have indicated is intended to reduce complexity/cost to an
absolute minimum for this type of device, in the default case, by allowing
for a pure, stateless, master/slave relationship between control (MGC) and
device (IP Phone MG).  (Of course, the designer may provide more than the
minimalist default capabilities -- we have provided mechanisms for this
also.)  By setting a known baseline capability the complexity of both MG and
MGC is greatly reduced.  Also, since this class of device will always be
highly resource constrained, the risk of failure for use of some protocol
options is quite a bit higher than in large MGs where such constraints are
not acute.  Simply not accepting optional parameters which are prone to such
failures again greatly simplifies things at both the MG and the MGC.

Also keep in mind that the reduced complexity approach is strictly used
between IP Phones and their controlling MGCs.  The MGC had sure better
understand its controlling phones -- after all its implementing the phone
application and user interface.  So the MGC side can easily accommodate the
reduced usage of the protocol by design of the IP Phone application.  This
has no effect on other applications/MGs the MGC may be controlling.

To allow for reduced complexity applications of MEGACO is clearly part of
the protocol's requirements.  See the requirements document,
draft-ietf-megaco-reqs-05, under "Restricted Capability Gateway" and also
"Access Gateway".  IP Phone is a prime example of a restricted capability
gateway application.  And all the things we propose to ignore by default are
described as "Optional" in the protocol anyway.

> 1. I think that the organization of terminations and
> packages is confusing and unnecessarily complex, as well as
> warping the concept of "root" beyond recognition.
>
> Why could you not implement exactly two terminations:
> Phone and RTP.  All of the packages you define could be
> defined on Phone.  There isn't any justification for
> having Td separate from Ta, and there is NO justification
> for making the user interface elements packages defined on
> root.
>
> There doesn't appear to be any interaction among Ta and Td.
> I don't think you ever have one without the other, and in a
> given phone, I think you always have exactly one of each
> (multiple appearances COULD result in more than one RTP
> termination, right?).
>
> Putting the user interface elements in root really offends
> me.
>
Its unfortunate this "offends" you.  I believe the approach is actually
pretty elegant in this regard.  Perhaps further explanation of how these
devices work will help settle things in your mind.

First, a telephone's user interface is not associated with particular media
streams, its associated with the device as a whole.  After all, many
end-user applications may be in operation at a time, only some of them
communication related (eg. directory access, message list, stock quotes,
reminders, etc).  The user interface resources are shared amongst these
applications, and are not specific to streams.  If this were not the case,
IP telephones would be limited to behaving like low feature, single
application "black phones" -- surely we can do far better than this.  This
same reasoning is holds for all sorts of IP appliances, not just telephones.
Where else would user interface elements go other than at the root?!

Second, multiple, separate audio transducer terminations are required to
support many highly desirable applications.  Consider for example paging
while on a call, group listening (one person talking on handset, others
listening on speaker), or music broadcast.  These require individual control
of multiple input/output devices, and require multiple audio contexts to
exist simultaneously.  The approach we specify is simple and clean for these
applications.

The DTMF tone generator (Td) is provided as a separate termination to allow
it to be moved in and out of multiple audio contexts, for flexibility. This
could also be done in other ways by associating DTMF tone generation and
keypad echo with audio resources, and we are looking at this in putting
together the MEGACO Generic Packages.  Please stay tuned on this one, and
see further comments under 13-15 below.

> 2. The term "root class" has no meaning.  The root
> termination can have a package implemented on it, which
> would define new properties/events/signals applicable to
> the entire MG.
>
Fair enough.  I guess "root class" is out of date, though I think the
meaning is clear enough.  Will check terminology relative to MEGACO/H.248
and try to align.  This terminology seems to be open to debate in the
current document however (see note under 6.2.3.6 "Root Termination").

As above, the packages we associate with root termination DO define
properties, events and signals which are applicable the MG as a whole.

> 3. Not implementing EventDescriptor is a mistake.
> The MGC should have the ability to control events.
> It's cheap to implement.
>
I definitely disagree.  The marginal value of  EventDescriptors in IP Phone
applications is low, and the complexity of handling them is considerably
higher than using a pure stateless approach.  All things are relative here!
In general, we expect that all events would be enabled all the time, to
allow the MGC to receive all user inputs and deal with them.  To use
EventDescriptors any other way would require a new EventDescriptor to be
sent after most user events, re-specifying what specific buttons, softkeys
etc are to be listened to.  Since the user is unlikely to press the
non-active ones anyway, this adds no value and would likely increase
traffic, not reduce it.

It would also introduce many situations where state is effectively split
between MG and MGC, and require event buffering and state synchronization.
Without EventDescriptors, or rather with an assumed one that simply turns
all events on, event buffering and state synchronization are not required.
See also comment 4 below.

Remember also that multiple end user applications may be sharing the user
interface resources, so any state change in one that affects expected events
would need to be co-ordinated with all the other applications.  Not a big
deal, but does add some more complexity.

Alternate approaches would be to allow only a single EventDescriptor at
startup that would turn all events on, or to accept only very constrained
EventDescriptors (all on, or all off).  Either of these would not carry any
real information, and the same effects can be had other ways, so why use
them at all?   See also next comment.

> 4. Not implementing TerminationState is a mistake.
> An IPPhone should be able to be taken out of service.
> I actually think that it should be a requirement that it
> implement loopback -- remote diagnostics would be MUCH more
> effective if it could do so.
>
This is really part of the overall event handling decision.  Given all
events are sent blindly by default, event buffering is meaningless.  Its
actually the event buffering we wish to turn off by default.

Its unclear in the current MEGACO Protocol text if this means we should not
accept TerminationStateDescriptors or if we could selectively choose not to
accept the TerminationBuffered parameter which is part of that descriptor.
It looks, at least to me, as if the intent is that the latter is a required
part of the descriptor, i.e. if the descriptor is sent, it must contain the
buffer control parameter.  (The text description seems to imply this, while
the ABNF does not.)  Therefore, since we don't actually need any
package-specific state anyway, we chose to say we ignore the whole
descriptor.

If our assumptions on intent are incorrect, we could be more specific and
not accept the TerminationBuffered parameter part.  (Or is it really 2
parameters, BufferedEventProcessingMode and BufferedEventNotificationMode?
The description is not very clear.)  This would actually be preferable since
it would leave room for package-specific state if the need arose in the
future.

If by "taken out of service" you mean turned off in the event generating
sense, I agree this is a good thing to support.  To accomplish this, the MGC
can simply turn off the MG by sending it a ServiceChange with
ServiceChangeReason=out-of-service and no MGCIdToTry assigned.  (Oops, I
just noticed there are no reason codes yet defined for the reason
parameter.)   Or, of course, the MGC could simply ignore MGs it does not
want to talk to.

I can sort of see why you would want to use TerminationState to cause no
events to be reported, though I prefer other means.  What does
TerminationState have to do with loopback though?  And what would be looped
back, from where?

> 5. Embedded events and embedded signals are another trivial
> to implement feature - if you have one, you make believe
> you got a command.  How hard can that be?  Silly to
> eliminate.  Also useful.
>
No, these are not trivial in the context of IP Phone.  Again, all things are
relative.  Embedding of events and signals is essentially a form of
primitive scripting, and adds appreciable complexity due to management of
split state between MG and MGC.  They are also not very useful since they
are not rich enough to implement much of a user interface for this type of
device.  And co-ordination of multiple end-user applications running at the
MGC would become all the more complex as well.

> 6. Not implementing digitmaps is somewhat defensible.
> You might actually see some code size difference.  If it
> was more than 4KB, get a new programmer.   On the other
> hand, you have greatly increased the system cost, because
> your MGC has to be able to handle 2-3 times more messages
> per call.  Not a good tradeoff.
>
Digit maps are a case where resource constraints could definitely cause
failures to occur.  Its not so much a matter of code size as it is one of
constrained RAM.  Digit maps are open-ended -- there is no set way to tell
the MGC how big a digit map can be accepted, or how many.  Therefore the MG
could fail, so the MGC must know how to deal with things without using digit
maps anyway.

To my mind, this one is closer to being useful than the others since it
actually could save some messaging.  I doubt it would be anything like 2-3
times in a decently designed system however.  Users will use their personal
directory, not dial the number manually.

> 7. The line "Audits MAY be used by the MGC to discover if
> a particular IP Phone MG" is incorrect.  It always is used
> to discover if a particular IPPhone has some more
> capability.  In fact, it is used to discover that a
> particular MG is an IPPhone!.  Just make the "may" lower
> case.
>
Intent of "MAY" here is that the MGC might or might not want to figure out
if a given IP Phone MG supports capabilities beyond the basic defaults.  If
it does, it must use audits to do it.  Will see if we can re-word to make
this more clear.

> 8. You can audit a termination to find out what packages
> are implemented on it.  There will be a Packages option in
> RequestedInfo on an audit.  That is how you find out what
> properties/events/signals are legal on the termination.
>
Agreed.  We also wish to know what terminations are available, particularly
the audio transducers.  Its not sufficient to know what packages, since this
leaves it unclear how they relate to user inputs and outputs and the
physical properties of the device.  We need some well known termination
names or types for this.  MEGACO does not need to specify this, but the IP
Phone MG application description does.

> 9. The text in transport should be reworded.  I'll give you
> some specific suggestions if you wish.  Just say, all
> IPPhones implement UDP/ALF.
>
Transport is still a moving target.  We felt it was necessary to record our
transport requirements somewhere (I assume this is what you are really
objecting to here).  We do say IP Phone uses UDP/ALF, but we also say we
must be able to unplug this in the future if/when a better approach becomes
available.  ALF is not a very clean approach with respect to layering, which
is unfortunate.  (I have been trying desperately to avoid getting into the
current transport debate.  Alas, perhaps it can't be avoided...)

> 10. I have reworked the "how to define a package" text
> originally proposed by Mike Kallas.  I suggest you look at
> that for suggestions on how to format section 5.
>
We are working directly with Mike and others on the Generic Packages
document, and the approach used in the current IP Phone MG document is very
close to it.  Or do you mean the MEGACO Protocol text has changed in a way
significantly different from Mike's proposal?  If so, please let us all know
where/how to get ahold of the new text for review.

> 11. The term and the text defining xducerlist confused the
> heck out of me.  As best as I can see, it is supposed to
> tell you what transducers are implemented on this IPPhone.
> If that is true, then name it something like
> xducersAvailable.  I gotta ask if you ever could have more
> than one of any of them?  It wouldn't work if you could.
>
Intent is to describe what end user inputs/outputs are available, in terms
that relate to usage.  I agree the transducer list may indeed need work as
these packages are split out and merged with others in the Generic Packages
document.  Will consider a name change for this and work on clarifying the
wording.

And yes, there can definitely be more than one audio transducer.  See
applications described under point 1.

What wouldn't work?  Please be more specific if you still see a problem, and
we can work this input in.

> 12.  How do you control the audio transducers?
> How do you turn on/off the speaker for example?
>
As described in section 3.3.2 "Control Interaction", audio transducers are
controlled by bringing them in and out of context.  Additional control can
be achieved using the Mode parameter of StreamDescriptor/LocalDescriptor on
Add or Modify commands, to set sendonly, recvonly etc.  All normal MEGACO
stuff.  Is more descriptive text required to describe this in more detail?
Would be redundant with MEGACO.

> 13. I expect that the basic packages document will fix the
> tone stuff for you.  There are several things not to like
> in this package.  Let's see how that comes out before we
> rip this one apart.  One particularly glaring item is
> stoptone.  Get rid of it; there is MEGACO syntax to deal
> with stopping a signal, use it.
>
We are working directly with Mike and others to work this content in.

StopTone was put in as a way to explicitly control ending a tone.  Pretty
normal stuff really.  Don't see what you're objecting to here.  What
specific syntax are you referring to?

> 14. Why is DTMF tone separate from tone?  A tone is a tone
> is a tone.
>
DTMF tones are kept separate from others such as call progress to enable
greater reuse of the packages.  If all tones are bundled together, we need
to figure out what specific tones are actually implemented.  If they are
kept separate, packages can be implemented in more of an "all or nothing"
manner, and auditing package support narrows down what is implemented very
quickly.  No further audits would be required in many cases.  I prefer to
see a larger number of smaller packages for this reason, and this applies to
all packages, not just audio.

> 15. In 5.2.3.2, it says:
> [[ ISSUE: There is currently no means to control the context to allow
> this. ]]
> I don't understand this.  What does the context have to do
> with this capability?
>
> I do think that is not a signal, it is a property, and
> should be defined as such.
>
The comment refers to directionality of keypad echo.  When a tone generator
termination is added to a context, normal behavior would be to send tones to
all other terminations in the context, which is usually not what you want to
do.  Therefore some means is needed to send the tones only to the right
places at the right levels.  Contexts currently provide no way to do this.
I guess this relates to the current discussion on the list on the topic of
topology.

As these packages are merged into the Generic Packages document, I suspect
this one will change.  Agree DTMF tone generator is a bit awkward, though
the needs are clear.  Not clear to me its a property we need to control
directionality, since there could, in the general case, be more than one
source of DTMF keypad input, so would need to sort out which one was
supplying input to what.  Definitely open to suggestions on this one.

> 16. Punt keyIds.  Each key has a name, you always refer to
> the key by it's name.  The MG is built with a set of keys,
> so you can audit to find out what the names are.
> The MGC has to know what the possible values of name is,
> having any kind of dynamic naming is silly.
>
KeyId is a fixed (static) assignment which acts as an index, whereas the
NameString relates to its intended purpose and may or may not be settable by
the application (i.e. the MGC) to save an additional mapping step when key
events are received.  NameStrings will often have a well known name assigned
corresponding to a feature invocation, for example "Hold" or "Park".  These
well known names are extremely useful for figuring out the intended purpose
of a particular key on the device, especially in cases where keys are
permanently assigned (as by permanent labels) or associated with particular
parts of the device (eg. the hookswitch).  It was felt that both indexing
and naming were sufficiently useful to be included.

> 17. What does "set name" do?  Associate keyId with nameStr?
> If so, get rid of it as above.
>
Yes.  See 16 above.

> 18. In 5.4.1 you have to spec what the syntax of the
> indicatorList is better.  Is it a string that is parsed
> with id, and attributes?  Is it a compound structure?
> What is the (text) syntax?
>
Will work on cleaning this up in Generic Packages.

> 19. Same argument on names and ids for indicators.
> One is enough.
>
Disagree.  See comments under item 16.

> 20. Need a more precise syntax in 5.5.1  I understand what
> the integers mean, just specify what the syntax is to
> get a list.
>
Will clean that one up.

> 21. I personally don't see why softkeys are not just
> indicators and function keys with an appropriate name.
> I get that you need another command, but you might as
> well just define it in indicator and make them the same.
> You want simple - that makes it simpler.
>
Hmmm...  A softkey is a key with an associated piece of display, for showing
dynamic, context-sensitive text.  Combination of key and indicator does not
implement this function.  Also, if we have only keys and separate indicators
or display regions, or whatever, then there is the problem of somehow
associating them with one and other, which is confusing at best.  Since
softkeys are a well understood user interface mechanism in their own right,
and a very powerful one at that, yet are implemented differently by
different manufacturers, we opted to provide a distinct abstraction.  With
just 3 softkeys, a virtually unlimited list of features and applications
could be supported!

Your description more closely matches what I would call a key/indicator pair
(a key with associated LED or something along those lines).  We toyed with
making this a separate abstraction as well, but did not on the grounds that
it was not as obviously useful as softkeys.  Basically, we're talking object
hierarchy here, and there is no perfect answer.  We could have collapsed all
indicators, keys, softkeys into a single class, but it appeared unwieldy.
In the other extreme, we could have dissociated everything, including
display segments from softkeys, but this also looked confusing and error
prone.  We chose a compromise somewhere in the middle.

> Brian
[snip]

---

From: Peter Blatherwick <[email-masked]>
Date: Mon, 6 Sep 1999 11:11:24 -0500

Steve:

Comments in line below.

Regards,
Peter Blatherwick

> Sent: Friday, September 03, 1999 16:02
> Cc:   [email-masked]
Just a thought.  Agree activate/deactivate would be a bit odd.

Have looked again at my notes, and I think the original intent at the
meeting was to use the display string (not name) to activate/deactivate, so
it looks like we should change that.

> display that maps all non-empty strings to "lit".
This has gone around several times now, and seems to keep coming back to the
same place.  A softkey is a key with an associated piece of display, for
showing dynamic, context-sensitive text.  If we have only keys and separate
display regions, then there is the problem of somehow associating them with
one and other, which is confusing and error prone.  Since softkeys are a
well understood user interface mechanism in their own right, and a very
powerful one, we opted to provide a distinct abstraction for them.   This
was discussed and settled as far back as last May in TR-41.3.4.  The current
solution seems to be the best compromise.

See further comments in responses to Brian and Rex, same thread.

[snip]

---

From: Peter Blatherwick <[email-masked]>
Date: Mon, 6 Sep 1999 12:10:52 -0400

Rex:

Thanks for the input.  Comments below.

Regards,
Peter Blatherwick

> From: Rex Coldren [SMTP:[email-masked]]
> Sent: Thursday, September 02, 1999 19:06
> To:   [email-masked]
> Whew!  Brian saved me a lot of typing.  I mostly agree with his
> dissertation,
> but will point out a few more things and ask some questions.  Oh, and lest
>
> you think this is just a bash IPphone festival, I must congratulate the
> authors
> on doing a pretty good job of hitting a moving target.
>
Thanks.

> 1) Are we allowing definition of new termination types in the package
>    definition methodology?  This seems to be what is suggested.  I think
>    I actually like that idea.
>
Intent is to define everything belonging to sets of related functionality in
one place.  Since packages are the only defined extension mechanism at this
point, that's where everything must go.  This is consistent with the
approach taken in Mike Kallas' proposal for specifying packages and being
used in the Generic Packages document under construction.  And it works
pretty well for the IP Phone application description.

Actually I would like to see some well known termination classes as well,
but this would mean defining a second extension mechanism in MEGACO.  The
time is probably not right to do this in the current go round.  Applications
such as IP Phone can describe their own assumptions for now, and ways to
audit the information.   Not ideal, but quite workable.

> 2) Having a DTMF tone generator termination fits the definition of a
> termination
>    as a source and/or sink of media and/or control streams.  Whether or
> not it
>    really should be a separate termination is questionable and is really a
> question
>    for H.248/MEGACO in general.  The answer to the question should apply
>    also to announcement clip sources as well.  If it seems useful to play
> tones
>    and announcements to more than one termination in a context
> simultaneously,
>    then it would make sense to have tone and annoucement terminations.
>
Yes, I think this is quire similar to audio/announcement server applications
as well.  We chose to make DTMF generator a separate termination for
flexibility and control, and I think audio servers will want to do the same.
This may well get re-organized in IP Phone as we align with Generic Packages
though.  See also further comments in the reply to Brian's comments, same
thread.

> 3) I agree with Brian that tones are tones.  Keep DTMF with the other
> pile.
>    If we define a media source termination per 2, then the tone packages
> can
>    be added to the termination.
>
I like more smaller packages as this can improve reuse and simplify audits
to discover what is actually implemented.  Using audio as an example, it is
not necessarily the case that all terminations that support call progress
tones will also want to support DTMF.  With smaller packages, we can have
more of an "all or nothing" approach, so if its there at all, its all there.

> 4) The keypad echo signal seems out of place at the DTMF tone generator
>    termination.  A tone generator wouldn't have a keypad.  It really seems
> to
>    be a symptom of not allowing embedded  events/signals or scripts.  That
>
>    is, with those you'd simply respond to a DTMF event by signaling that
> the
>    same DTMF tone be generated from the tone generator (yeah, it's pretty
>    monotonous doing it that way).
>
Agree keypad echo is a bit awkward.  However it should work assuming we get
the syntax right.  I really don't think embedded events/signals is the right
answer for this.  It would require setting events and supplying signals
corresponding to every possible key press, which is bulky and just not
necessary.  Just turn on DTMF keypad echo and be done with it.

> 5) This is a little premature, but Rich Bowen proposed multiplexing of
> tones
>    within the RTP audio stream so that compression would not distort DTMF
>    unduly (actually, I think credit must also be given to
> Petrack/Schulzrinne on
>    this too).  This is a general H.248/MEGACO issue, not just for
> IPphones.
>    I'm guessing the best way to handle this would be at the RTP
> termination,
>    but don't have a proposal for how to do it.  And the issue isn't
> decided yet
>    anyway.  I just wanted to point it out so we don't preclude the
> possibility.
>
Not familiar with this.  Please describe further.  But probably better on a
different thread.

> 6) What is "Handsfree"?  Seems to me it is a combination of Speaker and
>    Microphone.
>
Yes, handsfree could be constructed that way, but most users think of
handsfree as a single entity.  We decided to keep handset, headset,
handsfree, speaker and microphone as separate types to allow maximum
flexibility and to make it intelligible to the MGC application what the
intent and behavior of each transducer is.  Handsfree is bi-directional and
has built-in echo cancellation and so on, whereas speaker and microphone
probably do not.  The speaker and microphone terminations could, for
example, be used to construct a conference unit with one speakers and
several individually controllable microphones.

> 7) If you decide to stick by the idea of not allowing use of
> EventsDescriptors
>    then you will need to change the sentence just above 5.1 to say "Event
> and
>    signal information specifies the legal properties (values) for observed
> event
>    and signal descriptors applied to the corresponding terminations."
>
Yup.  Will check wording.

> 8) 5.3.2.2 Observed Events == Some (i.e.-not None).
>
Oops.  (Darn those fingers.)

> 9) References are out-of-date.  Big surprise there.  Also, Mike Kallas' TD
>
>    was for the Berlin meeting.  TD40 appears in more than one SG16
> meeting.
>
Yeah.  Its the best we had.  This will be updated when we have something
solid to point at.

[snip]

---

From: Brian Rosen <[email-masked]>
Date: Tue, 7 Sep 1999 12:38:25 -0400

We have a couple of really fundamental issues here.
I'm not sure if you intend this to be part of the
"basic" packages.  If not, we can carry on this
discussion without a time constraint.  If you do,
I think maybe you should reconsider.

The first fundamental issue is whether a profile can
decide to eliminate some feature of the protocol which
is not considered optional and so labeled in the protocol
definition.  While nothing stops any vendor, industry
group or other standards bodies from defining a new
protocol as a subset/superset/whatever of an IETF or
ITU protocol, we generally don't permit subsets as being
considered conformant implementations (reminding everyone
that we are not the protocol police).

EventDescriptors are not optional.  If you believe that
they should be, then you should get the document changed
so that they are designated optional.  If consensus exists
to do that, we should.  If consensus exists that we should
not, then you can't define a "profile" that eliminates them,
you have to create a new protocol.  You are free to do that,
but it's not MEGACO.

Specifics below:

....snip....
> large MG Vs small MG.  IP Phone is definitely a very small MG.
Small gateways have been a major driving force in the design
of the protocol.  There have been some serious compromising done
by the "big gateway" folks to make the "little gateway" folks
happy, and vice versa.  To come along and demand further changes
(and still try to claim that it's MEGACO) is not a good idea IMO.

This DOES mean some additional costs.  It should not mean
much, and there are quite a few people on the list who think
that the compromises made to try to keep one protocol have been
appropriate.

> be, extremely cost sensitive, so ANY incremental cost is a bad thing.
I agree with this statement, especially the part that says
"makes use of all protocol options".  Most of the places
you define as optional are not.

> failures again greatly simplifies things at both the MG and the MGC.
This point has been made repeatedly in the development of
the protocol.  It is believed that the set of capabilities not
labeled optional represent the appropriate set when considering the
disparate needs of both big and small gateways.  It may have been
better to have two protocols, but many of us disagree, even if
it means carrying features that raise the cost and complexity of
one end or the other.

...snip....
> described as "Optional" in the protocol anyway.
Please show me where EventDescriptors are defined as optional.
Just because they are not required in every instance of a command
does not imply that the MG is free to not implement them.
There are very few options in the protocol.  By design.  By effort
of a large number of people to make very interoperable MGs and MGCs.
By a large amount of compromise.

.... snip .....

> communication related (e.g.. directory access, message list,
> stock quotes,
Not applying to a particular stream does not imply not associated with
a particular termination.  The basic model of the protocol is that
all capabilities of a "call" are associated with a set of terminations.
The root (which many people actually think should be eliminated,
but there are just too many things you just HAVE to be able to refer to
the entire MG for), is for those properties that cannot be associated
with one call/conference.

I see where you got to the idea that a button, for example, is not
permanently part of a conference, but I believe you warped the model
in saying "therefore, it is a property of the gateway".  To be manipulated,
the user interface elements should be on a termination, in a context.
The context they might be in, if they are not part of an active call,
is the "null" context.

> exist simultaneously.  The approach we specify is simple and
The wording is confusing in that it was not clear to me that
each transducer was a separate termination.  This is okay
for me.  One of the major confusions is that you have the
xducerList on the user interface elements.  Now that I get
that you propose multiple Tas, each of which is a different
one of the elements on the transducer list, then you should
just audit the gateway to find what transducer Tas there are,
and not have the xducerList at all.  Having 2 ways to do the
same thing is not a good idea, and auditing the gateway
to find the terminations is how it's done.

> see further comments under 13-15 below.
It should just be signals on a Ta.  There is another
message on this thread which I spent more time on this
item.

> current document however (see note under 6.2.3.6 "Root
I'll fix the text.  We say that a termination implements or realizes
a set of packages.  I expect that one of the characteristics of
a profile is a list of packages that would be supported.  Profiles
are not currently defined however.

> properties, events and signals which are applicable the MG as
Don't agree.

> higher than using a pure stateless approach.  All things are
I don't believe that the MG is stateless.  It has contexts.
They are state.  It has properties with values, they are state.
It has transactions in progress, they are state.  The event
mechanism itself has state regardless of the eventDescriptor.
The additional state of an event descriptor is very small
incremental state.  I can't imagine how you could even see the
additional complexity in an implementation if you have the
event mechanism at all.

If you remove it, you have some problems.  What is the
RequestID for example?  It's MGC specific what value
is appropriate.

> non-active ones anyway, this adds no value and would likely increase
The embedded event rearms it.  That is one reason it is there.
Defining new mechanisms when the existing one is very simple
is not appropriate IMO.

> See also comment 4 below.
I don't understand this.  If there are events, then you have
synchronization.  The event descriptor simply enables events
and supplies the RequestID.  You save an infinitesimal amount
of code to have it always enabled and some other way to
specify the RequestID.

> deal, but does add some more complexity.
In what way does eliminating the EventDescriptor help this?

> them at all?   See also next comment.
Mystifying to me why such a simple command seems to imply some
huge implementation effort.  The idea that having all on, vs.
some on and some not on is hard to implement is, uh, ?silly?
Are you worried about how hard it is to parse the names?

> actually the event buffering we wish to turn off by default.
Multiple events can happen "simultaneously".  Therefore they have
to be buffered in the MG.  The issue is whether the Notify is always
sent as soon as the event is recognized and handled, or whether some
mechanism keeps track of the event buffer and sends them "later".
While there is no doubt that it is more complicated, the question is,
how much more complicated? 10 lines, 40 lines, 100 lines?  Where is
the line drawn, and how much are you willing to sacrifice MG/MGC
non-interoperability?

When you get to a major item like digit maps, you can see the
complexity.  That is something that was debated for a while, and
the compromise answer is EVERYONE implements digitmaps.  In this case,
the complexity is very low, it does affect interrupt rate at the MGC,
and there doesn't seem (to me) to be sufficient justification for
changing the protocol to make it optional to implement.

TerminationState is the descriptor that gets properties defined
in packages that are not stream specific.  Another reason you need it.

> package-specific state anyway, we chose to say we ignore the whole
A mistake I believe, as outlined above.

> it would leave room for package-specific state if the need
Right

> parameter.)   Or, of course, the MGC could simply ignore MGs
The protocol has two capabilities that are being split.

In service/out of service is part of TerminationState because it
is not stream specific.  Loopback (and sendonly...) is stream
specific and is therefore part of LocalControl.

Neither is optional.

> TerminationState have to do with loopback though?  And what
Loopback is termination as well as stream specific.
You loop back your input to your output.

> MGC would become all the more complex as well.
Maybe it would be helpful to discuss a specific
example.  I can't see any significant complexity.  It's all
just a handful of lines of code per feature, and the entire set
of features is just not that large.  It is non-trivial to code,
but I find it hard to believe it has any cost in production.
You can argue that we should have real scripts.  I've made
that argument.  You can argue that it is baggage for this
application.  Regardless, if it's called Megaco, it has
the capabilities as defined.

> could fail, so the MGC must know how to deal with things
There should be an error which is not enough room to store a digitmap.
I could see a property of root which was the maximum space allocated
for digitmaps, and maybe a dynamic how much of that space was currently
in use.  We had arguments over how many digitmaps, but were unable
to resolve them, leaving us with just the error.  I would say that
a profile could define something in this area (like, at minimum one
map of no more that 1K characters).  I once looked at the standard
North American dialing plane digit map - it's pretty small.
I imagine that even a PBX plan with a relatively complex dialing plan
would still be pretty small.  You do only need one.

> directory, not dial the number manually.
Huh?  Ever seen statistics on that?  I've looked into that one
before.  In the PBXs that were studied, use of personal directories
(speed dial) was minimal.  One touch dialing (soft keys) does work.

> it does, it must use audits to do it.  Will see if we can
Okay, but how do you know the IPPhone is an IPPhone unless you audit?
Even just the profile is only discovered by audit.  Are you saying
an MGC might just assume any MG contacting it had to be an IPPhone?
Please remind me not to buy that brand :)

> Phone MG application description does.
You audit to get a list of terminations.  Then you audit each termination
to find out what packages it supports.  If that is insufficient,
someone has a misunderstanding which we should rectify asap.

If I get your proposal, auditCapability * would return
a Ta for each transducer and the Td (if that stays), plus (I've got
a thread going on this one) some form of a Trtp.  You audit
each of these to find the packages it implements.  You can then
audit them to find the value of properties (like what kind of
transducer it is).

> current transport debate.  Alas, perhaps it can't be avoided...)
Don't go there :)   We have a compromise, and no one has objected yet!

> where/how to get ahold of the new text for review.
Yes the text has changed.  I put out a message showing what
changed on the original thread that Mike released his text on.
There is a new (V10) version coming out which will have it.

The changes aren't very substantial.  Won't take you more than
a couple of minutes to edit your text.

> applications described under point 1.
Discussed above.  Not appropriate as a property of some unrelated
termination.  Should be a single valued property of a Ta.

> we can work this input in.
The list has no way to represent more than one handset, for example.
Moot point if it's made a property of a Ta.

> Would be redundant with MEGACO.
No, I get it.  If you clear up the initial description in the front,
this part is more clear.

> specific syntax are you referring to?
From the text "A new SignalDescriptor replaces any existing
SignalDescriptor.
Any signals applied to the Termination not in the replacement descriptor
are stopped, and new signals are applied."  A null SignalDescriptor
stops all signals.

> all packages, not just audio.
This generates intersecting packages, a no-no.
Auditing to find the range of tones supported is reasonable.

> I guess this relates to the current discussion on the list on
Yep.

> supplying input to what.  Definitely open to suggestions on
First let's see how the topology discussion settles.
The line: "since there could, in the general case, be more than one
source of DTMF keypad input"  intrigues me.

If there can be more than one Td, then there can be more than one
set of softkeys.  This is more ammunition for making them part of
a termination, and not part of root.

One scenario is a box that turns a set of existing phones into IPPhones.
Each one has it's own devices.  The MG is a set of IPPhones, not just one.

> and naming were sufficiently useful to be included.
Wow, did anyone who actually implements these things look at this?
Two ways to refer to the same thing is bad, bad, bad.
Programmers have lots of tools to make it easier to have meaningful
names without generating bits on the wire.  Let's have some
examples in support of this.

> Hmmm...  A softkey is a key with an associated piece of
> display, for showing dynamic, context-sensitive text.
Right, it's a key with a changeable indicator.
There is no functional difference between a softkey with
a label on the key, a softkey with the label in an
adjacent LCD screen, or a separate LCD screen that just
has softkey labels.

>Combination of key and indicator does not implement this function.
Why not?  The only difference is the automatic assumption of
the linkage.

> Also, if we have only keys and separate indicators
> associating them with one and other, which is confusing at
> best.
It's always confusing at best.  Sometimes to the user!
Seriously, the only confusion comes when the softkey is part of
a more general LCD screen.  Are you forcing the IPPhone to deal
with that - treat the LCD screen as separate devices?  Wrong place
for such complexity I would think.

>Since
I think treating them as indicators and function keys doesn't
change the complexity of code one whit.  The system still knows
that the softkey is a combination of capabilities, it still needs
the same primitives to manipulate them.  Keys are addressed items,
as are any kind of separated indicator.  The MG doesn't intrinsically
know the address, it discovers it.  Whether it's two separate addresses
or one doesn't make any difference at all.

> prone.  We chose a compromise somewhere in the middle.
I think they are all the same thing = something to show
an indication, and something to accept input from.  The fact
that they are paired distinguishes them, but that is very easy
to deal with.  You do need to know they are paired, it's just
how you discover it.

Brian

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 7 Sep 1999 13:07:39 -0400

I have to intervene on the tone issue.

> From: Brian Rosen [SMTP:[email-masked]]
> Sent: Tuesday, September 07, 1999 12:38 PM
        [[TomT]]  ...
> Auditing to find the range of tones supported is reasonable.
        [[TomT]]
        The very opposite is intended.  By limiting the scope of a specific
package to what would reasonably be supported in its entirety by every
gateway that supports the package, you don't have to go down another level
to find out what particular pieces of the package are supported.  There are
some signals (particularly dial tone and physical ringing) that would be
supported only by an access gateway (access in the generic sense).
Requiring support of these on all GWs is unreasonable, so why not put them
into a separate package?  I'm not sure this is a justification for
separating DTMF, mind you, but DTMF is so nicely self-contained that it is
tempting to put it by itself.

---

From: Brian Rosen <[email-masked]>
Date: Tue, 7 Sep 1999 13:52:15 -0400

Tom

This message is confusing to me.

There are 3 possible ways to group things:
1. A small number of very general packages covering a wide
range of capabilities.  Subsets are common.

2. A large number of feature specific packages, each one
covering one area, but not any overlapping of elements
between packages.  Subsets are not common.

3. A large number of function specific packages with lots
of overlap between them. Subsets are not common.

I thought we were heading towards #1 or #2.
I favor #2, but I'm okay with #1 as long as subsets are
allowed and audit works to discover the subset.  Based on
what I'd read, I had though that tone coming in the generic
package was a #1 style - one package that described most of
the known tones.

I oppose #3.

This could mean for tones that there is a basic tone
package that describes a tone with a name.  Only a very
small set of tones are defined.  Another package could then
expand the list of tones in a specific direction.  Only
rarely (by accident or lack of foresight) would the same
tone end up in two different packages.  The basic package
deals with issues like national variants, etc.

Brian

> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Tuesday, September 07, 1999 1:08 PM
> To: Brian Rosen; [email-masked]

---

From: Brian Rosen <[email-masked]>
Date: Tue, 7 Sep 1999 14:16:38 -0400

See comments below

Brian

> From: Peter Blatherwick [mailto:[email-masked]]
> Sent: Monday, September 06, 1999 12:11 PM
> To: [email-masked]
I'd say that in general, packages are the way you describe a set
of related properties/events/statistics so that they will
be implemented the same on a variety of gateways.

The document is more than a set of package definitions,
because it attempts to define a profile.  That is fine.

There was a lot of discussion on what was meant by "termination
class".  The idea that a set of packages equalled a termination
class is obvious, but there doesn't seem to be a reason to
create a new term.

Right

> though.  See also further comments in the reply to Brian's
I've wrestled with this.  My conclusion is that a tone generator
or an announcement server as a separate termination makes sense
only when there are some significant limitations on it's capabilities
that must be respected.  If that isn't true, then it is best
modeled as a set of signals that can be applied to a termination.
The signals concept is so general, and has parameters, so making a
tone generator a separate termination doesn't buy you anything.
It's only when the MG has to know, for example, that there can
only be ONE tone generator active in the entire MG that you may
have to model it as a separate resource.  This might apply to
an IP phone, but I suspect that in practice it isn't an issue
(that is, there might only be one tone generator, but the MG
is rationing resources for the device like crazy, and doesn't need
the one termination per tone generator to be able to deal with
it).

> more of an "all or nothing" approach, so if its there at all,
See above.  I hope that the generic tone package is ALL that there
is.  I do think you will need to be able to restrict the tone set
on an individual termination to whatever the real tone generator
can do.  It still is one package definition.

Multiple intersecting packagaes are a BAD idea.  Lots of non-intersecting
packages are a good idea.  One general package is better than several
tiny little subset packages if there are reasonable ways to discover
and use the implemented subset.
....snip...

> several individually controllable microphones.
Implies you can have handsfree on one call, and speaker on another.
I generally think that if there is one physical device you either have
to model it as one device, or have an expicit, and carefully thought
out multiplexing scheme.  That is not apparent in speaker/handsfree.
I see the distinction, but I fear the consequences.

...snip......