Re: [MMUSIC] [rtcweb] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description

Justin Uberti <justin@uberti.name> Sat, 11 March 2017 00:31 UTC

Return-Path: <juberti@gmail.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 3749C1289C4; Fri, 10 Mar 2017 16:31:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 F4aWVEzulqgf; Fri, 10 Mar 2017 16:31:55 -0800 (PST)
Received: from mail-wr0-f179.google.com (mail-wr0-f179.google.com [209.85.128.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45AF9129495; Fri, 10 Mar 2017 16:31:55 -0800 (PST)
Received: by mail-wr0-f179.google.com with SMTP id l37so74106777wrc.1; Fri, 10 Mar 2017 16:31:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xXtYOteH60pVABS19KSWxmCzyP8TSATaU/qqtJZ2Cgc=; b=dcK28e97/5e5JcNtX15js7t1j2RPFVWudwlgyrr+sRV+Gm80x+TosvJj8RVYDeGKIW CjsE1qCTYtqRF3bIgCEJWhOGTic58qrSmpEyGWPJ/FRh2zayyM3iCHfbruZOQy/q8EIR +q92Qmr3gJvMRRMvBM9UXtE0CWkmspyKNafaXPT+z5kzmjbVMnkLFtDnP/rWAhSAyIZr ZltJYBIrALSQQnKKQBztjSgHZ2uIGQN29BLecG3TGNric6ckV5UncoiDURBmv983WPND 6JyOBClmgE4F0ot/Pz8P3jA6jLwErB+ddOroZCUBz/yQkX/9ovESagI5a/QpwdB4jQR3 IYoQ==
X-Gm-Message-State: AMke39nid/H9tvOgk11JIclwkhgZWzBzeIsfrxsbgW4i2iWrKTntLTbdjtguli2MEshkizVUutVdfnLz9LbUBA==
X-Received: by 10.223.150.205 with SMTP id u71mr17898189wrb.195.1489192313749; Fri, 10 Mar 2017 16:31:53 -0800 (PST)
MIME-Version: 1.0
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> <D4DDE159.18A51%christer.holmberg@ericsson.com>
In-Reply-To: <D4DDE159.18A51%christer.holmberg@ericsson.com>
From: Justin Uberti <justin@uberti.name>
Date: Sat, 11 Mar 2017 00:31:42 +0000
Message-ID: <CALe60zBOHgM-==qOFUhkL67S7LAfXBk3Ucu6O-YHS0J3q0ZECA@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: multipart/alternative; boundary=f403045f584edd0640054a699ad1
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/ZODSfCMfc8SXuN8kqb29EpYM7ZE>
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: Sat, 11 Mar 2017 00:31:57 -0000

The new jsep-19 draft
<https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-19> incorporates the
outcome of said PRs. Please take a look at the new Appendix C.

On Thu, Mar 2, 2017 at 4:49 AM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

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
<+46%2010%20714%2082%2087>
>> Färögatan 6                 | Mobile +46 73 0949079
<+46%2073%20094%2090%2079>
>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>> ----------------------------------------------------------------------
>>
>