We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byJacquelyn Swafford
Modified over 2 years ago
Copyright © 2003 Colin Perkins SDP Specification Update Colin Perkins http://csperkins.org/
Copyright © 2003 Colin Perkins Status draft-ietf-mmusic-sdp-new-13 submitted in late May –Attempt to clarify when it is appropriate to use " k= " –Deprecate unregistered " X- " attributes and media formats Descriptive text and IANA Considerations sections were inconsistent previously –Clarify that RTP can use non-contiguous ports To match changes in RTP specification since RFC 1889 –Clarify that " a=charset " is a session level attribute –Edit IANA Considerations text for clarity –Update references A few minor comments on the mailing list IESG review found a number of issues –Full set sent to the mailing list yesterday –Looking for input today…
Copyright © 2003 Colin Perkins Issues raised on the mailing list (1) Inconsistency between ABNF definition of token-char and the comment following it (Pekka Pessi) –Affects " m= ", " a= ", " k= ", " c= " and " b= " lines Two options: 1.Leave ABNF as-is, and change the comment 2.Update the ABNF for token-char, making the following legal: 0x22 0x2f 0x3d 0x3f 0x5b 0x5d 0x5c " / = ? [ ] \ Opinions from implementers?
Copyright © 2003 Colin Perkins Issues raised on the mailing list (2) Clarify use of " b= " with layered coding (Belling Thomas) For the CT modifier add: For RTP, if several RTP sessions are part of the conference, the conference total refers to total bandwidth of all RTP sessions. Accept?
Copyright © 2003 Colin Perkins Issues raised on the mailing list (3) Clarify which ports are associated with which " m= " line, with layered coding (Belling Thomas). In the definition of " m= " change: For RTP, the default is that only the even numbered ports are used for data and the corresponding one- higher odd port is used for the RTCP belonging to this RTP session, and the denotes the number of RTP sessions. Accept
Copyright © 2003 Colin Perkins IESG comments (1) The " k= " field is under-specified Should it be deprecated and/or replaced by the work in sdescriptions or key-mgmt? Opinions from implementers?
Copyright © 2003 Colin Perkins IESG comments (2) Specify that, when using " k= ": "ensure that the secure channel is with the party that is authorized to join the session, not an intermediary" "If a caching server is used, there ought to be a way to keep the server from accessing the key" Good points, need to be specified by users of SDP?
Copyright © 2003 Colin Perkins IESG comments (3) Regarding " k= ": "Also, it is generally a good idea to indicate the algorithm that a cryptographic key is intended to support. I suggest that the encryption key type be revised to specify the key as well as the algorithm that the key will be used with." Implied by the URI reference or media protocol "Finally, many security protocols require two keys, one for confidentiality and another for integrity. This specification does not support the transfer of two keys." use sdescriptions or key-mgmt if this is important
Copyright © 2003 Colin Perkins IESG comments (4) Two suggested additions to " k= ": "name the key without actually including the key. In PEM (see RFC 1040), the Recipient-ID was used to name key- encryption keys, and a similar scheme could be employed here." "would be nice to encrypt the session key in a key that is not included in SDP. PEM also includes a mechanism for wrapped symmetric keys." Use sdescriptions or key-mgmt if this is important
Copyright © 2003 Colin Perkins IESG comments (5) In security considerations: SHOULD NOT automatically drop you into an interactive session MUST NOT Accept
Copyright © 2003 Colin Perkins IESG comments (6) Regarding " c= ": Just as a query, has anyone considered using a specific marker of private address realms for SDP? That is, using a network type other than IN to indicate that the domain name or address given are not globally unique/globally reachable? Reject; Interesting, but not backwards compatible
Copyright © 2003 Colin Perkins IESG comments (7) "The text on internationalisation says UTF-8 only applies to informational fields. Does this mean it isn't required to perform any normalization whatsoever on the UTF-8? Would it make sense to explicitly state that normalization isn't needed." Seek clarification…
Copyright © 2003 Colin Perkins IESG comments (8) For " a=inactive " It was suggested apps use something like "sdp.inactive" so that the.inactive TLD could reinforce the a=inactive flag. In that instance, would the presence of that TLD be a condition under which the RTCP SHOULD is appropriately not done, and no RTCP sent? If so, is mentioning that case appropriate here?" Note that it might be appropriate to set the " c= " line for inactive media to indicate no transport address. Specify in the users of SDP?
Copyright © 2003 Colin Perkins IESG comments (9) The "u=" and " k= " lines assume the that the URI can be de-referenced. This is not always the case; so we may need to explicitly state the assumption The URI for " k= " only makes sense for particular types of URI. Might give guidance that this is typically an http or https URI? Accept both
Copyright © 2003 Colin Perkins The way forward Summarise these slides and discussion to the list… Incorporate comments into a –14 revision in the next couple of weeks – please give feedback! Discuss with IESG and resubmit…
SDP draft-ietf-mmusic-sdp-new-21.txt Colin Perkins.
SPPP Transport Session Peering Provisioning Protocol draft-ietf-drinks-sppp-over-soap-04.
SIP wg Items Jonathan Rosenberg dynamicsoft Caller Preferences: Changes Discussion of Redirects –Previous draft only proxy –Nothing different for redirect.
Slide title In CAPITALS 50 pt Slide subtitle 32 pt RTSP draft-ietf-mmusic-rfc2396bis-10 Magnus Westerlund Co-auhtors: Henning Schulzrinne, Rob Lanphier,
Magnus Westerlund 1 The RTSP Core specification draft-ietf-mmusic-rfc2326bis-06.txt Magnus Westerlund Aravind Narasimhan Rob Lanphier Anup Rao Henning.
RTSP Interoperability Bakeoff Ron Frederick
Audio/Video Transport Working Group 44th IETF, Minneapolis March 1999 Stephen Casner -- Cisco Systems Colin Perkins -- UCL Mailing list:
July 27, 2009IETF NEA Meeting1 NEA Working Group IETF 75 Co-chairs: Steve Hanna
RFC 4068bis draft-ietf-mipshop-fmipv6-rfc4068bis-01.txt Rajeev Koodli.
4395bis irireg Tony Hansen, Larry Masinter, Ted Hardie IETF 82, Nov 16, 2011.
CT-KIP Magnus Nyström, RSA Security OTPS Workshop, October 2005.
MSRP Again! draft-ietf-simple-message- session-09.
SIP working group IETF#70 Essential corrections Keith Drage.
Re-INVITE Handling draft-camarillo-sipping-reinvite-00.txt
NEMO Basic Support update IETF 61. Status IANA assignments done Very close to AUTH48 call Some issues raised recently We need to figure out if we want.
Dynamic Symmetric Key Provisioning Protocol (DSKPP)
Real-time Transport Protocol (RTP) Recommendations for SIPREC (draft-eckel-siprec-rtp-rec-02) Charles Eckel SIPREC Virtual Interim.
Session Announcement Protocol Colin Perkins University College London.
Requirements and Selection Process for RADIUS Crypto-Agility December 5, 2007 David B. Nelson IETF 70 Vancouver, BC.
RTSP to Draft Standard draft-ietf-mmusic-rfc2236bis-02.txt Authors: Henning Schulzrinne, Anup Rao, Robert Lanphier, Magnus Westerlund.
WG Document Status 192nd IETF TEAS Working Group.
IETF 60 – San Diegodraft-ietf-mmusic-rfc2326bis-07 Magnus Westerlund Real-Time Streaming Protocol draft-ietf-mmusic-rfc2326bis-07 Magnus Westerlund Aravind.
KeyProv PSKC Specification Mingliang Pei Authors: P. Hoyer, M. Pei and S. Machani 73 nd IETF meeting, Minneapolis, Nov
The Session Initiation Protocol - SIP © Internation Institute of Telecommunications inc.,
Audio/Video Transport Working Group 49th IETF, San Diego December 2000 Stephen Casner -- Packet Colin Perkins -- ISI,
48th IETFMMUSIC WG1 48th IETF - Pittsburgh 31 July August 2000.
Real Time Protocol (RTP) 김 준
Rfc4474bis-01 IETF 90 (Toronto) STIR WG Jon. First principles (yet again) Separating the work into two buckets: 1) Signaling – What fields are signed,
Real-time Transport Protocol (RTP) Recommendations for SIPREC (draft-eckel-siprec-rtp-rec-01) Charles Eckel IETF-81, Quebec City, July.
Revision of the Binary Floor Control Protocol (BFCP) for use over an unreliable transport (draft-sandbakken-dispatch-bfcp-udp-02) Charles Eckel, Tom Kristensen,
Slide # 1 IETF-62 March 2005Conference Package Conference Package Status March 11 th, 2005 IETF 62, Minnesota draft-sipping-conference-package-09.
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.
Audio/Video Transport Core Maintenance Working Group Magnus Westerlund Roni Even Jabber room:
Alexander Potapov. Authentication definition Protocol architectures Cryptographic properties Freshness Types of attack on protocols Two-way.
Disman – IETF 56 Alarm MIB Sharon Chisholm Dan Romascanu
Applicability Statement for Secure Health Transport v1.1: Proposed Clarifications & Updates July 21, 2015.
IEEE SISWG (P1619.3) Messaging & Transport. AGENDA Transport Protocols & Channel Protection Messaging Layer Capability Exchange & Authentication Groups.
RTP: A Transport Protocol for Real-Time Applications Provides end-to-end delivery services for data with real-time characteristics, such as interactive.
Page 1 IETF Speermint Working Group Speermint Requirements/Guidelines for SIP session peering draft-ietf-speermint-requirements-02 IETF 69 - Monday July.
P2PSIP Charter Proposal Many people helped write this charter…
WG RAQMON Internet-Drafts RMON MIB WG Meeting Washington, Nov. 11, 2004.
Session Initiation Protocol (SIP) Chapter 5 speaker ： Wenping Zhang data ：
IETF 71 Philadelphia - ENUM IANA Registration of Enumservices: Guide, Template and IANA Considerations draft-ietf-enum-enumservices-guide-08 B. Hoeneisen.
RTP Relay Support in Intelligent Gateway Author: Pieere Pi
Network Transport Circuit Breakers draft-ietf-tsvwg-circuit-breaker Most recent version -08 (uploaded for this meeting). Editor: Gorry Fairhurst.
Session Description Protocol
Node Information Queries July 2002 Yokohama IETF Bob Hinden / Nokia.
SDP. Session Description Protocol (SDP) an application-layer protocol intended to describe multimedia sessions a text-based protocol when describing.
Open issues from SIP list Jonathan Rosenberg dynamicsoft.
7/27/2004IETF San-Diego Plenary meeting 8/2004 EPON MIBs Lior Khermosh – Passave Technologies
© 2017 SlidePlayer.com Inc. All rights reserved.