BLISS Problem Statement and Motivation

1
_at_ 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_at_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
Caller

• 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

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

2
Park Server
1
UA 1
UA 2
11
Approach 2 REFER to Park Server
Caller

• 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)

2
Park Server
1
UA 1
UA 2
12
Approach 3 KPML App
Caller

• 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)

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

• Mix 1
• UA 1 uses REFER to caller (approach 1)
• Caller uses REFER to park (approach 2)
• Doesnt even matter what park server does
• UA 1 sends REFER to caller
• Caller doesnt 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
1
UA 1
UA 2
15
Mix 2
Caller

• 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 doesnt support KPML
• UA 1 tries to REFER to park server on its own,
  but this is rejected by park server since it
  wasnt expecting to receive REFER

1
Park Server
4
2
3
UA 1
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 doesnt support
• MUST make sure all components are sufficiently
  agreed what to do in each particular case
• We dont 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

• SIPs 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 dont 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 dont 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?