[Sipping] Minutes, SIPPING WG, IETF 55

["Dean Willis" <[e-mail]>]

The following current minutes for SIPPING at IETF 55 are posted at:
http://www.softarmor.com/sipping/meets/ietf55/minutes/minutes.html

------------
Minutes, SIPPING WG IETF 55
Edited by Dean Willis
Meeting Notes by Vijay Gurbani

----------------------------------------------------------------------------
----
Meetings in Atlanta, GA, USA

Two Sessions:
    Wednesday, November 20 at 1530-1730
    Thursday, November 21 at 1300-1500

CHAIRS:    G. Camarillo <[e-mail]>
    Dean Willis <[e-mail]>
    R. Mahy <[e-mail]>


Wednesday, November 20 at 1530-1730: Salon III
===================================

Agenda Bash
--------------
No issues.

Status and Charter, Chairs
---------------------------
New co-chair Gonzalo Camarillo introduced.
Status report given by Rohan Mahy.

Discussion: Scope and home of filtering work. Conclusion to pursue rate
limiting in SIPPING as a generic topic and that individual event packages
should specify their own filtering requirments.  Group agreed to consider a
framework draft for rate limiting, and Aki Niemi volunteered to attempt a
first draft.

Registration Event Package Open Issues, Jonathan Rosenberg
---------------------------------------------------------------

Statuess: In IETF LC.  One change: add shortened event to the state machine.

Issue:  default expiration matching default registration expiration (default
lifetime: 3600 sec, same as default registration time).  Made people nervous
due to race conditions/synchronization problem. 
Proposal: change to 4200s. No opposition shown

Issue: XML vs sipfrag: why convert reg msg to XML?  
Discussion: Extensive on pros and cons and costs.
Poll: XML vs anythying else. Consensus: XML.


SIP-T Related Issues, Jon Peterson
------------------------------------

Status Current work done; SIP-ISUP is in authors 48 right now. Overlap I-D
is still in progress; not a general solution -- there is
none.  

Issue: Overlap:.What should we do?  SG11 is considering using this from the
IETF.  
Discussion: Wide ranging discussion of requirement and rationale for overlap
and whether the overal draft should ve published and if so on what track.
OPtion of letting ITU deal with it raised. Noted that if done in IETF, we
will have serious security concerns.
Conclusion: There doesn't seem to have been any conclusion.

Topic: New directions for SIP-T:

Issue: SDP mapping: draft by Gonzalo on early media and other SDP mapping
aspects: code mapping and absence of SDP (in case of  3PCC).
 
Q.931->SIP mapping: 
Discussion: widely implemented without a standard, not sure  what value a
standard will add to it.

Issue:  Privacy-identity mapping for SIP-T: 
Discussion: SG11 already looking at this.  We are looking at the
P-Asserted-Identity version, not the long- term identity we discussed in sip
yesterday. Suggestion that we at least do the privacy mapping for long term
identity and that this could be informational. Suggestion that we make this
an explicit non-goal and that we minimize "educational" I-Ds. 
Conclusion; Jon Peterson will attemp Privacy-mapping I-D. Group will not do
any Q.931 work until at least next meeting. SDP mapping will go to list for
discussion.

Poll: Consensus: do people agree on working on document on how to use
existing tools on providing early media in SIP?  A document that explains
how to use UPDATE and other tools to do early media?. Result: consensus to
do this work.

Poll: Should we do 3PCC/SDP interworking with PSTN - No one hummed.
Discussion inidicated that there is no clear understanding of the problem
and we need to get a individual I-F writeup.


Message Waiting Package Open Issues, Rohan Mahy
--------------------------------------------------------

Changes since last version reviewed. 
Discussion: Suggested that a couple of things are complex enough to be
non-trivial and not important enough to be useful.  Given that we do any
other events stuff
shall we align it with event style description rather than having a
restrictive count only description? 
Poll: Continute with text body: No objection.
Concluion: Document will be revised to account for new caller-prefs.


Transfer  and Service Flows Open Issues, Alan Johnston
----------------------------------------------------------

Topic: Transfer

Changes since last version reviewed with slides. 

Issue: A Refer-To URI needs to allow the transferee to reach the transfer
target.  One way is to put Route header in a Contact, but this is
illegal as per rfc3261.
Discussion:  This problem keeps popping up in many places; in conferencing
it happens as well.  Better not to solve it here, but  rather do it in a
separate I-D.
Poll: Any voluntters? None.
Remaining work: close open issues, track REFER as it completes, add
uses showing Referred-By.


Request History Open Issues Mary Barnes
-------------------------------------------
Slides presented are available in proceedings.

Discussion: It might be possible to use this in conjunction with  Jiri
Kuthan's SIP diagnostics.  Maybe we can use this work to apply in that
context.

Issue: ABNF issues:
  explicit counter: plain counters do not work due to forking
  options: indexiing using a dot delimiter to reflect the depth of
           forking
  <went through an example; see viewgraphs>

Forking: need to add more scenarios

Privacy: if you need privacy, use draft-ietf-sip-privacy-general

Security: primary concern is in regard to a rogue app/proxy challenging  HI
entries.
Discussion:  You are already assuming some level of trust in these
intermediaries; i.e. they are proxying the request in the first place. It
strikes me as a "sips" kind of thing; then you can guarantee that no rogue
element has put anything in since all are trusted. Proposal:  Maybe you can
use the Auth-ID body draft.
Idea is not to assume a weird trust relationship b/w all intermediaries.
What you get is some optional information in a signed auth-ID body that
asserts that proxy A retargetted to location Y.  Maybe we should allow
proxies to add bodies (they add headers). Comment : This is hard to spec
right.  Maybe we can start with writing
reqs so we can spec it right.
Poll; Ready for WGLC? Resolved to take to list, not enough people had read
Poll: Do we feel that the reqs have sufficiently been presented in public
that we are ready to ask SIP to consider a mechanism?  Even split between
waiting before implementing a solution and asking SIP to proceed.


Diagnostics -- Jiri Kuthan
-------------------------

Status: Narrowed the scope due to the discussion of mailing list; scope now
is diagnostics of SIP routing only.

Proposal: Let the UAS be talkative and disclose what they know about
circumstances under which a request failed. Proxy Hints: disclose aggregated
processing logic; mirror hints upstream  so that troubleshooters located
upstream can see it

Issues: privacy concern.

Proposal is to use sipfrag and include the diagnostic in sipfrag.
Discussion: Might be better to  have a standardized way of doing this to
make it easier to implement and deal with. However,  we have the same
problem with email processing; the email server sends error messages that
say where the message died.

Proposal: Reqs developed for history would apply to this quite well.  We
should start with that and see how far it gets us. 

Conclusion: We should start working on requirments..



Thursday, November 21 at 1300-1500: Salon III
=================================

Evaluation of IEPREP requirements on SIP, Chairs, Henning Schulzrinne
-------------------------------------------------------------------------

Changes since last rev discussed. 

Issue: What should the process be? Does this draft cearly define
requirements for extensions to SIP that can be taken to SIP WG?

Conclusion: We will scheduel a WG review ASAP. We will not crosspost
to IEPREP, but will ask a volunteer (Kimberly?) to take any 
discussion needed to IEPREP

Status report on Conferencing design team, Alan Johntson
--------------------------------------------------------

Status New smaller design team formed to try and get back on schedule and
docs agree with each other. Each team member now responsible for one or more
docs. First out will bea revised framework document that will include
terminology. There are drafts of several documents, agreements on
terminology and scope, and progress seems good. 

Poll: Anyone have problems with this approach?
Suggestion that docs be out a month to six weeke before next IETF.

Status report and open issues from Hearing Impairment design team, Gonzalo
Camarillo
----------------------------------------------------------------------------
------------
Slides presented are available in proceedings.

Goals: Going beyond the reqs for the deaf; we are working on invocation of
services that involve media manipulations including codec and language
transcoding. Want to be opes aware.

Deliveries: transcoding services invocation in SIP and the source and sink
attributes for SIP (2 I-Ds).

Possible future deliveries: labeling of transcoded media streams, caller
prefs extensions. We have to think about these two before finalizing them.

Issues: invocation in the B2BUA model as opposed to 3pcc model which is seen
as  quite complete. We use Route header field as if the B2BUA was a proxy.
We did not feel comfortable with this approach. Maybe we can  use something
else like message encapsulation or REFER. Current decision is REFER: more
opes friendly and has security built in. Disadvantage:  more signaling. But
generality wins.

Discussion: the work may not have taken into consideration other
requirements about transcoding. Consenus that these can be added as they are
brough up on list.

Poll: is plumbing draft (draft-camarillo...sink-00) needed? Discussion that
it might overlap with conferencing and be able to reuse conference work or
be input to conferencing work. 
Conclusions: co-ordinate with conf DT on overlap and ask SIPPING WG to
advise on further path.


App Interaction Design TeamT, Jonathan Rosenberg
------------------------------------------------

Status: 
Small team -- 4 members.

What are we doing? Stimulus with SIP -- the way in which users interact with
apps using media, markup and dtmf. Team is making good progress on
understanding the nature of dtmf in these networks, but there is a general
problem here: event reporting.

Produced 3 documents (framework, KPML, and interaction) and inherited one on
interaction requirements.

Issue: infamous SIP vs HTTP debate -- who carries the information? Document
clarifies difference between rfc2833 and using SIP or HTTP
to carry these. It deliniates the UI from the app. Comment: If you have
markups that assume HTTP they will use it; if you have markups that assume
SIP, then they will use SIP. The language construction is different.

Issue: Focus determination for KPML: when a user enters a digit, which KPML
amongst the ones from various apps does it apply to. Current draft says send
it everywhere -- same as PSTN does. Architectural solution: have a central
controller model which runs a super app and make decisions for the user. Is
this adequate?  Any other ideas?
No discussion noted.

Issue: Error reporting for App-Info: what if App-Info URI is invalid?
Options: no error reporting, only send App-Info in requests (where a error
response can be generated), error reporting URI (infinite recursion
problem).
No discussion noted.

Issue: indicating script termination -- should we or not?
Discussion: This is complicated, and overlaps with IMAP issues
Comment: A lot of it is problem statement: we want to do what HTTP does, but
get started in some other way.

Issue: Barge-in ==> framework has feature that allows IVR barging to be
pushed to endpoint. Problem is how to detect when its OK to start
playing media again? Need some media synch. Markup bits don't work; PT
changes may work; others?

Further discssion referred to list. 

Discussion about potential new work in QSIG and Q.931 interworking, 
Jon Peterson
--------------------------------------------------------------------

Discussion Some interest in going forward with this in Yokohama IETF. Not a
lot of discussion since then on list. As per yesterday's SIPPING
WG, we would also prefer to do some SIP->Q.SIG mapping. 

John Elwell has released a new version of I-D since Yokohama; changes:  use
of P-Asserted-Identity in mapping to CLIP/CLIR and strengthened security
text following the SIP-ISUP draft.

Not a SIPPING WG item yet, any comments?
Keith: Minor nit: it is QSIG, not Q.SIG.

Poll: Any objections to make this a WG item? No objection noted.


FYI and Discussion on iCal usage in SIP, Pekka Pessi
----------------------------------------------------
Slides presented are available in proceedings.

Status: iCalendar is a calendaring information exchange format based on
vCalendar. iTIP is an abstract protocol for interaction between calendar
UAs. It has methods like PUBLISH, REQUEST, REPLY, CANCEL,  ADD, etc.

iCalendar use with SIP: off-line invitations, describing SIP
tele-conferences,  indicating schedule and timezone, notifications for
schedule, conference, etc. 
Procedure :Map iTIP to SIP ==> iSIP. iSIP is very similar to iTIP.

Open issues: does iSIP fit in calsch? It does not change how SIP is used.
Submit new draft using standard iCalendar format?
Specify iSIP apps separately: iCalendar for on-line conf?

Discussion: Why do we have to carry this in SIP?
Answer: SIP brings SIP addressing

Discussion: One model is that this is some MIME type and I don't care. Then
why do we have to define a mapping if we are carrying an object?
Answer: It is an object and you don't have to do anything in SIP. However,
some protocols provide optimizations for carrying the object. Do we want to
do that here?

Further discussion referred to list due to end of allotted time.

Meeting adjourned.

----------------------------------------------------------------------------
----


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