@ IETF 68

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.

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

Agenda

• Agenda Bashing [5m] – Chairs

• Problem Statement and Motivation [30m] – Rosenberg

• Charter Review [45m] – Schubert

• Shared Line [30m] - Johnston

BLISS Problem Statement and Motivation

Jonathan Rosenberg

Cisco

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.

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

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

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 from1. Caller to UA 12. Caller to park function3. Caller to UA 2

– Lets consider just the initial park request

ParkServer

UA 1

Caller

UA 2

1

2

3

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

ParkServer

UA 1

Caller

UA 2

1

2

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)

ParkServer

UA 1

Caller

UA 2

1

2

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)

ParkServer

UA 1

Caller

UA 2

1

23

4

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?

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

ParkServer

UA 1

Caller

UA 2

1

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

ParkServer

UA 1

Caller

1

23

4

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

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

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

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

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

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

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

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

Proposed Deliverables

• Shared Line Appearance

• Do-Not-Disturb

• Call Park and Retrieve

• Call Completion Busy Subscriber

Questions?