Jonathan Rosenberg dynamicsoft SIPPING Work Items Jonathan Rosenberg dynamicsoft

Registration Event Package Changes Add shortened event Indicates a decrease in registration interval Client should re-register before new expiration Includes an expiration parameter

Open Issues Counter-arguments Default expiration matching default registration expiration Change to 4200s XML vs. sipfrag Why convert reg message to XML? Answer: separate data from protocol There is data in XML not in registration Registration data can change through non-SIP means (administratively) Example: shortening of registration Counter-arguments Size overhead No need for XML abstraction for simple data

App Interaction Who are we? What are we doing? Cullen Jennings, Eric Burger, Robert Fairlie-Cuninghame, Jonathan Rosenberg What are we doing? Stimulation with SIP! The way in which users interact with applications using stimulus Media Markups DTMF

What have we produced? Draft-rosenberg-sipping-app-interaction-00 Overall framework Draft-burger-sipping-kpml Keypad Markup Language Think HTML for black phones Draft-jennings-sipping-app-info SIP extensions for the framework Draft-culpepper-sipping-app-interact-reqs Top level requirements

Open Issues The infamous SIP v. HTTP Debate Sending the results of a user keypress between a user interface and the application Interface between apps and UI don’t depend on the type of UI (HTML, VoiceXML) -> HTTP Security problem -> SIP Quarantine -> SIP? Routing argument -> SIP This is a synchronous operation -> HTTP, but do we care?

Focus Determination for KPML When a user enters a digit, which KPML amongst the ones from the various apps does it apply to? No way to know for sure Current draft says send it everywhere – same as the PSTN Provides a central controller model to deal with cases where a single provider knows the rules Is that adequate?

KPML Post data in HTTP URI or Body <assuming HTTP> HTTP allows both. Does it matter.

Error Reporting for App-Info What if the App-Info URI is invalid? If the header appears in a request, you can reject the request with some error code But we allow it in responses…. Options No error reporting Only send App-Info in requests Error reporting URI (infinite recursion problem)

Indicating Script Termination If the user dismisses a UI component, there is no way for the application to find out Same is true in the web, but… Is this limitation OK for us? If not, we need to wrap app interactions in dialogs

Barge Framework has a very cool feature that allows IVR barging to be pushed to the endpoint KPML includes a barge parameter that causes media to be dropped when a regular expression is matched Means zero-latency barges in IVR – better than PSTN Problem: how to detect when its OK to start playing media again? Need some kind of media stream synchronization Marker bits -> don’t work PT changes -> might work Others?

Too many solutions? Framework provides multiple ways to do the same thing Main one: Composition Model Model I: Pipe-and-filter Model II: Central Server Model III: Endpoint Controlled The ones that can be used depend on endpoint capabilities, introducing capability determination requirements

Hookflash Should hookflash be added to KPML as an event? Opinions? Its been made “historical” in ISDN and other places If it knows enough to distinguish clear from hookflash, its functional and can send the right functional message This is a fallacy I think Opinions?