Jump to content

andrewgroup

Members
  • Posts

    615
  • Joined

  • Last visited

Everything posted by andrewgroup

  1. The PBX snmp values are the same across the board. Linux has an snmp module, and if you want them on the same port "161" you may need to add a virual NIC net-snmp I believe is the linux module... a common command would read the linux values from the net-snmp linux module... snmpwalk -v 2c -c private 127.0.0.1 .1.3.6.1.2.1.2.2.1.2 Please Note - The Snom SNMP stack in both the PBX and any Snom Phone will not respond or support the SNMP WALK... you can only get values with a properly formed SNMP GET command....
  2. Sent a PM with my contact information, send me a note with details..
  3. We definitely had issues of crosstalk within active calls, and aligning the ports fixed the issues, or it was EXTREMELY coincidental. So we've posted various ITSP Port recommendations in the past. Coredial out of Philidelphia recommends RTP Ports: Port Range Start: 10000 Port Range End: 30000, We've had no issues with them... Window Stream - Nuvox when using their SONOS servers gave us these recommendations long ago. I assume they can use multiple UDP ranges for Media RTP Media - udp range 16384 32767 udp range 49152 53247 Signal Protocol - udp 5060 tcp 5060 udp range 1718 1720 tcp range 1718 1720 udp 2427 tcp 2427 udp 2000 tcp 2000 We know have a large enterprise using the BroadSoft Platform on the Paetec Division of Windstream and working through the re-occurance of call issues. I personally called the client and appeared to have been connected to an in progress call..
  4. Thanks for the Snappy reply, but in the past, we've have situations where callers appeared to be cross connected, and the issues were resolved by matching the PORT range with the port range information provided by the carrier. IE Windstream / Nuvox Communications on their SONOS sip servers recommend the following ports. These SIP trunks are not behind NAT devices and making these adjustments fixed the issues at the time. RTP Media - udp range 16384 32767 udp range 49152 53247 We now make sure and ask the tech support groups at any carriers and see if they make recommendations. This new trunk, just added a week ago, in on a BroadSoft Platform, and they recommended the MEDIA ports to be 35000-40000 I'm sure the carriers have to create some sort of acceptable port values in their equipment, so it seemed logical to match that. This new PBX and SERVER is running Windows Server 2008, and their is a known issue with DNS grabbing a range of PORTS for DNS services, but I don't think that had any effect or issue within only the DNS client.. We'll dig some more and get a trace.
  5. When you have two trunks configured from two seperate providers and dial plans allowing the use of either trunk. How do we deal with the issue of each ITSP requesting the RTP ranges to be in two different Port Ranges. Example 35000 - 40000 for ITSP provider #1 and 49152-53247 for ITSP provider # Do we simply put 35000-53247 and let the SDP packets negotiate the final set of ports that will be used? Do we select the "FOLLOW RTP" option on the ports settings page? We recently added another SIP provider, and we are experiencing dropped calls... We think this may be the issue. (I just placed an inbound call, and was connected to what appeared to have been an active call hearing one side of an active call.
  6. On advise, I am making a second post about call accounting software options. We have a call center prospect and they have an interesting request. (outbound calling only) they would like a shift report that shows the IDLE time that this extension was making no calls, regardless of being on hold, talking or otherwise. they are a 30+ year old firm with ZERO technology, and a the owners believe this is the single most important report... From that report they can drill down to more information if needed. they operate on shifts so a reporting that shows EXTENSION IDLE or NO CALL TIME from 8:00 - 12:00 arriving at 12:15 will immediately highlight potential trouble spots. The second shift report from 13:00-17:00 arriving at 17:15 addresses the afternoon shift.. It seems the available Call Reporting Software only reports on activity (not the lack of calls) Sure a little math gives you a number, but having a canned report is not to much to ask. Your thoughts,,,
  7. We've recently completed a reasonable advanced and agressive setup to help a client.. We have a 10MB Fiber Trunk from Windstream Communications and the VoIP trunk originates on the PAETEC Broadsoft platform. On the trunk they provide 5 static non routable IP addresses of our choosing, 10.x.x.x, 172.x.x.x or 192.168.x.x These five IP addresses are the interface to our PBX... We have a PBX on 2 IP addresses and they have provisioned their SIP trunk to do out of band sip inquiries to the trunk. In the event the primary PBX fails to respond "200" the next inbound call we be delivered to the second PBX on another trunk. They continue to poll the first PBX and when it reponds, the call resume on the primay PBX. We also have an enterprise option, allowing the PBX's to deliver the originating Call ID to a number the call may be transferred too.. They have 24 x 7 emergency inbound calling and it's important the on-call folks see the original caller ID and the area codes they come from. A note of interest the second PBX can be configured to place calls against the primary and secondary trunk simultaneously. this environment creates a fully redundant system at the carrier environment as opposed to trying to make multiple servers failover and use the same trunk. If you have clients with this level of requirements, please PM us and we can get you in touch with the consultant and companies that can make this happen. (We have no vested interest, but wanted to share the positive experience.) Cheers - Andy
  8. actually I believe the testing of the SIP trunk is more advanced than that. We simply outpulse the appropriate AREA CODE ANI where we have the carrier provisioned numbers, and they deliver the call through the PSTN carriers to the local numbers. All of this occures on a single SIP trunk. We simply need to make sure we only present the correct numbers in the ANI stream. So we thought we would make extensions with the correct ANI's and register multiple phones against that number... Assume my explanations of the SIP trunk will work as described, we are wondering if their is a dynamic method to allow any extension to call into any area code. By way of an agent group, dial plan, or other interesting method. Thanks...
  9. We have an "Old School" manual outbound call center that focuses all of it's dialing into less than 2 dozen area codeds among a dozen calling agents. Groups of 2,3 or 4 agents dial into these areas during a campaign. Here is the plan to help improve there success. We have a national provider than can provision our SIP trunk to deliver these area codes on our SIP trunk and will outpulse and originate the outbound call to the area codes so the recepient sees a friendly area code. We hope to eliminate the need to dial the area code in one of several ways. 1. Agent Groups are for inbund calls only. No Help 2. We make Extensions with AREA code ANI's and register 1,2,3, or 4 phones on that extension. (This seems to be the best choice) This method is static and offers little flexibility 3. Create dial plans that insert the correct area code example 10555-5555 the diail plan see beginning two digitis [10] and inserts a three digit dial plan. [11] etc.... [12]..... This would allow any of the two dozen agents to participate in a campaign, but eliminates only 1 digit in dialing. What other methods might one suggest? Secondly the last post related to using Metropolis call accounting software was in 2011. An important report the agency wishes to have is Shift Idle time. IE Extension IDLE time from 8:00 - 12:00 delivered at 12:15 Seems most call accounting systems are good at calculating call activity, and does anyone have experience with a call accounting system that calculates the IDLE times by subtracting the activity from a time specific time period? All comments are welcome and greatly appreciated.. Andrew
  10. Yes, these problems arose last November after windstream - Nuvox did a software upgrade on one of their Sonus Softswitches. We quickly identified the issue after pressing them to tell us the differences between the .173 Switch and another that was on another client with no problems. We learned they had done a software upgrade, and a SIP trace they identified the problem that we were sending the call quality stuff to them that was causing the Sonus to reject the calls... We've had no problems since and make these our default settings..
  11. FYI. We have numerous clients using windstream (Formerly Nuvox) SIP trunks provided off of a T1 using a Cisco 2431 IAD. Windstream provides a Client Internet IP address on Wic1 and a seperate single IP in WIC2 for the SIP trunk... A problem began within the past day where calls to or from some cell phones would drop in 15 to 30 seconds. The problems was traced to a setting in the SIP trunk settings in the Sonus Server related to what they call a service Profile. The preferred service profile they call "Nuvox Sip-SipT-Noss" and this accommodates more codecs and keep alive settings for the cell carriers. For some reason this clients service profile was set to "Nuvox Transcode" The following are the settings we are using across the board for all SnomOne installations where Windstream - Nuvox using the Sonus switches are the carriers RTP Media - udp range 16384 32767 udp range 49152 53247 Signal Protocol - udp 5060 tcp 5060 udp range 1718 1720 tcp range 1718 1720 udp 2427 tcp 2427 udp 2000 tcp 2000 Trunk Settings: Type: SIP Gateway Dest: Generic SIP server Domain: Public IP of PBX Proxy Address: 74.223.147.173 Codec: G.711U G729A Settings To Yes or Enabled: Lock Codec During Conversation, Interpret SIP URI as Phone Number Remote Party: Remote-Party-ID For DIDs use Send Call to Extension: !(.*)!\1!t! Wind Steam uses SONUS soft switches and they have a known issue. (SEE BELOW) http://wiki.snomone.com/index.php?title=RTCP-XR In order to disable these settings you must log onto the SIP PBX using the IP address and then move to the ADMIN settings page and paste, (1 by 1) the following URLs into the web. After each paste the page will switch to a status page, and you should go back to the settings page and do each of the remaining in the same way. These changes do not require a reboot, and take immediate effect. http://pbx-ip:8080/reg_status.htm?save=save&rtcp_loss_rle=false http://pbx-ip:8080/reg_status.htm?save=save&rtcp_dup_rle=false http://pbx-ip:8080/reg_status.htm?save=save&rtcp_rcpt_times=false http://pbx-ip:8080/reg_status.htm?save=save&rtcp_rcvr_rtt=false http://pbx-ip:8080/reg_status.htm?save=save&rtcp_voip_metrics=false
  12. Seems the previous install has installed a newer version of C++ libraries
  13. Any further development? Seems this fails instantly on w764/pro with this error Problem Event Name: CLR20r3 Problem Signature 01: attendantconsole.exe Problem Signature 02: 1.0.0.0 Problem Signature 03: 4f91e78c Problem Signature 04: AttendantConsole Problem Signature 05: 1.0.0.0 Problem Signature 06: 4f91e78c Problem Signature 07: c Problem Signature 08: a Problem Signature 09: System.Windows.Markup.XamlParse OS Version: 6.1.7601.2.1.0.256.48 Locale ID: 1033 Additional Information 1: 0a9e Additional Information 2: 0a9e372d3b4ad19135b953a78882e789 Additional Information 3: 0a9e Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
  14. We've taken the following approach. Burn an invisible autoattendent and create the following service flag 601 Normal Closed (Sheduled close hours) NOT OPEN 602 Holiday Closed Hours 603 Manual Closed (gone home for weather of early close) Then place the service flags in the AA service flag field in least used order 603 602 601 Then brach to to the appropriate AA,HG,AG, or EXT.... in the matching order... Make the timeout settings so if none of these are set, then send the call to a CLOSED AA.... Burning this AA allows you to create other Manual or scheduled service flags.. (IE Extended Hours 17:00-19:00 M-F, this would be placed just after Holiday) This at least gets the following Logic in place.... IF CLOSED FOR BAD WEATHER go to the WEATHER ALERT AA, or if on Holiday go to the Holiday AA, or if OPEN goto the OPEN AA, ELSE we must be closed so play the Closed Greeting on this AA.. The logic is the stack whatever service flags you need in LEAST LIKELY to OCCUR Order.... We have begun to standardize our Service Flags and Matching Actions beginning at 601 through 610 for the3 service flags and 701 through 710 for the associated AA's, HG, and AG,,
  15. Thanks all, this may not be the perfect solution, but added the public IP alias to the Soho, removed the 192.xxxx LAN gateway, IP replacements were added, along with routes and appears to be OK. Seems to require the remote phone ports forwarded to the PBX. We will take another look to further simplify the install, but this seems reasonable in light of the goal... Once we regain some space on our upload portal, we'll provide better docs....
  16. I agree on all points with one exception. Designing a reliable method to deploy the Soho on a single Static IP address is only required once, and this gives us a decided advantage in the marketplace. Unlike the traditional interconnect, we focus our sales efforts the long term proactive monitoring maintenance plan as opposed to large margins on the initial sale. All of our system over the years have been very standardized, albiet with dual NIC's, on Windows, CS410, and NEO Linux boxes. The extreme low cost, and great functionality when using Snom Phones, and upgrade path to the SnomOne Plus is a great offering. All of the discovery work is simply an acceptable part of the business plan and we'll be happy to share our results... So far the Lower Cost Zyxel devices are failing to meet our needs due to the inability to control local loopback natting. Working with the Engineering team at Zyxel the USG series has the ability to do what we need. Cheers -
  17. 250K,,,, PDF.... using this as a the basis to create a details plan on using a single Static IP, a reasonably smart firewall with DMZ support to support LAN and remote Phones.... I'll forward the item too
  18. Was attempting to upload and share documentation we are creating, but we have little room left to upload. Can we request a larger upload setting, or how can we delete things uploaded in the past? Cheers -
  19. Thank you for the added comments, I've created a decent Visio Plan documenting a test setup system to share with everyone, but it seems I have little room to upload anything further... I suspect the auto provisioning issue is icmp blockage on the DMZ, we are using Zyxel routers and they have an option to allow ICMP multicasting from DMZ to LAN... I'll know something in a bit, and will see if they can delete my old upload stuff or grant me larger space on the forums. Cheers
  20. DMZ? Could you better define your use of the DMZ? In my example the internal LAN is 192.168.100.X We could create a DMZ port on the Firewall and SET That IP as Range as 192.168.200.X The External WAN interface of the Firewall has a single IP. I assume th Firewall Allow Rule and PInhole (port forward for 5060 goes to the DMZ address that is a seperate port on the firewall...) The LAN phones register against that IP or FQDN.... Your continued thoughts are appreciated.. Thanks
  21. SMB connections are used for file/print operations, whille the PBX will create and handle it's own TCP connections. I would not expect to see any limitations....
  22. We have recently installed our first Soho for a client. To keep expenses low for our clients were are now wanting to support "single" static IP addresses and are putting he Soho behind firewalls. I'd like to propose the following example for discussions... 1. The Local LAN uses the following IP scheme 192.168.100.X (we've chosen this, since many remote phones may be on the common 192.168.1.0, 0.0 network and that might light result in issues. (It kills ipsec VPNs) and assume errors The Firewall is providing all DHCP Services and can also Provide DNS services for specific domains or simply forwards requests to ISP DNS (IE this can be used to create FQDN for phones internally like pbx.fqdndomain.com to point to 192.168.100.99 for the PBX internally while remote phones will see the pbx.fqdndomain.com as the real single static IP address.. The PBX is on 192.168.100.99 The Public IP address is 23.23.23.50 (example) The SIP carrier uses RTP port ranges 10000-30000 The PBX and the local Phones are working fine We like Zyxel Firewalls, but others support SIP too, but we disable SIP ALG.... The problems we are having are one way audio We've followed many tips and wiki posts, but we have no proven solution... SIP replacements, and Routes appear to kill the local phones or the remote phones.... I'd sure be willing to donate whatever time or equipment is needed to come up with a proven Single Static IP address with a Firewall of choice, that reliably supports LAN and WAN phones.... My guess is this first failure is going to cost us the client, the time and the money spent to date, and having the client now request multiple IP addresses from the ISP is off the table... Argg... and all comments or suggestions are welcome... Thanks...
  23. I agree with GotVoIP, We are a Snom Partner, and not a single one of our clients understand, or are aware of trial and tribulations we go through. Problems are not Unique to Snom, as every vendor of technology products has issues. I will say that to our delight, our Snom Value Added Distributor appears to have been well trained by Snom and were able to answer some questions we had. they earn their money, and anyone who would purchase anything, assuming they should be able to self-install with no prior experience, and no assistance from a trusted reseller is shall I say, getting what they paid for. I do see this product is going to mature, and get even better.
  24. This can happen, and it's important to ask your SIP provider for the RTP Port ranges they are expecting to be used. Be sure to match these port ranges on you PBX. In the case of Windows PBX's, Microsoft made a few updates in 2011 to battle security breached with DNS, and other services, and the OS will allocate a random range of ports during normal operations. Good reading begins here - http://support.microsoft.com/kb/956188 Based on our analysis, RTP streams were becoming crossed.
  25. We've deployed 4 SnomOnePlus / Yellow systems and in each case we've had to contact our selling distributor to discuss a technical issue. We'll admit we didn't read every page of documentation, but we did dig deep when we had some issues. We've recently made some suggestions via private emails to the development team, and I'll include them here for community comments. The numbered suggestions are the original notes, and the blue comments were in reply to Snom Responses that have been deleted. Not that they were bad, but I don't want to skew the comments.. In two of our systems, a telecommunications consultant ask us to provide a system quote. The client and consultant had quotes from several major players, including Shotetel, Avaya. In each winning case, we didn't leave any money on the table, circa 45% margins and 20% first year maintenance agreement, with a trip charge.... But our single biggest issue, is the distributors are shipping Snom Phones with V7.3 firmware that prevents autoupdates, the 2 digit extension plans, we change them all to three digits, the lack of multicast preconfigured, and the issues listed below. We really want to see the time when we unbox a SnomOne Plus, plug in a phone, and Voila..... The real margins get bigger when that happens... 1. You need to make a default template making all accounts a three digit code. I recommend using 400 through 409 as accounts, 700 for main attendant… WHY. Because every SnomOne plus we’ve installed has more that 10 extensions and we have to manually make these changes.. So for consistency across your installation base, I’d recommend you establish some basic standards. To help you internally determine the correct answer, ask your distributors the following question. “What percentage of all SnomOne Plus” PBX are sold with a Yellow Software license?” IF the answer is over 50% then making the change will help more people than not. In fact making that change across the board will not HARM anyone in the future. It will only save us time, and further standardize your client base. I Strongly recommend keeping the extensions at 400 through 4XX, leaving single button access for auto attendants on 1, 2, and 3 and not accidentally getting transferred with someone hits a 2 and forgets the rest of an extension, and the AA times out and sends them to the “2” option. 2. When the LAN IP address is changed or modified, automatically put that IP address and mask in the WHITELIST ACCESS list. WHY. Because we can easily forget, and you have phone registration issues, and I waste 10 minutes, and look stupid in front of clients, as I soon remember to add the LAN IP to the LIST. Let me also suggest you GIVE up the practice of using 127.0.0.1 in the SANGOMA and the TRUNK settings. Why, Because today your default settings bit us in the rear, and the inbound caller, or the person you called, could not hear the person on the PBX for 20 seconds. Then it corrected itself. I contacted our distributor, and he corrected those settings to be the LAN IP address of the PBX and the problem was corrected. The tech from Novus, said he sees this all of the time and they almost always put the LAN IP into the proxy and sangoma card fields with the :5066. There may be technical reason you leave the localhost 127.0.0.1 in there, but this happened to us last time, and forget since then, and it bit me again. My Bad… 3. You should go ahead and assume that all clients are going to use SNOM phones and add the Multicast settings to the PBX and to the default PNP settings for the XML files for the phones Clients really like the ability to PAGE 1 or all extensions, and we have to always remember to setup paging. I would once again ask my distributors what percentage of SnomOne Plus systems they sell also include Snom Telephones. If the answer is anywhere near 50% then setting the PBX up as much as possible to support SNOM phones makes your target customers more happy and further standardizes your installed system base. If necessary, include a piece of paper that says, “The SnomOne plus is preconfigured to support the features of SNOM VoIP handsets.” This includes PNP, PAGING, and more. If you are using other than SNOM handsets, please make the needed changes… 4. Might I also suggest you add a TFTP server and allow us to put the latest firmware in the folder, (A web interface to download latest SNOM firmware to TFTP server) this way we can quickly and manually LOAD new firmware onto phones using the manual method. The WEB interface can have the following options. A. Start TFP SERVER. (always start) B. Update Firmware Choose Model or ALL We are installing 15 Snom 320 handsets on this latest system and the majority of these handsets have 7.3.XXX firmware. DUH….. IT would be extremely nice to simply press a key on the phone, enter the IP address of the PBX and voila’, down comes the latest FIRMWARE. A WEB interface to manually upload the latest firmware from a local machine or pulling it from the WEB would be nice. As you know, PNP does not work well in the older firmware, so it’s impossible for them to get the latest firmware VIA PNP, so we’ve have to manually access each phone, and COPY/PASTE the link into the phones to upgrade them. All in all, we’ve wasted or shot ourselves in the foot that has cost us at least (5) hours.
×
×
  • Create New...