Subject: [siprec] draft-ietf-siprec-protocol-04.txt

From: "Dave Higton" <[email-masked]>
Date: Wed, 23 May 2012 12:07:38 +0100

I have a couple of comments:

1) Section 7.1.1.1 "Forwarding Translator" says: "RTCP Receiver Reports generated by the SRS MUST be forwarded to the relevant UA."

This implies that the UA receives an RR for something that it didn't send.

Shouldn't the RR from the SRS be received by the translator, and the translator send an RR to the UA?  In effect, shouldn't the translator translate the RTCP as well as the RTP, rather than purely forwarding it?  I think each path (UA <-> translator and translator <-> SRS) should be independent and complete within themselves.  A source sends RTP to a destination; that destination (and no other) should provide the RR, and the RR should go back to the source of that RTP, not some other source of a different stream.

2) Section 7.1.1.2. "Transcoding Translator" says: "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."

This is a malformed sentence.  I think the equivalent from section 7.1.1.1 is correct: "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."

Subject to my comments in point 1, anyway.

Dave

NICE Systems UK Limited ("NICE") is registered in England under company number, 3403044. The registered office of NICE is at Tollbar Way, Hedge End, Southampton, Hampshire SO30 2ZP.

Confidentiality: This communication and any attachments are intended for the above-named persons only and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of NICE. If this communication has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender by e-mail immediately.

Monitoring: NICE may monitor incoming and outgoing e-mails.

Viruses: Although we have taken steps toward ensuring that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 23 May 2012 14:10:30 +0000

Dave,

In case of forwarding translator, SRC is not the source of the RTP and SRC does not manipulate RTP data format. So, I'm not seeing issue in forwarding RTCP packet to RTP Endpoint as per Sec 7.2 of RFC 3550. 

Thanks
Partha

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Dave Higton
>Sent: Wednesday, May 23, 2012 4:38 PM
>To: [email-masked]
>Subject: [siprec] draft-ietf-siprec-protocol-04.txt
>
>1) Section 7.1.1.1 "Forwarding Translator" says: "RTCP Receiver Reports
>generated by the SRS MUST be forwarded to the relevant UA."
>
>Shouldn't the RR from the SRS be received by the translator, and the
>translator send an RR to the UA?  In effect, shouldn't the translator
>translate the RTCP as well as the RTP, rather than purely forwarding it?
>I think each path (UA <-> translator and translator <-> SRS) should be
>independent and complete within themselves.  A source sends RTP to a
>destination; that destination (and no other) should provide the RR, and
>the RR should go back to the source of that RTP, not some other source
>of a different stream.
>
>2) Section 7.1.1.2. "Transcoding Translator" says: "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."
>
>This is a malformed sentence.  I think the equivalent from section
>7.1.1.1 is correct: "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."
>
>NICE Systems UK Limited ("NICE") is registered in England under company
>number, 3403044. The registered office of NICE is at Tollbar Way, Hedge
>End, Southampton, Hampshire SO30 2ZP.
>
>Confidentiality: This communication and any attachments are intended for
>the above-named persons only and may be confidential and/or legally
>privileged. Any opinions expressed in this communication are not
>necessarily those of NICE. If this communication has come to you in
>error you must take no action based on it, nor must you copy or show it
>to anyone; please delete/destroy and inform the sender by e-mail
>immediately.
>
>Viruses: Although we have taken steps toward ensuring that this e-mail
>and attachments are free from any virus, we advise that in keeping with
>good computing practice the recipient should ensure they are actually
>virus free.
>_______________________________________________
>siprec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/siprec

---

From: "Dave Higton" <[email-masked]>
Date: Wed, 23 May 2012 15:15:51 +0100

Surely the whole point of a translator is that the two RTP streams (the one into the translator and the one out of the translator) are different, and have different destinations.  It seems to me, therefore, that the destination of each stream should send RRs to the source of that stream.

It seems bizarre to me that A should send a stream to B, but then get a receiver report from C for a different stream.

Dave

> From: Ravindran, Parthasarathi [mailto:[email-masked]]
> Sent: 2012 May 23 15:11
> To: Dave Higton; [email-masked]
> Subject: RE: draft-ietf-siprec-protocol-04.txt
> 
> Dave,
> 
> In case of forwarding translator, SRC is not the source of the RTP and
> SRC does not manipulate RTP data format. So, I'm not seeing issue in
> forwarding RTCP packet to RTP Endpoint as per Sec 7.2 of RFC 3550.
> 
> Thanks
> Partha
>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 24 May 2012 02:02:20 +0000

Dave,

Translator may be between unicast to multicast IP address as well and 
in such translator, RTCP from multicast endpoints are not mandated to 
be dropped by translator. RFC snippet in Sec 7.2 of RFC3550  is as 
follows:

  " A translator that does not modify the data packets, for example one
   that just replicates between a multicast address and a unicast
   address, MAY simply forward RTCP packets unmodified as well."

In fact, the basic SIP session (signaling) perspective in 
RTP translator, A send stream to B but receive RTCP from C which is the 
actual destination. In SIPREC scenario, A send stream to B but receive 
RTCP report from C (destination) and D (recorder).

Thanks
Partha

>From: Dave Higton [mailto:[email-masked]]
>Sent: Wednesday, May 23, 2012 7:46 PM
>To: Ravindran, Parthasarathi; [email-masked]
>Surely the whole point of a translator is that the two RTP streams (the
>one into the translator and the one out of the translator) are
>different, and have different destinations.  It seems to me, therefore,
>that the destination of each stream should send RRs to the source of
>that stream.
>
>It seems bizarre to me that A should send a stream to B, but then get a
>receiver report from C for a different stream.
>
>Dave
>
>> >I think each path (UA <-> translator and translator <-> SRS) should
>> >be independent and complete within themselves.  A source sends RTP to
>> >a destination; that destination (and no other) should provide the RR,
>> and
>> >the RR should go back to the source of that RTP, not some other
>> >source of a different stream.
>> >

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 24 May 2012 09:32:40 -0700

Hi Dave,

First, thanks for reviewing the draft and for catching the typo in
7.1.1.2. The word "be" was accidentally omitted. I will see to it that
the next rev of draft is updated as you suggested.
As for your concern regarding the functionality of the RTP translator,
it seems your expectations are more in line with an SRC acting as an RTP
endpoint, as discussed in section 7.1.3. This is a perfectly acceptable
model. Please have a look at that section and let me know if it aligns
better with your expectations.

Cheers,
Charles

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Dave Higton
> Sent: Wednesday, May 23, 2012 7:16 AM
> Subject: Re: [siprec] draft-ietf-siprec-protocol-04.txt
> 
> > >This implies that the UA receives an RR for something that it
didn't
> > >send.
> > >translate the RTCP as well as the RTP, rather than purely
forwarding
> > it?
> be
> > >MUST passed by the SRC between the UAs and the SRS, such the UAs
and
> > SRS
> Confidentiality: This communication and any attachments are intended
> for the above-named persons only and may be confidential and/or
legally