Subject: Re: [siprec] [AVTCORE] 答复: Request to review a SIPREC draft related to RTP

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

Hi,
This is a feedback from Qin, it was sent to avtcore list
Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Qin Wu
> Sent: Saturday, July 23, 2011 10:27 PM
> To: Gonzalo Camarillo; [email-masked]
> Subject: [AVTCORE] 答复: Request to review a SIPREC draft related to
> RTP
> 
> 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,
> 
> 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
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
> _______________________________________________
> 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:29:06 +0300

Hi,
I reviewed the draft and I have some questions about it.

1. Figure 1 does not show the media receiving UA just the sender.  For
translator  the RTCP RR from the SRS and the receiving UA may show different
losses and may cause changes in the media flow from the sender UA, some are
caused by the leg to the SRS. It looks to me that adding the SRC and SRS may
affect the regular call, is this discussed some place. For example, what
should the SRC do in packet loss cases or specific RTCP feedback requests
from the SRS like TMMBR. 

2. I can see the SRC as a RTP translator I am not sure when is it a RTP
mixer. How does the implementer decide which topology to use?

3. In section 6 you discuss the RTP profile to use. If the SRC is a
translator it will use the same RTP profile for the leg to SRS as the one
from UA to SRC. Even for the RTP mixer case if used, why do you need a
different profile for the leg from SRC to SRS.

4. This was asked by Qin but I repeat it. In section 12.1.1 you say use FIR
instead and in section 12.2 you disallow FIR. Why?

5. For the packet los, the question is where is the loss. In the translator
case, if it is between the sending UA and the SRC, both receiving UA and SRS
will notice the loss and can ask for FIR. If it is on one of the legs from
the SRC (to SRS or receive UA each can send a FIR), why disallow it.

6. I am missing discussion on SRTP case. Is the SRC a trusted entity, how
are you going to address the key exchange. I assume that some of it is
discussed in the other documents but in terms of this draft, how does it
affect the RTP flow for the translator or mixer cases, is it the same?

Regards
Roni Even

> 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:35:23 -0700

I responded to Qin on the avtcore list. I did not cross post to this alias as I was not sure if it was appropriate to do so.

Cheers,
Charles

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
> Sent: Sunday, July 24, 2011 4:11 AM
> To: [email-masked]
> Cc: 'Qin Wu'
> Subject: Re: [siprec][AVTCORE] 答复: Request to review a SIPREC draft related to RTP
> 
> Hi,
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: "Roni Even" <[email-masked]>
Date: Sun, 24 Jul 2011 21:37:54 +0300

Charles,
The request was to post only to siprec
Roni

> From: Charles Eckel (eckelcu) [mailto:[email-masked]]
> Sent: Sunday, July 24, 2011 9:35 PM
> To: Roni Even; [email-masked]
> Cc: Qin Wu
> Subject: RE: [siprec][AVTCORE] 答复: Request to review a SIPREC draft
> related to RTP
> 
> I responded to Qin on the avtcore list. I did not cross post to this
> alias as I was not sure if it was appropriate to do so.
> 
> Cheers,
> Charles
>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 25 Jul 2011 13:39:49 +0200

Responding just to a couple of points: 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Roni Even
> Sent: 24 July 2011 12:29
> To: [email-masked]
> Cc: 'Magnus Westerlund'
> Subject: Re: [siprec] [AVTCORE] Request to review a SIPREC 
> draft related to RTP
> 
> Hi,
[JRE] If the SRS doesn't support the same profile that the UAs in the Communication Session are using.

> affect the RTP flow for the translator or mixer cases, is it the same?
[JRE] Yes, that is correct. If the SRC is located at the Communication Session endpoint (UA), this is not a problem. If it is located at a B2BUA, the B2BUA would need to negotiate SRTP separately with the two UAs in the Communication Session as well as with the SRS. The only case where you might avoid this if the SRC forwards RTP packets unchanged, but then the SRS would need to be part of key negotiation, or would at least need to know the keys. This would have different security properties - for example it might require new keys to be generated on the Communication Session whenever there is a period when the session is not being recorded, so that the SRS cannot tap into that part of the session.

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: Qin Wu <[email-masked]>
Date: Mon, 25 Jul 2011 17:34:22 +0000

Hi, 
Sorry for late reply on this list.
________________________________________
发件人: Charles Eckel (eckelcu) [[email-masked]]
发送时间: 2011年7月25日 2:28
到: Qin Wu; Gonzalo Camarillo; [email-masked]
主题: RE: [AVTCORE] 答复:  Request to review a SIPREC draft related to RTP

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
> Subject: [AVTCORE] 答复: Request to review a SIPREC draft related to RTP
>
> 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

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?

[Qin]:Yes, it could be applied to both case. So it make sense to be clearly in this document to distinguish between each other.

> 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.

[Qin]: Yes, it partly address my concern. What I really want to say here is if you can carry SDES item in one SES packet, why you need to send each SDES item in multiple SDES packet? So you need a good reason to say why multiple SDES packets is needed.

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

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.

[Qin]: Yes, this does make sense.

> 4. In section 12.2, why Using the FIR command to recover from errors is explicitly

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.

[Qin]: Okay.

Cheers,
Charles

> 发件人: [email-masked] [[email-masked]] 代表 Gonzalo Camarillo
> [[email-masked]]
> 发送时间: 2011年7月24日 0:51
> 到: [email-masked]
> SIPREC environments. We would like to get someone from AVTCORE to have a

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 25 Jul 2011 10:56:57 -0700

More comments inline.

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
> Sent: Monday, July 25, 2011 7:40 AM
> Subject: Re: [siprec] [AVTCORE] Request to review a SIPREC draft
relatedto RTP
> > should the SRC do in packet loss cases or specific RTCP
To address both this comment and Qin's, I think I need to add more
topology diagrams to illustrate the SRC as a UA within the CS, as a
middlebox between two UAs in a CS, and as a conference focus.

> > mixer. How does the implementer decide which topology to use?

Ultimately this is up to the SRC implementation and policy. In the case
of a point to point call in which the SRC is in the middle of the two
UAs or it one of the UAs, it may be more straightforward for the SRC to
act as a translator and essentially fork the streams to the SRS. In the
case of a multipoint conference in which the SRC is the focus, it may
make more sense for the SRC to treat the SRS similar to a recvonly
participant in the conference, and send it a mixed stream similar to the
ones it sends to other participants. 

> [JRE] If the SRS doesn't support the same profile that the UAs in the
Communication Session are using.

Yes. The SRC can use the same profile, or use a different profile. It is
up to the implementation of the SRC and the capabilities of the UAs and
SRS.

> > instead and in section 12.2 you disallow FIR. Why?

FIR should be used as defined in RFC 5104, but only for the things for
which it is appropriate. For example, FIR is appropriate for scene
change resulting from active speaker video switching. On the other hand,
using the FIR command to recover from errors is explicitly disallowed in
RFC 5104. Instead the PLI message defined in AVPF [RFC4585] should be
used.

> > the SRC (to SRS or receive UA each can send a FIR), why disallow it.

Better to use PLI for loss than FIR.

Cheers,
Charles

> [JRE] Yes, that is correct. If the SRC is located at the Communication
Session endpoint (UA), this is
> not a problem. If it is located at a B2BUA, the B2BUA would need to
negotiate SRTP separately with the
> two UAs in the Communication Session as well as with the SRS. The only
case where you might avoid this
> if the SRC forwards RTP packets unchanged, but then the SRS would need
to be part of key negotiation,
> or would at least need to know the keys. This would have different
security properties - for example
> it might require new keys to be generated on the Communication Session
whenever there is a period when
> the session is not being recorded, so that the SRS cannot tap into
that part of the session.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 28 Jul 2011 08:59:55 -0400

Hi,

Here are my review comments:

In general the document is pretty straight forward and understandable.
And make for me reasonable recommendations. As can be seen by the
comments I think Section 4 is where the most improvements can be made.

1. In Section 4.1: The following sentence exist:
More specifically,
   the SRC cannot multiple RTP streams with different SSRCs into a
   single RTP stream multiplexed by SSRC and/or CSRC.

If I guess that there should be "put multiple RTP streams" I would
really wonder over the "cannot". If the Streams are from the same
call/multimedia session and from the corresponding RTP session between
the UAs being recorded, I don't see why you couldn't put all the streams
into the same RTP session. They are related, from the same context, and
should also have unique SSRCs thus allowing the recording "translator"
to create copies and forward them to the SRS. As long as each original
stream has its own SSRC (assuming that the actual media isn't mixed in
the SRC).

2. Section 4.1:
RTCP Receiver Reports generated by the SRS
   need to be forwarded to the relevant UA.

If the goal is that the UAs shall know of the SRS then this is the
correct approach. If not, then the SRC can in fact suppress the SRS's
RTCP messages.

3. Section 4.1:

This sentence just don't make sense:

This implies that the SRC
   cannot take multiplex RTP packets with different SSRC values into a
   single SSRC stream unless it was The SRC in the case may need to
   manipulate the RTCP Receiver Reports to take account of any
   transcoding that has taken place.

I would suggest that Section 4.1 would be easier to understand if one
first starts with a Translator that doesn't modify the media streams,
just forwards them to the SRS. Then follow if with a translator that
does transcoding of the media streams individually.  There will not be
any major change of the RTP behavior from the first case. Except that
RTCP translation will be needed if forwarding of RTCP is done. Please
note that RTCP translation is going to be a bit complex and you might
consider why this should be supported. Unless the UA really need to know
that their media streams reaches the SRS I would suppress the RTCP.

4. Section 7.
I would recommend that you point people at
   [RFC6222]  Begen, A., Perkins, C., and D. Wing, "Guidelines for
              Choosing RTP Control Protocol (RTCP) Canonical Names
              (CNAMEs)", RFC 6222, April 2011.

For generation of CNAMES. This is much more robust in the presence of
NATs and end-points that lack DNS names.

5. I would make section 10 (CNAME) a subsection to 9 (SDES) as it is an
SDES item.

6. Section 11:
In order to the bindings and any pinholes in NATs/firewalls
   to remain active during such intervals, it is RECOMMENDED to follow
   the keep-alive procedures in "Application Mechanism for Keeping Alive
   the NAT Mappings Associated to RTP/RTP Control Protocol (RTCP) Flows"
   [RFC6263] for all RTP media streams.

I would suggest that you stress that one should use the recommended
method in this document.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 28 Jul 2011 09:26:32 -0700

Hi Magnus,

Thank you for reviewing and for your comments. Please see inline.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: Thursday, July 28, 2011 9:00 AM
> To: Roni Even
> Cc: [email-masked]
> Subject: Re: [siprec] [AVTCORE] Request to review a SIPREC draft related toRTP
> 
> Hi,
> 

I am not sure what I was trying to say here. Fixing the grammar is easy, but as you point out, doing so results in a false statement. I think it is best to remove this sentence completely.

> correct approach. If not, then the SRC can in fact suppress the SRS's

Okay, but what would you suggest an SRC does it forwards packets from UA1 to SRS and UA2, and reports from the SRS indicates loss of packets while reports from a UA-B do not.

> does transcoding of the media streams individually.

Good idea. I will try that.

> There will not be

Okay.

> NATs and end-points that lack DNS names.

I do, put in section 10 which is devoted to CNAME.

> 5. I would make section 10 (CNAME) a subsection to 9 (SDES) as it is an

Okay.
 
> I would suggest that you stress that one should use the recommended

Will add that.

Thanks!
Charles