RTSP Interoperability Bakeoff

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

2. 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 48th IETF, MMUSIC WG

3. 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 48th IETF, MMUSIC WG

4. 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? 48th IETF, MMUSIC WG

5. 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 48th IETF, MMUSIC WG

6. 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 48th IETF, MMUSIC WG

7. 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? 48th IETF, MMUSIC WG

8. 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 48th IETF, MMUSIC WG

9. 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 48th IETF, MMUSIC WG

10. 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? 48th IETF, MMUSIC WG

11. 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? 48th IETF, MMUSIC WG

12. 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 48th IETF, MMUSIC WG

13. 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 48th IETF, MMUSIC WG

14. 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? 48th IETF, MMUSIC WG

15. 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 48th IETF, MMUSIC WG

16. 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? 48th IETF, MMUSIC WG

17. 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? 48th IETF, MMUSIC WG