Nathan,
The best thing to do right now is to get a complete trace of these failed calls. Clear your logs, regenerate the failed calls and grab a merged Xml file. With that, I'm sure someone on this list will be able to point you in the right direction fairly quickly. My guess is that you do not have a single problem here, but several small ones. You will most likely have to attack these individually to come to a resolution. The trace file is the starting point. From: [email protected] [mailto:[email protected]] On Behalf Of Nathan Nieblas Sent: Monday, January 04, 2010 11:30 PM To: Josh Patten; [email protected] Subject: Re: [sipx-users] multi site deployment The SIP inspection is only done for Internet sourced and destined packets, anything over VPN bypasses these rules. Since bandwidth.com is sending me SIP traffic over 5080, the only thing SIP inspection is handling is outbound calling and remote workers connecting to the PBX over the Internet. We have less than 10 extensions at each location and the slowest link is 3mbit/768kbit DSL, the Datacenter has a 100mbit pipe. Each location has a unique subnet but there are no restrictions in regards to communication between them. My main concern right now is operability for incoming call handling, redundancy is taking a back seat until this actually works normal. I am completely puzzled as to why these Polycom's cannot dial the Cisco's, when the Cisco's can call the Polycom's and Polycom's can dial eachother. Is there a recommended Cisco firmware I should not go past as well? I have the phones on 8.5.2 right now. This page is obviously a little outdated: http://sipx-wiki.calivia.com/index.php/HowTo_configure_Cisco_SIP_phone_with_ sipX Thanks From: Josh Patten [mailto:[email protected]] Sent: Monday, January 04, 2010 9:07 PM To: Nathan Nieblas; [email protected] Subject: Re: [sipx-users] multi site deployment If all of your sites are VPN'd together and subnet-to-subnet communication between sites is transparent over the VPN connection then there should be no need to be messing with the SIP packets in the firewall. That document is the framework for a fault resistant sipX setup. While the setup you have outlines will work just fine, if one of your site links goes down then your phones will too. With a redundant setup like the one outlined in the DNS document if a site link goes down users will still be able to perform basic calling scenarios and dial 911, which in most cases is very important. My suggestion is to buy an FXO gateway for each location, set up the emergency dial rule with location based settings for each FXO gateway and see if you can get the local telco to install a 911 only phone line for cheap. In my case I have to pay for a full local line every month per location (upwards of $45 a month) but it has proven worth it's salt to have a secondary server and FXO gateway when there was actually a situation where the network was down to the site and there was a medical emergency. You can still keep the main installation in the datacenter, but I'd recommend putting small inexpensive secondary servers in place for redundancy. Out of curiosity how many extensions are you running at each site, and how much bandwidth do you have between your sites? Nathan Nieblas wrote: Based on that DNS document, my assumption is that I should have a local sipX box at each location rather than a cluster residing in the datacenter? Polycom's are on 3.2.2, I will downgrade them to 3.1.3c and see what happens. All phones are showing up registered. What I mean by SIP inspection is that the firewall is essentially handling the SIP protocol for translation sanity (since it's being NAT'd) and security. -----Original Message----- From: Josh Patten [mailto:[email protected]] Sent: Monday, January 04, 2010 8:21 PM To: Nathan Nieblas Cc: [email protected] Subject: Re: [sipx-users] multi site deployment http://wiki.sipfoundry.org/display/xecsuserV4r0/Setting+up+BIND+with+loc ation+based+views+for+sipX this may be helpful for you to implement as it creates a much more redundant setup As far as the other issues you are experiencing, make sure your Polycom phones are on a firmware revision no later than 3.1.3c. 3.2 and up has known issues with sipX and should be avoided until sipX version 4.2 is released. Also, are all of your phones showing up in the registration table? What do you mean by "SIP injection"? sipX and sipXbridge generally work best when the SIP messaging isn't messed with by a third party product. Nathan Nieblas wrote: I come from a Cisco Call Manager background and I am trying to apply the same centralized concept/design for a sipX deployment... I'm just gonna throw what I think would be all relevant facts out there and hopefully one of you guys can point me in the right direction. Thanks in advance. Scenario: 1 Head office, 2 branch offices, 1 Datacenter All locations are connected by VPN tunnel. Mixture of Polycom and Cisco phones PBX located in datacenter, virtualized on ESXi 4.x We are randomly having issues with 1-way audio after putting a call on hold and resuming it or being picked up from call park. The issue appears to be related with calls that originate from the Auto Attendant. Another issue appears to be that Polycom phones cannot dial extensions on Cisco phones and the call ends up in voicemail but works the other way around. I have all phones pulling their configuration from the TFTP server on the sipX box so I'm assuming there shouldn't be any URI/SIP preferences missing that would keep the phones from talking the same language. This is my digitmap on the Polycom's, our extension ranges are 100-113, 200-205, 400, 700-705 and 1200-1203: [2-9]11|0T|10x|11x|[2-7]xx|120x|*xxxx|011xxx.T|9011xxx.T|1[2-9]xxxxxxxxx |91[2-9]xxxxxxxxx|9[2-9]xxxxxx|[8]xxx The PBX assigned a private address and is NAT'd behind a Cisco ASA that's handling all the SIP inspection, Bandwidth.com is our trunk provider. I have calls delivering over port 5080 to a local sipXbridge and I have SIP inspection also being done over that port with the ASA. I have nothing special configured for inspection. What could I be doing wrong here? Nathan Nieblas SACA Technologies, Inc. _______________________________________________ sipx-users mailing list [email protected] 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 [email protected] 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/
