Subject: Re: Issues with draft-ietf-megaco-ipphone-03.txt

From: "Taylor, Tom-PT" <[email-masked]>
Date: Tue, 14 Nov 2000 10:41:52 -0500

In response to your concern, text has been added to the description of the
keydown event in the Key package of Annex G, stating that if the key is
already down when the event is activated the event will be reported
immediately.  As I read the description of action of the hookswitch key,
this will give you what you need.

-----Original Message-----
From: Bob Lukas [mailto:[email-masked]]
Sent: Friday, October 13, 2000 12:35 AM
To: [email-masked]
Subject: Re: Issues with draft-ietf-megaco-ipphone-03.txt

Peter,
I have been considering your comments and hoping for additional feedback
from MGC vendors.

I agree my issues are not really specific to the ipphone draft, but with the
Annex G packages used by the IPPhone profile.  And I concede that most
things work fine for MGCs that want "raw" event reporting, ie. not using
digitmaps or event descriptors for filtering. It would be useful for an MGC
vendor that is planning to support IP Phones to express an opinion here.

Maybe these are issues for the implementors guide or for version 2 update of
Megaco annexes.

One issue that I am stuck on, however, is that I can't find a way to audit
the current value of the hookswitch (or any persistent-state key, for that
matter). Even if the MGC is hot-standby/auto-failover, there will be times
where it is conceivable that the current state of a particular IP Phone will
be unknown. e.g. powering up a phone while the handset is knocked off the
cradle. I would like to be able to apply off-hook warning tone in this case.
Relying on user-behaviour to jiggle the hookswitch a few times, or have the
phone possibly ring while off-hook is not optimal. You make reference to
having the Phone generate immediate events for each key on event descriptor
download - I'm not aware how to make the phone do that w.r.t. the key
package.

On the issue of multiple terminations, I absolutely agree that it is a good
architecture to separate the terminations. But until we can find a way to
allow reflex operations between terminations, we will have to admit that we
either avoid reflex operations or make the device have some implicit
knowledge of local interactions.

-----Original Message-----
From: Peter Blatherwick [mailto:[email-masked]]
Sent: Thursday, October 05, 2000 10:23 AM
To: [email-masked]
Subject: Re: Issues with draft-ietf-megaco-ipphone-03.txt

Bob:

I believe your comments below do not actually affect the Megaco IP Phone
draft itself.  However, I agree with some of the issues you raise.  Since
the Megaco IP Phone draft is currently in last call, its important to
identify where the issues reside.  See [pb] comments below.

-- Peter Blatherwick

-----Original Message-----
From: Bob Lukas [ mailto:[email-masked] <mailto:[email-masked]> ]
Sent: Thursday, October 05, 2000 01:10
To: [email-masked]
Subject: Issues with draft-ietf-megaco-ipphone-03.txt

We've been looking at implementing draft-ietf-megaco-ipphone-03.txt and a
few thorny issues have come up that I haven't seen discussed. Keypad and
hookswitch are extensions of the basic annex G key package in the UI
termination - this means:

[pb] A quick clarification: all the UI packages used by IP Phone are Annex G
packages, no extensions to Annex G are proposed.  Your statement above is
correct, but wanted to make sure all understood it.

1. There is no "current state" property value of these switches, only keyup
and keydown events that are generated. e.g. the event reported is
key/ku{keyid=kh} for an off-hook event. Not normally an issue for momentary
push-buttons, but it means an MGC cannot audit for whether the phone is
currently off-hook. Kind of a problem for an MGC that is trying to recover
state at startup...

[pb} True, there is no current state property.  I like the general approach
you suggest below to time 0 state problem.  I personally think the MGC side
of things must be responsible for recovering state if their is a failure
cut-over (not sure if that's the scenario you are concerned about) since
there's a heck of a lot more than hookswitch state involved in call state.
At device startup, the worst that can happen is the user will get bored and
hang up, generating the event anyway.

[pb] Since this is a limitation of what is specified in Annex G, this does
not directly affect the Megaco IP Phone draft.  I don't think this is
serious though.

2. At times, I'm only interested in events from a subset of the possible
keys. How can I set an event descriptor to only monitor hookswitch (for
example), and not random other button presses?

Is this syntax legal? ...modify = ui { events =1 { key/ku { keyid = kh },
key/kd { keyid = f001} }
If it was, it would help overcome the audit issue, by getting an immediate
event if currently off-hook.

[pb] I like it, even though I personally favour the all events on all the
time approach.  But I am personally unclear if this syntax is valid or not
(its been a while).  Unless someone on the list can clarify, I'll look into
it.  Even if suggested syntax is not valid, immediate Events could be
returned indicating key states at the time the EventsDescriptor is received
at the MG.

[pb] This is an issue related to Megaco/H.248 Protocol overall, not
specifically Megaco IP Phone.  Useful for Implementer's Guide?

3. The audio transducers are separate terminations from the UI. This has
great impact on wanting to automatically stop call progress tones
immediately when keys are pressed. As far as I understand, an event
occurring in one termination must not affect the signals active in another
termination (which would be a huge problem for a multiple line device for
example). For example, I cannot have dialtone automatically stop when I
press a key - the MGC must send down a signal to explicitly stop it. Even
worse, if I choose to implement a digitmap on my keypad, the MGC has no way
of knowing when to stop dialtone, because it gets no event until after the
entire dial string is entered. Saying the IP Phone should know and
understand the implicit interactions between the terminations is also
problematic and against the general Megaco philosophy of centralized
control.

[pb] The issue of Termination organization has been picked apart at length
several times before, resulting in the current organization. While I
certainly understand there is a tradeoff around causing reflex actions to
occur as a result of Events, grouping of all termination functionality into
a single termination (the implied solution) would result in drastically
reduced flexibility for the model overall, and make several powerful
applications non-intuitive at best.  For example, applications like group
listening (talker on a handset while others listen on handsfree) require
individual control over the audio input/outputs, hence separate Transducer
Terminations to allow them to be freely manipulated.  Paging while on a
call, IP-radio and several other applications would also be awkward without
separate terminations.  Since the MGC can control everything, albeit with
some extra load, the flexible model is favoured, with the intent to open up
new applications well beyond what "phones" can do today.

[pb] I strongly agree with you statement that MGs should have no knowledge
of call-related interactions (or any other application-level knowledge for
that matter), and it would indeed break the Megaco/H.248 master/slave model.
I think we all agree we don't go there.

[pb] Since this topic has been visited several times, and good agreement
achieved that this flexibility is important, I would not favour opening the
issues again.  I believe the general issue of inter-termination interaction
may be a useful area for work in future versions of Megaco/H.248, as I can
see several other example where it might be helpful.

-- PB
_____________________________________________________
Bob Lukas
Broadcom Canada
Richmond B.C.
[email-masked]
604-233-8665