@ 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.

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 [email_address]

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

[email_address]

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

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.

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

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

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

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

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

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

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 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 2 3 4

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)

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?

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

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 2 3 4

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

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

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

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

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

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

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

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

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

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

Shared Line Appearance

Do-Not-Disturb

Call Park and Retrieve

Call Completion Busy Subscriber

Questions?