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's NAT is very robust and configurable (openBSD's pf) and we're using STUN. However, in comparing the old sip traces to <br>
the fs sip traces, we have noticed something that I just don'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: <sip:gw+trunk-voipms@<span style="background-color:rgb(255,255,0)">192.168.2.3</span>:5080;transport=udp;gw=trunk-voipms><br>
To: <sip:<span style="background-color:rgb(255,0,0)">99.1.2.3</span>:5080>;tag=0myeUN32NySac<br></span><br>With the 'other' config, we'd instead see,<br><br><span style="font-family:courier new,monospace">Contact: <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><br>
To: <sip:<span style="background-color:rgb(255,0,0)"><a href="http://mydomain.ca">mydomain.ca</a></span>:5060>;tag=0myeUN32NySac<br></span><br>Rolling forward, we'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'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's one of the force-<>-domain or db-domain params but (our bad) cannot "get it right."<br>
<br>Any thoughts as to the correct fs param="?" 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>