Subject: Re: [AVTCORE] [AVT] New version of RTCP for IDMS

From: Colin Perkins <[email-masked]>
Date: Wed, 2 Feb 2011 18:33:33 +0000

Ray,

On 20 Jan 2011, at 08:43, Brandenburg, R. (Ray) van wrote:
> 
> Hi,
> 
> On 19 Jan 2011, at 23:27, Colin Perkins wrote:
> 
> ...
> 
>>> The main reason we went with an RTCP-XR report block was that we believed it would be less controversial to add an XR block type than a completely new RTCP packet type. In RFC5968 (which I believe you authored) it says that the only valid reason to create a new RTCP packet type is if the required functionality would not be appropriate as part of one of the current packet types (such as XR-). In the description of the XR- packet type in the same document it says the XR blocks are appropriate for "for transporting new metrics regarding media transmission or reception quality". So I think we should have a discussion about whether the IDMS block fits this description. 
> 
>> As I said, I think using RTCP XR is appropriate for receivers to provide feedback to the sender on receipt and presentation times for RTP packets. 
> 
>> I don't think an RTCP XR block is appropriate to, as your draft phrases it, "indicate synchronization settings instructions to a receiver". That seems to be providing guidance on when to playout the media, rather than conveying a metric on how well media playout is doing. This message from MSAS to SC would be better expressed as a new RTCP packet type, I think.
> 
> I agree that this sentence is somewhat misleading and leads one to believe that this IDMS message is some sort of control/command protocol. That is not our goal. The message is used to inform receivers of how media playout is doing on their slowest peer receiver. They can then use this information to possibly synchronize their own playout to this peer, although this is not required. In practice, a receiver would probably only synchronize when the playout difference crosses some threshold (e.g. for Social TV >150ms), to not cause unnecessary stutters for the user.

Sure, I understand. However, I still disagree that this is appropriate for RTCP XR, because it's not a report on how a particular receiver sees the session, but instead a summary of the overall state, and a playout hint. This seems much better suited to be a new RTCP packet type.

-- 
Colin Perkins
http://csperkins.org/

---

From: Peter Musgrave <[email-masked]>
Date: Wed, 2 Feb 2011 18:42:42 +0000

I think this is a valid point. 

Should this be an APP packet then?

From 3550: 
"After testing and if wider use is justified, it is RECOMMENDED that
   each APP packet be redefined without the subtype and name fields and
   registered with IANA using an RTCP packet type.
"

Or should the draft indicate a new packet type?

Peter Musgrave

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 3 Feb 2011 10:52:59 +0100

>    registered with IANA using an RTCP packet type.

Well, if one is doing a AVT defined solution for this, then we can
clearly go for a new RTCP packet type directly. We don't need to test it
before. That is already happening with the current spec, isn't it?

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: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Mon, 7 Feb 2011 13:45:57 +0000

Hi Colin/Peter/Magnus and all,

Thanks for your input. After giving it much thought I now agree that it would be best to define a new packet type for the sender->receiver message. 

I therefore propose the following: 

- The receiver->sender message remains a XR block message as currently defined by the I-D. This would allow it to be compatible with the ETSI TISPAN version, and would prevent unnecessary duplication. 

- The sender->receiver message becomes a new RTCP packet type.

- We include a section on compatibility with the TISPAN solution indicating that receivers MUST use the XR block for providing the sender with input while senders SHOULD use the new RTCP packet type for sender->receiver but MAY use the TISPAN defined sender->receiver XR block (which will not be defined in the I-D but remain in the ETSI spec). This should include an explanation on that the TISPAN sender->receiver XR block MUST only be used for purposes of compatibility with the TISPAN solution, but MUST NOT be used if all senders and receivers involved support the new RTCP packet type. In this way, backward compatibility is ensured, while not limiting improvements made within IETF.

- A new SDP parameter is defined for the new sender->receiver RTCP packet type. This would mean that there are two SDP parameters for the server->client message in the IANA registry; one for the ETSI solution and one for the IETF solution. This would also mean: if all elements in the SDP negotiation support the IETF solution, they SHOULD use the new RTCP packet type. 

Would this solution be acceptable to you? 

Regards,

Ray van Brandenburg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: donderdag 3 februari 2011 10:53
To: [email-masked]
Subject: Re: [AVTCORE] [AVT] New version of RTCP for IDMS

>    registered with IANA using an RTCP packet type.

Well, if one is doing a AVT defined solution for this, then we can clearly go for a new RTCP packet type directly. We don't need to test it before. That is already happening with the current spec, isn't it?

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]
----------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]
https://www.ietf.org/mailman/listinfo/avt
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html

---

From: Peter Musgrave <[email-masked]>
Date: Mon, 7 Feb 2011 13:56:56 -0500

I am ok with this - but I have no expertise on the TISPAN implications - I defer to others on that issue...

Cheers,

Peter Musgrave

---

From: Colin Perkins <[email-masked]>
Date: Wed, 9 Feb 2011 18:21:12 +0000

Sounds good to me.
Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 15 Feb 2011 10:07:40 +0100

> Would this solution be acceptable to you? 

Yes, this sounds very reasonable.

Thanks

Magnus Westerlund