Subject: [Sipping] Possible missing functionality in App Interaction Framwork

From: Bert Culpepper <[email-masked]>
Date: Thu, 07 Nov 2002 14:32:20 -0500

Hi all,

It has been brought to my attention (from one individual involved in
PacketCable work) that functionality present in the Key-Events proposal
no longer has a home in an IETF I-D with the expiration of the
Key-Events I-D.  The functionality is the ability of a SIP-based
application to be notified of hook flash and on/off hook events.

I've been told this functionality is needed to support Emergency
Services (E-911) and Operator Services BLV/OI (Busy Line Verify/Operator
Interrupt) for endpoints (SIP phones) in the IP network.  I can see the
SIP Events Dialog Package and REFER supporting the busy
line verification/Operator Interrupt (as I understand these services).

Would it be reasonable to extend the KPML or create a new markup to
support this?  Or some other mechanism?

Thanks,
Bert

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 07 Nov 2002 14:55:55 -0500

I think its reasonable for it to be in the KPML specification. I don't 
think it was an intentional omission. ANything which is physically 
present as an input signal on a standard phone should be in there.

Of course, that leads to the interesting question of how a phone knows 
whether hookflash should cause the phone to be hung up, or to generate 
an event that KPML sends to an application. Its an instance of the 
inter-application feature interaction problem caused by a focusless UA. 
The second application here is the actual SIP UA running inside the 
phone, which might interpret on-hook as a signal to end the call. The 
recommendation in the framework document is to send the user input to 
all user interfaces, which means that a KPML event is generated at the 
same time as a hangup. Probably not what you want.

I suppose though, that a switch has this same problem, and thats why 
hookflashes are short. So, adding hookflash within KPML probably makes 
sense; it would be sent to both the KPML UI and to the local UI. The 
local UI would not hang up the call, so KPML would get the signal and 
could do something with it. A full blown on-hook, however, is probably 
pretty darn useless in KPML, since any device who's local app isn't 
interpreting on-hook as a hangup is probably not a good candidate for 
KPML to begin with.

Remember, this aint megaco. I recommend people say this to themselves a 
few times.

The role of stimulus signaling in SIP is to interact with network 
applications that a SIP UA is involved with. The phone is still "smart", 
in that its a full SIP UA and may even have the worlds most complex 
functional signaling interface. Therefore, you cannot say that "the 
controller decides whether hookflash ends the call". THis is a highly 
distributed stimulus framework, and not at all like the totally 
centralized model of megaco.

And just so we are clear; from the framework, it is the job of the user 
interface (read: KMPL) to determine whether or not user input 
constitutes a hookflash or on-hook event. The timing for makign the 
decision is a UI issue. An application behind the UI doesn't care. If 
you wanted to run the UI remotely, you would use rfc2833 to convey the 
actual input to the UI running on a server, and the server would figure 
out the timings and generate the appropriate event. rfc2833 is needed 
for the remote-client UI to figure out the timings.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com