Basic Level of Interoperability for SIP Services (BLISS) BoF

1. Notes taken by Spencer Dawkins
2. Notes taken by Vijay Gurani

1. Notes taken by Spencer Dawkins:

1. Agenda Bashing [5m, chairs]

• Focus is on problem statement and charter - other work if we have time.
• No bashing of the agenda happened.
  

2. Problem statement and motivation [30m, Jonathan Rosenberg]
   [Slides only, no draft]

• Interoperability for advanced features is fairly poor today - probably the worst place in SIP.
• Tend to be more complicated, often enterprise features.
  
• Why? PBXes weren't designed to interoperate, that was the business model. Sometimes it's poor implementation. Sometimes SIP does too much and sometimes not enough. Too many ways to implement a feature, but specific capabilities are missing. This is a lot of what we see today.
• The too-much-and-not-enough problem is what we want to work on in BLISS.
• "Too many choices" variations - processing could happen in the UA or in the network, many different ways to invoke a feature (all legitimate but won't interoperate).
• Call park example... at least three approaches, all observed in the wild, no two will interoperate. Refer to caller, refer to park server, KPML application ("legitimate bastardization of SIP").
• Rohan - there is a statement in 3515 for Refer/Replaces authorization, only approach 1 follows this recommendation.
  
• Mix-n-match puzzle - approach 1 surprises caller, either ignores REFER or thinks it's a transfer.
• Paul - caller doesn't know he's being parked, right? Why should he be able to know? Park and transfer are different, this is a missing thing. Whatever you pick, the wrong thing will happen. But won't transfer fail, too? Two separate cases, both fail, one is more subtle but both fail.
  
• Dave Oran - can we move on if you're giving people a high-level view? But this is a transfer, at a high-level. If UA supports transfer, problem does not occur.
• Jonathan - please tell me that all of these things really work!
• Francois - don't solve call park right now, you're showing the problems.
• KPML totally fails if UA 1 doesn't support KPML.
• How to fix this? "Minimum implementation requirements for each component" - must implement REFER...
  
• Henning - alternative view of the world is that we don't want to name all the features. This is back to the original view of SIP, you need to support a toolkit. Stimulus things are tricky, don't work well ever, and this is what we don't want to do (standardize star features).
  
• Jonathan - concern is that there really are problems.
  
• Henning - alternative approach is to use features as test cases. If you implement everything we say, you should never have a problem. May also need to worry about user interface aspects (so user doesn't suddenly THINK they are being transferred, etc.)
• Jonathan - document would say "this is what we mean by park, here's what you have to implement, here's how it works in every case."
• Keith - need to identify services when you start out - what do you mean by "call park"? And you keep saying "PBX, PBX, PBX" - carriers have different viewpoints, based on who owns the terminal and how easy it is to upgrade.
• Jonathan - agree that we have to say something about the service, but don't want to rigorously define all the variants - they don't affect this problem. Refer to a class of services that mean approximately "this". Want to figure out what's broke and fix it while we preserve flexibility. Totally agree that this isn't only IP-PBXes. Want people on both sides of the fence to do something the same way.
• Ben - term I remember with horror was "the SIPPING 13". Seeing how the services work is good, but you'll have marketing following along. Be very careful about the language you use. "test cases" is a lovely term, services and features are not.
  
• Jonathan - either we ignore the problem or we solve it as best we can. There are probably ten different park variants in Telcordia specs. We don't care, but we need to say "this is how we've seen people implement this feature, and this is how you interoperate with all of them".
  
• Francois - agree 100 percent. Think the solution is not overly specifying these things. Be general, characterize problems. Be careful about using names with meaning in the industry. Don't look at every variant. The problem we're seeing is that people are reluctant to move to SIP because you either can't implement a service or can't interoperate - need to prove that these concerns are wrong.
• Alan - understand what Jonathan is saying, problem appeared on SIPPING list yesterday. Need a little more guiidance.
• Mary - should be no distinction between IP-PBX and carrier - that's the legacy of implementations. We failed if anything we do is a PBX feature, etc.
• EKR - "park does approximately X", constrain implementation choices. What are controversies when you identify choices?
• Jonathan - this is what we do when we engineer. "B" in BLISS is important. Define a minimum set of requirements that define behavior we want to standardize, recommend a minimum set of specifications to support and behaviors to exhibit. Output is typically a BCP. "at least these things will work".
• Andrew Allen - we've seen the problem. About every PBX implements these differently, mobile devices are worse because they move around. Thought the hitchhiker's guide helped with this.
• Jonathan - not at all, that's a grouping of specs, period.
• Eric - really confused, we're not going to define services and call flows, just minimal requirements, but we get those from call flows.
• Jonathan - not H.450.1-n. We have a problem, we fix it by telling people what to do. Won't ever say "you must support this call flow", target bucket-by-bucket. There is an approach where we support new services and still have interoperability.
• Eric - what am I going to have my programmers program? If the IETF says do it this way, people will do it that way.
• Robert - the idea that you can have a call flow and have people not refuse to interop with someone who doesn't do it that way is not realistic.
• Jonathan - what's the alternative?
• Rohan - if this group is chartered, would should be similar to 3rd party call control. People looked at flows and figured out what to do and why. A BCP that describes why approaches work and don't work is just a clarification of existing specs - important thing is to explain why something doesn't work or does work. My objection to your slides was picking a nit. Absolutely agree that there's a problem in the wild.
• Vijay - next step is implementation guide, 3PCC is good example.
• John - really need to dispell the nits behind 14 service examples.
  
• Jonathan - we have this premise that multiple things will work, let's prove it.
• Eric - IETF doesn't have an interop problem, we're trying to define services and getting vendors to agree how to do the service. There are better-suited organizations to do this. IETF charter isn't to replicate PBX/carrier functionality. Send it to ITU, send it to SIP Forum...
  
• Jonathan - this is about what endpoints have to do in order to work - that's what's in our charter.
• Francois - disagree 100 percent with Eric, there are not other groups that can do this, when they try we have problems, they aren't malicious, they just don't care about breaking SIP as much as we care. PBX group wouldn't care about PSTN, etc. We'll have to do a lot of call flows, and we've had to do that before.
  
• Robert - did not say "don't do call flows". Saying that we have to present call flows in a different way, or they'll become normative and people will refuse to work with different call flows, even if they SHOULD work.
• Paul - call flows have troubled me for a long time - the way they're used. We're talking about multicomponent systems. None of the other components know what call flows the first component is doing. That's not the way people implement. In some cases, call flows are normative - REFER is extreme case - unless you have context you can't know what to do.
• Henry - park is a good use case to show that presence would give you a completely separate view of the world. Restricting scope is a good thing, but restricting to voice only for a standard in two years seems wrong.
• For park - this is what you have to implement, this is what you have to indicate.
• How to do vendor variation? Don't kill vender differentiation.
• How to do feature variation? look for places where vendor variation can happen without interoperability loss.
• Do not want to recognize PBXes, App servers, etc. - this is not IMS for the Enterprise.
  
• Consider PSTN endpoints and interworking, but this working group is not about replication of PSTN features. Support multimedia, support hetrogeneous endpoints.
• Four initial deliverables are reasonable, we've had drafts in the past on every one of them.

3. Charter review [45m, Shida Schubert]
   http://www.bliss-ietf.org/charter.html

• (see charter for details being discussed)
• Charter is not to change 3261, and we can't do that, anyway. BCP for each bucket.
  
• Rohan - concerns about documenting variations that exist in the wild - focus on what variations affect interoperability.
• David Bryan - are you going to document what's wrong and why, or only what's following the rules.
  
• "even when they are wrong" - but more or less compliant. - Megaco over KPML is compliant, right?
• David - then, normative text that explains what the problem is?
• Jonathan - that's very valuable. Our job is to figure out what the problem is. We're not SIP, but we can send them requirements.
• Andrew - need to decide where we draw the line. This is what I see from PBX developers.
• Jonathan - would love to have all the variations included and write down why things don't work.
• Ben - can we get the whole charter first?
• Guiding principles (in charter)
• Rohan - you want April 2008 in the charter
• Ben - we say we're not defining services, but every other line of this charter sounds like we're designing services.
• Jonathan - can use any term, may avoid services and features
• Ben - we could define the output as "BCP for REFER"
• Jonathan - I wish it were so, I think that's wrong.
• Cullen - what is "here's why", if it's not "because you need REFER to implement DND"?
• Ben - if I start organization to output based on SIP extensions that are important, that's one way. If I start organization based on services, that's another way. If we focus on services, new services become harder.
  
• Shriram- 1200 features in the wild? 2500?
  
• Jonathan - we focus on what people report as problems - there are challenges on some features today. We can rename DND - is that too specific? List of buckets will grow as people have problems.
• Philip - "approaches described here do not assume centralized servers" - want to use in P2PSIP. Mention the working group?
  
• Jonathan - am fine with that, that's why we're doing components and not device types.
• Richard Barnes - template itself is a valuable deliverable.
• Jonathan - yes, that's the August deliverable.
• Keith - do we have to have service definitions in the charter? If so, I'll get more picky about the details.
  
• Cullen - most IESG members don't know what the services are, just giving flavors. If there's a better way, we should use it.
• Jonathan - we'll put a caveat in the charter - takes analysis to do well. Need something rough, don't pick it to death.
• Paul - you're not going to know what feature the other guy is invoking. Output should be descriptions about what you do, in what contexts. Can't do this line item by line item.
• Jonathan - if this stuff works, let's prove it - I think we're going to find holes.
• Scott Lawrence - in terms of things like call park and DND, product managers don't understand REPLACES header.  We need to help implementer bridge that gap. Would like to hear (post-charter is OK) discussion about process to bring work into this group - could be open-ended. If we put out a good spec every
  
• ??? - need to captute how features interact with each other, and with precedence.  Start with this as basis of protocol design. "Minimal requirements" is in conflict.
• Jonathan - we can't capture every way that MIGHT work - only what affects interoperability.
• Spencer - agree with this work, agree with Ben, agree with Scott.
• Mary - good starting list, I agree with Ben, I have a UA stuck in DND and I have no idea why - would love to understand what's going on!
• Ashalam- speaking in support of this work.
• Eric - why not, do it here, it's a honeypot for people who want to work on services, I'll bet Cullen $100 in local currency that they'll have one service done by Asia IETF.
• Christer - can we identify requirements for SIPPING (new headers)?
• Jonathan - think we will find things that need to be specified, will write individual mechanism drafts and send them through SIPPING when we know what the BCP requirements are. TISPAN does requirements the same way (on the mailing list). CCBS/CCNR doesn't have enough mechanisms in SIP now. They poll, they do presence without queues...
  
• Alan - support the charter, we'll produce more documents that look like CC-transfer, less like service examples.
• Tom - in favor of charter. Fixing DND - do we want to talk about configuration in the charter?
• Jonathan - we do whatever we need to do for interoperability. Configuration could be in scope - we would do requirements, of course. "BCP for how this would work". Don't want to get into URIs, but touching on missing information for authorization, etc.
• Jeff - you need to do this. We've called these profiles in SAML, terminology is going to be important, needs to be application-neutral.
  
• Henning - for many years we've talked about profiles, Henry, SIPphone... not BLISS territory, but would be nice to coordinate with them.
• Jonathan - this will show why UA Profile is useful - makes it easier for product managers. Don't need to call this out in the charter, but should demonstrate that our specifications really work
  

• Form a working group, roughly on this charter - rough consensus in the room.
  
• Vijay will hold Eric's money for the bet between Eric and Cullen
• Cullen - need to think about concerns expressed. Discuss charter on mailing list, then go to IESG.
• Jonathan - BLISS problem statement is new addition, needs a better name, very important first deliverable.
• Cullen - give people one more chance to look at the charter.

2. Notes taken by Vijay Gurbani

Problem statement, Jonathan Rosenberg

* Interop of "advanced" call features is poor today, especially
in the enterprise space, though not exclusively so:
- shared line appearence
- do-not-disturb
- call park, pickup, ...
- transfer
- call completion to busy subscriber
- etc.

Why?
- By design (PBXes did not interop with others.)
- Poor implementations (bugs, incomplete specs, etc.)
- SIP does too much sometimes and too little other times.
* Many ways to implement a feature.
- SIP is missing some stuff (being used environments that it
was not initially designed for.)
- SIP provides too many choices.
* processing of feature could occur in the UA or network.
* All ways can be argued as being legit, but who is right?

[ Went through a Call Park example; see slides. ]
[ Three ways to solve this, none of which interwork. ]
[ All three approaches have been witnessed in the wild. ]

[ Slide entitled "Mix 1" discussion ensued regarding
whether or not the caller should know that it is being put
on hold for the "Call Park" service. The caller may only
implement the REFER method for a "Transfer" service.
Dave Oran made the assertion that "Call Park" is a form of
"Transfer" anyway, so it should work. It was decided that
we are not out to solve the "Call Park" problem; just use
it as an example. ]

How do we fix this?
- Define a set of min. implementation reqs.
[ Much mic discussion ensued. ]
[ Henning: One view of the world, another not to excruciatingly
define them. Instead, use a "toolkit" approach. If you
use stimulus things, it will not work well since we have not
defined the key combinations, etc.
Keith: We should define what Park means and proceed from there.
JDR: We will do so, but we will not define every possible
variation to this.
Mary: Diffrenciate between carrier services and PBX services.
EKR: Deliverables?
JDR: Will have a template, or a "bucket" for each feature.
Each feature will have constraints that the developer will have to
look at.
andrew allen: hitchhikers guide vs. this worik (JDR: Hitch is an
enumeration.
e.burger: Are we creatng h.450 CS1 CS2 CS3 CS4?
rohan: Same as 3pcc work. Laid out the call flows. Very
beneficial.
JDR: 3pcc did not go far enough -- no implementation details.
vijay: 3pcc is key to let implementors know that if you want to
talk to automata, do this. If we go beyond that and provide
implementation details, great.
eric.burger: IETF should not specify how service works. Do it
in ITU, SIP Forum.
JDR: IETF is in the interop game, that is why this is important
to IETF.
Francois: Other groups cannot do this, will result in different
outputs, not out of malice as much out of ignorance. IETF is the
right place to do it.
RjSparks: Need to reign in how we do this work. ]

- Challenges:
* 1: Vendor variation: must still be enabled, but it should not
act as a depressor.
* 2: Feature variation
* Do not want to recoginze componente like phones, PBXes, etc. We
will work on UA and server, proxy level. This is not about PSTN
emulation services.
* Must work w/ multimedia and support

- Initial services looked at:
* shared line appeareance
* dnd
* call park and retreive
* call completion busy subs

[ Presented the charter; see slides ]
[ Opej mic charter discussion. ]
Vijay: The intent is not to normatively change 3261 or other
docs?
JDR: Yes, the intent is to fill these "buckets" and see how to
foster interop.
Rohan: Instead of saying "Rather, the focus will be on
documenting the variations that exist in the wild", need
to change the charter to document the effect to which
variations in the wild affect interoperability.
JDR: Yes, will do.
David Bryan: document even what is in the wild if it is wrong?
JDR: Yes, we will document these and if these are within reason, we
should capture them.
JDR: We cannot define a new spec, but the work here could feed into
SIP to help clarify the protocol.

[ Went thru the deliverables of the 4 initial services. ]

Ben: Impl. community will see this as IETF defined services instead
of viewing this as putting building blocks together.
JDR: Maybe we want to avoid the term "service" and "feature"
altogether.
???: Are we going to limit the list of features?
JDR: We first focus on the list of features that have witnessed
interop problems. There are cases where people do not have clear
guidance to make things interoperate.
???: We should solve the "classes" of problems instead of individual
problems.
Philip Matthews: The charter should say something about no centralized
servers, can be implemented in a distributed manner.
Keith: 1 - what the group is allowed to define or not: Be careful about
the term "SIP extensions" to be used in your charter.
2 - we do not want statement of what the service is in the
charter.
Paul: The output should be description that you ought to do these
things in this context.
Scott Lawrence: Supportive of this work in general. One more thing that
should go in the charter : What is the process for bringing work to
this group?
Spencer Dawkins: Support the work.
Mary Barnes: The list has a good starting point. View this as building
blocks and lets educate people in how to put these together.
A.Houri: Support for the work; clarify the charter a bit more. This
moves SIP from the protocol to the features; makes SIP more consumer-
oriented.
Eric Burger: Go ahed and do the work; will be a good honeypot to
keep people interested in this busy. Will bet Cullen local $100
that the first deliverable will not be done as stated in the charter
by the delivery time.
Cullen: Accepted the $100 challenge.
Christer: Make sure that the charter reflects that we can take reqs
to other groups (SIPPING, etc.)
Alan Johnston: Support the charter. We will produce documents like
CC-transfer and less like Service Examples.
Tom Taylor: Do we want to talk about "Configuration" in the charter?
Like configuring something in the UA.
JDR: If everyone configures their UA to do Feature X, then sure yes,
configuration will be in scope. We will define a mechanism for
configuration.
JDR: One area that will come up may be UI specific issuses we may have
to deal with. Another is authorization-specific issues.
Jeff Hodges: Good idea, need to do this. We have gone thru this
excerise in SAML. Terminology will be important.
Henning: Over years we have had many drafts on user agent profile.
Will be good if BLISS co-ordinated with these profiles.

Chairs asked consensus, and consensus recorded as follows:

Formation of WG to address the problem described in the charter?
Consensus on chartering the WG.

Cullen: we will evolve the charter in mailing list to fine tune the
charter and take it to the IESG.