Re: RTX/RED/FEC packet routing

2016-06-02 0:47 GMT+02:00 Bernard Aboba <Bernard.Aboba@microsoft.com>:
> "I don't agree. That would break multiple RtpReceivers over the same Transport. This is: two RtpReceivers could not share the same Transport if both use the same payloadType=111 for, for example, CN codec. They would conflict."
>
> [BA] Right.  Is this fixed by your proposal https://github.com/openpeer/ortc/pull/557 ?

Right. See below.



> If one of the audio codecs had encodings[i].ssrc unset (see scenario below) then wouldn't we add pt_table entries for G722, uLaw and CN?  The uLaw packets are no longer dropped, but now we have a conflict if multiple RtpReceivers attempt to do voice activity detection with G.722 (even though an SSRC is specified for G.722 so it shouldn't be an issue).

The problem is that featured codecs such as CN and telephone-event can
not be placed into encoding.codecPayloadType (as per ORTC spec). So
your example below is wrong (the encoding.codecPayloadType: 111 points
to audio/CN, which is not a media codec).

So I'll modify your example as follows:

{
    codecs :
    [
        {
            name        : 'audio/g722',
            payloadType : 100
        },
        {
            name        : 'audio/ulaw',
            payloadType : 0
        },
        {
            name        : 'audio/CN',
            payloadType : 111
        }
    ],
    encodings :
    [
        {
            codecPayloadType : 100,
            ssrc             : 1111
        },
        {
            codecPayloadType : 0
        }
    ]
}


With my solution (number 2 in #558) it produces the following tables:

{
    "muxIdTable": {},
    "ptTable": {
        "0": "64468694",       // ulaw
        "100": "64468694",   // g722
        "111": "64468694"     // CN
    },
    "ssrcTable": {
        "1111": "64468694"
    }
}


ptTable is filled because the second encoding does not specify ssrc.


One may wonder: "why is 100 (g722) included in ptTable?"

That's right, it does not need to be since we know that it will be
carried over ssrc 1111. But that's a very small "optimization" that
prevents nothing IMHO because any other RtpReceiver over the same
DtlsTransport may also want to receive CN with payload 111 and that
would conflict and fail.



To make clear what my solution fixes, let's consider this example:



{
  codecs :
  [
    {
      name        : 'audio/opus',
      payloadType : 100
    },
    {
      name        : 'audio/ulaw',
      payloadType : 0
    }
  ],
  encodings :
  [
    {
      codecPayloadType : 100,
      ssrc             : 1111
    },
    {
      codecPayloadType : 0
    }
  ]
}



With the current ORTC rules, it would generate these routing tables:

{
  "muxIdTable": {},
  "ptTable": {},
  "ssrcTable": {
    "1111": rtpReceiver
  }
}

It is wrong because ulaw codec will be dropped.



With my solution, generated routing tables are:

{
  "muxIdTable": {},
  "ptTable": {
    "0": "43133830",
    "100": "43133830"
  },
  "ssrcTable": {
    "1111": "43133830"
  }
}

Here ulaw is properly handled.



-- 
Iñaki Baz Castillo
<ibc@aliax.net>

Received on Wednesday, 1 June 2016 23:17:12 UTC