Subject: [Sipping] TISPAN BOF Minutes -- very raw

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 02 Aug 2005 13:43:42 -0400

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.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP