@@ 0,0 1,50 @@
+From 90351465cb8c02b008bc32e149266313ee45a43b Mon Sep 17 00:00:00 2001
+From: Christopher Vollick <0@psycoti.ca>
+Date: Thu, 11 Mar 2021 14:57:20 -0500
+Subject: [PATCH] Hacky "support" for Renomination
+
+This is a feature libwebrtc supports, that's barely standardized.
+But if a client uses it, then it uses an alternative attribute for
+nomination, and the value of this attribute is taken as a monotonically
+increasing number, telling us to choose whichever option they nominated
+"most recently", ignoring priority.
+
+Since it's an alternative attribute, if we don't understand it then we
+think the controlling side hasn't nominated anything.
+So it's a bigger change to actually implement the storage of nomination
+counter and use that instead of priority.
+But if we just treat it as a normal "USE-CANDIDATE"... then it should at
+least work better than nothing.
+
+I'm hoping the other side will be tolerant to our limited understanding
+of nomination.
+---
+ pjnath/src/pjnath/ice_session.c | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+diff --git a/pjnath/src/pjnath/ice_session.c b/pjnath/src/pjnath/ice_session.c
+index c51dba771..e2c5c3cb8 100644
+--- a/pjnath/src/pjnath/ice_session.c
++++ b/pjnath/src/pjnath/ice_session.c
+@@ -2540,6 +2540,19 @@ static pj_status_t on_stun_rx_request(pj_stun_session *sess,
+ /* Get USE-CANDIDATE attribute */
+ uc_attr = (pj_stun_use_candidate_attr*)
+ pj_stun_msg_find_attr(msg, PJ_STUN_ATTR_USE_CANDIDATE, 0);
++ /*
++ * CV:
++ * Simple, incomplete, support for renomination.
++ * This header has a value with an incrementing number, and we should
++ * always consider the highest value of this as the true nomination.
++ * But that means changing how priority works, etc, so for now just
++ * consider them nominated and hope it works anyway...
++ */
++ if (uc_attr == NULL) {
++ uc_attr = (pj_stun_use_candidate_attr*)
++ pj_stun_msg_find_attr(msg, 0xC001, 0);
++ }
++
+
+
+ /* Get ICE-CONTROLLING or ICE-CONTROLLED */
+--
+2.25.1