1. RTSP Interoperability Bakeoff Ron Frederick ronf@entera.com

2. July 31, 200048th IETF, MMUSIC WG1 Overview July 24th & 25th, 2000 –Hosted at Entera in Fremont, CA About 27 attendees from 7 organizations –Apple, Cisco, Entera, Microsoft, Real, Sun, and University of Technology in Darmstadt Goals: –Test interoperability of various RTSP clients, proxies, and servers –Provide feedback to the IETF about the RTSP specification

3. July 31, 200048th IETF, MMUSIC WG2 OPTIONS Command Passing real URL rather than “*” is useful when proxies are involved –Proxy can potentially pass OPTIONS on to origin server, rather than simply returning what commands it supports

4. July 31, 200048th IETF, MMUSIC WG3 SETUP Command Spec should be clearer about whether (or when) servers must allow a SETUP without a preceding DESCRIBE Are servers required to allow a SETUP on only a subset of tracks in an aggregate object? Can SETUPs for tracks in different objects be combined into a single session?

5. July 31, 200048th IETF, MMUSIC WG4 PLAY Command Proposal: Allow * for URL when PLAY has a Session specified –If SETUPs return a Session ID, play URL is redundant –If tracks from different objects are put into the same session, what URL makes sense? Queued PLAY described in spec has not been widely implemented by existing servers

6. July 31, 200048th IETF, MMUSIC WG5 CSeq Header Would be useful to clarify that CSeq values should be unique within a single connection between client & server –There was some confusion about whether they might be per-session instead

7. July 31, 200048th IETF, MMUSIC WG6 RTP-info Header Quoting the URLs would be useful –If not, RTP-Info can be hard to parse Meaning of “seq” and “rtptime” could use clarification –Spec does say one doesn’t always correspond to the other, but a more detailed example might be helpful Should RTP-Info also specify timestamp of first real packet in track?

8. July 31, 200048th IETF, MMUSIC WG7 Session Header Getting session state before SETUP –It’d be useful to get a session ID to associate state with before setting up a particular media stream – perhaps some kind of optional header to request one could be added to OPTIONS? All session ID examples are numeric! –Using some alphanumeric examples would reinforce the fact that Session IDs should be treated as opaque strings

9. July 31, 200048th IETF, MMUSIC WG8 Session Header (cont.) Is SETUP required to return Session? –Spec says not always, but some kinds of aggregate control are hard without it Session timeouts could use explanation –Section 12.37 says timeout is delay between RTSP commands, but Section A also mentions other “wellness” information like RTCP reports –There was some confusion about timeout and/or teardown of session vs. control connection

10. July 31, 200048th IETF, MMUSIC WG9 Transport Header RTP/AVP/TCP and “unicast” –Spec currently says “multicast” is the default for all transports if nothing else is specified, but “multicast” doesn’t make sense for TCP –Should RTP/AVP/TCP default to “unicast”? Interleaved TCP transport –Does RTP/AVP/TCP imply interleaved? –If not, how does a client ask for it without specifying channel numbers?

11. July 31, 200048th IETF, MMUSIC WG10 Transport Header (cont.) Port numbers –Options port, client_port, and server_port allow either “port” or “port1-port2”. Spec should clarify meaning of specifying only one port. –What would be the meaning of a port range where port2 wasn’t port1+1? Is this ever useful?

12. July 31, 200048th IETF, MMUSIC WG11 Transport Header (cont.) Proxy issues –It is useful for proxies to add “source” field to transport, to make sure client RTCPs are sent to the right place –Proxy implementation is easier if servers echo back full transport info, including things like “client_port”, when they reply

13. July 31, 200048th IETF, MMUSIC WG12 RTP Issues Servers need to be more careful to pay attention to seq #s and timestamps when seeking, as mentioned in Section B Setting marker bit for audio in a server is difficult, though – many servers wouldn’t even know if a track was audio –Where possible, have clients use the “seq” field in RTP-Info to force playout adaption to occur at the transition point –This works for both audio & video

14. July 31, 200048th IETF, MMUSIC WG13 SDP Issues a=control: relative URL handling –If only Content-Location is found, should it be used as-is as the base or should its final component after the last ‘/’ be stripped? –Is a relative URL legal at the “session” level? –If a session-level “control” is specified, does that become the base URL for all the media level controls, or do they use the original base?

15. July 31, 200048th IETF, MMUSIC WG14 SDP Issues (cont.) How can one do content negotiation? –A few different non-standard extensions exist right now. Having a single standard scheme would be useful. On video tracks, “cliprect” field could be useful even when playing back video at its natural size

16. July 31, 200048th IETF, MMUSIC WG15 Other Issues “Stream done” notification would be useful –Sent by a server after last data packets sent –RTP-Info could specify next seq # & RTP time –Similar info would be useful after a PAUSE Should RTSP proxies preserve port #s? –If multiple SETUPs from a client use the same port numbers, should the proxy be required to also use the same ports?

17. July 31, 200048th IETF, MMUSIC WG16 Other Issues (cont.) How should multiple headers of the same name be treated? –For some headers like “Accept” and “Transport”, this could be treated like one header with multiple comma-separated items. Is this legal for all headers, though? What line continuation conventions are allowed, if any?