Gonzalo Camarillo chairing. This BOF met in Room 352, 1815 to 1945 Slides available on the SoftArmor site: www.softarmor.com/sipping/meetings/ietf63/minutes Denis Alexeitsev presenting. Services in scope: Anonymous Communication Rejection Terminating Indication Presentation Advice of Charge Call Completion on Busy Subscriber CCBS CCNR MCID Communication Diversion IDs in scope: draft-jesske-sipping (3 drafts) draft-garcia (2 drafts)\ Issue 1: ACR ============ Need specific reasons to return Possible solutions: allow Reason header in unsuccessful responses, or Allow warn-codes in Warning header. Discussion ---------- Paul Kyzivat: is this meant to work only in a closed environment? Denis: want a general solution. Paul's point: this one requires callee cooperation. Implies mandatory requirement on all UASs. Denis agrees that service available only when callee supports it. Keith Drage: environment essentially IMS. Basically want something that will work in nother networks if at all possible. Denis: which solution is preferable? Looking for comments so they can complete a draft. Gonzalo summary of issue: response codes and Reason headers seemed to be redundant when originally defined. Key requirement that name spaces not collide. Dean: others want more information in returns too. Henning: SIP designed with high-level codes and Warning for more detail, why not use Warning? Denis: no problem with that. Henning advises to go that way. John Elwell: more name space in response codes? Denis: understood that would not be welcome. Mary: Reason will give something Warning does not. If Warning used, needs to be well scoped. Paul: OK in principle. But could native SIP endpoints to have to return Q.850 codes? Need to have something well documented. Denis: true, native SIP endpoint can't generate or handle this info now. Trying to create a service description so that conforming app wilol work. Henning: doesn't want to see status codes redefined in a new way. Kludgy to use Q.850. Why not define the status codes if they are needed. Jonathan: agreed. Known ways to expand code space if needed. Henning: ... Denis: so how do new response codes get generated? Henning: in the same draft the procedures are defined in. Jonathan: careful not to get too detailed, to preserve general applicability. Roni: where do we start to get ideas? Gonzalo: RFC 3398 ACR Issue 2: ACR override ========================== Lots of tools for call screening already. Nothing new about this application -- tools are already there. Denis, Cullen: trying determine not-understood requirements. Steve: point is that it is known that it is the police calling, might as well use role-based authorization. David O: not overriding anything. Policy: "Police are authorized to call" Jonathan: still probing. Is reqt that originator can decide whether ACR rejection policy will be overridden? (Yes) Then a difficulty is that the user doesn't know what policies are available. John Elwell: noted emphasis issue discussed in SIP re auto-answer. But depends in end on user's authorization policy. Issue 3: Terminating Indication Presentation ============================================ Called party needs to provide an identity to the calling party. Currently: Forward: have From, P-A-Id Backward: have P-A-Id Cullen: response identity has been under discussion for a while. Is SIPPING view of the problem same as this? Denis: in this case need that called party can pass arbitrary information, no requirement that the information be verified. Jon: verifiable information that the caller won't verify, or unverifiable information? Keith Drage: starting point was ISDN capability, used historically in Europe to give PBX extension nos. behind public PBX number. Need both ability to provide multiple identities and ability to indicate semantics of each. Jon: don't necessarily need to use header -- try to stay free of mechanism in defining requirements. Keith: doesn't think he did that. Basic requirement as already indicated (gave examples). Miguel Garcia: Jon: Call-Info overloaded, Reply-To hasn't the right semantics. We all want to solve the problem, but it has proved to be very complicated. Advice of Charge ================ Need indication of charge info within active session. Dave: clarifies: is it necessary for AoC to be inserted by intermediaries. Miguel: yes. Problems: how to invoke, how to transfer the information. To invoke, new P-header proposed (P-AoC). Requirement is for information during the dialogue or after it is done. Keith Drage: reqt to do for MESSAGE as well as INVITE dialogues. Should be retained for a reasonable. Jonathan: trying to get more details, asks if the value is a rate. Miguel: can't assume uniform rate. Considered event package, but may not have dialogue-id. Jonathan: that's all mechanism. What is the requirement. Denis: gave details. Pointed out also need transfer mechanism. Jonathan: need body format someone has to define. Suggested a bunch of requirement questions. Cullen: currency a tough issue. John Elwell: presumably P-AoC is addressed to some entity on the call path. What entity, does it need explicit addressing? Miguel: event package has possibilities. Jonathan: upset that mechanisms are being discussed without clear requirements. Communication Completion On Busy Subscriber =========================================== Need indication of support for dialogue event package in responses. Problem: multiple subscriptions could mean flood of attempts on completion of current session. Possible solution: include Allow-Events in 486 Adam: why is Subscribe not feasible? Denis: queued callers get served in order. Adam: Cullen: is reqt that you have as caller an indication on your user interface that this capability is available? Denis: Yes Second issue: sequential notification of dialogue state changes (i.e. FIFO queue of callers) Cullen: restate: don't necessarily need to put "dialogue package" in requirements. Denis: agreed Paul: is proposal to create new package that has sequential notification property? Denis: want, but can't see how in package Jonathan: have to preserve generality of dialogue event package. Decision about queuing not a property of the package, more one of called party decisions. Really a more general problem of presence. Denis: is it a general event mechanism we are looking for? Paul: agrees it is. Have to worry about queing disciplines Henning: how long is given caller's slot kept open before next caller is notified? Denisw: agreed, would hold only for finite interval Henning: wants solution at least as good as current ISDN solution. May be more plausible to think of general presence-based tools. Paul agrees it is a capability of general interest. Do need to get all the requirements out and hope we don't end up redefining event framework. Third issue: management of the notification queue for sequential notifications. Subscribe should be able to suspend and resume his position in queue. While in suspension, gets no notification -- next one in line gets it. Solutions suggested. Fourth issue: indication about sequential notification policy to allow queue management from the subscribers. i.e. indication to tell subscribers that they are being queued. Cullen: metaquestion: when is solution needed? Denis: end of year Cullen: Rate of progress far too slow here. Lucky to get small fraction of reqts satisfied. Henning: too large a blob. Break it up. Gonzalo: half an hour more on Thursday.