draft-audet-sipping-feature-ref Feature Referral in the Session Initiation Protocol (SIP) draft-audet-sipping-feature-ref-00 François Audet -

draft-audet-sipping-feature-ref Main idea Feature referral allows an application to make a high level request a SIP UA to perform an action or “feature”, and let the UA actually execute the feature as it sees fit Application can be a proxy, user agent, third-party, etc. Uses REFER with Refer-To URI containing a URN

draft-audet-sipping-feature-ref Uses cases Loosely coupled UAs which would like to present a coordinated user experience (PDAs, Phones, Computers, game console, etc.) Traditional CTI replacement that scales globally

draft-audet-sipping-feature-ref How to perform CTI functions CTI requires two components: –Monitoring – to learn the state of the UA –Control – request the UA to perform certain feature SIP already provides some capabilities for monitoring: –Dialog package, Registration package, Conference package SIP also provides a method for requesting UAs to perform certain task: REFER

draft-audet-sipping-feature-ref What is missing today? REFER does not allow for a UA to request another UA to respond to requests, e.g., –A UA cannot request another UA to answer a call –A UA cannot request another UA to reject a cal REFER does not allow for a UA to request another UA to invoke features, e.g. –REFER does not allow a UA to request another UA to place a call on hold, or mute it –REFER does not allow a UA to request another UA to transfer, conference or park a call

draft-audet-sipping-feature-ref The Mechanism Extension to SIP Call Control and Application Interaction Framework Uses REFER (as per the procedures of Dialog- Usage in RFC 5057) Would typically be used in conjunction with subscription to Dialog Package and maybe others Sample URNs: –urn:feature:AnswerCall –urn:feature:ClearConnection –urn:feature:DeflectCall –urn:feature:HoldCall –urn:feature:RetrieveCal –urn:feature:SingleStepTransfer –urn:feature:ConferenceCalls –urn:feature:SeperateCalls

draft-audet-sipping-feature-ref What’s different this time Not attempting to standardize “Supplementary Services” Only defining the mechanism for requesting simple “features” (perhaps “primitives” would be a better term) Very loose coupling

draft-audet-sipping-feature-ref Open Issues How open to new features should this be? How is support for feature referral negotiated, and for which feature set? Should feature set be defined separately?