Subject: [AVTCORE] Request to review a SIPREC draft related to RTP

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 23 Jul 2011 12:51:38 -0400

Folks,

the SIPREC WG is working on a description about how RTP will be used in
SIPREC environments. We would like to get someone from AVTCORE to have a
look at the document to make sure it is OK from an RTP architecture
perspective.

http://tools.ietf.org/html/draft-eckel-siprec-rtp-rec-01

Thanks,

Gonzalo

---

From: Qin Wu <[email-masked]>
Date: Sat, 23 Jul 2011 19:27:23 +0000

Hi,
I have read this draft and seems interesting and on the right track, However I have some comments below:
1. According to figure 1, the CS(Communication Session) is running between UA and SRS. However according to 
draft-ietf-siprec-architecture, CS is running between two UAs. So it seems there is a little inconsistency 
with this. Does it indicate SRS should be sitting at the UA? How to deal with the case where the SRS is sitting
between two UA, in this case, CS is just forwarded by SRS.
2.In section 9, it said:
"   A mixer sends one SDES packet containing a
   chunk for each contributing source from which it is receiving SDES
   information, or multiple complete SDES packets.
"
So the question is in which case,the Mixer should send multiple complete SDES packets instead of sending only on SDES packet containing all
SDES information?
3. In section 12.1.1, in which circumstance the xml schema for video fast update will be used instead of RTCP feedback method?
4. In section 12.2, why Using the FIR command to recover from errors is explicitly
   disallowed, instead, using PLI?

Regards!
-Qin
________________________________________
发件人: [email-masked] [[email-masked]] 代表 Gonzalo Camarillo [[email-masked]]
发送时间: 2011年7月24日 0:51
到: [email-masked]
主题: [AVTCORE] Request to review a SIPREC draft related to RTP

Folks,

Thanks,

Gonzalo
_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Roni Even <[email-masked]>
Date: Sun, 24 Jul 2011 14:30:43 +0300

Hi,
If you review this work please respond to [email-masked] and not avtcore list

Roni Even
AVTcore  co-chair

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Gonzalo Camarillo
> Sent: Saturday, July 23, 2011 7:52 PM
> To: [email-masked]
> Subject: [AVTCORE] Request to review a SIPREC draft related to RTP
> 
> Folks,
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Sun, 24 Jul 2011 11:28:42 -0700

Hi Qin,

Thank you for reviewing the draft and providing comments. Please see inline for my responses.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wu
> Sent: Saturday, July 23, 2011 12:27 PM
> To: Gonzalo Camarillo; [email-masked]
> Subject: [AVTCORE] 答复: Request to review a SIPREC draft related to RTP
> 
> Hi,

You are correct. In this case, the SRC is acting as the other UA within the CS. This is similar to Figure 2 of draft-ietf-siprec-architecture. The case you mention is similar to Figure 1 of draft-ietf-siprec-architecture. This draft is meant to apply to both cases. Do you think it would be help if I added another diagram and additional descriptions regarding this?

> So the question is in which case,the Mixer should send multiple complete SDES packets instead of
> sending only on SDES packet containing all
> SDES information?

My understanding is that this is up to implementation of the mixer. As such, an SRC needs to be able to handle both cases when dealing with a CS involving a mixer. Similarly, a SRC may act as a mixer toward the SRS, so the SRS needs to be able to handle both cases as well.
Let me know if that addresses your concern, and if so, I will add it as clarification.

> 3. In section 12.1.1, in which circumstance the xml schema for video fast update will be used instead

Its use is discouraged; however, it is mentioned here such that an SRC/SRS is aware of it and able to send/receive it when necessary. For example, if I UA does not support RTCP feedback, a SRC may want to use SIP INFO.
Let me know if that addresses your concern, and if so, I will add it as clarification.
 
>    disallowed, instead, using PLI?

I am merely restating the restrictions specified in RFC 5104 in order to highlight them. My intention is not to add any additional restrictions that are SIPREC specific.

Cheers,
Charles