1. @ IETF 68

2. Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: the IETF plenary session, any IETF working group or portion thereof, the IESG, or any member thereof on behalf of the IESG, the IAB or any member thereof on behalf of the IAB, any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3978 (updated by RFC 4878) and RFC 3979. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3978 (updated by RFC 4878) for details.

3. Administrative Volunteers for Note Takers? Jabber Scribe Volunteer? Please disable ad-hoc wireless For more information on BLISS: –http://www.bliss-ietf.orghttp://www.bliss-ietf.org –https://www1.ietf.org/mailman/listinfo/blisshttps://www1.ietf.org/mailman/listinfo/bliss –bliss@ietf.org

4. Agenda Agenda Bashing [5m] – Chairs Problem Statement and Motivation [30m] – Rosenberg Charter Review [45m] – Schubert Shared Line [30m] - Johnston

5. BLISS Problem Statement and Motivation Jonathan Rosenberg Cisco

6. What is the Problem? Interoperability for more advanced ‘call’ features is fairly poor today –Shared Line Appearances –Do-Not-Disturb –Call Park, Pickup, Retrieve –More complex transfer cases –Divert to voicemail –Call completion to Busy Subscriber –Etc.

7. Why? Purposeful –Traditional PBXs require phones to be made by same vendor of PBX –Translated into similar behavior for IP PBX vendors Poor Implementations –Bugs –Incomplete Specs SIP does too much and not enough –Too many ways to implement a feature Different approach selected by UA than servers Different approach selected by different UAs –Specific capabilities are missing Line indications in SLA

8. The “Too Many Choices” Variations Processing of the feature could occur in UA or in the network –UA vendor assumed it was in the UA and network vendor assumed in network –UA vendor assumed it was in the network and network vendor in the UA Feature provided in network and invoked by the UA –Through a new SIP method –Through a header –Through an INFO or REFER body –Through XCAP or HTTP

9. Example: Call Park Park allows a user to place a call on hold, ‘store’ it somewhere, go to another phone, and request to ‘retrieve’ it so that call continues on new phone Dialog moves from 1.Caller to UA 1 2.Caller to park function 3.Caller to UA 2 –Lets consider just the initial park request Park Server UA 1 Caller UA 2 1 2 3

10. Approach 1: REFER to Caller UA 1 sends REFER to caller (message 1) –Refer-To URI resides on park server Caller automatically follows REFER and sends INVITE to park server (message 2) which plays MoH Park Server UA 1 Caller UA 2 1 2

11. Approach 2: REFER to Park Server UA 1 sends REFER to its park server (message 1) Refer-To URI is GRUU of caller, contains embedded Replaces Park server sends INVITE with Replaces to Caller (message 2) Park Server UA 1 Caller UA 2 1 2

12. Approach 3: KPML App Caller sends call through “park server” which is a proxy (msg 1) Park server delivers INVITE to UA 1 (msg 2) Park server uses KPML and subscribes to DTMF events at UA 1 (msg 3) User enters digit sequence for park, reported to park server in NOTIFY (msg 4) Park server performs REFER (not shown) Park Server UA 1 Caller UA 2 1 23 4

13. The Mix-N-Match Problem All three approaches are – known to exist – use IETF specs in a reasonably compliant way (approach 3 is questionable from a SIP philosophy perspective…) What happens if each of the components implements a different approach?

14. Mix 1 Mix 1: –UA 1 uses REFER to caller (approach 1) –Caller uses REFER to park (approach 2) –Doesn’t even matter what park server does UA 1 sends REFER to caller –Caller doesn’t need to support receipt of REFER in approach 2, so it fails REFER –OR – caller supports REFER but just for transfer, so it informs the user the call is being transferred UI failure – the ‘unknown semantic’ for authorization and display Park Server UA 1 Caller UA 2 1

15. Mix 2 Mix 2: –Caller is supporting approach 1 (REFER to caller) –UA 1 is supporting approach 2 (REFER to park server) –Park server is supporting approach 3 (KPML) Subscribe (message 3) gets rejected by UA 1 since it doesn’t support KPML UA 1 tries to REFER to park server on its own, but this is rejected by park server since it wasn’t expecting to receive REFER Park Server UA 1 Caller 1 23 4

16. How do we fix this? Need to define a set of minimum implementation requirements on each component of the system –What UA vendors need to provide –What server vendors need to provide This guarantees that there is sufficient capabilities to support at least one approach Need to define required capability declarations and queries so that implementations can detect when other approaches work too

17. Example: Park All phones MUST support –Receipt of REFER –The REFER feature tags (RFC 4508) mechanism –A specific feature tag which somehow identifies that this is a park (for UI and authorization) –Generation of REFER to remote party towards park server –Obtain park URI through config package All phones must indicate –In REGISTER, if they do KPML this must be signaled with a media feature tag This would ensure that at least one case (approach 1) works for any combination of phones Allows park server to know if phone can do something different

18. Challenge 1: Vendor Variation Need to still enable vendor variation in how a feature works –MUST allow multiple vendors to do their own thing when they are the only components in the network –MUST detect when a vendor preferred technique cannot work since one component doesn’t support –MUST make sure all components are sufficiently agreed what to do in each particular case We don’t want to kill the innovation in SIP by MANDATING one and only one way to ever do this –We specify only MINIMUM INTEROPERABILITY REQUIREMENTS to ensure at least one way works

19. Challenge 2: Feature Variation SIP’s strength has been to allow many variations on a feature with a common set of tools We do not want to kill innovation by defining exactly what each service is and exactly how it works Want to identify the –Minimum requirements that EVERY combination of implementations should support –Purposefully exclude ones that are advanced and we are not trying to make those work in every single deployment Specifically look for places where vendor variation can occur without interoperability loss

20. Example: DND Treatment Do-Not-Disturb is largely non-interoperable since there are many ways to signal it from the phone to the server –Set a presence status –XCAP –Automatically reject calls with some 6xx or 4xx code Many possible treatments of a call that is DND –Send to voicemail –Custom IVR –Redirect to email Phone to server interoperability not dependent on selection of treatment, only on signaling it on/off So: don’t standardize what a server does on DND, just how to signal it, allowing for local innovations

21. How do we do this? Pick a feature at a time For each feature –Identify a MINIMUM set of requirements that define the behavior we want to standardize –Document the many ways it can be implemented and how they don’t interop –Document missing requirements from SIP for specific feature requirements –Recommend a minimum set of specifications to support and behaviors to exhibit for each component of the system Output is typically a BCP Individual mechanism documents for new SIP functions passed to SIP

22. What is a ‘component’? Do we need to explicitly recognize phones, IP PBXs, Application Servers, etc. in our specifications? We do not! –Refer to generic components like UA and ‘servers’ –Servers would be a role, that can be filled by one or more components that would come from the same vendor IP PBX + App Server B2BUA + Park Function

23. Design Constraints Should consider PSTN endpoints as participants and PSTN interworking as a consideration, but this is not about replication of PSTN services As with all SIP, it needs to work with multimedia Heterogeneous endpoints

24. Proposed Deliverables Shared Line Appearance Do-Not-Disturb Call Park and Retrieve Call Completion Busy Subscriber

25. Questions?