Subject: [siprec] Draft RTP Model text for the SIPREC Architecture draft.

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 5 May 2011 16:10:56 +0200

Hi All,

I propose the following text describing the different RTP models for the next update to the architecture draft please let me have any comments.

3.x RTP Model
An SRC has the task of gathering RTP media from the various participants in a CS and forwarding the information to the SRS in the context of the RS. For a given media stream the SRC has a number of ways of doing this and may choose different ways for different media streams.

3.x.1 SRC acting as an RTP Translator.

The SRC may act as a translator, as defined in [RFC3550]. In this case, the SRC forwards RTP packets to the SRS with their synchronization source identifier unchanged. Optionally an SRC acting as a translator can  perform transcoding (from one codec to another), and this can result in a different rate of packets. With this approach, RTP from different sources (i.e., from different participants) cannot be mixed by the SRC and must be sent separately to the SRS. In this case all RTCP reports are passed on by the SRC to the participants which will be able to detect any SSRC collisions.

RTCP packets Sender Reports will generated by a participant sending a stream and will need to be forwarded to the SRS (in addition to being sent to receiving participants). RTCP Receiver Reports will be generated by the SRS and need to be forwarded to the relevant participant, the SRC in the case may need to manipulate the RTCP Receiver Reports to take account of any transcoding that has taken place. 

OPEN ISSUE. With this approach, can SRTP be used? Can SRTP be used on the CS and not on the RS and vice versa? If SRTP is used on both the CS and the RS, can decryption and re-encryption occur and/or can decryption and re-encryption be avoided (clearly not when transcoding is involved or if different keys are to be used? 

3.x.2 SRC acting as an RTP Mixer.

In the case of the SRC acting as a RTP mixer. as defined in [RFC3550], the SRC combines RTP streams from different participants and sends them towards the SRS using its own synchronization source identifier. It will make timing adjustments among the received streams and generate its own timing on the stream sent to the SRS. Optionally an SRC acting as a mixer can perform transcoding, and can even cope with different codings received from different participants. RTCP Sender Reports and Receiver Reports are not forwarded by an SRC acting as mixer, but there are requirements for forwarding RTCP Source Description (SDES) packets. The use of SRTP between the SRC and the SRS is independent of the use of SRTP on the CS.

3.x.3 SRC acting as an RTP Endpoint.

The case of the SRC acting as an RTP endpoint, as defined in [RFC3550], is similar to the mixer case, except that the RTP session between the SRC and the SRS is considered completely independent from the RTP session that is part of the CS. The SRC can, but need not, mix RTP streams from different participants prior to sending to the SRS. RTCP between the SRC and the SRS is completely independent of RTCP on the CS. The use of SRTP between the SRC and the SRS is independent of the use of SRTP on the CS.

Regards
Andy