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.

-MC

On Mon, Feb 13, 2012 at 5:40 PM, Tim St. Pierre <fs-list@communicatefreely.net> wrote:
That sounds like a possibility.

I could come up with something like 'If the first three octets of the
source rtp is the same as the first three octets of the destination rtp
AND both endpoints are in the nonat profile THEN execute uuid_media on
the channel.

Each office on a tunnel is given a private class C address block that is
unique to that customer (phones are on their own VLAN that I have
control over).  We have a sofia profile dedicated to these tunneled
connections, so we can assume that if both ends are in this profile and
on the same subnet, that they are routable.

If I really wanted to, I could make all addresses on the nonat profile
routable to each other (would involve OSPF or some other dynamic routing
protocol to propagate the subnets properly), but it could be done.  That
way, all I have to match for is that they are on the same profile.

Thanks for the help!

-Tim


Michael Collins wrote:
> Well, there is this API:
>
> http://wiki.freeswitch.org/wiki/Mod_commands#uuid_media
>
> You might be able to do something like api_on_answer on the bridge.
> The key for you is just doing a condition that matches when the caller
> and callee are in the same office. All things being equal, how do you
> know when the caller and callee are in the same office?
>
> -MC
>
> On Mon, Feb 13, 2012 at 8:59 AM, Tim St. Pierre
> <fs-list@communicatefreely.net <mailto:fs-list@communicatefreely.net>>
> wrote:
>
>     Hello,
>
>     In order to eliminate NAT issues, we have built routable tunnels
>     to our
>     larger customers so that their phones are on a private subnet that is
>     routable to a private subnet at our datacenter.  Each Freeswitch
>     system
>     has a profile called nonat that uses an interface and address bound to
>     this network.  The remaining customers register to the "internal"
>     profile, which is bound to a public IP address.
>
>     At the moment, everything works just great - no nat issues, instant
>     failover between the primary and secondary (shared registrations
>     in DB),
>     but all media flows through our network.
>
>     If someone in office A calls another phone in office A, I would
>     like FS
>     to instruct the phones to send their media direct.  The addresses and
>     ports are all correct in this case.
>     If someone in office A calls a phone in office B, I want Freeswitch to
>     stay in the media path, as these two offices are not routable to each
>     other, even though each is routable to Freeswitch.
>
>     Is there a way to set up a profile (or dialplan) so that FS will
>     bypass
>     media only if the two endpoints are on the same subnet?   An ACL isn't
>     really the right thing, since it would require an exponential
>     number of
>     ACLs.  Also, many calls go to ring groups, where several phones
>     ring and
>     we don't know which one will answer until it actually does
>     (eliminating
>     some sort of dialplan code using the rtp variables).
>
>     Is this possible?
>
>
>
>     _________________________________________________________________________
>     Professional FreeSWITCH Consulting Services:
>     consulting@freeswitch.org <mailto:consulting@freeswitch.org>
>     http://www.freeswitchsolutions.com
>
>     FreeSWITCH-powered IP PBX: The CudaTel Communication Server
>     http://www.cudatel.com
>
>     Official FreeSWITCH Sites
>     http://www.freeswitch.org
>     http://wiki.freeswitch.org
>     http://www.cluecon.com
>
>     FreeSWITCH-users mailing list
>     FreeSWITCH-users@lists.freeswitch.org
>     <mailto:FreeSWITCH-users@lists.freeswitch.org>
>     http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>     UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>     http://www.freeswitch.org
>
>
> ------------------------------------------------------------------------
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting@freeswitch.org
> http://www.freeswitchsolutions.com
>
> FreeSWITCH-powered IP PBX: The CudaTel Communication Server
> http://www.cudatel.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users@lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>


_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org