SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0
CSeq: 1
Transport: RTP/AVP/UDP;unicast;client_port=3056-3057
但若是RTSP 使用 interleaved 的方式，則後續的RTP/RTCP則可以沿用已經建立的連線，不需要指定對應的埠號，另外建立連線，而是在原來的TCP連線之下，改成使用 channel id 來辨別封包內容為 RTP 或 RTCP，例如：
SETUP rtsp://video.foocorp.com:554/streams/example.rm RTSP/1.0
Cseq: 3
Transport: rtp/avp/tcp; interleaved=0-1
此表示 channel id 0 用來傳送 RTP，channel id 1 用來傳送 RTCP。
原文摘錄如下：
In certain scenarios, the best-effort, dynamic port methods of UDP-based RTP, as described previously, are not suitable. Some environments might consider the allocation of dynamic source and destination UDP ports through firewalls to be something they can live happily without. Moreover, just the nature of the Layer 1 and Layer 2 transport mechanisms underlying the data delivery might not be suited to nonguaranteed UDP traffic. In either instance, RTSP allows for the negotiation of theRTP delivery of the media data to be interleaved into the existing TCP connection.
When interleaving, the client-to-server SETUP command has the following format:
C->S SETUP rtsp://video.foocorp.com:554/streams/example.rm RTSP/1.0
Cseq: 3
Transport: rtp/avp/tcp; interleaved=0-1
The changeover in the preceding example is in the transport description. First, the transport mechanisms have changed to show that the RTP delivery must be over TCP rather than UDP. Second, the addition of the interleaved option shows that the RTP data should be interleaved and use channel identifiers 0 and 1—0 will be used for the RTP data and 1 will be used for the RTCPmessages. To confirm the transport setup, the server will respond with confirmation and a Session ID as before:
S->C RTSP/1.0 200 OK
Cseq: 3
Session: 12345678
Transport: rtp/ avp/tcp; interleaved=0-1
The RTP and RTCP data can now be transmitted over the existing RTSP TCP connection with the server using the 0 and 1 identifiers to represent the relevant channel.
One further delivery option for RTP and RTCP under RTSP is to wrap the delivery of all media streaming components inside traditional HTTP frame formats. This removes most barriers presented when using streaming media through firewalled environments, as even the most stringent administrator will typically allow HTTP traffic to traverse perimeter security. While HTTP and RTSPinterleaved delivery of the streamed media data will make the content available to the widest possible audience, when you consider the overhead of wrapping all RTP data inside either an existing TCP stream or, worse still, inside HTTP, it is the least efficient method for delivery. To enable the streaming media client browser to cope with the different options described previously, most offer the client users the ability to configure their preferred delivery mechanism or mechanisms, and the timeout that should be imposed in failing between them. What you will see from a client perspective is that the client application will first request that the stream be delivered using RTP inUDP, and if the stream does not arrive within x seconds (as it is potentially being blocked by an intermediate firewall), it will fail back to using RTP interleaved in the existing RTSP connection.
參考資料
