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

From: Brian Rosen <[email-masked]>
Date: Thu, 2 Sep 1999 17:58:34 -0400

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.

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.

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.

3. Not implementing EventDescriptor is a mistake.
The MGC should have the ability to control events.
It's cheap to implement.

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.

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.

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.

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.

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.

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.

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.

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.

12.  How do you control the audio transducers?
How do you turn on/off the speaker for example?

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.

14. Why is DTMF tone separate from tone?  A tone is a tone
is a tone.

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.

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.

17. What does "set name" do?  Associate keyId with nameStr?
If so, get rid of it as 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?

19. Same argument on names and ids for indicators.
One is enough.

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.

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.

Brian
------------
Brian Rosen, Principal Engineer
FORE Systems, 1000 FORE Drive, Warrendale, PA 15086
(724) 742-6826  mailto:[email-masked]

> -----Original Message-----
> From: Peter Blatherwick [mailto:[email-masked]]
> Sent: Monday, August 30, 1999 4:42 PM
> To: [email-masked]
> Subject: I-D posted: Megaco IP Phone MG 01
>
>
> Greetings:
>
> An updated version of the Megaco IP Phone MG I-D has been
> submitted as: "draft-ietf-megaco-ipphone-01.txt".
>
> Updates include:
> - Added a section on usage of the Megaco protocol ("protocol
>   profile", use of transport);
> - Alignment of IP Phone packages with the proposed package
>   document format;
> - Refinement, filling out and clean up of signals, events, and
>   other information.
>
> This update is the result of discussion and agreement of the TIA
> TR-41.3.4 working group on IP telephones.  TR-41.3.4 represents a
> wide cross-section of the industry.  The IP phone "whole device"
> standard being produced by TR-41.3.4 allows for both master/slave
> (Megaco) and peer-peer (SIP or H.323) types of control as options.
> We believe both control approaches are viable, are entirely
> compatible at the system level, and are complementary in the
> marketplace.  Products supporting both master/slave and peer-peer
> approaches will surely exist, so the standard seeks to cover both.
>
> Until the draft appears on the IETF site, it can be found at:
> ftp://standards.nortelnetworks.com/megaco/docs/Wash99/
>
> Regards,
> Peter Blatherwick
>

---

From: Rex Coldren <[email-masked]>
Date: Thu, 2 Sep 1999 16:06:15 -0700

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.

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.
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.
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.
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).
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.
6) What is "Handsfree"?  Seems to me it is a combination of Speaker and
   Microphone.
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."
8) 5.3.2.2 Observed Events == Some (i.e.-not None).
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.

Brian, how do we get to the new version of "How to Define a Package" text?

Rex

---

From: Min Su Cho <[email-masked]>
Date: Fri, 3 Sep 1999 11:26:32 +0900

Unsubscribe [email-masked]