html5-img
1 / 25

@ IETF 68

@ IETF 68. Note Well.

merlin
Télécharger la présentation

@ IETF 68

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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.org • https://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. 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 Why?

  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. 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 Caller to UA 1 Caller to park function Caller to UA 2 Lets consider just the initial park request Example: Call Park Caller 2 Park Server 3 1 UA 2 UA 1

  10. 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 Approach 1: REFER to Caller Caller 2 Park Server 1 UA 2 UA 1

  11. 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) Approach 2: REFER to Park Server Caller 2 Park Server 1 UA 2 UA 1

  12. 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) Approach 3: KPML App Caller 1 Park Server 4 3 2 UA 2 UA 1

  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: 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 Mix 1 Caller Park Server 1 UA 2 UA 1

  15. 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 Mix 2 Caller 1 Park Server 4 3 2 UA 1

  16. 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 How do we fix this?

  17. 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 Example: Park

  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?

More Related