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