Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-bundle-negotiation-32 - RTP demux - Pull Request

[Magnus Westerlund <[e-mail]>]

Hi,

Yes, there are history here, we also have made decision on what we 
wanted the m= line to mean. Yes, the path we chose it is not the one 
that results in the cleanest configuration for RTP.

I am also try my best to keep in mind that how you implemented your RTP 
stack can significantly impact how you consider these issues.

So comments inline.

Attempt to conclude at the bottom.


Den 2016-10-19 kl. 22:20, skrev Paul Kyzivat:
> On 10/19/16 9:18 AM, Colin Perkins wrote:
>> Getting the layering right is important, I think, to have something
>> that’s both understandable and extensible:
>>
>>  RTP Layer  : RTP and RTCP packets -> RTP streams
>>  SDP BUNDLE : RTP streams -> SDP “m=" lines
>>  JSEP       : SDP “m=" lines -> application-level semantics
>>
>> I don’t think this will need a big text change, but it is a semantic
>> change in how the BUNDLE draft describes the mapping.
>
> ISTM this isn't fundamentally about BUNDLE. It is about the relationship
> of SDP and RTP. My impression is that this was never *right*, and the
> introduction of BUNDLE has brought it to a head.

Agreed, the usage of SAP wiht SDP for configuring RAT/VIC MBONE tools 
actually worked on an RTP session level (with an assumption of sending 
one but receiving many streams per RTP session and media type). Then SIP 
O/A came along and introduced a media stream centric definition. Which I 
think is part of where it went in a direction that contributes to 
today's issues.

>
> For the most part SDP rarely mentions SSRCs. (It *can* using a=SSRC, but
> that is a rarely used construct.)
>
> SDP is a container for multiple "Media Descriptions". Syntactically it
> does this by:
>
> - grouping multiple SDP lines into multiple media descriptions
>   delineated by m-lines
> - associating a 3-tuple with each media description based on the
>   c-line and info in the m-line
> - associating two SDPs (offer and answer), pairing the media
>   descriptions in each in order to merge properties. This merges
>   two 3-tuples into a 5-tuple
>
> The code that interprets this stuff then (in the case of RTP) associates
> each media description with (possibly multiple) RTP streams. In non-rtp
> cases the interpretation is different.
>
> Historically (pre-bundle) that code was able to associate network
> packets with media descriptions based on the 5-tuple. This was partially
> done by the OS (sockets) and partially the application.

Yes, part of this tangle is that parameters that in reality are RTP 
session related parameters are tangled up with the media source you 
would like to receive and send.

And from my perspective, the OS (Sockets) selectors for incoming data 
are really associated first of all with the RTP session. Only a possible 
second usage for identifying a particular incoming RTP stream as being 
from a particular end-point and application context.

And the O/A design introduced an artificial limitation for RTP. As the 
3-tupe or 5-tuple are not at all related to how many RTP streams can 
flow between these end-points.

> The introduction of BUNDLE is with the intent using a single 5-tuple for
> multiple media descriptions. That means that the 5-tuple is insufficient
> to associate packets with media descriptions, so some additional
> algorithm is required to do that.
>
> When Christer is talking about an m-line he is generally using that as
> shorthand language for the media description delineated by the m-line.
> With that in mind, his wording "associate received RTP packets wth an m=
> line [media description]" seems right to me.
>
> In the case of RTP, it remains the job of the RTP implementation to
> associate those incoming RTP packets with a media description. *Then* it
> can use the other properties of that media description to help in
> figuring out what RTP stream they are associated with.
>
> That is only for RTP. In the case of non-RTP media that is is the bundle
> some different algorithm is needed to make the association. We have only
> defined a limited case for non-RTP media in a bundle, so the task is
> easier. But we just put that off. In principle more things could be
> bundled. For instance, we *could* have allowed multiple UDP/DTLS/SCTP
> media descriptions in the bundle as long as they had differing
> SCTP-ports. That would bind corresponding packets to one or the other of
> the media descriptions.

Yes, but also in the case for SCTP, one doesn't need to talk about SCTP 
packets, one should talk about the different SCTP association, which is 
what the SCTP ports identify. Yes, on the lowest level it might be easy 
to just abstract it to be packets from the other protocol. But, in most 
cases I think you can easily put another label on the flow(s) of 
packets, uni or bi-directional depending on the protocol. When defining 
an SDP configuration of a transport mechanism one have to consider what 
protocol elements that needs to be configured.


I currently fail to see that the above discussion changes what needs to 
be done. Yes, SDP's description of RTP is not optimally structured, but 
that we can't change. We also have the agreement that one m= should 
describe one Media Source, thus we simply have to describe how this is 
accomplished, despite the fact that one needs to consider both RTP 
session and the set of RTP streams associated with a media source that 
on sends as well as the RTP streams one is willing to receive.

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