Below - note for my convenience in providing context, this includes the slide contents as well. Regards Keith SIPPING Adhoc - SIP Extensibility: Monday 2200-2400, Room: Franklin 13 ------------------------------------------------------------------------ sipping ad-hoc discussion on SIP extensibility. Hum to decide whether to hold the meeting or not. Equal numbers in favour of having the meeting tonight, versus not holding the meeting at all this week. Meeting therefore cancelled. SIP Overload presentation to Transport Area (in TSVArea): Tuesday 1740-1950 Room: Franklin 1/2 ------------------------------------------------------------------------------------------------- Session advertised (in parallel with other RAI sessions) ---------------------------------------------------------- (draft-sinnreich-sip-tools-02) ------------------------------ Focus on Internet multimedia RT communications An alternative to SIP services 'in the network' with app servers Applications reside in the endpoints, including complex call scenarios (I1)* SIP in the network is used only for rendezvous (location) and session setup Applicable to both Client Server (CS) and P2P SIP Tool set for implementations includes NAT traversal, security Reduces SIP specific RFCs as of early 2008 from roughly 100 to about 9-10 (I1)* More RFCs and informative I-D on NAT traversal and security *I1 is still informative I-D:draft-ietf-sipping-cc-framework. Will be RFC. Mandatory References RFC 3261: "SIP: Session Initiation Protocol" RFC 3264: "An Offer/Answer Model with SDP" RFC 3263: "Locating SIP Servers" RFC 3840: "Indicating User Agent Capabilities in SIP" RFC 3856: "A Presence Event Package for SIP" RFC 3863 "Presence Information Data Format (PIDF)" RFC 3428: "SIP Extension for Instant Messaging" RFC 3581: "An Extension to SIP for Symmetric Response Routing" RFC 4961: "Symmetric RTP / RTCP" Informative References SIP applications in the endpoints "A Call Control and Multi-party usage framework for SIP" "Guidelines for Implementing the Dialog Event Package in User Agents" "A New Forking Mechanism for SIP" NAT Traversal "Managing Client Initiated Connections in SIP" RFC 3489bis: "Simple Traversal Under NAT (STUN)" "Interactive Connectivity Establishment (ICE)" "Obtaining Relay Addresses from Simple Traversal of UDP Through NAT" (TURN) "Best Current Practices for NAT Traversal for SIP" Other: Identity and media encryption "Enhancements for Authenticated Identity Management in SIP" RFC 4347: "Datagram Transport Layer Security" (DTLS) "ZRTP: Extensions to RTP for Diffie-Hellman Key Agreement for SRTP" Quick advertisment of the above draft. 1755 - 1810 15 minutes John Elwell Updates to Asserted Identity ---------------------------------------------------------------- (draft-ietf-sipping-update-pai-00.txt) -------------------------------------- Changes from draft-elwell-sipping-update-pai-02 More text on motivation for PAI in responses Reworded in many places to express in terms of Trust Domain References to the security requirements of RFC 3325 for connections between nodes within a Trust Domain P-Preferred-Identity allowed in additional request methods and in responses Many minor changes Open issue 1 Whether to allow P-Asserted-Identity in a REGISTER request, between an edge proxy that authenticates the UA and a registrar Only feedback was in favour Propose to allow this Questioned as to when it would be used in this case. Jonathan identified that where edge proxy authenticated. No apparent objection to inclusion. Open issue 2 Whether to allow P-Asserted-Identity in any mid-dialog request (including PRACK, INFO, BYE...) rather than just UPDATE Viewed another way: what is meaning of a mid-dialog request that omits PAI? source of request unchanged (UAC authenticated again)? source of unchanged (not necessarily authenticated again)? no deduction can be made about the source of the request? The last of these seems the safest (implying that all requests should be allowed to contain PAI) - but a suggestion on list that this could depend on spec(T) Conclusion seems to be to allow in all requests Several people spoke against allowing general use in all requests, as it was not the general intent of the draft. This change will not be documented. UPDATE (the original intent of the updated i-d) will still be included. Open issue 3 Are there any use cases that justify the use of P-Preferred-Identity in an UPDATE request? The conditions under which an UPDATE request needs to include P-Asserted-Identity are generally associated with B2BUAs and Gateways, which normally would be treated as being within the Trust Domain and would use PAI No real interest on list - but could allow just for completeness (does no harm) Jonathan had some ideas where he might be able to use it. No consensus. Unless further discussion on list, will not include. Open issue 4 Should we be precise (at least in the normative section) as to the conditions under which a proxy may assert an identity in the response? e.g., only if the proxy has TLS connectivity with the originator of the response and has previously authenticated the connected entity (e.g., using SIP digest authentication at registration time)) are there any other acceptable conditions? or do we need to leave it open? RFC 3325 is not precise even for requests - just says UAC must have been authenticated This is in line with "applicability statement" in section 1 of RFC 3325, which includes the statement: "The means by which the network determines the identity to assert is outside the scope of this document (though it commonly entails some form of authentication)." Question has been asked whether to have explicit text saying whether the applicability statement in RFC 3325 still holds or the draft updates it somehow Propose to say that applicability statement in RFC 3325 still holds and keep open the means of authenticating the UAS (keeping TLS example) Take all of issue 4 to the list. http://www.ietf.org/internet-drafts/draft-holmberg-sipping-199-04.txt ---------------------------------------------------------------------- 199 responses. Exclude HERFP. Rohan says he is never going to do anything with it. Information to WG to send the requirement in this draft to SIP. 1810 - 1825 15 minutes Sumanth Channabasappa User Agent Profile Datasets ------------------------------------------------------------------------ (draft-ietf-sipping-profile-datasets-00.txt) -------------------------------------------- Introduction draft-petrie-sipping-profile-datasets' was accepted as a WG item at IETF#70 The document specifies a Schema and guidelines for defining SIP UA profile datasets It complements the framework specified in draft-ietf-sipping-config by addressing profile data The document is now presented as 'draft-ietf-sipping-profile-datasets-00' and is available at: http://tools.ietf.org/wg/sipping/draft-ietf-sipping-profile-datasets-00. txt Update Changes made since acceptance as a WG item Mostly attempts to reduce verbosity Requirements are now the primary focus, the informative use cases are now in Appendix B Removed repeated information, for example, the transport protocol use case (repeat of the codec use case) Incorporated other editorial suggestions Questions Should the I-D mandate specific profile data sets, or just provide a framework? Recommendation: Framework? Should merging rules be part of the framework or delegated to the specific profile data sets? Recommendation: Delegate? Next Steps Reviews and Feedback We need Schema and RELAX NG experts; any volunteers? We need comments related to profile data; anything that is missing? Incorporation of comments, suggestions and resolutions John-Luc Bakker's offline comments related to the RELAX NG Schema The "invisible" attribute discussion Continue efforts to make it less verbose Comments and suggestions to mic requested. Chair said important to sip-session-policy-framework. Has been in WG as individual for at least 5 years. Goal is to make it more concise. Eric Rescorla commented on invisible attribute. Eric objects to SHOULD being applied to a terrible idea. He is happy to have an attribute that ???? Continue discussion on list on this issue. Cullen Jennings on exclude mechanism. Has no idea on how it might be implemented. Also seems to have limited use case - only one presented is to exclude certain codecs. Considers needs a lot of clarification before proceed with this. 1825 - 1840 15 minutes Sumanth Channabasappa Extension to the ua-profile Event Package to Support the Application Profile Type -------------------------------------------------------------------------------------------------------------------------------- (draft-channabasappa-sipping-app-profile-type-02.txt) ----------------------------------------------------- Recap The SIP Configuration Framework (draft-ietf-sipping-config) specifies the 'ua-profile' event package The framework is used to deliver profile data to SIP UAs The framework recognizes three types of profile data local-network, device, and user I-D '...-app-profile-type' is an extension to the SIP configuration framework It specifies an additional profile type, 'application' Feedback from IETF#70 Clarify the intent of the 'application' profile type Why do we need an additional profile type? How is it different from the device profile type? Changes: -01 to -02 Added text to explain the intent of the 'application' profile type A SIP UA can support multiple applications The application data can be: application-specific, i.e., unrelated to any users, or user-specific User-specific data may be provided via the user profile Application-specific data requires a new profile type; needs to handle one or more applications Clarified the 'app-id' parameter to be a URI, preferably a URN Retained multipart/mixed content-type for data related to multiple applications Incorporated other editorial changes such as removal of issues that have been addressed Feedback on -02 One comment has been received so far Clarify the population of the header fields, viz., Request-URI, From and Contact headers This will be incorporated Other comments or suggestions that we missed? Next Steps The authors request the WG to consider accepting the I-D as a WG item Specifications being developed in other standards bodies, such as OMA and TISPAN, are considering the 'application' profile type (or equivalents) The I-D will standardize the 'application' profile type and the associated requirements Only half dozen people indicated they had read the draft. Chairs asked for more discussion on the mailing list before proceeding. 1840 - 1855 15 minutes Jonathan Rosenberg What is a Session Initiation Protocol (SIP) Trunk Anyway? ---------------------------------------------------------------------------------------------------- (draft-rosenberg-sipping-siptrunk-00.txt) ----------------------------------------- Jonathan asked as to whether there was interest in this draft. Alan johnston said people using SIP trunks already know what they are therefore don't need draft. Martin Dolly said AT&T does not have SIP trunks - having been accused in the presentation of doing so. He does not see need for a draft. Henning asked question about SIP forum specification on SIPConnect, and as to whether this used this concept. Answer: No. Richard Shockley asked if this was limited to terminology or whether he wanted to go further. If limited to terminology did not have a problem with it. Francois Audet indicated that "SIP trunk" caused confusion as this term is somewhat "fluffy". This draft is alluding to a trunk identifier. Dan York everyone has lots of definitions of "SIP trunk" so will not be able to come to a single definition. Philip Matthews thinks the ship has sailed. Unknown: Other mechanisms exist. dtg or otg appended to a URI. Jonathan indicated that he did not like such mechanisms. Adam (most of what he wanted to say has been covered). Useful mechanism and defining it is useful, although don't call it a SIP trunk. Cullen indicated that the chair of the IPTEL WG should be objecting to this. Martin thinks we definitely need to say from this term. Need to identify wholesale traffic as a means of call processing. Takeaway that there is some interest. Jonathan will revise this draft and then WG can consider further, 1855 - 1910 15 minutes Hans Erik van Elburg Requirements for Explicit Private Network Indication ------------------------------------------------------------------------------------------------- (draft-vanelburg-sipping-private-network-indication-01.txt) ----------------------------------------------------------- Why differentiate private network traffic? NGN/IMS defined for public network infrastructure Need to handle business communications Different handling applies to enterprise traffic that never leaves enterprise context allthough it is routed through public network infrastructure and handled by public network operator hosted functionality. Examples of potential different processing behaviours: Routing Charging Required by regulation Transparency At this moment Jon Peterson sought clarification as to whether this was P-header of header. Why is an explicit indication needed Whether a call is to be treated as private network traffic or public network traffic can not always be inferred from signalling. A call where both the originating and the terminating party are identified as enterprise users from the same enterprise, may still need to be handled as public network traffic. Calls pass several proxies that may need to act on whether a call is private network traffic or not. Provisioning all these different proxies with the same knowledge is not desirable. Henry comes out with statement that this is illegal! No further explanation. Francois says doesn't explain well what is meant by private. Martin indicated that use terms like on net or off net traffic. Jonathan says does not explain conditions under which it is inserted, and that is what he needs to understand. Hans Erik says cannot be precise because it depends on the service level agreement. Remainder of slides not presented. Several solutions discussed and dismissed Resource-Priority header? P-Asserted-Service header? Request-Disposition header? P-Access-Network-Information header? Proposed solution New header Private-Network-Indicator = "Private-Network-Indicator" HCOLON PNI-value *(SEMI PNI-param) PNI-param = generic-param PNI-value = hostname Decision requested from SIPPING WG There is two directions that we can take with this solution Full SIP header field P- header field What does the meeting think is the most appropriate way forward? Conclusion to revise draft and then try to answer the questions on the way forward. 1910 - 1925 15 minutes Francois Audet Feature Referral in the Session Initiation Protocol (SIP) ----------------------------------------------------------------------------------------------- (draft-audet-sipping-feature-ref-00.txt) --------------------------------------- Main idea Feature referral allows an application to make a high level request a SIP UA to perform an action or "feature", and let the UA actually execute the feature as it sees fit Application can be a proxy, user agent, third-party, etc. Uses REFER with Refer-To URI containing a URN Uses cases Loosely coupled UAs which would like to present a coordinated user experience (PDAs, Phones, Computers, game console, etc.) Traditional CTI replacement that scales globally How to perform CTI functions CTI requires two components: Monitoring - to learn the state of the UA Control - request the UA to perform certain feature SIP already provides some capabilities for monitoring: Dialog package, Registration package, Conference package SIP also provides a method for requesting UAs to perform certain task: REFER Adam: Issue with REFER becoming such a general purpose overloaded mechanism. Francois says has issue on this in subsequent slides. What is missing today? REFER does not allow for a UA to request another UA to respond to requests, e.g., A UA cannot request another UA to answer a call A UA cannot request another UA to reject a cal REFER does not allow for a UA to request another UA to invoke features, e.g. REFER does not allow a UA to request another UA to place a call on hold, or mute it REFER does not allow a UA to request another UA to transfer, conference or park a call Scott Lawrence: Why is this not a REFER with replaces. Call pickup does this all the time. Clarified by Rohan that entity sending this does not want the media to arrive on their own UA. Dale: Cannot use REFER without a few assumptions. Can use REFER to direct to another UA. Jonathan does like this one the best of all the previous examples of this considered. Dean says we are overloading REFER, and also reinventing MGCP. Suggested that the appropriate mechanism was to send a 302 response to deal with this. This was the only way of making it work with media identity. Ted: This is a really terrible use of URN. The feature is so open ended that ... Rohan: Believes people have not understood the reason for the draft. Christer: Smells like service identification. Ian Macdonald wanted to know what parts of REFER it was intended to use. Robert asked what was special about this mechanism for CPI, rather than something that was asking to do channel changeing or fast forward. How much text is in the document saying "Why SIP?". Continue discussing on list. Remainder of slides not presented. The Mechanism Extension to SIP Call Control and Application Interaction Framework Uses REFER (as per the procedures of Dialog-Usage in RFC 5057) Would typically be used in conjunction with subscription to Dialog Package and maybe others Sample URNs: urn:feature:AnswerCall urn:feature:ClearConnection urn:feature:DeflectCall urn:feature:HoldCall urn:feature:RetrieveCal urn:feature:SingleStepTransfer urn:feature:ConferenceCalls urn:feature:SeperateCalls What's different this time Not attempting to standardize "Supplementary Services" Only defining the mechanism for requesting simple "features" (perhaps "primitives" would be a better term) Very loose coupling Open Issues How open to new features should this be? How is support for feature referral negotiated, and for which feature set? Should feature set be defined separately? 1925 - 1940 15 minutes Vijay Gurbani Methodology for Benchmarking SIP Networking Devices ----------------------------------------------------------------------------------------- (draft-poretsky-bmwg-sip-bench-meth-02) (draft-poretsky-sip-bench-term-04) -------------------------------------- IETF's Benchmarking Methodology Working Group (BMWG) * BMWG is in the Operations and Management Area * BMWG writes recommendations for benchmarking the performance characteristics of internetworking technologies * Documents are Terminology and Methodology * Benchmark Requirements - Benchmark a Single DUT or SUT - Benchmarks devices in the lab, not live networks - Benchmark performance, not conformance - Black-Box Benchmarks, Not White-Box * Methodology must be repeatable * Benchmarks must be comparable http://www.ietf.org/html.charters/bmwg-charter.html Motivation * Problem Statement: - Service Providers are now deploying VoIP and Multimedia using the IETF developed Session Initiation Protocol (SIP). - Industry lacks common terminology for SIP performance benchmarks - SIP allows a wide range of configuration and operational conditions that can influence performance benchmark measurements. * Goals: - Service Providers use the benchmarks to compare performance of RFC 3261 network devices - Vendors and others can use benchmarks to ensure performance claims are based on common terminology and methodology. - Benchmark metrics can be applied to make device deployment decisions for IETF SIP Industry Collaboration * BMWG to develop standard to benchmark SIP performance of a single device * SIPPING and BMWG Chairs met in Montreal to discuss this SIP Performance Benchmarking work item as it was first opened in BMWG * PMOL WG developing standard to benchmark end-to-end SIP application performance. * SPEC to develop industry-available test code for SIP benchmarking in accordance with IETF's BMWG and SIPPING standards Relevance to BMWG -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Sunday, June 25, 2006 6:00 AM I believe that the scope of the 'SIP Performance Metrics' draft is within the scope of what bmwg is doing for a while, quite successfully, some say. On a more 'philosophical plan', there is nothing that says that the IETF work must strictly deal with defining the bits in the Internet Protocols - see http://www.ietf.org/internet-drafts/draft-hoffmantaobis- 08.txt. And in any case, measuring how a protocol or a device implementing a protocol behaves can be considered also 'DIRECTLY related to protocol development'. -----Original Message----- From: nahum@watson.ibm.com [mailto:nahum@watson.ibm.com] Sent: Friday, May 26, 2006 2:51 PM SPEC wants to develop and distribute common code for benchmarking, as is done with SPECWeb a SPECJAppServer. That code can and should use the standardized peformance definitions agreed to by SIPPING and/or BMWG. Scope * Terminology defines Performance benchmark metrics for black-box measurements of SIP networking devices * Methodology describes how to measure the metrics for a DUT or SUT * DUT MUST be a RFC 3261 compliant device and MAY have SIP Aware Firewall/NAT and other functionality * SUT MAY be RFC 3261 compliant device with a separate external SIP Firewall and/or NAT * Benchmark * Control Signaling in presence of Media, not media itself * SIP Transport (TCP, UDP, TLS over these) * Invite and Non-Invite scenarios Benchmarks * Maximum Session Establishment Rate * Maximum Registration Rate * Maximum IM Rate * Session Capacity * Session attempt performance * Session setup delay * Session disconnect delay * Standing sessions Next Steps * Get this work item on BMWG agenda * Solicit input from SIP/SIPPING WGs * Have SIPPING expert review final draft at BMWG's WGLC Rohan: Indicated that it was going to be necessary to test for media. Response will test in the presence of media, but not testing the media. Eric Rescorla: ?????????? (Translation required) Christer: Is it useful to be RFC 3261 alone, rather than all the extensions that might be used in real life. 1940 - 1950 10 minutes Alan Johnston Secure Media Recording and Transcoding with SIP ------------------------------------------------------------------------------------- (draft-wing-sipping-srtp-key-03.txt) ------------------------------------ Note: IPR disclosure by Avaya New Sections on Use Cases Recording Modes Always On Recording Recording On Demand Required Recording Pause and Resume Recording Recording Call Flows Always On Recording Recording On Demand Required Recording Pause and Resume Recording Call Flow Conference Recording Changes Recorder as a SIP UA instead of an invisible packet sniffing device A Controller as a B2BUA in the middle Similar to a Focus B2BUA which has been standardized by the IETF Only Role is to INVITE Recorder and copy media stream to recorder No mixing Avoids Having only special UAs in recording scenarios Double bandwidth problems at endpoint Doing recording in endpoint UA still OK, it just does not require as much standardization Brian Rosen asked that do consider the case where the UA is aware of all this. Did not see this case brought out in the draft (is mentioned on slide). 2 slides with flow diagrams. No Changes To Key disclosure mechanism UA must cooperate and publish the key to the recorder Some sort of disclosure like ZRTP Event package Still needs work Richard Barnes asked for an explanation as to why a B2BUA was needed as opposed just to sucking up the media packets. Ordinary phones. Recorder does not have to be located as well. Eric Resorla. Key disclosure stuff is a new mechanism and B2BUA is guidance. Conclusion Is the working group interested in working on SIP call recording call flows? Requirements? Mechanisms? Hum to identify interest in WG. Unanimous among those that hummed.