- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Wed, 22 Oct 2014 22:56:57 +0000
- To: Iņaki Baz Castillo <ibc@aliax.net>
- CC: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, "public-ortc@w3.org" <public-ortc@w3.org>, "pthatcher@google.com" <pthatcher@google.com>
I would agree that the matching rules need to be able to demux on SSRC even if the payload types are overlapping between RtpReceivers. The case of multiple cameras from RFC 5576 Example 3 illustrates this. Currently the ORTC API spec does not say that such payload type overlap is illegal, although it is a requirement that a codec's payload type attribute be filled in (e.g. there is no payload type wildcard). > On Oct 22, 2014, at 3:34 PM, Iņaki Baz Castillo <ibc@aliax.net> wrote: > > 2014-10-22 23:39 GMT+02:00 Sergio Garcia Murillo > <sergio.garcia.murillo@gmail.com>: >> From an implementation point of view I would prefer to move out of the >> clunkiness of WebRTC 1.0, and be able to de-multiplex per ssrc only, without >> having to take a look at the pt. > > > +1 > > This is just layer hierarchy: > IP -> UDP -> RTP -> SSRC -> PT > > > The issue/limitation/bug in SDP is that payload-types must be unique > within a single m line (whatever a m line represents which nobody > knows nowadays). That's just a format/syntax limitation/issue in SDP. > It makes sense at 100% that the SSRC is inspected first (so we get the > "stream") and then we inspect the payload-type, so two different SSRCs > over the same transport should be able to carry same payload-type > values (regardless it means "vp8" in SSRC-A and "RED" in SSRC-B). > > -- > Iņaki Baz Castillo > <ibc@aliax.net>
Received on Wednesday, 22 October 2014 22:57:26 UTC