Closed kyzer-davis closed 1 year ago
Paraphrasing feedback from IETF individual discussions: "We know how implementations will handle unknown SDP attributes; we do not know well how well how implementations will handle unknown SDP Security Session Parameters"
Nothing to add here, this is more of a discovery based on feedback, if Jonathan Lennox sees this as a potential interop issue, I rather go with the least impacting for better adoption.
From RFC4568
Examples of theoretical declarative SDP Security Session Parameters for ROC, SEQ, SSRC conveyance:
My Analysis:
a=crypto
then other side has to support it else they are obligated to fail the session (assuming no alternative exist) e.ga=crypto1: ... ROC=0x1
being unknown could break things if that is the onlya=crypto
option in the SDP.a=crypto1: ... -ROC=0x1
ROC=
would mean crypto:1 is invalid and fallback to crypto:2 which is the same thing as crypto 1... kind of like what I see now with UNAUTHENTICATED_SRTP where a party may send two identical lines with and without the postfix....So in closing:
a=srtcpctx
loosely coupled with the crypto line of choice by mapping tags.Would also need to consider how this scales as per #1, the a=crypto gets very long even if you coupled them nicely wrapped in start/stop delimiters.