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

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 7 Oct 2011 15:25:36 -0700

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: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 19 Oct 2011 12:26:11 +0530

Hi Charles,

Sorry for delay in reviewing this. Here are my comments/questions on the
proposed text.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Charles Eckel (eckelcu)
> Sent: Saturday, October 08, 2011 3:56 AM
> To: [email-masked]
> Subject: [siprec] proposed text for dealing with packet loss
> 

Are you suggesting to replicate/fork the RTCP sender reports generated
by an UAs (which may not be SRC) in CS as is to SRS ? I wonder if that
is right since some of the fields may not be needed. For e.g. RTCP
sender report may have zero or more reception report blocks. This has
information about the number of other sources heard by this sender since
the last report. I guess this may not make sense to SRS.

Also in case of RTCP receiver report from SRS I see you mentioned that
SRC forwards to UA. what action do we want the UA to take ? Should we
leave it as a policy at the UA ? May be we need to add some text on
this. Note that the UA here may be receiving two receiver report ( one
from destination say UA2 who is in CS and other from SRS).

>    MUST be forwarded to the relevant UA.  

Why do we need to forward the RTCP reports from SRS back to UA here ? In
this case the SRC is acting as an endpoint terminating and
re-originating the media by doing transcoding. So the RTCP receiver
report are for the packets originated by the transcoder. 

The SRC may need to
> manipulate

Rest looks ok to me. In general we need some text on what UA/SRC MAY do
on receiving these reports. We can simply mention that based on policy a
UA/SRC may act on the reports.

Regards,
Ram

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

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 19 Oct 2011 10:36:45 -0700

Hi Ram,

Thanks for reviewing. Please see inline.

> From: Ram Mohan R (rmohanr)
> Sent: Tuesday, October 18, 2011 11:56 PM
> To: Charles Eckel (eckelcu); [email-masked]
> Subject: RE: [siprec] proposed text for dealing with packet loss
> 
> Hi Charles,
> 
> Sorry for delay in reviewing this. Here are my comments/questions on
the proposed text.
> Are you suggesting to replicate/fork the RTCP sender reports generated
by an UAs (which may not be
> SRC) in CS as is to SRS ?

Yes.

 I wonder if that is right since some of the fields may not be needed.
For
> e.g. RTCP sender report may have zero or more reception report blocks.
This has information about the
> number of other sources heard by this sender since the last report. I
guess this may not make sense to
> SRS.

True. If it is deemed important to do something more sophisticated, the
SRC implementer may want to consider acting as a mixer instead.

> Also in case of RTCP receiver report from SRS I see you mentioned that
SRC forwards to UA. what action
> do we want the UA to take ? Should we leave it as a policy at the UA ?
May be we need to add some text
> on this. Note that the UA here may be receiving two receiver report (
one from destination say UA2 who
> is in CS and other from SRS).

I was trying to avoid putting any requirements on the UA. Here as well,
I see it a reason for the SRC to consider acting as a mixer.
 
> >    transcoding (e.g., from one codec to another), and this may
result
> > in
> Why do we need to forward the RTCP reports from SRS back to UA here ?
In this case the SRC is acting
> as an endpoint terminating and re-originating the media by doing
transcoding. So the RTCP receiver
> report are for the packets originated by the transcoder.

The SRC is not originating packets in this case, it is simply altering
them as it they pass through it. What it needs to do is make sure that
it accounts for the changes in makes such that the RTCP information is
consistent with any changes it makes in the process. If the SRC wants to
originate packets, it should consider the endpoint model.

> Rest looks ok to me. In general we need some text on what UA/SRC MAY
do on receiving these reports. We
> can simply mention that based on policy a UA/SRC may act on the
reports.

What I was attempting to convey is that when acting as a translator, the
SRC does not really do anything based on the reports. Acting on the
reports is up to the UA. When acting as a mixer or endpoint, the SRC can
and should act upon the reports.
I can add something about the UA acting on them based on policy. This
would be true for all cases, independent of the RTP role used by the
SRC. I think that is not very useful and is outside of the
recommendations described here. Let me know if you still think adding it
to each case provides value, and if so, I can add it.

Cheers,
Charles

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Oct 2011 14:21:21 -0400

Looking at this discussion, I wonder if it ever makes sense for the SRC 
to act as a translator? It seems that doing so will result in presenting 
the CS participants with information that would be confusing to them. 
Perhaps the SRC should always be a mixer or endpoint.

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 24 Oct 2011 11:00:34 -0700

Hi Paul,

I essentially agree with your analysis and conclusion. The main reason I
see for discussing the translator models is to make people aware of the
limitations of those models such that they use them only in cases in
which they think those limitations will be acceptable. For example, if
the SRC is collocated with the UA, it may be acceptable to have the SRC
function an RTP translator. Or in an enterprise environment in which
there is a set of homogenous UAs, the SRC may be able to act as a
translator on behalf of a set of UAs that knows how to deal with the
resulting RTP flows.
While we could rule out, or not recommend, such models in general, I am
thinking it is best to describe them and let implementers make an
informed choice. But I am certainly open to other suggestions.

Cheers,
Charles 

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
> Sent: Wednesday, October 19, 2011 11:21 AM
> To: [email-masked]
> Subject: Re: [siprec] proposed text for dealing with packet loss
> 
> >>>     between the UAs and the SRS, such that the UAs and SRS are
able
> > to
> >>>     encryption may occur.  For example, if different keys are
used,
> > it
> >>>     If packet loss occurs, either from the UA to the SRC or from
the
> > SRC
> >>>     loss.  The SRC does not play a role in this other than
forwarding
> >>> the
> >>>     as separate streams from different sources (e.g., from
different
> > UAs
> >>>     between the UAs and the SRS, such the UAs and SRS they are
able
> > to
> >>>     the RTCP Receiver Reports to take account of any transcoding
that
> >>> has
> >>>     encryption may occur.  For example, if different keys are
used,
> > it
> >>>     If packet loss occurs, either from the UA to the SRC or from
the
> > SRC
> >>>     loss.  The SRC does not play a role in this other than
forwarding
> >>> the
> >>>     Optionally an SRC acting as a mixer can perform transcoding,
and
> > can
> >>>     use of SRTP between the SRC and the SRS for the RS is
independent
> > of
> >>>     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
> >>>     between the SRC and the SRS is considered completely
independent
> >>> from
> >>>     mix RTP streams from different participants prior to sending
to
> > the
> >>>     SRS.  RTCP between the SRC and the SRS is completely
independent
> > of
> >>>     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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Oct 2011 15:37:19 -0400

> informed choice. But I am certainly open to other suggestions.

I agree with your thinking here. I don't think we need to ban this - 
just making it clear what the implications are should be sufficient.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 Oct 2011 21:52:10 +0000

On Oct 19, 2011, at 2:21 PM, Paul Kyzivat wrote:

> Looking at this discussion, I wonder if it ever makes sense for the SRC to act as a translator? It seems that doing so will result in presenting the CS participants with information that would be confusing to them. Perhaps the SRC should always be a mixer or endpoint.
> 
> 	Thanks,
> 	Paul

There are some very real cost/scale benefits to acting as a forwarding-translator, and in practice it works fine today.  The SRC translator simply doesn't forward the SRS' RTCP reports onto the CS UAs, and they're never aware of the SRS' existence at an RTP/RTCP layer.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 Oct 2011 21:58:19 +0000

Hi Charles,
sorry for not responding sooner. :(
Comment below...

>   MUST be forwarded to the relevant UA.

Generally we only put "MUST" statements in RFCs if the protocol/mechanism would otherwise break or become insecure.

Can you explain what exactly "breaks" if the SRC doesn't forward on the RTCP reports from an SRS?  I know what breaks if a translator doesn't do so for multi-party calls, but this is not a true multi-party call.

-hadriel

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 25 Oct 2011 15:13:03 -0700

Please see inline.

> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: Tuesday, October 25, 2011 2:58 PM
> To: Charles Eckel (eckelcu)
> Cc: <[email-masked]>

No worries - better now than later, or never.

> Generally we only put "MUST" statements in RFCs if the
protocol/mechanism would otherwise break or
> become insecure.
> Can you explain what exactly "breaks" if the SRC doesn't forward on
the RTCP reports from an SRS?  I
> know what breaks if a translator doesn't do so for multi-party calls,
but this is not a true multi-
> party call.

If the SRC does not forward the RTCP reports from the SRS, the UA
either:
1) receives no RTCP reports, in the case where is the SRS is the only
recipient of the packets
2) receives RTCP reports from receivers other than the SRS receivers but
does not receive any reports from the SRS.

In case (1), the UA is not able to help in the recovery of media related
issues between the UA and the SRS.
In case (2), the UA may help in the recovery of media related issues
between the UA and SRC (assuming another recipient's reports indicated
the issue), but not those between the SRC and the SRS.

Cheers,
Charles

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Oct 2011 21:07:34 -0400

> There are some very real cost/scale benefits to acting as a forwarding-translator, and in practice it works fine today.  The SRC translator simply doesn't forward the SRS' RTCP reports onto the CS…

I'm a neophyte re RTP, so take what I say with a grain of salt...

IIUC, forwarding the RTCP is obligatory for a translator. If it doesn't 
do it, it isn't behaving as a translator. (A quick look at 3550 tells me 
the behavior is indeed MUST strength.)

While not conforming to that may "work" in some sense, I don't see how 
we can advocate that.

And I see that Charles already commented.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 26 Oct 2011 22:01:41 +0000

Howdy,
Sorry for the length of this email - it's a lot of text for a one-word change request. :)

> 1) receives no RTCP reports, in the case where is the SRS is the only

The _other_ UA in the CS is the receiver of RTP packets, and generates RTCP.  In other words, both real UAs in the CS generate RTCP which gets to each other.

Though of course there are UAs in the real-world which generate no RTCP to begin with, so in that case you wont get any - but that just provides examples that doing so doesn't necessarily break RTP, because calls work without the RTCP today.
(I should note I'm talking about audio, not video)

> the issue), but not those between the SRC and the SRS.

Right, so assume the following diagram:

 +--------+      +--------+      +--------+
 |        |  A   |        |  B   |        |
 |  UA-A  |------|  SRC   |------|  UA-B  |
 |        |      |        |      |        |
 +--------+      +--------+      +--------+
                     ||
                   C || D
                     ||
                 +--------+
                 |        |
                 |  SRS   |
                 |        |
                 +--------+

It is true that if C/D is congested, then for certain codecs the RTCP receiver reports can help improve the call quality to the SRS, but reduce the call quality for UA-A and UA-B.  Frankly I think this is a corner case in the real world, because I would expect people to (a) be able to control/manage the SRC-SRS path to not be congested, and (b) in some cases even prefer to keep the call quality of A-B regardless of the SRS's recording quality.  I recognize (b) is only for some folks and not others, but it is a real use-case, and one whereby forwarding on the RTCP reports would be a bad thing.

It's also true that if A is congested, then for certain codecs the SRS can help improve the call quality from UA-A to UA-B if UA-B does not itself generate RTCP reports; and vice-versa if B is congested, then for certain codecs the SRS can help improve the call quality from UA-B to UA-A if UA-A does not itself generate RTCP reports.

BUT for other codecs (like G.711 which I believe is popular), such RTCP receiver reports will not improve quality, because there isn't much you can do to improve it in the send direction.  (and frankly if both UA-A and UA-B support dynamic codecs, then the odds are they both support RTCP)

So... since (1) there's a use-case where forwarding the RTCP reports from SRS is not what the customer wants, and (2) there're popular codecs which don't improve with it regardless, I propose we change this:

> RTCP Receiver Reports generated by the SRS

To this:
> RTCP Receiver Reports generated by the SRS
>  SHOULD be forwarded to the relevant UA.

-hadriel

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 27 Oct 2011 11:45:31 -0700

Please see additional inline comments.

> Sent: Wednesday, October 26, 2011 3:02 PM
> The _other_ UA in the CS is the receiver of RTP packets, and generates
RTCP.  In other words, both
> real UAs in the CS generate RTCP which gets to each other.
> 
> Though of course there are UAs in the real-world which generate no
RTCP to begin with, so in that case
> you wont get any - but that just provides examples that doing so
doesn't necessarily break RTP,
> because calls work without the RTCP today.

Okay, so we could call out that special case. However, since having the
SRC forward the RTCP packets is required in the case of video, and
should only help in the case of audio, the MUST seems appropriate and
more straightforward to me. The UA receiving the multiple sets of RTCP
receiver reports should at worst ignore the ones from the SRS, right?

> It is true that if C/D is congested, then for certain codecs the RTCP
receiver reports can help
> improve the call quality to the SRS, but reduce the call quality for
UA-A and UA-B. 

I may be missing something here because I do not see how the RTCP
receiver reports from the SRS would reduce the call quality of UA-A and
UA-B. Is it because the recovery attempts by UA-A targeted for the SRS
would waste bandwidth on the path to UA-B?

> Frankly I think
> this is a corner case in the real world, because I would expect people
to (a) be able to
> control/manage the SRC-SRS path to not be congested, and (b) in some
cases even prefer to keep the
> call quality of A-B regardless of the SRS's recording quality.  I
recognize (b) is only for some folks
> and not others, but it is a real use-case, and one whereby forwarding
on the RTCP reports would be a
> bad thing.
> 
> It's also true that if A is congested, then for certain codecs the SRS
can help improve the call
> quality from UA-A to UA-B if UA-B does not itself generate RTCP
reports; and vice-versa if B is
> congested, then for certain codecs the SRS can help improve the call
quality from UA-B to UA-A if UA-A
> does not itself generate RTCP reports.
> 
> BUT for other codecs (like G.711 which I believe is popular), such
RTCP receiver reports will not
> improve quality, because there isn't much you can do to improve it in
the send direction.  (and
> frankly if both UA-A and UA-B support dynamic codecs, then the odds
are they both support RTCP)

Here as well, it may be that the RTCP reports from the SRS do not help,
but they should not hurt either.

> So... since (1) there's a use-case where forwarding the RTCP reports
from SRS is not what the customer
> wants, and (2) there're popular codecs which don't improve with it
regardless, I propose we change
> this:

I do not think changing this one word is an option. If we want to
downgrade this MUST to a SHOULD, we need to provide some justification.
The only justification I see so far is that forwarding the RTCP packets
may cause problems for "badly" broken UAs, where a "somewhat" broken UA
ignores RTCP receiver reports, and a "badly" broken UA chokes on rather
than ignores unexpected RTCP receiver reports. 
What if instead, I follow the suggestion Ram and John made that I add
some text with a bit more discussion on the implications of using either
of the translator models on the participating UAs, such as:

----------------------

   In such cases, UAs may receive multiple sets of RTCP Receiver
Reports, one or more from other UAs participating in the CS, and one
from the SRS participating in the RS. A SIPREC aware UA SHOULD be
prepared to process the RTCP Receiver Reports from the SRS, whereas a
SIPREC unaware UA may discard such RTCP packets as not of relevance.

--------------------------

If this is acceptable, I will update the Transcoding Translator section
similarly.

Cheers,
Charles

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Oct 2011 21:22:02 +0000

Hi Charles,
comments inline...

> receiver reports should at worst ignore the ones from the SRS, right?

Call what out as a special case?  The case of audio being used?
I'm not even convinced the SRC has to forward RTCP from the SRS for video, but that probably depends on the SRS' design and use-case. (i.e., I know of one which doesn't apparently send RTCP from itself to the two real UA's even for video, but I don't know if that's because of something special they do or what)

> would waste bandwidth on the path to UA-B?

If a dynamic audio codec is used - i.e., an audio codec which can adapt itself to compress-more/use-less-bandwidth, which is basically the only thing any audio codec does to improve things based on RTCP Receive Reports, afaict - then if the SRS tells UA-A it's getting packet loss, UA-A's dynamic codec will adapt to trade off quality vs. bandwidth.  This means the audio-quality of the UA-A to UA-B call degrades.

For some customer use-cases that's appropriate - what they want.
For some customer use-cases that's inappropriate - not what they want.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Oct 2011 21:51:36 +0000

> than ignores unexpected RTCP receiver reports. 

Yes, I would expect that to be the case as well.  I'm not sure I consider it a valid reason for an RFC, though.
But I think I've given a valid use-case for not doing it - namely not to impact the two real UA's call-quality no matter what the SRS is experiencing.

With regard to your proposed text, can we really make mandates for the real UA's, from a practical perspective?  And if we can, why would we make it a SHOULD not a MUST, since they won't know what type of SRC/SRS' they're talking through?

How about this instead:

----------------------

  forwarded to the SRS.  

  Per [RFC3550] RTCP Receiver Reports generated by the SRS
  MUST be forwarded to the relevant UA by default. The SRC MAY choose 
  to not forward RTCP Reports from the SRS to the UAs based on local 
  policy, however, since doing so may impact the audio-quality
  between the UAs for dynamic audio codecs.

  UAs may receive multiple sets of RTCP Receiver Reports, one or more 
  from other UAs participating in the CS, and one from the SRS 
  participating in the RS. A SIPREC aware UA MUST be prepared to 
  process the RTCP Receiver Reports from the SRS.

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 28 Oct 2011 15:00:52 -0700

Hi Hadriel,

I can live with that. Thanks for the suggested wording.
If anyone has anything else to add, please let me know asap, otherwise I
will submit the updated draft based on this wording.

Cheers,
Charles 

> Sent: Friday, October 28, 2011 2:52 PM
> Yes, I would expect that to be the case as well.  I'm not sure I
consider it a valid reason for an
> RFC, though.
> But I think I've given a valid use-case for not doing it - namely not
to impact the two real UA's
> call-quality no matter what the SRS is experiencing.
> 
> With regard to your proposed text, can we really make mandates for the
real UA's, from a practical
> perspective?  And if we can, why would we make it a SHOULD not a MUST,
since they won't know what type
> of SRC/SRS' they're talking through?
> 
> How about this instead:
> 
> ----------------------

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Oct 2011 18:53:33 -0400

> Call what out as a special case?  The case of audio being used?

I assumed that the special case was when RTCP wasn't being used on the CS.

> I'm not even convinced the SRC has to forward RTCP from the SRS for video, but that probably depends on the SRS' design and use-case. (i.e., I know of one which doesn't apparently send RTCP from it…

By "has to" do you mean what it must do so that things seem to work?
Or do you mean what it is required to do to conform to the requirements 
of a translator?

ISTM that we should expect that the SRC conforms to whatever RTP role it 
is following. If none of the defined ones is suitable, then maybe there 
should be another one. (But that will be hard.)

> For some customer use-cases that's inappropriate - not what they want.

Then perhaps in the first case the SRC can be a translator, but in the 
other case it will have to function as a (back-to-back) endpoint.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Oct 2011 19:02:36 -0400

> will submit the updated draft based on this wording.

I just replied to an earlier message on this.
I am quite sure we cannot give dispensation to violate a MUST condition 
in another RFC. That in effect is a revision of that RFC.

When AVT reviews this (as they will) they will burst into flames.

	Thanks,
	Paul

>> Cc:<[email-masked]>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Oct 2011 23:44:50 +0000

On Oct 28, 2011, at 7:02 PM, Paul Kyzivat wrote:

> I am quite sure we cannot give dispensation to violate a MUST condition in another RFC. That in effect is a revision of that RFC.

Yeah, you're probably right.  
Of course RFC 3550 Translator model never had an SRS model in mind ether, but I suppose we shouldn't open that can of worms.

On the other hand, if we're going to play the RFC-says-so card, why are we putting this MUST statement in at all?
Why aren't we just saying "the Translator MUST follow [RFC 3550]", period. ?
That way if, at some future time, there's an update or extension to RFC 3550 that affects the RTCP-forwarding behavior, then the update doesn't need to also update this SIPREC doc?

> When AVT reviews this (as they will) they will burst into flames.

Hmmm... maybe we *should* do it then - I'll bring the marshmallows.
;)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 29 Oct 2011 00:11:22 +0000

On Oct 28, 2011, at 6:53 PM, Paul Kyzivat wrote:

> Or do you mean what it is required to do to conform to the requirements of a translator?

I mean has to to make things work.  Of course it is has to to claim compliance with the RFC, but that RFC was written under the assumption that all RTP agents are active RTP endpoints in the RTP session.  That isn't always the case in call-recording, in practice.  Heck, some people just mirror the RTP packets and use the logical equivalent of wireshark to "record" it... and it works for them.

> Then perhaps in the first case the SRC can be a translator, but in the other case it will have to function as a (back-to-back) endpoint.

Sigh. Yes, from an RFC perspective that's probably what will have to be claimed.

For example my company makes an SRC, and though we offer transcoding it's not free, so instead as a Translator we may decide to forward the RTCP from the SRS by default just so we can claim compliance with this SIPREC doc... but in practice we'll probably tell people to disable that forwarding in order to make things truly work.  I was trying to get the MUST statement removed from this SIPREC spec because (1) I don't think it will actually break anything, (2) will likely make things better not to forward them, and (3) don't like to see misleading MUST statements.

I'm ok with keeping it though because you're right it will never pass AVT review.

And it actually occurs to me as an _SBC_ we can claim the SRC is a logically separate internal function that does indeed forward RTCP packets from the SRS, but the SBC simply discards them as a B2BUA, to make things work.  So we can be RFC compliant but still ignore the MUST.  It's good to be a B2BUA.
:)

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 29 Oct 2011 00:15:12 -0400

> That way if, at some future time, there's an update or extension to RFC 3550 that affects the RTCP-forwarding behavior, then the update doesn't need to also update this SIPREC doc?

I agree, at least regarding normative statements.
But it is helpful to spell out the implications of those requirements in 
the specific context of our usage.

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 31 Oct 2011 08:15:45 -0700

To summarize, I will keep the MUST in regard to forwarding the RTCP
packets, as well as the text describing the implications on the UA.

Cheers,
Charles

Behalf Of Paul Kyzivat
> Sent: Friday, October 28, 2011 9:15 PM
> To: Hadriel Kaplan
> Cc: <[email-masked]>
> >> I am quite sure we cannot give dispensation to violate a MUST
condition in another RFC. That in
> effect is a revision of that RFC.
> >
> > Of course RFC 3550 Translator model never had an SRS model in mind
ether, but I suppose we shouldn't
> open that can of worms.
> >
> > On the other hand, if we're going to play the RFC-says-so card, why
are we putting this MUST
> statement in at all?
> > That way if, at some future time, there's an update or extension to
RFC 3550 that affects the RTCP-
> forwarding behavior, then the update doesn't need to also update this
SIPREC doc?