Hi, just about 100% feature-function:feature-function migrated off of that other platform.  Bit of a learning curve but loving freeSWITCH.<br><br>Thanks for just a great project!<br><br>All is working.  Our edge router&#39;s NAT is very robust and configurable (openBSD&#39;s pf) and we&#39;re using STUN.  However, in comparing the old sip traces to <br>
the fs sip traces, we have noticed something that I just don&#39;t know what to tinker with.<br><br>With regard to the following fs sip trace output frag,<br><br><span style="font-family:courier new,monospace">Contact: &lt;sip:gw+trunk-voipms@<span style="background-color:rgb(255,255,0)">192.168.2.3</span>:5080;transport=udp;gw=trunk-voipms&gt;<br>
To: &lt;sip:<span style="background-color:rgb(255,0,0)">99.1.2.3</span>:5080&gt;;tag=0myeUN32NySac<br></span><br>With the &#39;other&#39; config, we&#39;d instead see,<br><br><span style="font-family:courier new,monospace">Contact: &lt;sip:gw+trunk-voipms@<span style="background-color:rgb(255,255,0)"><a href="http://mydomain.ca">mydomain.ca</a></span>:5060;transport=udp;gw=trunk-voipms&gt;<br>
To: &lt;sip:<span style="background-color:rgb(255,0,0)"><a href="http://mydomain.ca">mydomain.ca</a></span>:5060&gt;;tag=0myeUN32NySac<br></span><br>Rolling forward, we&#39;d prefer the <a href="http://mydomain.ca">mydomain.ca</a> flavor.<br>
<br>We operate a DNS with split horizon and SRV records, meaning public-outside, in fact, see&#39;s/resolves 99.1.2.3, and inside hosts and end points, in fact, see/resolve 192.168.2.3.<br><br>We think it&#39;s one of the force-&lt;&gt;-domain or db-domain params but (our bad) cannot &quot;get it right.&quot;<br>
<br>Any thoughts as to the correct fs param=&quot;?&quot; sip such that the fs sip-domain-string is used where that sip-domain-string that also is properly glued to a matching (resolvable) DNS-string?<br><br>Thanks,<br><br>
<br>