1 / 6

RTSP 2.0 draft-ietf-mmusic-rfc2326bis-28

RTSP 2.0 draft-ietf-mmusic-rfc2326bis-28. Magnus Westerlund magnus.westerlund@ericsson.com Martin Stiemerling martin.stiemerling@neclab.eu IETF-82, MMUSIC WG, 2011-11-18. Non-Editorials/Fixes. e.g. OLD: Unrecognized headers in responses are treated as message-headers.

arlen
Download Presentation

RTSP 2.0 draft-ietf-mmusic-rfc2326bis-28

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RTSP 2.0draft-ietf-mmusic-rfc2326bis-28 Magnus Westerlund magnus.westerlund@ericsson.com Martin Stiemerling martin.stiemerling@neclab.eu IETF-82, MMUSIC WG, 2011-11-18

  2. Non-Editorials/Fixes • e.g. • OLD:Unrecognized headers in responses are treated as message-headers. • NEW:Unrecognized headers in responses are treated as message-headers and hence MUST be ignored. • must -> MUST in some places • similar for shoulds, etc • ABNF:profile = "AVP" / "SAVP" / "AVPF" / "SAVPF" / token

  3. 13.3.1. Changing Transport Parameters • In a SETUP response for a request to change the transport parameters while in Play state, the server MUST include the Range to indicate at what point the new transport parameters will be used. Further, if RTP is used for delivery, the server MUST also include the RTP-Info header to indicate at what timestamp and RTP sequence number the change will take place. • FSA: This effectively makes RTSP incompatible with RTP mixers, right ? If so, should probably note that.

  4. 16.52 Transport • MIKEY: This parameter is used in conjunction with transport specifications that can utilize MIKEY for security context establishment. So far only the SRTP based RTP profiles SAVP and SAVPF can utilize MIKEY and this is defined in Appendix C.1.4.1. This parameter can be included both in request and response messages. The binary MIKEY message SHALL be BASE64 [RFC4648] encoded before being included in the value part of the parameter. • FSA: Is MIKEY the only keying mechanism supported. Seems restrictive for unicast at least. Has there been discussion around this more recently ?

  5. 16.55. Vary • Header/Section inherited from HTTP • The Vary field value indicates the set of request-header fields that fully determines, while the response is fresh, whether a cache is permitted to use the response to reply to a subsequent request without revalidation. • FSA: Operation is very unclear and there is nothing in Section 18 to explain it further (HTTP has much more detail here, but that doesn’t help in this document). • Section 18: Caching

  6. Next Steps • Work through remaining comments by Flemming • many require cross checking multiple parts of the draft • Martin to post open issues to list • WG to check next version on the changes • after remaining comments of Flemming have been addressed

More Related