BLISS WG Session - IETF 70

   Chairs: Jason Fischl, Shida Schubert
 Date: 2007.12.06
 Time: 13:00-15:00

Note taken by Bruce Lowekamp

note well slide

First topic: Feedback to problem statement

consensus to make the process whatever works

topic: Automated Handling

discussion that there are different use cases where sometimes the proxy needs to make the decision and sometimes the UA needs to make the decision

  1. do we need to make any recommendations? much discussion - if we don't, interop won't happen. - need to allow proxy or ua behavior, but also a way to make sure capabilities and roll are determined and understood by both uas and proxies jdr proposal: proxy MUST support and ua MAY. need to support P2PSIP use case. must provide way to coordinate when exists in both.
  2. is (e.g. provisioning) (config framework) suitable? (e.g.=for example) yes
  3. do we need response code or other information specified? much discussion. yes
  4. recommendations on 6xx? yes
  5. recommended or default for UA or PDS to configure proxy some discussion. let's not work out the details, but reword question "How do we synchronize user agents and proxies?" yes we need to work on this
  6. is it necessary to specify how to inform the calling ua of behavior? - details of how debatable, details of when this is desirable is debatable - when there's a good reason to do so, it should be properly specified and not falling back on text poll: adopt draft-elwell-bliss-ach-analysis as analysis wg item? quiet in favor, none opposed new

topic: Call Completion

poll: can we take a merge of poetzl and worley call completion drafts as a merged draft to be adopted as a wg item? strong in favor

topic: Line Sharing

discussion of whether specifying requirements is appropriate. requirements are appropriate as necessary to discuss features.

Note taken by Dean Willis

Note Well discussed

Topic: Agenda
Accepted as presented


Topic: Experience with ACH, Process Doc
led by Jason Fischl
Slides presented

Issue 1: Finding a Feature Group

Proposed: recommend making this optional

Issue 2: Call Flow

Proposed: alternative polling techniques

Concluded: Will revise and keep working


Topic: ACH Survey Results
Led by Shida Schubert
Slides presented

Comment by Robert Sparks that writing a survey for an implementation community is really really hard.

Comment by Christer Holmberg that the results of this study are interesting to the community.

Comment by JDR: Would be good to find out if the response code on the calling UA is treated specially by anybody, such as "ASsumed it was 480 and rendered DND to the caller.

Comment by John Elwell: For some of these questions, incremental polling on the mailing list would be a good way to acquire information.

Comment by Francois Audet: The questions were difficult answer because they reflected assumptions about the way a product would work that might not really apply. Further, the range of questions were incomplete. For example, a known implementation has not just DND, but has a context-driven set of settings. Important not to assume special constraints or behavior on the UA. (but JDR would not be surprised to see odd behavior).

Comment by JDR that we might get different answers in the semianonymous polling model relative to "on list". Might could survey "on list" but not broadcast responses.

Poll by chair: Do we want to do more survey on this topic? Question deferred to end of topic.

Comment from Jonathan: Survey told us we have an interop problem. Not sure another survey on the same topic would help resolve it.

Comment by Francois: Not sure we don't really have an interop problem. (Discussion deferred to after John's presentation).


Topic: Automated Handling
led by John Elwell
slides presented

Subtopic: ACH Analysis

Issue: Avoiding inconsistent configurations

Comment from JDR: In a P2PSIP environment, there may be only an opp for ACH in the UA, as there may not be any proxies.

Comment from Christer: Why doesn't the UA just indicate what it wants the proxy to do? Discussion ensued . . .

Comment from Maureen Stillman: When I set DND on my phone, I don't want my phone to ring. I don't want proxies arguing about it.

Comment from Derek: We're really trying to decide what the user wants, not what the UA wants.

Comment from Paul K: There could be more than one feature or variation thereof involved here. There's no simple feature interaction solution.

Comment from Christer: Configuration framework will help some.

Comment from JDR: This is a "terminating feature", so when it happens in a proxy, the call never reaches the UA.  The problem is that there can be mismatches on how the proxy is told to do it.

Noted by John Elwell: It's probably better to execute the feature at the place with the largest grasp of the policy.

Subtopic: ACH questions identified

Issue: Recommendations on proxy-based vs ua-based ACH. Do we need them?

Comment from Francois: May want to explain consequences and advantages of either method. This is more of an explanation opportunity than it is a recommendation.

Comment from JDR: If we don't make a recommendation, do we expect to see products from vendor A not work with products from vendor B? If so, then we need to make a recommendation.

Comment from Christer: No, we don't need to make a recommendation. We need more communication for the proxy and UA to decide what is being done and who is doing it.

Comment from Jason Fischl: As long as the UA has a way of figuring out what the proxy might do, then the UA can find something reasonable to do.

Comment from Paul K: Interoperability between what? Here, we have caller, caller, and a possible decomposition of the callee into proxy and UA.

Comment from Dean: There was recently discussion on P2PSIP about this sort of thing, with one proposal being a policy document that might be visible to the caller, or proxies and is controlled by the callee.

Comment from JDR:, paraphrased by recorder as "Recommend that the feature needs to be at least in the proxy, possibly in the ua, and that when there is no proxy, then the UA is responsible. Must make a normative recommendation on this. " on review, this wasn't quite what JDR meant, but we didn't quite get it wordsmithed.  JDR thinks that features that don't interrupt the UA have to be in the proxy. JDR thinks DND requires a protocol to turn it on and off.

Comment from Jason Fischl: There may be cases the proxy just doesn't care about ACH but the UA does.

Issue: Is provisioning a solution?

Conclusion: We need to look at it.

Issue: Do we need to make recommendations on response codes and other aspects of responses between UAS and proxy?

Consensus: yes.

Comment from Francois: This is almost "debugging". Maybe there are cases where better response codes are needed.

Comment fro Christer: We need also to look at topology, as there may be multiple layers of proxies with interaction, for example 302 recursion. We need to document assumptions about the topology, and possibly make recommendations.

Comment from PaulK: We need to make sure we have enough expressivity to account for all possible cases.

Comment from Christer: A topology example is forking in AS and 302 recursion in S-CSCF.

Comment from Paul K: Major interaction in forwarding if A forwards to B, and B is DND. Whose voicemail gets it?

Issue; Do we need recommendations on 6xx responses?

Answer: Yes

Issue: Do we need to specify a default method for a UA or PDS (profile delivery server) to configure its proxy and discover how its proxy is configured?

Comment from JDR: Describe this as "configuration synchronization problem" : How do we sycn the user agents and proxies. How does UA know whether proxy will do CFNA. Also, how does the US change what the proxy does?

NOTE: Rewrite problem as per above comment.

Question: We are using config framework terminology. Are we dependent on it?: Ans: NO.


Issue: To what extent do we need to make recommendations about informing the calling UA of what has happened?

Comment from JDR: Only in specific use cases where special action is required from the caller, such as in ACR.

Comment from Francois: Only define this when we have an application that needs it, else it will be transparent to the calling user and have security and privacy problems.

Comment from keith: If we don't define this at all, do we run a risk of falling back to a stimulus fashion?

Response, JDR: No. For example if policy is reject after 3 rings, all the caller needs to know is it was rejected, not why.

Comment from Keith: But "diversion" indicates we needed new responses from voice mail.

Comment from Francois: yes, when there is a good reason, we need to do new codes. But for this phase, we don't see a need to do so.

Question to room: Where do we take this draft? Poll to adopt draft-elwell-bliss-ach-analysis towards WG milestone ...

JDR proposes we adopt this as draft-ietf-bliss . ... but not necessarily send to IESG. Conclusion: strong consensus on adopting, chairs will work with AD to milestone.


Topic: Call Completion
led by Denis Alexseitev
Slides presented

Open Issue 1: Queue abuse

Suggestion from JDR: We need to separate two things: 1) that SUBSCRIBE doesn't create state, and 2) tools for state management like cookies: here we pass the state back to the caller in the response to INVITE, then recover it from the SUBSCRIBE.

Open Issue 2: preserving a window for notified caller to have exclusive access to callee

Noted by Denis that the cookie approach could make this work for the anoynmous case.

Open Issue 3; How to transfer the information about the call management application.

Proposal: Adopt this draft and merge with draft-worley-call-completion draft.

Discussion ensued -- Analysis is in pPoetzl draft, proposals are in Worley draft, all authors support proposal.

Comment from JDR: the Call-Info header field is allowed in responses

Comment from Keith Drage: Suggest we not call this "call queueing" and give specific requirements for new protocol pieces that would go to other groups.

Poll on adopt and merge into deliverable for call queueing... Conclusion: Adopt and merge. New draft will be: draft-ietf-bliss-call-completion

Question from chairs: Anybody want to join design team to work on ACH with biweekly calls? Please send expressions of interest to the chairs.

Note: Chairs will also make this plea on list.


Topic: Line Appearance
led by Alan Johnston
Slides Presented

Comment from Christer: This draft contains a lot of service requirements. Are we really going to do a service definition here? Is it OK to do service requirements in this group?

Response from JDR: This is not rigorous definition of services, so the answer is "NO!"

Chairs will send mail about this to list.

Comment from Keith: be sure to invite our peer organizations like TISPAN to the design teams.