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

[Magnus Westerlund <[e-mail]>]

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]
----------------------------------------------------------------------