Re: [rtcweb] Fwd: inconsistency in drafts: rtcp-fb and rtcp-rsize

Harald Alvestrand <harald@alvestrand.no> Tue, 28 January 2014 00:29 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C261A0251 for <rtcweb@ietfa.amsl.com>; Mon, 27 Jan 2014 16:29:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.434
X-Spam-Level:
X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S608fupqthug for <rtcweb@ietfa.amsl.com>; Mon, 27 Jan 2014 16:29:47 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [IPv6:2001:700:1:2:213:72ff:fe0b:80d8]) by ietfa.amsl.com (Postfix) with ESMTP id 78EF51A008F for <rtcweb@ietf.org>; Mon, 27 Jan 2014 16:29:47 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B936139E04C for <rtcweb@ietf.org>; Tue, 28 Jan 2014 01:29:53 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwKyXW806ukU for <rtcweb@ietf.org>; Tue, 28 Jan 2014 01:29:51 +0100 (CET)
Received: from [IPv6:2620:0:1000:167d:c550:9ce2:4855:2d11] (unknown [IPv6:2620:0:1000:167d:c550:9ce2:4855:2d11]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id BC3D739E304 for <rtcweb@ietf.org>; Tue, 28 Jan 2014 01:29:50 +0100 (CET)
Message-ID: <52E6F9F3.8000303@alvestrand.no>
Date: Tue, 28 Jan 2014 01:29:39 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CANCLmwnfxNoDB-xpf=QDeYhJYkak8qmWpFHBSZaFsWN2gWnOpg@mail.gmail.com> <CANCLmwktXP=Mj+BHGdq+vO=WCmKD6mi1rcHVruhHenxfo2GX2Q@mail.gmail.com>
In-Reply-To: <CANCLmwktXP=Mj+BHGdq+vO=WCmKD6mi1rcHVruhHenxfo2GX2Q@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/alternative; boundary="------------090802030102030408010200"
Subject: Re: [rtcweb] Fwd: inconsistency in drafts: rtcp-fb and rtcp-rsize
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2014 00:29:52 -0000

On 01/27/2014 04:52 PM, Rachel Dvori wrote:
>
>
> The basic question is:
>
> -          In WebRTC offer, do we *always* have to include both
> attributes of   rtcp-fb and rtcp-rsize ?  (even if we do not have any
> feedback msg to send ?)
>

Not speaking authoritatively, but trying to be of assistance in the
interpretation....

I don't quite understand - in which cases would you never, at any time
in the future, have any feedback messages to send, and never want the
other party to send those messages to you?

Remember - RFC 5506 "rtcp-rsize" is about telling the other side that
you are capable of receiving those messages, as well as saying that you
are capable of sending them. Even if you don't intend to send any
reduced-size RTCP, the other party may want to send them.

And the negotiation is always about what capabilities are available over
the lifetime of the session (until next renegotiation) - not just the
situation in the immediate moment.

It is also wise to look at "intended status" of messages, and what they
call themselves.

For draft-nandakumar-rtcweb-sdp, the intended status is Informational,
and the introduction says


   This documents provides an informational reference in describing the
   role of SDP and Offer/Answer exchange for the most common WebRTC use-
   cases.


Thus, its statements are not normative. It will adapt to other documents.

I hope this helps in interpreting the documents.


>  
>
>  
>
>  
>
> When looking into the draft of :  rtcweb-rtp-usage
> <http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-11>
>
> It is indicated that both below are MANDATORY (MUST).
>
>  
>
> Regarding *Reduced Size RTCP:*
>
>  Support for non- compound RTCP feedback packets [RFC5506
> <http://tools.ietf.org/html/rfc5506>] is REQUIRED , but MUST be
> negotiated using the signalling channel before use. 
>
>  
>
> Regarding *RTCP feedback:*
>
>  
>
> For WebRTC use, the Extended  Secure RTP Profile for RTCP-Based
> Feedback (RTP/SAVPF) [RFC5124 <http://tools.ietf.org/html/rfc5124>],
> MUST be implemented.  ....
>
> ....This builds on the basic ...... the RTP profile for RTCP-based
> feedback    (RTP/AVPF) [RFC4585 <http://tools.ietf.org/html/rfc4585>],
> ....
>
>  
>
> From above, one can conclude that the SDP of an offer *MUST* include
> *both*:
>
> *-          **a=  rtcp-fb** ***
>
> *-          **a = rtcp-rsize    *
>
>  
>
>  
>
>  
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> When looking into:   draft-ietf-rtcweb-jsep-05
> <http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-05>        (page 24)
>
>  
>
> It can be understood that only rtcp-rsize is MUST to be included in
> the offer (and  rtcp-fb is not mandatory to be included in the offer)
>
>  
>
> Below is quote from that dratft:
>
> -          For *each supported* RTCP feedback mechanism, an
> "a=rtcp-fb"...   (My Remark:   so if there is no support, it is not
> mandatory to add it)
>
> -          An "a=rtcp-rsize" line, as specified in [RFC5506], Section 5 <http://tools.ietf.org/html/rfc5506#section-5>.
>
>  
>
>    R-11  [RFC4585 <http://tools.ietf.org/html/rfc4585>] MUST be implemented to signal RTCP based feedback.
>    R-13  [RFC5506 <http://tools.ietf.org/html/rfc5506>] MUST be implemented to signal reduced-size RTCP  messages.
>  
>  
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
>  
> And last draft: draft-nandakumar-rtcweb-sdp-03 <http://tools.ietf.org/html/draft-nandakumar-rtcweb-sdp-03>
>  
> It indicates that:  
> A typical ... communication session can be characterized as below:
> -          Provides RTCP based feedback mechanisms,
>  
>  
> It does not mention that rtcp-rsize is MUST and it is does not appear in all examples of SDP's 
>  
>  
> So there is inconsistency between the drafts.
> I would appreciate VERY Much your comment on the first question:
>
>  In WebRTC offer, do we *always* have to include both attributes of  
> rtcp-fb and rtcp-rsize ?  (even if we do not have any feedback msg to
> send ?)
>
>  
>
> And if not --  can anyone provide clarification on what is expected to
> be on each SDP offer (even if we do not have fb msg to send, but it
> can be easily added in a SDP, if needed)
>
>  
>
> With appreciation
>
> RD
>
>  
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


-- 
Surveillance is pervasive. Go Dark.