<div dir="ltr"><div>Here's what I have working so far, based on the <a href="https://www.opensips.org/Documentation/Script-CoreFunctions-3-1#toc29">remove_branch() example</a> from the documentation. <br></div><div><br></div><div><font face="monospace">route {</font></div><div><font face="monospace">        <i>...things...</i></font></div><div><font face="monospace">        # Preserve this before fix_nated_contact() breaks it</font></div><font face="monospace">        $var(ct_uri) = $(ct.fields(uri){nameaddr.uri});</font><div><font face="monospace">        <i>...other things...</i></font></div><div><font face="monospace">}</font></div><div><font face="monospace"><br></font><div><font face="monospace">route[preauth] {<br>        if (is_gflag(0)) xlog("L_NOTICE", "[C5] Entering preauth route $fU -> $rU\n");<br><br>        if (!lookup("location", "B", $fu)) {<br>                if (is_gflag(0)) xlog("L_NOTICE", "[C5] ...lookup failed, returning -1\n");<br>                return(-1);<br>        }<br><br>        resetflag("PREAUTH_OK");<br>        $var(i) = 0;<br>        while ($(branch(uri)[$var(i)]) != null) {<br>                if ($var(ct_uri) == $(branch(uri)[$var(i)]{nameaddr.uri}) && <br>                    $si == $(branch(duri)[$var(i)]{uri.host}) &&<br>                    $sp == $(branch(duri)[$var(i)]{uri.port})) {<br>                        if (is_gflag(0)) xlog("L_NOTICE", "[C5] ...found match $(branch(uri)[$var(i)]) ($(branch(duri)[$var(i)])) \n");<br>                        setflag("PREAUTH_OK");<br>                }<br>                $var(i) = $var(i) + 1;<br>        }<br><br>        $var(i) = 0;<br>        while ($(branch(uri)[$var(i)]) != null) {<br>                remove_branch($var(i));<br>        }<br><br>        if (isflagset("PREAUTH_OK")) {<br>                return(1);<br>        } else {<br>                return(-1);<br>        }<br>}<br></font></div><div><br></div><div>This loads the registered contacts as branches, which allows me to iterate through each and compare 1) the base URI from the inbound INVITE with the base URI of the registered contact, 2) the received IP and 3) the received port.  Assuming one matches, that's enough to satisfy me that we've received a message from a registered endpoint.  I'm calling this route on initial INVITEs and so far, so good.  There are optimizations that could occur, such as exiting the while loop once we've found a match, but at least this works.</div><div><br></div><div><br></div><div>- Jeff</div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 8, 2020 at 3:58 AM Liviu Chircu <<a href="mailto:liviu@opensips.org">liviu@opensips.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <div>On 08.10.2020 00:42, Jeff Pyle wrote:<br>
    </div>
    <blockquote type="cite">The
      registered contact of a user is
      <a href="mailto:sip:+12162454107@192.168.201.123:4135;rinstance=946433DE" target="_blank">"sip:+12162454107@192.168.201.123:4135;rinstance=946433DE"</a>.  When
      I place a call from that user, its INVITE's Contact is "<a href="http://sip:+12162454107@192.168.201.123:4135" target="_blank">sip:+12162454107@192.168.201.123:4135</a>". 
      is_contact_registered() fails.  Is that caused by the lack of the
      rinstance param, or something else?</blockquote>
    <p><tt>Indeed, the matching now fails strictly because of that extra
        chunk: ";rinstance=946433DE".  </tt><tt><tt>According to the
          RFC 3261</tt> URI matching rules, they are indeed different
        contacts.</tt></p>
    <p><tt>However, if you really want to go the extra mile and tolerate
        those inconsistent INVITE Contacts (with the missing URI params)
        by somehow still matching them against Contact URIs with the
        params, I don't see a clean solution *)</tt></p>
    <p><tt>*) of course, you could use the local cache and store a
        "non-param-Contact: full-Contact" key-value pair on each
        REGISTER.  During INVITE processing, you would use the cache to
        look up and "fix" any non-param-Contact with its proper value,
        buffered in the local cache.  However, it's still a hacky
        solution: what if you restart the registrar?  Then, for a while,
        some INVITEs won't route out because the Contact conversion
        won't work until they re-register and populate the cache.</tt><br>
    </p>
    <pre cols="72">-- 
Liviu Chircu
<a href="http://www.twitter.com/liviuchircu" target="_blank">www.twitter.com/liviuchircu</a> | <a href="http://www.opensips-solutions.com" target="_blank">www.opensips-solutions.com</a></pre>
  </div>

_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</blockquote></div>