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

["Cullen Jennings (fluffy)" <[e-mail]>]

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 <[e-mail]> 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  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>