@ 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– [email protected]
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?
Top Related