Re: [MMUSIC] [rtcweb] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description
Christer Holmberg <christer.holmberg@ericsson.com> Thu, 02 March 2017 12:47 UTC
Return-Path: <christer.holmberg@ericsson.com>
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 8E3BD120727; Thu, 2 Mar 2017 04:47:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 p4_wawRKcma1; Thu, 2 Mar 2017 04:47:20 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3DBE1299EB; Thu, 2 Mar 2017 04:47:19 -0800 (PST)
X-AuditID: c1b4fb30-677ff70000001a00-e6-58b814542ba4
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id 4D.8B.06656.45418B85; Thu, 2 Mar 2017 13:47:17 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0319.002; Thu, 2 Mar 2017 13:47:16 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>
Thread-Topic: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description
Thread-Index: AQHSfaJ5jrr91gBvrE2+PKFOpdD0GaFojxEAgAF+gQCAF67hgA==
Date: Thu, 02 Mar 2017 12:47:16 +0000
Message-ID: <D4DDE159.18A51%christer.holmberg@ericsson.com>
References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <2e0ea537-d03e-f263-ad64-cdd65ecd3fb5@ericsson.com> <D701B5B7-C221-4D0E-B10A-D01D3FE5E4AD@cisco.com> <0e84fe0e-8e50-7b9f-bede-76ebf293a0d8@ericsson.com> <D4A9EB8A-A4DD-4006-983D-D0DBF5A9428C@cisco.com>
In-Reply-To: <D4A9EB8A-A4DD-4006-983D-D0DBF5A9428C@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.1.161129
x-originating-ip: [153.88.183.146]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <7BCE6202729D6841BFE781B4F0359B05@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMIsWRmVeSWpSXmKPExsUyM2K7rm6oyI4Igw3LtCymz3rHZjG/Yx2b RcdkNoupyx+zWKz9187uwOox5fdGVo8lS34yeXy5/JktgDmKyyYlNSezLLVI3y6BK6O1axpr wUz9ipZZx5kaGBerdjFyckgImEjsur2BsYuRi0NIYB2jxNarqxlBEkICixglvh6M7WLk4GAT sJDo/qcNEhYRSJdof/CIGcRmFuhgkri0QgHEFhaoljgway8jRE2NxJrVV1ghbCeJ8/sns4HY LAIqEo+mfWYHsXkFrCW6/t6H2juRSWLv7BVgCU4BW4lV96cwgdiMAmIS30+tYYJYJi5x68l8 JoijBSSW7DnPDGGLSrx8/A9smaiAnsTy52ug4koSPzZcYoHo1ZO4MXUKG4RtLXH//AWoB7Ql li18zQxxkKDEyZlPWCYwis9Csm4WkvZZSNpnIWmfhaR9ASPrKkbR4tTipNx0IyO91KLM5OLi /Dy9vNSSTYzAqDy45bfBDsaXzx0PMQpwMCrx8BpIbY8QYk0sK67MPcQowcGsJMKbxb8jQog3 JbGyKrUoP76oNCe1+BCjNAeLkjiv2cr74UIC6YklqdmpqQWpRTBZJg5OqQbGHFaPGd3X/kfP 3RDw5N2cC3FBfEILT916/ZG/JMrsQ8VNY9Y/lf9UxV/FaDlWVrzexXSUwZqtVbw+aGt2eGwJ Z9GxGT+f6lYu/SCWVz9r3peOQCVeI72vr3cyr89ZMcnRsLVSSSslsf5dM2sLw2HGd9sC3h4S itp12UjuarjCktct4abVtaeVWIozEg21mIuKEwG7FenGxgIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/yIs3aMZ8GNslQ0CRMjUqRRrG3bE>
Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" <draft-ietf-rtcweb-jsep@tools.ietf.org>, RTCWeb IETF <rtcweb@ietf.org>, "mmusic (E-mail)" <mmusic@ietf.org>, "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" <draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org>
Subject: Re: [MMUSIC] [rtcweb] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Mar 2017 12:47:21 -0000
Hi, Where are we on this? I see Cullen¹s pull requests, but I don¹t think think there are many agreements. Or? Regards, Christer On 15/02/17 15:09, "Cullen Jennings (fluffy)" <fluffy@cisco.com> wrote: > >To try and help get you text merged in, I separated your text up into a >bunch of PRs so that the diffs were all clear and each PR tried to deal >with one issue. There are all in github now and commenting on theses >would probably be the easies way to get to some combined text. > > >> On Feb 14, 2017, at 7:20 AM, Magnus Westerlund >><magnus.westerlund@ericsson.com> wrote: >> >> Hi, >> >> Thanks for the feedback. Sorry for my delay in responding, a cold have >> kept from work. >> >> Den 2017-02-02 kl. 23:19, skrev Cullen Jennings (fluffy): >>> >>> So I much prefer the current text and think there are a bunch of >>> problems with this text. If we actually had emails explaining what >>> problems in the current text this was trying to fix, with individual >>> PRs for those, this would be much easier to resolve each of them and >>> get them fixed. >>> >>> 1) we have been trying to avoid the use of "RTP session" as it has >>> been very unclear to implementors what it is. I think this would be >>> better if we could rephrase to not use that >> >> Okay, but the RTP session is very easy to make clear in the context in >> of BUNDLE, where this text is intended to be. I can improve that. >> >>> >>> 2) both the proposed and current text seem lacking in dealing with >>> multiple bundle groups >> >> Okay, that can be fixed by clarifying that each bundle group results in >> its own RTP session, thus the procedures in this is per bundle group. >> >>> >>> 3) Stats are typically maintained by things after the packet is >>> routed - not before. >> >> So this comes a question of ones view of RTP stack and the question of >> layering. And this is exactly why I think the current text is >> problematic. It takes one very particular view, why I attempted to be >> much more neutral on which order things happens. There are a number of >> functions that are in the RTP protocol layer, not in the higher layers. >> There are however some things, like XR VoIP metrcis that are metrics in >> the higher layers. So, yes this is not clear cut. I think ones view of >> this depends on if one have a very integrated RTP implementation, then >> what you say makes sense, but if one has a very layered and modularized >> design, then my viewpoint makes more sense. >> >> From my perspective the most important thing here is that this text if >> it contains any RFC 2119 words can't prevent some possible >> implementation choices of the RTP stack. >> >>> >>> 4) Need to explain how the SDES in compound RTCP causes updates >>> >> >> I can attempt to clarify this. However, there is a potential issue here >> in that some implementations may not be able to force the receiver to >> process the content of the SDES RTCP packet prior to some or even all >> the other RTCP packets in a compound packet. >> >> What in the current text: >> >> On reception of any compound RTCP packet prior to dispatching the >> received information and data, if there is an RTCP SDES packet >> included that SHOULD be processed first. If that SDES packet >> contains SDES MID entries, this can results in updates and additions >> to the RTP stream to "m=" line mapping table. Thus each of the SDES >> MID items are processed and the current table entries are checked if >> the corresponding MID value matches the current RTP stream to "m=" >> line mapping, else the entry is updated. If there is no RTP stream >> to "m=" line table mapping entry for the received SDES item's SSRC, >> such an entry is created. Note, that in the process of updating the >> table entries, update flap suppression as discussed in Section 4.2.6 >> of [RFC7941] should be considered. >> >> Is insufficient in that regards. Is it only the placement prior to the >> individual RTCP packet types that is the issue? Should with the >> exception of the first sentence be moved under the SDES text? >> >>> 5) given this removes the outgoing SSRC table, not clear how it >>> routes RTCP reports. I think this needs to be clarified. >>> >> >> Okay, I think I understand that. I have an implicit assumption that the >> implementation knows how its local (outgoing) RTP Streams are related to >> the media sources and thus the related RTPsender. I can update the text >> to address this. >> >>> 6) I don't think most implementers are going to have a clue what to >>> do for the "Third Party Targeted Reports or Feedback" section >>> >> >> I can understand that, but I think it is important to call out that this >> bucket do exist, and if you don't know what to do I think it is fine to >> ignore these. >> >>> I will try and take your PR and break it up into some bit size pieces >>> so we can try and see if we can get the easy ones out of the way and >>> focus on the parts that are key changes. >>> >> >> Ok, I have seen that you generated a lot of individual issues, I will >>attempt to look through them and comment if there are things that was >>unintentional or where I have additional aspects to add. >> >> I intend to update my PR based on the feedback I received. >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Services, Media and Network features, Ericsson Research EAB/TXM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >
- [MMUSIC] Text proposal for Bundle regarding Assoc… Magnus Westerlund
- Re: [MMUSIC] Text proposal for Bundle regarding A… Magnus Westerlund
- Re: [MMUSIC] [rtcweb] Text proposal for Bundle re… Magnus Westerlund
- Re: [MMUSIC] Text proposal for Bundle regarding A… Jonathan Lennox
- Re: [MMUSIC] Text proposal for Bundle regarding A… Jonathan Lennox
- Re: [MMUSIC] Text proposal for Bundle regarding A… Magnus Westerlund
- Re: [MMUSIC] Text proposal for Bundle regarding A… Christer Holmberg
- Re: [MMUSIC] Text proposal for Bundle regarding A… Jonathan Lennox
- Re: [MMUSIC] Text proposal for Bundle regarding A… Jonathan Lennox
- Re: [MMUSIC] Text proposal for Bundle regarding A… Christer Holmberg
- Re: [MMUSIC] [rtcweb] Text proposal for Bundle re… Bernard Aboba
- Re: [MMUSIC] Text proposal for Bundle regarding A… Magnus Westerlund
- Re: [MMUSIC] [rtcweb] Text proposal for Bundle re… Magnus Westerlund
- Re: [MMUSIC] [rtcweb] Text proposal for Bundle re… Roni Even
- Re: [MMUSIC] Text proposal for Bundle regarding A… Cullen Jennings
- Re: [MMUSIC] [rtcweb] Text proposal for Bundle re… Cullen Jennings (fluffy)
- Re: [MMUSIC] [rtcweb] Text proposal for Bundle re… Iñaki Baz Castillo
- Re: [MMUSIC] [rtcweb] Text proposal for Bundle re… Bernard Aboba
- Re: [MMUSIC] [rtcweb] Text proposal for Bundle re… Christer Holmberg
- Re: [MMUSIC] [rtcweb] Text proposal for Bundle re… Magnus Westerlund
- Re: [MMUSIC] Text proposal for Bundle regarding A… Magnus Westerlund
- Re: [MMUSIC] [rtcweb] Text proposal for Bundle re… Cullen Jennings (fluffy)
- Re: [MMUSIC] [rtcweb] Text proposal for Bundle re… Christer Holmberg
- Re: [MMUSIC] [rtcweb] Text proposal for Bundle re… Justin Uberti