RE: [ortc] Same payload for different codecs in same RtpSender/RtpReceiver

I am not sure this is a real problem for the SFU developer.  Let me explain why. 

Within O/A it is quite possible for the participants to offer different PT values.  For example, today FF might offer PT=97 for H.264 packetization-mode 0 and PT=126 for packetization-mode 1, with both including a profile-level-id value of "42e01f " (e.g. constrained baseline profile, level 3.1). 

Other browsers might offer different PTs or parameters (e.g. only offer packetization-mode-1 and a profile-level-id of "42c02a" (constrained baseline profile, level 4.2)). 

To deal with this, the SFU developer needs to be able to rewrite payload types, so as to be able to send a given participant multiple streams using the same PT.  

Is this possible despite the text you quote? 

Yes!

What the SFU has to do is to answer with a single H.264 PT for all participants (e.g. 126), and choose a common set of parameters (e.g. packetization-mode 1 and profile-level-id of "42e01f ") that all the participants are capable of receiving. 

If that is done, then there is no need to offer multiple PTs, one for each set of parameters (e.g. PT of 126 for FF profile-level-id "42e01f ", PT of 130 for profile-level-id "42c02a ", etc.). 

-----Original Message-----
From: Iñaki Baz Castillo via GitHub [mailto:sysbot+gh@w3.org] 
Sent: Monday, March 7, 2016 2:16 PM
To: public-ortc@w3.org
Subject: [ortc] Same payload for different codecs in same RtpSender/RtpReceiver

ibc has just created a new issue for https://github.com/openpeer/ortc:

== Same payload for different codecs in same RtpSender/RtpReceiver ==
NOTE: Related email posted in
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2flists.w3.org%2fArchives%2fPublic%2fpublic-webrtc%2f2016Mar%2f0021.html.&data=01%7c01%7cBernard.Aboba%40microsoft.com%7c493b4665e0d54d924fe908d346d6402c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=NZK1B8cz1jBZGW%2bZ%2fDxl2PNccIHRCuh%2feRbt6PRMq84%3d


[draft-ietf-mmusic-sdp-bundle-negotiation](https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-mmusic-sdp-bundle-negotiation-27&data=01%7c01%7cBernard.Aboba%40microsoft.com%7c493b4665e0d54d924fe908d346d6402c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=0210BKpJLj%2f%2bP43Rnao0KhWdvP4p6dzS6daKjtC5%2f38%3d)
 in section 10.1.2:

```
   Multiple bundled "m=" lines might represent RTP based media.  As all
   RTP based media associated with a BUNDLE group belong to the same RTP
   session, in order for a given payload type value to be used inside
   more than one bundled "m=" line, all codecs associated with the
   payload type number MUST share an identical codec configuration.
   This means that the codecs MUST share the same media type, encoding
   name, clock rate and any parameter that can affect the codec
   configuration and packetization.
   [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose
   attribute values must be identical for all codecs that use the same
   payload type value.
```

As I explain in the email this is a no sense. At the end it basically states that there cannot be two different codecs with same `payloadType` (or same codec with different codec parameters) within the same `RtpSender`/`RtpReceiver`.

This is a pain for a SFU developer as it forces me to override the payload types of different participants in the same conference (otherwise a receiver should create different transports for each media track...).

So, what about ORTC and this topic?

Please view or discuss this issue at
https://github.com/openpeer/ortc/issues/407 using your GitHub account

Received on Monday, 7 March 2016 22:56:37 UTC