Not sure what you guys mean. The draft we did on RTX says it should be HBH,
wedged in between the two layers of encryption. Just as Sergio described it
in this thread.
I have never defended RTX having to be e2e.
There was a separate discussion about whether you can drop RTX packets you
havent asked for (such as padding) or whether you should just let them go
through but that has nothing to do with how RTX should be constructed.
The argument we had with Mo was whether to make the encryption before or
after the HBH encryption layer and other than Mo no one else was defending
this.
Emil
On Fri, 31 Mar 2017 at 04:49, Alexandre GOUAILLARD <agouaillard@xxxxxxxxx>
wrote:
On Fri, Mar 31, 2017 at 4:16 PM, Sergio Garcia Murillo <sent from my mobile
sergio.garcia.murillo@xxxxxxxxx> wrote:
Yes, I was attending remotely to the meeting, so I think I understand
Emil's concerns. What I don't agree is that those concerns can be solved
with E2E RTX/FEC anyway.
If I understood the issue correctly, the problem is when the receiver
nacks a packet that is out of the MD repair window.
Yes, that was the use case.
In this case, the MD would have to request the packet back to decide if
request it back to the receiver, or just drop it. If it sends back the nack
to the receiver, a HBH RTX packet would be sent, so the MD will be able to
reconstruct the original RTP packet, calculate the OHB to form the new rtp
packet, create an RTX for it and send it back to any receiver that had
requested, the same way as if it were in the repair window. Note that this
is the almost the same procedure as which the SFU would do for
non-double-per scenarios, and if OBH would be carried on the payload, then
the SFU would almost requires no modification at all.
I will let emil comment on this, I just wanted to point to it to be
thorough.
Alex.
Best regards
Sergio
On 31/03/2017 10:47, Alexandre GOUAILLARD wrote:
I think during Emil s RTX presentation at perc in Chicago the room also
wanted fec/RTX to be HBH.
Emil was mentioning that for a few cases though it needs to be e2e:
- when a real RTX is sent from the receiver end and the me does not have a
copy at hand,
- when the window for which you keep packet along is different on the
receiver side and the md side.
I might translate it poorly, and Emil will sirry explain it better.
In any case, I think Emil eventually agreed it was acceptable to just
treat it as HBH.
Alex
Sent from my iPhone
On 31 Mar 2017, at 15:22, Sergio Garcia Murillo <
sergio.garcia.murillo@xxxxxxxxx> wrote:
Hi all,
Not sure if you have being following the discussions on the perc list, but
I would like to recap some thoughts I have about perc current state:
- RTP extensions can't be E2E, because they are negotiated HBH and
different peers may support different headers, and even for the shared
ones, they may have different ids. Also, most extensions, except video
orientation, are meant to be used HBH, not e2E
- Because of that, extensions can only be HBH, and that crazy stuff of
putting the OBH between the E2E and the HBH headers can be avoided and just
place OBH normally.
- IMHO, FEC/RTX should be HBH and applied over the inner encryption
payload. The probing RTX packets should apply the padding on the "outer
packet", that is, the RTX would carry an empty encrypted payload, and they
will be then HBH.
- It could be possible to move the OHB to the packet payload from MD
to endpoint (even we could just include the whole RTP Header as OHB).
This modifications would make implementation on the SFU to be almost
transparent, and also the implementation on chrome would be simplified as
well.
What do you think?
Best regards
Sergio
--
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
President - CoSMo Software Consulting, Singapore
------------------------------------------------------------------------------------
sg.linkedin.com/agouaillard
-
--
