~singpolyma/asterisk

267252f2e227162c88985ec0a4efd8b8baba7259 — Christopher Vollick 23 days ago 642ccf2 master
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.
1 files changed, 50 insertions(+), 0 deletions(-)

A third-party/pjproject/patches/0030-Hacky-support-for-Renomination.patch
A third-party/pjproject/patches/0030-Hacky-support-for-Renomination.patch => third-party/pjproject/patches/0030-Hacky-support-for-Renomination.patch +50 -0
@@ 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