| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
See the attached. This is both internal LAN clients and also external
(NAT'd) clients. The quality is perfect and the reliability has been
rock solid once the configuration bugs were worked out. I'm running on a
quad core Xeon X3220 2.4Ghz with 2gb of RAM and a 80 gb HD. CPU usage
hasn't gone above 6% yet but the RAM always stays pretty full:
[root@pbx ~]# free -m
total used free shared buffers
cached
Mem: 2010 1891 118 0 238
621
-/+ buffers/cache: 1031 978
Swap: 6142 0 6141
On Fri, 2009-07-03 at 04:56 -0400, Picher, Michael wrote:
> My $0.02...
>
> If you are building a phone system on a hobbled together foundation (the
> network), you'll end up with a hobbled together phone system. For 3 or
> 4 phones this may not matter. For anything more than that the system
> will not scale well and users will get disgusted with reliability and
> call quality.
>
> Mike
>
> -----Original Message-----
> From: sipx-users-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:sipx-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Matt Keys
> Sent: Thursday, July 02, 2009 10:39 PM
> To: Rob Hicks
> Cc: sipXecs mailing list
> Subject: Re: [sipx-users] Possible Deployment Scenario
>
> I tried an almost identical setup with a 4.0 release and failed
> miserably. What will happen is your internal clients will attempt to
> register to the public IP and a loop will be created on the sipx box.
> Trust me on this one--it just won't work right. You may be able to hack
> various things to where it will only respond on certain interfaces but
> that setup is totally unsupported right now. Don't expect to get help
> from the devs if you try.
>
> I can tell you what I did instead and maybe it'll help you in your
> situation. We already had a internal network equipped with a MS server
> handing DHCP and DNS. In order for everything to work as it should and
> to make the setup easier I created a separate network and just plugged a
> jumper from switch to switch. :
>
> WAN1 -> 192.168.1.0/24 -> Workstations/Desktops/Printers with static IPs
> pointing to MS server for DNS and other services.
>
> WAN2 -> 172.16.1.0/24 -> DHCP/DNS from sipx, clients are all phones and
> any "guests" that plug in or wireless clients.
>
> I didn't have to re-wire the phone drops, I could still use the
> "computer" port on the back of our Polycom phones for desktop
> connections, and because the computers were static their gateway and DNS
> remained the same (outbound/inbound traffic remained separate). DHCP
> addresses get handed out by sipX and the switches are cool with it
> because it's just broadcast traffic. No need to vlan, buy additional
> equipment, or rewire but this is a pretty small setup we're talking
> about... your mileage may vary. In my particular case I don't really
> care if 172.16.0.1/24 knows how to get to 192.168.1.0/24 and vice versa
> but since my sipxecs server has two nics I could probably plug the other
> one into the 192 side, create a static IP, and setup routing in between
> the two if needed.
>
> HTH,
> Matt
>
> On Thu, 2009-07-02 at 15:51 -0600, Rob Hicks wrote:
> > Hi.
> >
> > Is it possible to deploy sipXecs with a network configuration where
> > sipXecs has both a public IP address and a public IP address. Only the
> > Trunking Service would be connected through the public IP address.
> >
> > Thanks!
> > Rob
> > _______________________________________________
> > sipx-users mailing list sipx-users@xxxxxxxxxxxxxxxxxxx
> > List Archive: http://list.sipfoundry.org/archive/sipx-users
> > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
> > sipXecs IP PBX -- http://www.sipfoundry.org/
> _______________________________________________
> sipx-users mailing list sipx-users@xxxxxxxxxxxxxxxxxxx
> List Archive: http://list.sipfoundry.org/archive/sipx-users
> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
> sipXecs IP PBX -- http://www.sipfoundry.org/
Attachment:
registrations.png
Description: PNG image
