Subject: [BLISS] Draft minutes, BLISS IETF 69

From: Shida Schubert <[email-masked]>
Date: Wed, 25 Jul 2007 09:33:33 -0700

IETF 69 - BLISS Work Group

Date: July 24, 2007

Note Taker: Eric Burger

Bliss Problem Statement: JDR----------------------------
Add to problem statement: do not need to define the distinction between 
Application, Service, and Feature. Do not focus on whether something is 
just a service or a feature, rather just talk about how "it" works.

AI for JDR: try to use traces from SIPiT to extract call flows.

Do we need guidelines for how BLISS will work: YES

Do we take JDR's document as basis for problem statement: YES

Find a milestone to run the complete process on.

Automated Handling: DND by John Elwell----------------------------
Is this separable from other DND features? No, part of the whole DND 
feature set. Could be separable after analysis of all features of interest.

Call Completion by Martin Huelsemann----------------------------
Open Issue: prioritization: can we do prioritization by comparing caller 
identity with top-most queue entry? Open Issue: What if no call 
completion attempt started after free?

Open Issue: What if call completion attempt results in busy?

Open Issue: what to do if there is an error, like no queue entry at time 
of subscription?

Open Issue: what if lots of user devices subscribe to the same queue entry?

Paul procedures - new solution; what about interoperating with what's 
out there?

Is text on dialog package sufficient? Should directly reference queuing 
directly.

Multiple Line Appearances by Alan Johnston---------------------------- 
How large is large, with respect to multiple lines? 5-10?

Why not use NOTIFY, since one is sending NOTIFY's anyway?
One issue is that the phone needs to ring / flash / indicate a call is 
coming. Is that not an INVITE issue?

How to indicate the line identifier?
How about a separate AOR for the aggregate group?
Two-level registrations (or implicit two-level), where the lines are 
sub-addresses of the device.

Note Taker: Brian Rosen

List of acronyms used for names in this note
jdr presents Bliss Problem Statement

Solution Considerations:

Avoid Enumeration

Allow variability of definitions

Assume multimedia

Allow variability of Implementation in a multiplicity of environments

MD-Is this just SIP or also including e.g. web services.
There are services invoked using sip, and others invoked with a GUI, 
what is in scope

JDR-some mechanisms may need, e.g. configuration and may need other 
protocols to achieve interopeability

Bliss Process: 1. Define functional primatives - a bucket with similar flows
SN-What do you mean by feature, service
JDR-Don't try to parse too finely, just agree on what the thing is we 
need to interoperate
CH-okay, but need to describe differences between the feature and the 
service
JDR-Don't think its a problem
JE-We called them features before we invented services Indentify common 
interaction patterns

Bliss Process: 2. submit feature flows
Get a lot of them from different implementations Not a deliverable.
MD-Like the idea of flows, but not the detail diagrams in ASCII
JDR-Okay, lets not get process in the way

Bliss Process: 3. problem determination, minimum interop definition
Analyze what happens when elements from different implementations get 
plugged together
SN-Lets not apportion blame
JDR-Anonymous call flows okay :)
??-There is a confidentiality issues to be worked out in some NDA 
environment
JDR-IETF can't deal with that
PB-Any way to do data mining from SIPit?
JDR-Good idea
CH-Feature names can confuse us
JDR-Thats part of the problem we are solving. Decide if they are in the 
bucket

Bliss Process: 4. Interop Spec Actual Deliverable
TD-Carriers may be able to help
JDR-Great AA-Capabilities negotiation in scope?
JDR-Case by case discussion
AA-Are provisioning mechanisms in scope
JDR-Only as a mention of how to achieve interoperability. Example of DND.
BS-Do we assume things meet specs first, or is protocol repair in scope
JDR-Hmmm, well spec misinterpretation could be fixed, need to ferret out 
assumptions etc to find the
BS-Problem is eating cost to fix implementation. If we assume correct 
interpretation, many problems may go away.
JDR-don't want to figure out the line ahead of time. Generally agree
MS-Great doc. worried about negotiation of capabilities conflict between 
innovation and simplicity
JDR-Agree. Have to make the tradeoff on case by case basis
AA-Don't want to have PSTN does it this way spear
PB-Don't want only RFCs on the one rightway. Wants a dont do it this way 
doc
JDR-propose a summary of experience in doc
JS-How do we separate scope issues with sip/sipping
JDR-on a case by case basis HK-Are SBCs in scope?
JDR-Yes
AA -People don't want their flows to appear in Worst Current Practice
JD-Yeah
SD-Lots of problems with values rather than message flows
JDR-In scope
CH-Only sip to sip or interactions with PSTN in scope
JDR-What happens on PSTN side doesn't matter but SIP side in scope
AE-How are we organizing this
JDR-Maybe a "pilot program"
JDR-Is this really the process we want to do? Ask for humm
MD-Question: What layer of detail?
JDR-Only as much as we have to to get interoperability. Maybe a minimum 
implementation plus a capability discovery for more features
CH-Are you asking that other drafts already submitted that don't follow 
this process have to be redone?

Chairs: Yeah, documents will have to be respun
JE-Good way forward. Must be fine tuned for each group of features
DS-Interpretation of response codes in scope
JDR-If it causes interoperability problems in the functional groups it 
is in scope
CH-Does this mean define new codes?
JDR-Good point. If things are missing, write requirements for sip, final 
draft references sip mechanisms draft
KD-That is the charter defined process

Chairs: Humm on this approach Consensus: yes
Humm on using this draft as the basis for this work Consensus: ??
See hands, Consensus yes
Chairs: Propose to take one bucket and run through the process for a 
milestone with a design team

AA-By a milestone, do you mean pick a feature
CH-One feature or one feature group
Chairs: Feature Group
MD-Process okay, do you have a sense of the buckets?
JDR-In the charter

John Elwell presents DND draft

DND, CFU, CFNA in same bucket Indicatin DND to a proxy Need explicit 
indication, reason phrase not sufficient Lots of ways people do this now 
Maybe a new 4xx or 6xx Scope of 6xx Forking and retargeting issues Does 
it apply to contacts?
Indicating DND to a caller Are they different for indicating DND to a 
proxy May wish to hide this from caller Reason Phrase has issues Is it 
sufficient to rely on proxy HERFP problem Indicating DND in presence 
Need something in RPID?
Would this be something in "open"?
DND problems that don't need solving Do we need SIP means for 
setting/clearing DND?
Do we need SIP means for overriding DND Is 4412 (RPH) enough?
Similarity between DND and other automated handling Differences between 
DND and other automated handling

MD-Is proxy as well as UA work in scope for this
JE-Yes
MD-Feature line interaction issues, may be regulatory mandate, is that 
in scope?
JE-Explain
MD-May be an ovveride required by regulation, is that in scope
JE-Have to look at that
CH-Need a feature definition first. Is this draft in line with the 
process define before?
JE-No, need to do that. Draft as is doesn't define DND
PK-I draw opposite conclusion on related features, they are very related
JDR-Feature interaction is generally NOT in charter, but may have to 
note interactions in resolutions Agree with Paul that these are very 
related, there is state. If the state is in the endpoint, need a way to 
signal the proxy to do things. If the state lives in the proxy, then we 
need signaling to change the state in the proxy.
JE-Doc doesn't say one way or another
JDR-Great example of what we are doing, doc describes one way, I thought 
it worked another way
JE-Doc describes both
SN-Need to look at requirements from user perspective, this does look 
like other features in the bucket also has feature inteactions within 
the bucket
JE-Seems like we should combine with automated handling
JDR-For now yes, but just "consider" that, no final decision
??-Sometimes one part of call flow from one feature is a part of another 
feature. Look for common flow parts and tie together
JE-not sure that is the intention of the process we just agreed
AA-Common elements (indicating primative) here. Maybe there are building 
blocks that could be useful that may also help the non-disclosure problem
JE-Yes but you can't slice fragments too small or you lose meaning
AA-Building blocks may be here and be useful
JE-SIP defines building blocks, we don't want to redefine them
Chairs: Out of time
JDR-Don't worry about buckets now: put it in now, decide later if it 
comes out

Poetzl on Call Completion

Was a sipping draft, now moved to BLISS Compares different solutions, 
has not looked into interop issues yet Queueing method has changed Event 
headers not used, done implicitly by creating queue entry Call 
completion prioritization has changed, new p-header not used Issue: can 
prioritization be implicit by comparing calller identity with queue 
entry on top?
Changed Queue model: entry created when busy or no reply deleted after 
timer expiry or call completion attempted Several open issues Next 
Steps: resolve open issues, revision to align with problem statement draft
pk-Stressing the process already, this describes a new procedure without 
investigating what is done already. Given history, I'm pretty happy with 
how it addresses the requirements Fundamentally a caller requirement, if 
the mechanism is there, that's swell. If the caller was in a place where 
the mechanism isn't there? Phone should have a bag of tricks. Anything 
better that forcing the user to redial
JG-Naive, but why not use 192/408?
FA-Section talks about alternatives, using floor control and dialog 
package. Don't like the dialog package suggestion in the draft. If not 
really needed, delete. I think a dialog package solution is actually 
useful.
JDR-Think this fits the model. Proprietary piece missing. Maybe we could 
define at least requirements Possibly a new event package. Using dialog 
package is a great alternative, but not interoperable. Need the process 
to show all the possibilities, tradeoffs and solution. An example of 
lack of standards
EB-Focussing on solutions like this open up to big DoS attack. Is this a 
good idea?
JDR-Got to evaluate it in that light.

Alan Johnson On Multiple Appearances

AKA Bridged Line, Shared Call Appearance, ,,, Avoids using "Line" Group 
of UAs that can handle incoming lines. Outgoing calls assigned to a 
unique "appearance" number from a managed pool Bunch of Requirements 
List Discussion: How large can the group be, Ability to make exceptins 
(e.g. emergency call). Privacy of Contact URIs
FA-How would Notify (if N is large) work?
AJ-REFER/Replaces
AA-Order of 5-10 gets to be a problem
CH-This is one of many ways, need to look at other ways. Now you want to 
look at requirements? Not the process
GD-Notify is a better way all. Need to show lamp status anyway.

Requirements Analysis: Forking Proxy/Registrar meets

R1 Dialog Pkg meets

R2 Replaces/Join meets

R3 Registration Pkg meets

R4 State Agent for Dialog Pkg meets

R5,R6 suggests an "Appearance Agent" which subscribes to the dialog package

AA-Always assume single user agent with separate registration for each 
line?
AJ-Doesn't have to be that way Implementation options URI Parameter in 
e.g. contact (line=) Dialog Package Parameter - needs additional 
mechanism for incoming calls possibly alert-info
FA-Third option, AoR for the group, register with that, subscribe to 
that, ... May also need a group regsitration, but sometimes not 
Comparisons: Dialog package meets many, URI parameter not as many

Appearance Contention Resolution: 2 UAs use the same appearance number, 
Could use Publish vs Notifiy

JDR = Jonathan Rosenberg
SN = Steve Norrys
CH = Christer Holmberg
AA = Andrew Allen
JE = John Elway
PB = Peter Blatherwick
TD = Tim Dwight
BS = Brian Stucker
MS = Maureen Stillman
HK =Hadriel Kaplan
SD=Spencer Dawkins
PK=Paul Kyzviat
JG=Janet Gunn
EB=Eric Berger
FA=Francois Audet
GD=Geoff Devine

_______________________________________________
BLISS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bliss