Subject: Re: [MMUSIC] Clarification of use and association of SSRCs in RTSP

From: Aravind Narasimhan <[email-masked]>
Date: Mon, 16 Jun 2003 14:57:33 -0400

I'm clarifying the edits I had proposed before the May 28th concall in 
the RTSP draft with regards to the SSRC field.  See inline for comments.

Aravind

Aravind Narasimhan wrote:

> Hi folks,
> This is two-fold attempt to clarify how ssrc's are dealt with in 
> RTSP.  First, is a clarification of the use of the ssrc fields in the 
> Transport header.  Next is a clarification of the association of 
> stream ssrcs with other stream information in the RTP-Info header. 

[snip]

> Reword To:
>     RTCP: Is used to report transport statistics and SHALL also work as
>          keep alive. The server can determine the client by used net-
>          work address and port together with the fact that the client
>          is reporting on the server's SSRC(s). The first source 
> being      |
>          reported on in a Reciever Report should be the SSRC of 
> the        |
>          server as established from the ssrc field of the 
> transport        |
>          header of the SETUP response.  A downside of using RTCP 
> is        |
>          that it gives lower statistical guarantees to reach 
> the           |
>          server.  However that probability is so little that it can be
>          ignored in most cases. For example, a session with 60 seconds
>          timeout and enough bitrate assigned to the RTCP messages, so
>          the client sends a message on average every 5 seconds.  That
>          session have for a network with 5 % packet loss the probabil-
>          ity to not get a liveness sign over to the server in the time-
>          out interval is 2.4*E-16. In sessions with shorter timeout
>          times, or much higher packet loss, or small RTCP bandwidths
>          SHOULD use any of the mechanisms below. 

In light of comments from the concall of May 28th, I am removing the 
edits made to the above paragraph.  The full body of edits made to the 
spec with regards to clarification of the use of SSRCs is included below:

Section 13.40, Page 79:

    ssrc: The ssrc parameter indicates the RTP SSRC [23] value that
         should be (request) or will be (response) used by the media
         server. This parameter is only valid for unicast transmission.
         It identifies the synchronization source to be associated with
         the media stream, and is expressed as an eight digit hexideci-
         mal value. In cases that a sender will use multiple SSRCs it
         SHOULD NOT use this parameter.

Reword To:

    ssrc: The ssrc parameter, if included in a SETUP 
response,             |
         indicates the RTP SSRC [23] value that will be used by 
the        |
         media server within the stream.  It is expressed as an 
eight      |
         digit hexadecimal value.  If the server does not act as a 
syn-    |
         chronization source for stream data (for instance, server is 
a    |
         translator or reflector, etc.) the value will be the 
"packet      |
         sender's SSRC" that would be used in the RTCP Receiver 
Reports    |
         generated by the server, regardless of whether the 
server         |
         actually generates RTCP RRs.  If there are mutiple 
sources        |
         within the stream, the ssrc parameter only indicates the 
value    |
         for a single sychronization source.  Other sources must 
be        |
         deduced from the actual RTP/RTCP 
stream.                          |
         The functionality of specifing the ssrc parameter in a 
SETUP      |
         request is deprecated as it is incompatible with the 
specifica-   |
         tion of RTP in RFC 1889.  If the parameter is included in 
the     |
         transport header of a SETUP request, the server may ignore 
the    |
         it, and choose an appropriate SSRC for the stream.  It MAY 
set    |
         the ssrc parameter in the transport header of the 
response.       |

Section 13.40, Page 79:

    client_ssrc: The client_ssrc parameter indicates the RTP SSRC [23]
         value that will be used by the client. This parameter is only
         valid for unicast transmission. It identifies the synchroniza-
         tion source to be associated with the media stream, and is
         expressed as an eight digit hexidecimal value. In cases that a
         client will use multiple SSRCs it SHOULD NOT use this parame-
         ter.

Reword To:

    client_ssrc:  The client_ssrc parameter, if included in a 
SETUP        |
         request, indicates the RTP SSRC [23] value that will be used 
by   |
         the client.  It is expressed as an eight digit 
hexadecimal        |
         value.  If the client does not act as a sychronization 
source     |
         for stream data (for instance, client is a player or proxy 
or     |
         intermediary, etc.) the value will be the "packet 
sender's        |
         SSRC" that would be used in the RTCP Receiver Reports 
generated   |
         by the client.  If there are mutiple sources within the 
stream,   |
         the client_ssrc parameter only indicates the value for a 
single   |
         sychronization source.  Other sources must be deduced from 
the    |
         actual RTP/RTCP 
stream.                                           |
         A server SHALL NOT specify the client_ssrc parameter in a 
SETUP   |
         response.

Section 13.33, Page 70

13.33 RTP-Info

  The RTP-Info response-header field is used to set RTP-specific param-
  eters in the PLAY response. For streams using RTP as transport proto-
  col the RTP-Info header SHALL be part of a 200 response to PLAY.

    url: Indicates the stream URL which for which the following RTP
         parameters correspond, this URL MUST be the same used in the
         SETUP request for this media stream. Any relative URL SHALL
         use the request URL as base URL.

    seq: Indicates the sequence number of the first packet of the
         stream. This allows clients to gracefully deal with packets
         when seeking. The client uses this value to differentiate
         packets that originated before the seek from packets that
         originated after the seek.

    rtptime: Indicates the RTP timestamp corresponding to the time
         value in the Range response header. (Note: For aggregate con-
         trol, a particular stream may not actually generate a packet
         for the Range time value returned or implied. Thus, there is
         no guarantee that the packet with the sequence number
         indicated by seq actually has the timestamp indicated by rtp-
         time.) The client uses this value to calculate the mapping of
         RTP time to NPT.

         A mapping from RTP timestamps to NTP timestamps (wall
         clock) is available via RTCP. However, this information
         is not sufficient to generate a mapping from RTP times-
         tamps to NPT. Furthermore, in order to ensure that this
         information is available at the necessary time (immedi-
         ately at startup or after a seek), and that it is deliv-
         ered reliably, this mapping is placed in the RTSP control
         channel.

         In order to compensate for drift for long, uninterrupted pre-
         sentations, RTSP clients should additionally map NPT to NTP,
         using initial RTCP sender reports to do the mapping, and later
         reports to check drift against the mapping.

Reword to:

13.33 RTP-Info

  The RTP-Info response-header field is used to set RTP-specific param-
  eters in the PLAY response. These parameters correspond to the 
syn-       |
  chronization source indentified by the 'ssrc' parameter of 
the            |
  Transport response header in the SETUP reponse.  For streams 
using        |
  RTP as transport protocol the RTP-Info header SHALL be part of a 
200      |
  response to 
PLAY.                                                         |  
    url: Indicates the stream URL which for which the following RTP
         parameters correspond, this URL MUST be the same used in the
         SETUP request for this media stream. Any relative URL SHALL
         use the request URL as base URL.

    seq: Indicates the sequence number of the first packet of the
         stream. This allows clients to gracefully deal with packets
         when seeking. The client uses this value to differentiate
         packets that originated before the seek from packets that
         originated after the seek.

    rtptime: Indicates the RTP timestamp corresponding to the time
         value in the Range response header. (Note: For aggregate con-
         trol, a particular stream may not actually generate a packet
         for the Range time value returned or implied. Thus, there is
         no guarantee that the packet with the sequence number
         indicated by seq actually has the timestamp indicated by rtp-
         time.) The client uses this value to calculate the mapping of
         RTP time to NPT.

         A mapping from RTP timestamps to NTP timestamps (wall
         clock) is available via RTCP. However, this information
         is not sufficient to generate a mapping from RTP times-
         tamps to NPT. Furthermore, in order to ensure that this
         information is available at the necessary time (immedi-
         ately at startup or after a seek), and that it is deliv-
         ered reliably, this mapping is placed in the RTSP control
         channel.

         In order to compensate for drift for long, uninterrupted pre-
         sentations, RTSP clients should additionally map NPT to NTP,
         using initial RTCP sender reports to do the mapping, and later
         reports to check drift against the mapping.

         Additionally, the RTP-Info header parameter fields only 
apply      |
         to a single SSRC within a stream (the SSRC reported in 
the         |
         transport response header; see 13.40).  If there are 
multiple      |
         synchronization sources present within a RTP session, RTCP 
must    |
         be used to map RTP and NTP timestamps for those sources, 
for       |
         both synchronization and 
drift-checking.                           |

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic