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 A251421F8FA3 for ; Tue, 7 May 2013 15:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXVp9eRiZmy2 for ; Tue, 7 May 2013 15:28:23 -0700 (PDT) Received: from blu0-omc3-s17.blu0.hotmail.com (blu0-omc3-s17.blu0.hotmail.com [65.55.116.92]) by ietfa.amsl.com (Postfix) with ESMTP id C61AE21F8F28 for ; Tue, 7 May 2013 15:28:22 -0700 (PDT) Received: from BLU169-W126 ([65.55.116.73]) by blu0-omc3-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 May 2013 15:28:22 -0700 X-EIP: [g+oTpYYNHCuewQ3CRzghxZfsLp91icHhCcbwWBZlOL4=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_bbc70912-89fb-4d2b-95b7-10b201cc239e_" From: Bernard Aboba To: Magnus Westerlund Date: Tue, 7 May 2013 15:28:21 -0700 Importance: Normal In-Reply-To: <517F7859.4060600@ericsson.com> References: <201304292159.r3TLxwMs3753609@shell01.TheWorld.com>, <517F7859.4060600@ericsson.com> MIME-Version: 1.0 X-OriginalArrivalTime: 07 May 2013 22:28:22.0627 (UTC) FILETIME=[2EF1B330:01CE4B72] Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Demultiplexing via indexes in RTCP SDES packets 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: Tue, 07 May 2013 22:28:27 -0000 --_bbc70912-89fb-4d2b-95b7-10b201cc239e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Magnus said:=20 > I support your proposal of including a level of indirection enabling us > to avoid having to update the SDP for any addition of SSRCs=2C which a > a=3Dssrc based solution would require. >=20 > However=2C SDP is not the only signalling solution=2C it is the currently > dominating one=2C but if you ever is going enable us of breaking out of > the SDP trap=2C we need to ensure that the solutions around are not SDP > specific.=20 [BA] Indeed. It is one thing to chain the WebRTC API to the SDP boat ancho= r=3B it is another thing to require use of SDP eyeglasses to navigate the = ship by REQUIRING SDP to be used in order to make sense of RTP SDES packets= . Overall=2C I think that various aspects of WebRTC (including things like= signalling resolution or frame rate changes) should be handled in RTP/RTCP= rather than in signalling so as to maintain WebRTC signalling independence= .=20 >Thus=2C using SDES items for in stream bindings are something I > support=2C but the label should be done in such a way that it can be > handled as labels for a particular purpose and thus be included in other > signalling solutions. [BA] Agree.=20 > - Application related usage of video streams=2C for example if a SSRC is > currently carrying a main video or a thumbnail and thus which negotiated > constraints it tries to adhere to. [BA] I believe that this is often handled today by cooperation between the = mixer and application without new RTP/SDP functionality (other than simultc= ast/layering support). For example=2C the mixer can decide to forward a h= igher bandwidth simulcast stream or more layers since the audio indicates t= hat the stream relates to the speaker. The application sees the change and= promotes the stream to the main video and demotes the stream previously oc= cupying the main video to a thumbnail. Why couldn't this approach work for= WebRTC as well? Isn't enabling dynamism the goal of frameworks such as An= gularJS?=20 =20 > - Is the this SSRC part of a simulcast set=2C and if which quality strata > does it carry [BA] This could potentially be indicated inband within the codec=2C which = would enable a receiver to figure things out before the Answer arrived.=20 =20 > - Is this SSRC a related repair or retransmission stream to another > primary media carrying SSRC. >=20 > One issue is that for example the first can easily be a dynamic process= =2C > some implementations will reconfigure a SSRC between application purpose > due to user or application input. >=20 > Just these three above examples points to one very clear issues in > making progress here. We must try to clearly define the usage different > people see. See which is the same=2C which is orthogonal and which must b= e > possible to have in place at the same time. >=20 > This is the realization we have come to with in the discussion around > the SRCNAME proposal: > http://tools.ietf.org/html/draft-westerlund-avtext-rtcp-sdes-srcname [BA] Yes=2C there are advantages to additional SDES information that should= be explored further=2C particularly in situations where signalling indepen= dence is a goal. Personally=2C I was ok with the initial drafts of SRCNAME= =2C but am not sure it can be stretched to handle all the simulcast/layerin= g info (since that may end up in-band within the codec anyway) . > This discussion has proven the importance of having common terminology > and I hope we can make progress with the grouping taxonomy=2C because tha= t > document will discuss both object names and different possible relation > ships between these different types of object=2C like RTP sessions=2C SSR= Cs=2C > FEC groups. [BA] IMHO=2C I think it has proven we do not have agreement about some very= basic architectural issues :) > I think one important question here is if you really want and think it > is possible to bind have each different usage or purpose for an RTP > media stream (specific SSRC) can be captured with its own unique Media > Description (m=3D block)? [BA] I don't know that each SSRC has to be bound to its own unique Media Description (e.g. only one SSRC to an "m=3D" line). I also don't think tha= t each SSRC should have to have its own a=3Dssrc line either. As long as it is po= ssible to figure out what parameters apply to a given SSRC (some of which could be transmitted within the codec and some within SDES)=2C that is enough. =20 Applications are built today and they work without the restrictions being proposed in either Plan A or Plan B. Handling these things isn't even all that complicated.=20 > I also think it is important to realize that a particular SSRC may at > the same time have multiple relationships=2C for example it can be the > primary for a retransmission=2C part of a FEC group=2C be a particular > simulcast quality strata. [BA] Personally=2C I'd like to see an Internet-Draft describing what existi= ng implementations do before advocating that we allow infinite degrees of flexibility here. For example=2C there are implementations that use distin= ct SSRCs for different simulcast streams and layers (which is why things like SDP SSRC groups and SDES SRCNAME can be useful to bind them together). =20 > Please don't bind identifier and group ides to SDP concepts. Lets use a > level of indirection that both enables usage without SDP in certain > cases=2C and which can be bound to other signalling solutions in the futu= re. [BA] I agree -- and thank you for sending this to the list.=20 = --_bbc70912-89fb-4d2b-95b7-10b201cc239e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Magnus said:

>=3B= I support your proposal of including a level of indirection enabling us>=3B to avoid having to update the SDP for any addition of SSRCs=2C whic= h a
>=3B a=3Dssrc based solution would require.
>=3B
>=3B H= owever=2C SDP is not the only signalling solution=2C it is the currently>=3B dominating one=2C but if you ever is going enable us of breaking ou= t of
>=3B the SDP trap=2C we need to ensure that the solutions around = are not SDP
>=3B specific.

[BA] Indeed. =3B It is one thin= g to chain the WebRTC API to the SDP boat anchor=3B =3B it is another t= hing to require use of SDP eyeglasses to navigate the ship by REQUIRING SDP= to be used in order to make sense of RTP SDES packets. =3B Overall=2C = I think that various aspects of WebRTC (including things like signalling re= solution or frame rate changes) should be handled in RTP/RTCP rather than i= n signalling so as to maintain WebRTC signalling independence.

>= =3BThus=2C using SDES items for in stream bindings are something I
>= =3B support=2C but the label should be done in such a way that it can be>=3B handled as labels for a particular purpose and thus be included in = other
>=3B signalling solutions.

[BA] Agree.

>=3B - A= pplication related usage of video streams=2C for example if a SSRC is
&g= t=3B currently carrying a main video or a thumbnail and thus which negotiat= ed
>=3B constraints it tries to adhere to.

[BA] I believe that = this is often handled today by cooperation between the mixer and applicatio= n without new RTP/SDP functionality (other than simultcast/layering support= ). =3B =3B For example=2C the mixer can decide to forward a higher = bandwidth simulcast stream or more layers since the audio indicates that th= e stream relates to the speaker. =3B The application sees the change an= d promotes the stream to the main video and demotes the stream previously o= ccupying the main video to a thumbnail. =3B Why couldn't this approach = work for WebRTC as well? =3B Isn't enabling dynamism the goal of framew= orks such as AngularJS?
 =3B
>=3B - Is the this SSRC part of a= simulcast set=2C and if which quality strata
>=3B does it carry
[BA] =3B This could potentially be indicated inband within the codec= =2C which would enable a receiver to figure things out before the Answer ar= rived.
 =3B
>=3B - Is this SSRC a related repair or retransmis= sion stream to another
>=3B primary media carrying SSRC.
>=3B >=3B One issue is that for example the first can easily be a dynamic pro= cess=2C
>=3B some implementations will reconfigure a SSRC between appl= ication purpose
>=3B due to user or application input.
>=3B
&= gt=3B Just these three above examples points to one very clear issues in>=3B making progress here. We must try to clearly define the usage diffe= rent
>=3B people see. See which is the same=2C which is orthogonal and= which must be
>=3B possible to have in place at the same time.
>= =3B
>=3B This is the realization we have come to with in the discussi= on around
>=3B the SRCNAME proposal:
>=3B http://tools.ietf.org/h= tml/draft-westerlund-avtext-rtcp-sdes-srcname

[BA] Yes=2C there are = advantages to additional SDES information that should be explored further= =2C particularly in situations where signalling independence is a goal.&nbs= p=3B Personally=2C I was ok with the initial drafts of SRCNAME=2C but am no= t sure it can be stretched to handle all the simulcast/layering info (since= that may end up in-band within the codec anyway) .

>=3B This disc= ussion has proven the importance of having common terminology
>=3B and= I hope we can make progress with the grouping taxonomy=2C because that
= >=3B document will discuss both object names and different possible relat= ion
>=3B ships between these different types of object=2C like RTP ses= sions=2C SSRCs=2C
>=3B FEC groups.

[BA] IMHO=2C I think it has = proven we do not have agreement about some very basic architectural issues = :)
>=3B I think one important question here is if you really want and = think it
>=3B is possible to bind have each different usage or purpose= for an RTP
>=3B media stream (specific SSRC) can be captured with its= own unique Media
>=3B Description (m=3D block)?

[BA] I don't k= now that each SSRC has to be bound to its own unique Media
Description (= e.g. only one SSRC to an "m=3D" line). =3B I also don't think that each=
SSRC should have to have its own a=3Dssrc line either. =3B As long = as it is possible
to figure out what parameters apply to a given SSRC (s= ome of which could
be transmitted within the codec and some within SDES)= =2C that is enough. =3B
Applications are built today and they work = without the restrictions being
proposed in either Plan A or Plan B. = =3B =3B Handling these things isn't even all
that complicated.
<= br>>=3B I also think it is important to realize that a particular SSRC ma= y at
>=3B the same time have multiple relationships=2C for example it = can be the
>=3B primary for a retransmission=2C part of a FEC group=2C= be a particular
>=3B simulcast quality strata.

[BA] Personally= =2C I'd like to see an Internet-Draft describing what existing
implement= ations do before advocating that we allow infinite degrees of
flexibilit= y here. =3B For example=2C there are implementations that use distinct<= br>SSRCs for different simulcast streams and layers (which is why things li= ke
SDP SSRC groups and SDES SRCNAME can be useful to bind them together)= . =3B

>=3B Please don't bind identifier and group ides to SDP= concepts. Lets use a
>=3B level of indirection that both enables usag= e without SDP in certain
>=3B cases=2C and which can be bound to other= signalling solutions in the future.

[BA] I agree -- and thank you f= or sending this to the list.
= --_bbc70912-89fb-4d2b-95b7-10b201cc239e_--