Subject: [siprec] Questions/comments on draft-eckel-siprec-rtp-rec-01

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 26 Jul 2011 11:33:31 -0400

Howdy,
I read the draft and I have some comments/questions:
1) Why is feedback-based RTP recommended? (i.e., AVPF or SAVPF)  Not only is it fairly rare in usage, but I don't know how an SRC in translator mode could possibly do it for the RS, since it has no control over the RTP from the CS. (I'm not even exactly sure how an SRC in mixer mode would do it, but I suppose it might be possible)  In fact, I'd go so far as to ask the AVTCORE group what doing AVPF on an SRC would entail, if the CS is plain AVP.

2) Section 4.1 on translator mode says:
    "RTCP Receiver Reports generated by the SRS need to be forwarded to the relevant UA."
I'm not so sure that's a good idea.  For one, I shudder to think what the legacy VoIP devices out there will do if they start receiving RTCP-RR's from multiple sources (since there could be one from the real UAS and another one from the SRS).  Second, there are lots of middleboxes/sniffers which monitor the RTCP Receiver Reports to calculate latency, and the SRS sending it will screw them up.  

3) Section 13 only "recommends" symmetric RTP.  Is there some reason not to make it mandatory?  Things sometimes break in the real world if it's not symmetric, and I don't see any reason for it not to be mandated.

-hadriel

---

From: Leon Portman <[email-masked]>
Date: Tue, 26 Jul 2011 19:41:20 +0300

I agree with Hadriel points below.

Leon

On Jul 26, 2011, at 6:33 PM, Hadriel Kaplan <[email-masked]> wrote:

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

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 26 Jul 2011 09:51:19 -0700

Hi Hadriel,

Please see inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hadriel Kaplan
> Sent: Tuesday, July 26, 2011 11:34 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [siprec] Questions/comments on draft-eckel-siprec-rtp-rec-01
> 
> Howdy,
> 1) Why is feedback-based RTP recommended? (i.e., AVPF or SAVPF)  Not
only is it fairly rare in usage,
> but I don't know how an SRC in translator mode could possibly do it
for the RS, since it has no
> control over the RTP from the CS. (I'm not even exactly sure how an
SRC in mixer mode would do it, but
> I suppose it might be possible)  In fact, I'd go so far as to ask the
AVTCORE group what doing AVPF on
> an SRC would entail, if the CS is plain AVP.

The most basic thing the SRS would request from the SRC is a fast
picture update via RTCP feedback as defined in RFC 5104 FIR. Others
described in later sections of the draft, such as tmmbr, would be useful
as well. In some case, the SRC may not able to generate these on its own
and may need to relay the request to the CS participants.

> I'm not so sure that's a good idea.  For one, I shudder to think what
the legacy VoIP devices out
> there will do if they start receiving RTCP-RR's from multiple sources
(since there could be one from
> the real UAS and another one from the SRS).  Second, there are lots of
middleboxes/sniffers which
> monitor the RTCP Receiver Reports to calculate latency, and the SRS
sending it will screw them up.

Good point. This section is probably overly simplistic at best. Let me
see if I can rework it.

> 3) Section 13 only "recommends" symmetric RTP.  Is there some reason
not to make it mandatory?  Things
> sometimes break in the real world if it's not symmetric, and I don't
see any reason for it not to be
> mandated.

Works for me. I tried to avoid using the word must in this draft,
thinking that what eventually gets incorporated into the protocol draft
might add some musts. If people prefer to identify musts in this draft,
we can go that way as well.

Cheers,
Charles

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 27 Jul 2011 21:41:48 +0200

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
> Sent: 26 July 2011 17:51
> To: Hadriel Kaplan; [email-masked]
> Subject: Re: [siprec] Questions/comments on 
> draft-eckel-siprec-rtp-rec-01
> 
> Hi Hadriel,
> 
> Please see inline.
> 
[JRE] since we want to have text in this draft that can be merged into the protocol draft, with a view to adopting the result as a WG document, I think it would be helpful to use RFC 2119 language where appropriate.

John

John Elwell
Tel: +44 1908 817801 (office and mobile)
Email: [email-masked]
http://www.siemens-enterprise.com/uk/

Siemens Enterprise Communications Limited.
Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
Registered No: 5903714, England.

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 27 Jul 2011 21:44:41 +0200

We certainly need a solution to FIR for video. It seems to me there are only two possibilities (depending to some extent on RTP model):
A) The SRC caches sufficient information to allow it to do an FIR when requested by the SRS.
B) The SRC forwards the FIR request to the CS UA.

John (as individual)

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 27 Jul 2011 14:55:56 -0700

Okay. I will update the draft to use RFC 2119 language as deemed
appropriate for inclusion within the protocol draft.

Cheers,
Charles

> From: Elwell, John [mailto:[email-masked]]
> Sent: Wednesday, July 27, 2011 3:42 PM
> To: Charles Eckel (eckelcu); Hadriel Kaplan; [email-masked]
> Subject: RE: [siprec] Questions/comments on
> > >     "RTCP Receiver Reports generated by the SRS need to be
forwarded
> > to the relevant UA."
> [JRE] since we want to have text in this draft that can be merged into
the protocol draft, with a view
> to adopting the result as a WG document, I think it would be helpful
to use RFC 2119 language where
> appropriate.

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 27 Jul 2011 14:57:00 -0700

Agreed. I will have a slide on FIR/PLI and we can discuss the details at
that time.

Cheers,
Charles

> Sent: Wednesday, July 27, 2011 3:45 PM
> Subject: FIR
> We certainly need a solution to FIR for video. It seems to me there
are only two possibilities
> (depending to some extent on RTP model):