<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 08.10.2020 00:42, Jeff Pyle wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAPhW+0KXzdtcpnxjWBKvm2dSEadnYk_-z2Opv_yxo8CnXS=6KA@mail.gmail.com">The
registered contact of a user is
<a class="moz-txt-link-rfc2396E" href="mailto:sip:+12162454107@192.168.201.123:4135;rinstance=946433DE">"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"
moz-do-not-send="true">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 class="moz-signature" cols="72">--
Liviu Chircu
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/liviuchircu">www.twitter.com/liviuchircu</a> | <a class="moz-txt-link-abbreviated" href="http://www.opensips-solutions.com">www.opensips-solutions.com</a></pre>
</body>
</html>