Upload
lucy-barrett
View
214
Download
0
Embed Size (px)
Citation preview
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, [email protected] >
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.