Re: [AVTCORE] BUNDLE and same payload type in different "bundled" m= lines

[Magnus Westerlund <[e-mail]>]

Den 2016-03-10 kl. 23:44, skrev Iñaki Baz Castillo:
> 2016-03-09 23:29 GMT+01:00 Bernard Aboba <[e-mail]>:
>> [BA] What specific text in BUNDLE mandates this? In particular, the
>> VP8 decoder can decode anything that the encoder can send, so the
>> streams from the different participants do not require unique
>> decoder settings. So AFAICT the SFU could send N streams to a given
>> participant, each using PT=100, but with N distinct SSRCs.
>
> At the end it happens that RFC 3550 (RTP) defines "RTP session" as
> all the stuff sent by an RTP participant over a specific transport
> (5-tuple), and it mandates PT to be unique within a "RTP session".
>
> Due to that, it seems that legacy middleboxes/endpoints just take
> the PT to identify codecs.
>
> Then BUNDLE arrives and a "RTP session" no longer identifies a
> single transport for a single RTP participant. But legacy systems
> still assume that, so PT must remain unique.

I don't really agree to this characterization of Bundle. Bundle is SDP
solution for how one adds media source level information around the RTP
streams that all are sent within a single RTP session.

In non offer/answer usage of SDP, like in SAP and RTSP the m= lines
represents a RTP session, not a media source. In these cases you don't
have any information about the specific RTP streams, there is an
assumption that there will be sent one or more per direction in these
usages.

>
> I don't yet understand why the same PT value can be used for
> different bundled streams if they refer to the same
> codec+configuration, since those PTs now belong to different streams.
> But I don't care too much about that.
>

To be clear, from a high level it exists a possibility to define usages
of the RTP that would define the PT value to be scoped on SSRC basis,
rather then RTP session level. However the devil is in the details and
such a usage would require careful review of existing specifications to
find where there might be issues. I am especially worried about issues
in the RTCP parts, for cases where PT information are used. Normally
this is clearly done in the context of an SSRC. But, to be certain there
are no issues one has to review things.  I am also expecting that more
than one RTP stack implementation are unable to support this without
modifications, possibly extensive ones. This as the data structures for
the PT are associated with the RTP session rather than individual SSRCs.

I want to be clear that if one like to pursue this idea of redefining 
what PT are scoped by, then this requires AVTCORE work to create a 
specification for such a usage. If that is a new profile or something 
else that will have to be for future discussions.


So, I would like to make sure that we are on a common understanding what 
a SFU have to do with the RTP streams to make it possible to re-use the PTs.

So if we start with A and B communicating across an SFU. I will continue 
this from your example when you raised this in MMUSIC:

1) mid: alice-audio,  codec: opus,  payload: 100, ssrc: 1111
2) mid: bob-audio,   codec: g722,  payload: 100, ssrc: 2222

This would mean that Carol receives an SDP with two "m=audio"
sections using BUNDLE:


   m=audio [...] 100
   a=sendonly
   a=mid:alice-audio
   a=rtpmap:100 opus/48000/2
   a=ssrc:1111 cname:foo
   [...]
   m=audio [...] 100
   a=sendonly
   a=mid:bob-audio
   a=rtpmap:100 g722/48000
   a=ssrc:2222 cname:bar
   [...]

So from my perspective what the conference signalling server has to send 
Carol is an SDP that looks like this:

This would mean that Carol receives an SDP with two "m=audio"
sections using BUNDLE:


   m=audio [...] 100
   a=sendonly
   a=mid:alice-audio
   a=rtpmap:100 opus/48000/2
   a=ssrc:1111 cname:foo
   [...]
   m=audio [...] 101
   a=sendonly
   a=mid:bob-audio
   a=rtpmap:101 g722/48000
   a=ssrc:2222 cname:bar
   [...]


Then the SFU will need to change all RTP packets with PT=100 from Bob to 
PT=101 when forwarding them to Carol. The packets from Alice it can 
leave unchanged from an PT perspective.

If David joins the session and can do both codecs and offers like this:

m=audio [...] 98 99
a=sendrecv
a=rtpmap:98 opus/48000/2
a=rtpmap:99 g722/48000
a=ssrc:4444 cname:groo

Then I expect the conference server to determine that these 
configurations are identical to already existing ones and answer:

m=audio [...] 98
a=sendonly
a=mid:alice-audio
a=rtpmap:98 opus/48000/2
a=ssrc:1111 cname:foo
[...]
m=audio [...] 99
a=sendonly
a=mid:bob-audio
a=rtpmap:99 g722/48000
a=ssrc:2222 cname:bar
[...]
m=audio [...] 98 99
a=sendonly
a=mid:carol-audio
a=rtpmap:98 opus/48000/2
a=rtpmap:99 g722/48000
a=ssrc:3333 cname:skog
[...]
m=audio [...] 100 101
i=M block for David's audio stream
a=recv
a=rtpmap:100 opus/48000/2
a=rtpmap:101 g722/48000

So the SFU will translate the PTs towards Dave, to match what Dave 
accepts receiving. The SFU request Dave's endpoint to use the PTs it has 
defined as its common reception table out of the ones the Dave support.

Yes, using RTP middleboxes and SDP offer/answer do result in that one 
will have to specific PT values in use on each leg. It is very difficult 
to get this aligned to between the legs.

Your proposal is one way to avoid that translation. Which would require 
certain changes and issues. Another possibility would be to try to 
address it in the signalling system. Because having the possibility for 
the central controller to dictate the actual configuration within the 
capabilities of the endpoints would simplify certain things. 
Unfortunately both have issues to resolve and significant legacy inertia.

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