SIPPING%20Working%20Group%20IETF%2065

1
SIPPING Working GroupIETF 65

• Mary Barnes
• Gonzalo Camarillo

2
Note Well

• Any submission to the IETF intended by the
  Contributor for publication as all or part of an
  IETF Internet-Draft or RFC and any statement made
  within the context of an IETF activity is
  considered an "IETF Contribution". Such
  statements include oral statements in IETF
  sessions, as well as written and electronic
  communications made at any time or place, which
  are addressed to
• the IETF plenary session,
• any IETF working group or portion thereof,
• the IESG, or any member thereof on behalf of the
  IESG,
• the IAB or any member thereof on behalf of the
  IAB,
• any IETF mailing list, including the IETF list
  itself, any working group or design team list, or
  any other list functioning under IETF auspices,
• the RFC Editor or the Internet-Drafts function
• All IETF Contributions are subject to the rules
  of RFC 3978 and RFC 3979. Statements made outside
  of an IETF session, mailing list or other
  function, that are clearly not intended to be
  input to an IETF activity, group or function, are
  not IETF Contributions in the context of this
  notice.
• Please consult RFC 3978 for details.

3
Other Notes

• Need a Note Taker
• Need a scribe for Jabber session
• MP3 streaming
• Use the microphone, and state your name
• Wireless Make sure your computer is not in
  adhoc mode

4
Supplementary Web Page

• http//www.softarmor.com/sipping
• Draft database with status information
• Too much work for the value it adds
• To be discontinued
• Use IETF tools and the ID tracker instead

5
Wednesday Agenda

• 1300 Chairs - Status and Agenda Bash
• 1315 Dan Petrie - Config Framework Split
• 1325 Sumanth Channabasappa - Use Case and
  Considerations for SIPPING Config
• 1340 Gonzalo Camarillo - Consent Framework
• 1425 Volker Hilt - Session Policies
• 1445 Arnoud van Wijk - ToIP

6
Friday Agenda

• 0900 Chairs - Agenda Bash
• 0905 Robert Sparks - Multiple Dialog Usages in
  SIP
• 0920 Robert Sparks - Limiting the Damage from
  Amplification Attacks in SIP Proxies
• 0925 Andrew Allen - Requirements for IMS service
  identification
• 0940 Steffen Fries - SIP Identity Usage in
  Enterprise Scenarios
• 0950 Jani Hautakorpi - Requirements from SIP
  Session Border Control Deployments
• 1000 Jonathan Rosenberg - Overload Requirements
• 1010 Salvatore Loreto - Same Session Header Field
  
• 1020 Jason Fischl - SIP for Media over DTLS
• 1035 Haseeb Akhtar - New SIP Headers for Reducing
  SIP Message Size
• 1040 Haseeb Akhtar - 3G Wireless Support in the
  SIP/SDP Static Dictionary for SigComp
• 1045 Miki Hasebe - Race Condition Examples
• 1055 Peili Xu - The User-registered Routable UA
  URL
• 1100 Xiao Wang - Requirements for batch
  Subscriptions Refreshment
• 1110 Byron Campen - An Efficient Loop Detection
  Algorithm for SIP Proxies
• 1120 Rocky Wang - A method to override the
  barring services

7
RFCs Published since IETF 64

• RFC 4245 Conferencing Requirements
• RFC 4354 Conferencing Framework
• RFC 4235 Dialog Package
• RFC 4411 Reason Header for Preemption

8
RFC Editors Queue

• draft-ietf-sipping-app-interaction-framework (PS)
• draft-ietf-sipping-callerprefs-usecases
  (Informational)
• draft-ietf-sipping-cc-conferencing (BCP)
• draft-ietf-sipping-conference-package (PS)
• draft-ietf-sipping-consent-reqs (Informational)
• AUTH 48
• draft-ietf-sipping-kpml (PS)
• draft-ietf-sipping-message-tag (Informational)
• draft-ietf-sipping-qsig2sip (BCP)
• draft-ietf-sipping-torture-tests (Informational)
• draft-ietf-sipping-trait-authz (Informational)

9
Post-Publication Request

• draft-ietf-sipping-uri-services (PS)
• draft-ietf-sipping-config-framework (PS)
• draft-ietf-sipping-transc-conf (PS)
• draft-ietf-sipping-transc-framework (Info)
• draft-ietf-sipping-rtcp-summary (PS)

10

• draft-isomaki-sipping-file-transfer-01.txt

11

• draft-isomaki-sipping-file-transfer-01
• A minor update from the -00 version
• Describes use cases and requirements for file
  transfer in the following SIP related contexts
• one-to-one page-mode file transfer
• one-to-one session-mode file transfer
• e.g. as a component in a session with other media
• one-to-many page-mode file transfer
• File transfer in a multiparty conference
• Some interest expressed (mainly privately) on
  the draft, also relevant to OMA
• draft-garcia-sipping-file-tranfer-mech addresses
  the requirements related to scenarios 1. and 2.
• Scenario 3. probably with draft-ietf-sipping-uri-l
  ist-message and content indirection
• Scenario 4. needs first some more maturity in the
  area of MSRP conferencing
• Should the reqs draft be adopted by some WG
  (SIPPING?) and the relevant work chartered, or do
  we just go about proposing the solutions?

12

• draft-garcia-sipping-file-tranfer-mech-00.txt
• Presented in MMUSIC

13
Summary

• Requirements for this mechanism in
• draft-isomaki-sipping-file-transfer-00.txt
• How to describe, using SDP, the file to be
  transferred
• The answerer needs to be able to reject the file
  before the transfer starts
• Note that, still, MSRP messages carry, as usual,
  a MIME container describing the file being
  transferred
• Recommendations on how to perform the transfer
  using MSRP
• E.g., an MSRP session carries one file, but
  several MSRP sessions can be multiplexed over the
  same TCP connection

14
Example

• mmessage 7654 TCP/MSRP iThis is my
  latest picture asendonly aaccept-types
  apathmsrp//alicepc.example.com7654/jshA7wetcp
  afilenameMy cool picture.jpg
  afiletypeimage/jpeg adispositioninline
  afilesize4096 ahashSHA 72245fe8653ddaf371362
  f86d471913ee4a2ce2e

15

• draft-hasebe-sipping-race-examples-00.txt

16

• Represented a basic idea to explain race
  conditions
• Made a figure of the dialog state transition to
  reveal the underlying structure of race
  conditions.
• Organize and reclassify examples in race
  condition
• Examples in the previous draft is organized into
  categories based on the figure of dialog state
  transition.

17

• Let me hear your candid opinion of my proposal.
• The idea of causing race conditions arising from
  the dialog state transition.
• Classification of examples based on that idea.

Proposal

• I hope to promote discussions on the draft as a
  WG item.

18

• draft-kang-sipping-transc-scenario-01.txt

19
Use case of Multi-transcoding
draft-kang-sipping-transc-scenario-01.txt

• Changes
• Added the use cases of Multi-transcoding
• Updated new response codes for multi-transcoding
  error case
• Use cases
• Heterogeneous networks Enterprise network, IMS,
  PacketCable, WiBro
• Multiple ITSPs each of which uses a different
  specific codec
• Wideband transcodecs without tandem (Narrowband)
• This effort will be
• Minimizing the number of transcoding
• Providing higher end-to-end speech quality
• Maximizing successful call setup (codec matching)
  in SBC
• Next steps
• Defining more detailed use cases and scenarios

20

• SIP LDAP User Schema

21
SIP LDAP User Schema lt Leif Johansson,
leifj_at_it.su.se gt

• Problem use LDAP directories for three related
  but separate things
• SIP white-pages contact information
• - i.e the sip uri you print on your
  business card or present to an ldap-client. This
  is analogous to the 'mail' attribute of the
  classical LDAP user schema.
• SIP authentication data e.g. username and digest
  password
• Static SIP routing information
• This is analogous to the mailRouting LDAP
  schema and might contain a list of equivalent
  sip-addresses (compare to email aliases) and a
  sip-address (or set of sip addresses if forking
  is used) to be used as the key in the location
  server.
• Typical deployment-scenario for the last two
  cases is a sip-server using LDAP as the
  repository for sip users.
• Team is working on http//www.stacken.kth.se/proje
  ct/yxa/ which has implemented a schema which
  implements 2 and 3.

22
SPIT Authorization Policies
Policies
Policies
Policies
Policies
Proxy
Proxy
SIP
SIP
SIP
RTP
Alice
Bob

• A few aspects to think about
• Are authorization policies (black lists/white
  lists) useful for this purpose?
• What attributes are useful in a condition part of
  an policy rule?
• What mechanisms are suitable to create, modify
  and delete these policies? (e.g., XCAP,
  Subscribe/Notify)
• Where are these policies placed? (e.g., end host,
  SIP proxy)
• Who creates these policies? (e.g., parents for
  their kids, owner of the device, etc.)
• Can we reuse existing work? (e.g., Geopriv Common
  Policy)

23
draft-niccolini-sipping-feedback-spit-00.txt

• Requirements and methods for SPIT identification
  using feedbacks in SIP
• Motivation
• User feedback is important for SPIT prevention
• Users can send a feedback using a button on the
  user interface of the client(see
  draft-ietf-sipping-spam-02.txt)
• Content
• Requirements list
• Parameters to be included in feedback
• Candidate methods for sending feedback
• Is the SIPPING working group interested in
  discussing such a topic?

24

• SAML-CPC Draft
• Draft
• draft-schubert-sipping-saml-cpc-00.txt
• One of the SAML base draft author as a co-author.
• Evaluates semantics of cpc, possible architecture
  and use-cases when SAML is used to convey cpc.
• Will revise the draft
• Now that there is one way to skin a cat..
• Evaluates and reuse whatever possible from the
  new SAML base draft.
• Keep on work together with the SAML base draft
  authors to come up with something thats in
  alignment with the base spec.