SIPPING Working GroupIETF 65

Mary Barnes

Gonzalo Camarillo

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.

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

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

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

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

RFCs Published since IETF 64

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

RFC Editor’s 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)

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)

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

● 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

1. one-to-one “page-mode” file transfer2. one-to-one “session-mode” file transfer

● e.g. as a component in a session with other media3. one-to-many “page-mode” file transfer4. 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-list-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?

draft-garcia-sipping-file-tranfer-mech-00.txt

Presented in MMUSIC

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

Example

m=message 7654 TCP/MSRP * i=This is my latest picture a=sendonly a=accept-types:* a=path:msrp://alicepc.example.com:7654/jshA7we;tcp a=filename:My cool picture.jpg a=filetype:image/jpeg a=disposition:inline a=filesize:4096 a=hash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e

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

Changes from the previous draft

• 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.

Open issues

• 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.

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

Use case of Multi-transcoding● 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

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

SIP LDAP User Schema

SIP LDAP User Schema < Leif Johansson, leifj@it.su.se >

Problem: use LDAP directories for three related but separate things:

1. 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.

1. SIP authentication data: e.g. username and digest password

2. 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/project/yxa/ which has implemented a schema which implements 2 and 3.

SPIT Authorization Policies

● 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)

Proxy

SIPSIP

SIP

ProxyPolicies

Alice BobRTP

Policies Policies

Policies

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?

● 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 that’s in alignment with the base spec.