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

[Iñaki Baz Castillo <[e-mail]>]

2016-03-11 9:50 GMT+01:00 Magnus Westerlund <[e-mail]>:
> 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.

Not sure if I get it. At the end, in WebRTC each m= line means a
MediaStreamTrack to be sent and/or a MediaStreamTrack to be received.


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

Useful information. However I will start another thread (not sure in
which mailing list) with a simple question:

As BUNDLE spec states, two bundled m= lines can just share the same PT
value if it points to the same codec name and codec configuration.
Where is specified what "same configuration" means? I expect it
depends on each codec...



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


Thanks a lot. Very valuable information.

However I plan to do something a bit different:

When a new participant joins the SFU room and sends its SDP offer, the
room will check the offered codecs. If same codec+configuration
already exists in the room (with an assigned unique PT) the SFU will
generate a SDP answer including the PT in the room for that
codec+configuration. According to SDP O/A, the offerer is mandated to
send RTP using the PT indicated in the SDP answer.

With this, I will avoid PT mangling in the SFU.




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

That's exactly what I propose above :)
However I do know that, probably, I will have to implement PT mangling
in some cases (for example when the SFU sends a re-offer to a browser
indicating its preferred PT values but the browser replies with
different values).


Thanks a lot Magnus.




-- 
Iñaki Baz Castillo
<[e-mail]>