Subject: Re: [siprec] proposed text for dealing with packet loss

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 14 Oct 2011 10:22:01 -0700

So far I have not received any comments in this text, good, bad, or
otherwise. As such, I plan  to incorporate it as is in the next version
of the RTP recommendations draft.
If you planned to comment but just need more time, let me know asap.

Cheers,
Charles

> -----Original Message-----
> From: Charles Eckel (eckelcu)
> Sent: Friday, October 07, 2011 3:26 PM
> To: [email-masked]
> Subject: proposed text for dealing with packet loss
> 
> During the last interim meeting, I accepted an action item to propose
some text for draft-eckel-
> siprec-rtp-rec regarding SRC handling of packet loss. Here is text for
the various RTP models with the
> proposed text added (look for "If packet loss occurs" within each
model):
> 
> ----------------
> 
> 4.1.  SRC acting as an RTP Translator
> 
>    The SRC may act as a translator, as defined in [RFC3550].  A
defining
>    characteristic of a translator is that it forwards RTP packets with
>    their SSRC identifier intact.  There are two types of translators,
>    one that simply forwards, and another that performs transcoding
>    (e.g., from one codec to another) in addition to forwarding.
> 
> 4.1.1.  Forwarding Translator
> 
>    When acting as a forwarding translator, RTP received as separate
>    streams from different sources (e.g., from different UAs with
>    different SSRCs) cannot be mixed by the SRC and MUST be sent
>    separately to the SRS.  All RTCP reports MUST be passed by the SRC
>    between the UAs and the SRS, such that the UAs and SRS are able to
>    detect any SSRC collisions.
> 
>    RTCP Sender Reports generated by a UA sending a stream MUST be
>    forwarded to the SRS.  RTCP Receiver Reports generated by the SRS
>    MUST be forwarded to the relevant UA.
> 
>    If SRTP is used on both the CS and the RS, decryption and/or re-
>    encryption may occur.  For example, if different keys are used, it
>    will occur.  If the same keys are used, it need not occur.
> 
>    If packet loss occurs, either from the UA to the SRC or from the
SRC
>    to the SRS, the SRS SHOULD detect and attempt to recover from the
>    loss.  The SRC does not play a role in this other than forwarding
the
>    associated RTP and RTCP packets.
> 
> 4.1.2.  Transcoding Translator
> 
>    When acting as a transcoding translator, an SRC MAY perform
>    transcoding (e.g., from one codec to another), and this may result
in
>    a different rate of packets between what the SRC receives and what
>    the sends.  As when acting as a forwarding translator, RTP received
>    as separate streams from different sources (e.g., from different
UAs
>    with different SSRCs) cannot be mixed by the SRC and MUST be sent
>    separately to the SRS.  All RTCP reports MUST passed by the SRC
>    between the UAs and the SRS, such the UAs and SRS they are able to
>    detect any SSRC collisions.
> 
>    RTCP Sender Reports generated by a UA sending a stream MUST be
>    forwarded to the SRS.  RTCP Receiver Reports generated by the SRS
>    MUST be forwarded to the relevant UA.  The SRC may need to
manipulate
>    the RTCP Receiver Reports to take account of any transcoding that
has
>    taken place.
> 
>    If SRTP is used on both the CS and the RS, decryption and/or re-
>    encryption may occur.  For example, if different keys are used, it
>    will occur.  If the same keys are used, it need not occur.
> 
>    If packet loss occurs, either from the UA to the SRC or from the
SRC
>    to the SRS, the SRS SHOULD detect and attempt to recover from the
>    loss.  The SRC does not play a role in this other than forwarding
the
>    associated RTP and RTCP packets.
> 
> 4.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 UA and sends
>    them towards the SRS using its own SSRC.  The SSRCs from the
>    contributing UA SHOULD be conveyed as CSRCs identifiers within this
>    stream.  The SRC may 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 UAs.  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 SRC generates its own RTCP
>    Sender and Receiver reports toward the associated UAs and SRS.  The
>    use of SRTP between the SRC and the SRS for the RS is independent
of
>    the use of SRTP between the UAs and SRC for the CS.
> 
>    If packet loss occurs from the UA to the SRC, the SRC SHOULD detect
>    and attempt to recover from the loss.  If packet loss occurs from
the
>    SRC to the SRS, the SRS SHOULD detect and attempt to recover from
the
>    loss.
> 
> 4.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.
> 
>    If packet loss occurs from the UA to the SRC, the SRC SHOULD detect
>    and attempt to recover from the loss.  If packet loss occurs from
the
>    SRC to the SRS, the SRS SHOULD detect and attempt to recover from
the
>    loss.
> ------------------
> 
> Comment on this are greatly appreciated.
> Thanks,
> Charles

---

From: "John Elwell" <[email-masked]>
Date: Thu, 27 Oct 2011 09:42:41 +0100

Sorry I am late, but the text looks good to me. Perhaps we also need some 
text somewhere with a bit more discussion on the implications of using 
either of the translator models. Essentially a UA participating in a CS 
should not need to do anything special at the RTP/RTCP level to accommodate 
the fact that there is a an SRC somewhere on the path. With the endpoint and 
mixer models this is hidden, but with the translator models it is not 
hidden. I would hope that a SIPREC-unaware UA would not break as a result of 
a translator model being used, but would not be required to do anything 
special other than silently discard RTCP information that is not of 
relevance.

John

----- Original Message ----- 
From: "Charles Eckel (eckelcu)" <[email-masked]>
To: <[email-masked]>
Sent: Friday, October 14, 2011 6:22 PM
Subject: Re: [siprec] proposed text for dealing with packet loss

> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec