Don't forget Antony's alternative idea posted in the same thread. Either way will probably work, but I would recommend investigating both methods to see if one fits your needs better than the other.<br><br>-MC<br><br>
<div class="gmail_quote">On Mon, Feb 13, 2012 at 5:40 PM, Tim St. Pierre <span dir="ltr"><<a href="mailto:fs-list@communicatefreely.net">fs-list@communicatefreely.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That sounds like a possibility.<br>
<br>
I could come up with something like 'If the first three octets of the<br>
source rtp is the same as the first three octets of the destination rtp<br>
AND both endpoints are in the nonat profile THEN execute uuid_media on<br>
the channel.<br>
<br>
Each office on a tunnel is given a private class C address block that is<br>
unique to that customer (phones are on their own VLAN that I have<br>
control over). We have a sofia profile dedicated to these tunneled<br>
connections, so we can assume that if both ends are in this profile and<br>
on the same subnet, that they are routable.<br>
<br>
If I really wanted to, I could make all addresses on the nonat profile<br>
routable to each other (would involve OSPF or some other dynamic routing<br>
protocol to propagate the subnets properly), but it could be done. That<br>
way, all I have to match for is that they are on the same profile.<br>
<br>
Thanks for the help!<br>
<br>
-Tim<br>
<br>
<br>
Michael Collins wrote:<br>
> Well, there is this API:<br>
><br>
> <a href="http://wiki.freeswitch.org/wiki/Mod_commands#uuid_media" target="_blank">http://wiki.freeswitch.org/wiki/Mod_commands#uuid_media</a><br>
><br>
> You might be able to do something like api_on_answer on the bridge.<br>
> The key for you is just doing a condition that matches when the caller<br>
> and callee are in the same office. All things being equal, how do you<br>
> know when the caller and callee are in the same office?<br>
><br>
> -MC<br>
><br>
> On Mon, Feb 13, 2012 at 8:59 AM, Tim St. Pierre<br>
> <<a href="mailto:fs-list@communicatefreely.net">fs-list@communicatefreely.net</a> <mailto:<a href="mailto:fs-list@communicatefreely.net">fs-list@communicatefreely.net</a>>><br>
> wrote:<br>
><br>
> Hello,<br>
><br>
> In order to eliminate NAT issues, we have built routable tunnels<br>
> to our<br>
> larger customers so that their phones are on a private subnet that is<br>
> routable to a private subnet at our datacenter. Each Freeswitch<br>
> system<br>
> has a profile called nonat that uses an interface and address bound to<br>
> this network. The remaining customers register to the "internal"<br>
> profile, which is bound to a public IP address.<br>
><br>
> At the moment, everything works just great - no nat issues, instant<br>
> failover between the primary and secondary (shared registrations<br>
> in DB),<br>
> but all media flows through our network.<br>
><br>
> If someone in office A calls another phone in office A, I would<br>
> like FS<br>
> to instruct the phones to send their media direct. The addresses and<br>
> ports are all correct in this case.<br>
> If someone in office A calls a phone in office B, I want Freeswitch to<br>
> stay in the media path, as these two offices are not routable to each<br>
> other, even though each is routable to Freeswitch.<br>
><br>
> Is there a way to set up a profile (or dialplan) so that FS will<br>
> bypass<br>
> media only if the two endpoints are on the same subnet? An ACL isn't<br>
> really the right thing, since it would require an exponential<br>
> number of<br>
> ACLs. Also, many calls go to ring groups, where several phones<br>
> ring and<br>
> we don't know which one will answer until it actually does<br>
> (eliminating<br>
> some sort of dialplan code using the rtp variables).<br>
><br>
> Is this possible?<br>
><br>
><br>
><br>
> _________________________________________________________________________<br>
> Professional FreeSWITCH Consulting Services:<br>
> <a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a> <mailto:<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a>><br>
> <a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
><br>
> FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
> <a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
><br>
> Official FreeSWITCH Sites<br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
> <a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
> <a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
><br>
> FreeSWITCH-users mailing list<br>
> <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
> <mailto:<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a>><br>
> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
><br>
><br>
> ------------------------------------------------------------------------<br>
><br>
> _________________________________________________________________________<br>
> Professional FreeSWITCH Consulting Services:<br>
> <a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
> <a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
><br>
> FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
> <a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
><br>
> Official FreeSWITCH Sites<br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
> <a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
> <a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
><br>
> FreeSWITCH-users mailing list<br>
> <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
><br>
<br>
<br>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</blockquote></div><br>