Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09C621F8570 for ; Tue, 20 Nov 2012 16:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.091 X-Spam-Level: X-Spam-Status: No, score=-102.091 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWbrPJuwKyor for ; Tue, 20 Nov 2012 16:50:38 -0800 (PST) Received: from blu0-omc2-s11.blu0.hotmail.com (blu0-omc2-s11.blu0.hotmail.com [65.55.111.86]) by ietfa.amsl.com (Postfix) with ESMTP id 105E021F84EB for ; Tue, 20 Nov 2012 16:50:37 -0800 (PST) Received: from BLU002-W217 ([65.55.111.72]) by blu0-omc2-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Nov 2012 16:50:37 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_1375a7c9-5dab-4edc-b8cc-c38d1fadb17a_" X-Originating-IP: [131.107.0.114] From: Bernard Aboba To: "mmusic@ietf.org" , "christer.holmberg@ericsson.com" Date: Tue, 20 Nov 2012 16:50:36 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 21 Nov 2012 00:50:37.0007 (UTC) FILETIME=[386EBDF0:01CDC782] Subject: Re: [MMUSIC] RFC 5576 is da answah X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 00:50:39 -0000 --_1375a7c9-5dab-4edc-b8cc-c38d1fadb17a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Christer said: "RFC 5576 is da answah :)=0A= =0A= http://tools.ietf.org/rfc/rfc5576.txt=0A= =0A= Or=2C do you have specific examples/use-cases where it wouldn't work?=0A= " [BA] In the WebRTC context=2C IMHO there are a lot of unanswered questions = in RFC 5576.=20 >From Section 5: Endpoints MUST NOT assume that only the sources mentioned in SDP will be present in an RTP session=3B additional sources=2C with previously unmentioned SSRC IDs=2C can be added at any time=2C and endpoints MUST b= e prepared to receive packets from these sources. (How endpoints handle such packets is not specified here=3B they SHOULD be handled in the same manner as packets from additional sources would be handled had the endpoint not received any a=3Dssrc: attributes at all.) [BA] While the advice above seems generally sensible=2C the meaning of "pre= pared to receive" isn't very clear. Implementations may differ in how they= respond if they don't receive any a=3Dssrc attributes. For example=2C an= implementation might only be able to deal with a single undeclared source = or perhaps not at all. So being "prepared to receive" isn't enough to be a= ble to deal with an RTP translator=2C for example.=20 >From Section 8: When used with the SDP Offer/Answer Model [RFC3264]=2C SDP source- specific attributes describe only the sources that each party is willing to send (whether it is sending RTP data or RTCP report blocks). No mechanism is provided by which an answer can accept or reject individual sources within a media stream=3B if the set of sources in a media stream is unacceptable=2C the answerer's only option is to reject the media stream or the entire multimedia session. [BA] The advice above appears to only apply to an answerer that supports RF= C 5576. If it doesn't support RFC 5576=2C then it will presumably ignore t= he a=3Dssrc lines=2C but may not reject the media stream (by setting the po= rt to zero) or the entire session. In this case=2C it may not be clear to= the Offerer whether in fact it can send all the declared ssrc's or not. C= ontrast this with the CLUE approach in which receiver gets to indicate what= media captures it would like to receive.=20 >From Section 9: Source descriptions are specified in this document such that RTP endpoints that are compliant with the RTP specification [RFC3550] will be able to decode the media streams they describe whether or not they support explicit source descriptions. However=2C some deployed RTP implementations may not actually support multiple media sources in a media stream. Media senders MAY wish to restrict themselves to a single source at a time unless they have some means of concluding that the receivers of the media stream support source multiplexing. [BA] The obvious way for an answerer to indicate support for RFC 5576 woul= d be to include a=3Dssrc lines in the answer. If the Answer doesn't inclu= de a=3Dssrc lines=2C should the Offerer conclude that only one source can b= e sent? The above paragraph indicates this is optional.=20 = --_1375a7c9-5dab-4edc-b8cc-c38d1fadb17a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Christer said:

"RFC 5576 = is da answah :)=0A= =0A= http://t= ools.ietf.org/rfc/rfc5576.txt=0A= =0A= Or=2C do you have specific examples/use-cases where it wouldn't work?=0A= "

[BA] In the WebRTC context=2C IMHO there are a lot of unanswered q= uestions in RFC 5576.

From Section 5:

 =3B =3B Endpo= ints MUST NOT assume that only the sources mentioned in SDP will
 = =3B =3B be present in an RTP session=3B additional sources=2C with prev= iously
 =3B =3B unmentioned SSRC IDs=2C can be added at any time= =2C and endpoints MUST be
 =3B =3B prepared to receive packets f= rom these sources. =3B (How endpoints
 =3B =3B handle such p= ackets is not specified here=3B they SHOULD be handled in
 =3B = =3B the same manner as packets from additional sources would be handled
=  =3B =3B had the endpoint not received any a=3Dssrc: attributes at = all.)

[BA] While the advice above seems generally sensible=2C the me= aning of "prepared to receive" isn't very clear. =3B Implementations ma= y differ in how they respond if they don't receive any a=3Dssrc attributes.=  =3B =3B For example=2C an implementation might only be able to dea= l with a single undeclared source or perhaps not at all. =3B So being "= prepared to receive" isn't enough to be able to deal with an RTP translator= =2C for example.

From Section 8:

 =3B =3B When used = with the SDP Offer/Answer Model [RFC3264]=2C SDP source-
 =3B = =3B specific attributes describe only the sources that each party is
&nb= sp=3B =3B willing to send (whether it is sending RTP data or RTCP repor= t
 =3B =3B blocks). =3B No mechanism is provided by which an= answer can accept or
 =3B =3B reject individual sources within = a media stream=3B if the set of
 =3B =3B sources in a media stre= am is unacceptable=2C the answerer's only option
 =3B =3B is to = reject the media stream or the entire multimedia session.

[BA] The a= dvice above appears to only apply to an answerer that supports RFC 5576.&nb= sp=3B If it doesn't support RFC 5576=2C then it will presumably ignore the = a=3Dssrc lines=2C but may not reject the media stream (by setting the port = to zero) or the entire session. =3B =3B In this case=2C it may not = be clear to the Offerer whether in fact it can send all the declared ssrc's= or not. =3B Contrast this with the CLUE approach in which receiver get= s to indicate what media captures it would like to receive.

From Se= ction 9:

 =3B =3B Source descriptions are specified in this = document such that RTP
 =3B =3B endpoints that are compliant wit= h the RTP specification [RFC3550]
 =3B =3B will be able to decod= e the media streams they describe whether or not
 =3B =3B they s= upport explicit source descriptions. =3B However=2C some deployed
&n= bsp=3B =3B RTP implementations may not actually support multiple media = sources
 =3B =3B in a media stream. =3B Media senders MAY wi= sh to restrict themselves to
 =3B =3B a single source at a time = unless they have some means of concluding
 =3B =3B that the rece= ivers of the media stream support source multiplexing.

[BA] =3B = The obvious way for an answerer to indicate support for RFC 5576 would be t= o include a=3Dssrc lines in the answer. =3B =3B If the Answer doesn= 't include a=3Dssrc lines=2C should the Offerer conclude that only one sour= ce can be sent? =3B =3B The above paragraph indicates this is optio= nal.
= --_1375a7c9-5dab-4edc-b8cc-c38d1fadb17a_--