Jump to content

Parks

Members
  • Posts

    115
  • Joined

  • Last visited

Parks's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. I'm not following understanding. Currently all snom phones have an ip address in their outbound proxy setting. If we wanted to move them to another cluster and their provisioning address is that of the old cluster we would have to do lots of manual work updating their provisioning addresses to their new server, correct?
  2. No so in the outbound proxy setting we place sip:voip.vonvox.net:5061;transport=tls which gets resolved to sip:216.218.236.2:5061;transport=tls after the snom phone reboots. So now if we wanted to move this customer to another cluster we would have to manually update this field in all their phones. Hope this is more clear.
  3. Is there a way to stop this. If we ever wanted to move the pbxnsip we would have to manually go into each snom endpoint and make the change. This isn't going to be possible without having users down for some time which is unacceptable.
  4. For several months now this hasn't been working but I not need to pnp new phones on this system. Here is what the snom logfile says: [5]24/12/2001 00:00:09: Using GUI language English from: /mnt/snomlang/gui_lang_EN.xml [5]24/12/2001 00:00:10: Using WEB language English from: /mnt/snomlang/web_lang_EN.xml [5]24/12/2001 00:00:10: read_xml_settings: found dial-plan XML header [5]24/12/2001 00:00:10: read_xml_settings: found one byte encoding: 0 [5]24/12/2001 00:00:18: DHCP: Received IP address 192.168.5.201 [0]24/12/2001 00:00:18: tcp::set_port: Default SO_RCVBUF=43689 [0]24/12/2001 00:00:18: tcp::set_port: Default SO_SNDBUF=16384 [5]24/12/2001 00:00:18: Opening TCP socket on port 843 [5]24/12/2001 00:00:23: Setting server was already set: http://voip.vonvox.net/provisioning/snom360-{mac}.htm [5]24/12/2001 00:00:23: Fetching URL: http://voip.vonvox.net/provisioning/snom360-000413291522.htm [5]24/12/2001 00:00:30: sip::process_challenge:No nonce found on response [2]23/12/2001 16:00:33: start_dst(984276000) end_dst(1004839200) offset_dst(3600) offset_utc(-28800) [2]23/12/2001 16:00:33: start DST: 03/11/2001 02:00:00 (984276000) [2]23/12/2001 16:00:33: end DST: 11/04/2001 02:00:00 (1004839200) [5]23/12/2001 16:00:34: read_xml_settings: found phone-book XML header [5]23/12/2001 16:00:34: read_xml_settings: found one byte encoding: 0 [5]23/12/2001 16:00:34: Using GUI language English from: /mnt/snomlang/gui_lang_EN.xml [5]23/12/2001 16:00:35: Using WEB language English from: /mnt/snomlang/web_lang_EN.xml [0]23/12/2001 16:00:36: tcp::set_port: Default SO_RCVBUF=43689 [0]23/12/2001 16:00:36: tcp::set_port: Default SO_SNDBUF=16384 [5]23/12/2001 16:00:36: Opening TCP socket on port 80 [0]23/12/2001 16:00:36: tcp::set_port: Default SO_RCVBUF=43689 [0]23/12/2001 16:00:36: tcp::set_port: Default SO_SNDBUF=16384 [5]23/12/2001 16:00:36: Opening TCP socket on port 443 [2]28/3/2010 15:44:35: start_dst(1268532000) end_dst(1289095200) offset_dst(3600) offset_utc(-28800) [2]28/3/2010 15:44:35: start DST: 03/14/2010 02:00:00 (1268532000) [2]28/3/2010 15:44:35: end DST: 11/07/2010 02:00:00 (1289095200) Please let me know your thoughts, thanks.
  5. I rebuilt the server again last night. So far so good. Keeping my fingers crossed. We didn't update windows through September but rather through April. Hopefully everything is fixed.
  6. We are using pnp. Where is the directory for this that we can look at the settings?
  7. I don't think you read my last post because WE DON'T use windows firewall at all. It's also not on every calls so leaving wireshark on might be hugh but guess I can always try it.
  8. I understand that the default is 160 per snoms wiki but it doesn't go into detail on changing this. I've even when to the gui in the phones and changed the qos diffser in the advanced tab to 25 46 but calls are still be tagged 160. Please let me know if you have dealt with this and how to correct it.
  9. We don't have windows firewall but do use juniper and that's been fine as we have the tcp and udp ports open for the sip and rtp traffic. We have the cdrs duration set to 90 days which should be fine. I can always change sense we don't use the pbxnsip cdrs. What would I be looking for in the pcap?
  10. We're experiencing this and believe it's because of a recent windows update. We reinstalled the os and it still happens. Can or does anyone have any other ideas? Basically the pbxnsip service doesn't auto start on reboot and when starting manually can take a few tries. It goes half way and hangs and sometimes starts and sometimes gives an error message that M$ doesn't have any help with.
  11. Ok. My linux and network engineer is testing with Debian because of how it handles packet management. We're going to deploy with 2 servers to start and use NFS for syncing. Thanks for the input as well.
  12. We want to move away from MS and into something more reliable but would like to know which version is more suggested for clusters. Any suggestions would be great.
  13. That is what I needed to do. Thanks all for your help.
  14. We are testing the newest stable release from our 3.1.x.xxxx version. We're not able to have the switch send the 1 as it always removes it before sending to our class 4 switch for routing. We have the following in the dialplans: xxxxxxx -> 1925* xxxxxxxxxx -> 1* xxxxxxxxxxx -> blank 011* -> 011* Why is it removing the leading 1 every time?
  15. This scenario only applies if the 911 operator needs to call back the caller but the whole point of registering each location is to have it auto route to the nearest 911 call center. enable911 charges you if you go through the national operator an extra $100 per attempt. If we are using 1 trunk to propagate this ANI it's always going to be the same. Am I missing understanding this? Anyway I can call to speak about it?
×
×
  • Create New...