andrewgroup

With an upcoming call center application we anticipate having over 200 inbound 800 numbers coming to the PBX being handled by a half dozen agent groups and hunt groups. These 800 numbers reflect local advertising in various media thoughout the country and may be moved or changed depending on marketing campaigns. Do any concievable limits exist in the name field for listing these DID? With so many inbound 800 nuimbers, would it be possible to craft ERE's to send different DID ranges to different Hunt or Agent Groups?

With an entry like this in the call log occurring 10 entries in a row. 2008/12/16 06:39:42 pending (XXX4036757@localhost 2008/12/16 06:39:45 pending (XXX4036757@localhost 2008/12/16 06:40:12 pending (XXX4036757@localhost 2008/12/16 06:40:12 pending (XXX4036757@localhost All in a very brief period immediately followed by a call from the same number making it to the destination might indicate what?

I think someone posted "Snom is Learning" Not real fast though, Making a White Telephone is about the single most absurd thing they could do. For those that have Life before VoIP telecom experience, try remembering the Lucent Partner White phones and others. They discolor easily, show dirt and grime and after 1 year the users will be embarrassed to have them setting on their desks. I strongly suggest they stop the production and immediately start making black or grey handsets. Oh, and what color patch cord do we use? :-) My .02 contribution.

Agreed, running 3.1.0.3043 (Win32) created a test DAY NIGHT Flag assigned my extension to change / monitor set time schedule for 8:00am to 11:59am, the service flag shows set, calling the service flag I get a dual tone acknowledgement, but the service flag remains set. I've never seen this feature work on any previous releases.

Somewhere along the way the dynamic recording feature has become inactive on our SNOM phones. VM, CDR, Performance and Status changes are all working ok, but recording shows it's recording on the server, but is never delivered via email. Has this feature setting changed or gone away. Cheers. 3.1.0.3043 (Win32) this was likely broke in late august or sept, but nobody noticed...

We have a staff member from the mountains in and around Limon, Costa Rica, He longs to visit his Mother Soon. The CS410 is a good choice when considering the other options. The Local Telecoms in all countries can advise on what the Cadences are, and having that information is a wise option. http://nemesis.lonestar.org/reference/tele...g/ringring.html Perhaps a Cross reference on setting the CS410 would be useful, Have you shared the settings that acheived the 99% success? Cheers

It's easy to make a Dial Plan for "Dial Extension" and assign the Lobby Phone to that Dial Plan, but to give that Extension E911 access, it seems another Dial Plan with access to a Trunk with 911 dialed sends 911 followed by an ERE expression to strip all but the first three digits is required. Is this how others have done this, or can the main dial plan detect the restricted extension and do the work?

Never had much use for TAPI, nor did many other people considering its reputation. But people like to see the fancy stuff, knowing they'll never use it, so why not go ahead and get TAPI working if for no other reason to show off. Follow the ever so simple WIKI DOCS and on my first HOME PC setting behind a good firewall set to allow all internal going out, the results are less than spectacular. The PBX is setting on a Public IP address and the results are "Internal Error Close and retry" Darn. Will retry on the Local LAN on another PC with a local IP connection to the PBX. But in looking for how to diagnose the TAPI stuff, I came along the following TAPI related items http://www.julmar.com/tapi/ I thought I might share this, and hopefully someone with successful TAPI installations might make some benchmarks or tests with these tools and report back some tips, I'm certain to.

My Posts in Sep 3 2008, 03:07 PM and the following day outline a procedure that I'm 99% will isolate the troubles. what were the results of these procedures?

Does this mean the full CS410 TGZ WEB UPDATE PROCESS does not update the FXO Firmware? We've not experienced any issues on any of our installations and have done many TGZ updates with no serious ill affects.

When the Black CS410 was introduced, I thought a final white case cs410 F/W release was issued. What is the last supported release if so?

Still trying to figure out how I can provide a VPN link to a location using the ISP in question. I'd rather not test on a live system.

Something else that comes to mind, since you are using softphones, and likely DHCP from the Router, as a test to isolate internal/external issues. set two PC's to static IP's, manually register the softphone, with no Gateway and make calls to each extension. You can turn off the router, and I suspect the call troubles will disappear. I would then register a remote phone to the PBX and make calls among those extensions. Again I suspect the troubles will disappear. This likely will confirm the issues previously mentioned, or lead you to suspect the ITSP is contributing the problem.

I first suspect the trouble to be the DSL / Modem Switch. It's like a 1/N packet scheduler and know nothing of QOS. What's likely contributing to this is the DHCP server is handing out itself as the gateway. Invites may contain public IPs and they may attempt to pass through the router, as opposed directly back to the PBX. Does the Softphone contain settings for a registration and proxy server? If so make them the same... You may want to make the PBX the LAN DHCP Server. Packets may very well be outbound to the PBX through the Router to the WAN side of the PBX.... We prefer not to place the WAN side of the PBX on a Public IP, Instead we use SIP AWARE routers and router SIP Traffic to the PBX and allow the router to Shape the traffic to allow WEB surfing on the LAN. I think you are nearby, and would be happy to help put this issue to rest. Cheers.

An installation is having troubles using the ISP mail server to send mail. This is a Nuvox Communications T1, with PSTN T1 data services. Nuvox offers a on-net SMTP server to send mail. SMTP.NUVOX.NET that accepts and relays mail from all On-Net Hosts. We have Nuvox on many clients and regularly us this mail server, (LINUX SENDMAIL) to smarthost exhange servers and to send management alerts from many devices. The CS410 reports the following in the logs. [6] 2008/08/26 18:00:04: Sending CDR email to <me@mydomain.com> [8] 2008/08/26 18:00:08: SMTP: Connect to 70.43.63.17:25 [8] 2008/08/26 18:00:08: SMTP: Received 220 smtp02.atlngahp.sys.nuvox.net ESMTP Tue, 26 Aug 2008 18:00:07 -0400 [8] 2008/08/26 18:00:08: SMTP: Received 250-smtp02.atlngahp.sys.nuvox.net Hello 74.223.YYY.XXX.nw.nuvox.net [74.223.YYY.XXX], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 52428800 250-DSN 250-ETRN 250-STARTTLS 250-DELIVERBY 250 HELP [8] 2008/08/26 18:00:08: SMTP: Received 220 2.0.0 Ready to start TLS [8] 2008/08/26 18:00:09: SMTP: Received [8] 2008/08/26 18:00:09: Last message repeated 2 times [5] 2008/08/26 18:00:09: SMTP: Connection refused on 70.43.63.17:25 The technical support group at Nuvox report the error message from the server is Here is the error I see in the mail logs: did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA Has something changed with the mail send tools, we have this on numerous ISP's an relay from On-Net Mail Servers. A commercial SMTP tester on this same IP address works fine. Has a new options been slipstreamed into release 2993 release?

Agreed, other problems must exist as these malformed packets are LAN based and would not traverse the WAN. I suspect the culprit is spread across several contributing factors; the hosts for X-lite, switches and routers, and without some advanced knowledge and experience troubles like this can linger as one plays the guessing game. SIPp 3.1, Wireshark are excellent tool to discover the exact cause. Laura Chappell with http://www.packet-level.com offers some tremendous tools and training on Packet Decoding and use of WireShark. While her daily rate is $$$$$$ her tools and training programs are very affordable. I also suspect no TOS/COS/QUEUING packet control exists on any device.

QOS - VLAN for a small office. 10 Users is quite small to consider VLANS. QOS is an option, but we've gone as high as 40 Extensions - 40 Computers and No troubles with call quality. (That installation is still going strong almost 2 years) a Full 23 Channel PRI (40,000 minutes monthly) Phones are on Linksys SRW series POE, computers are on SRW non-POE, servers on on Gigabit ports, we use spanning tree... But if you really want to go in that direction, it's all really simple. Enable Flow control on ports, Assign a Port to Switch Queue (4) high, attach PBX to that port, assigned SNOM default DSCP values to Queues Snoms default to 160. (this is on QOS DSCP page.) You can choose STRICT RWW on the Queues PAGE or go weighted RWW Validate this using Wireshark that all packets are being tagged with 0xa0 in the DSP DIFF SERVE header. I think that's about all you have to do. OPPS, you said Netgear, these instructions apply to LinkSys, but the lessons are likely the same.

Most typical routers do see SIP as a unique protocol. Typically users create a PORT Forward range tha include the range of ports listed on the settings, ports page. these are forwarded to the internal PBX if it's not on it's own public IP. Also forwarding 5060 (SIP) Port Range Start: 49152 Port Range End: 65534 But since you appear to have a router in front of the PBX, you can test this yourself by simply moving the PBX to the Public IP on the router and retest... MTU values can also cause problems. These can be exacerbated with using long SIP vs. short SIP headers.

We updated to same release late last week on one of our light users.... Still up and going... Version: 3.0.0.2993 (Linux) License Status: Appliance Key License Duration: Permanent Additional license information: Extensions: 10/32 Accounts: 20/40 Working Directory: /pbx MAC Addresses: 001915683FD0 001915683FD1 Calls: 52/17 (CDR: 69) 0/0 Calls SIP packet statistics: Tx: 38231 Rx: 38252 Emails: Successful sent: 0 Unsuccessful attempts: Available file system space: 70% Uptime: 4 10:18:25 (4002 4476480-0) WAV cache: 1 several linux memory testers are available, perhaps PBXnSIP might consider preloading a few ram testers on the system, that can be set tp run from the GUI and flash some lights as a GOOD/BAD indicators...

Fool me once, shame on you - Fool me twice, shame on me. I'll not let my enthusiasm bite me in the rear on this one. :-)

I made the full post in snom forum, http://forum.pbxnsip.com/index.php?showtopic=1204

Speaking of shooting oneself in the foot, read on. We had a client with some intermittent call quality issues...Additionally they needed a VPN established for the corporate. Given this we need to add VPN firmware to their router, and while onsite I took the liberty to upgrade the CS410 to 2992. While I'm at it, I'm a big fan (experience) says I'd rather apologize to a client for problems induces by new firmware, than make an excuse for not having the latest firmware, should a HACK occur. So I upgraded the firmware on the Switch, (surprisingly finding release notes related to QOS) and being there, let's upgrade the Snom 360's to 7.3.7 What's the old story, don't change to many variables............duh.... Focusing on the critical VPN IPSEC stuff with routes etc.... We then discovered one-way audio issues..... After considerable traces, tests, etc.... I pony'd up the cash for support to help bail my rear out of this one.... That's what I love about America, Money Talks.... So here's the free lesson for everyone else. Based on all the changes, I was mostly sure this was a routing issue, caused by the new VPN interfaces on the routers or perhaps the new enhanced settings we were making on the switch for QOS stuff. A lot of stuff did change. With Wireshark I began the quest to isolate the troubles. The folks in support and development where going down that same path of logic (routing) and we did some minor configs on the CS410, access was granted to SSL to the box and no immediate answer seemed plausible. So trying to reverse things, I downgraded a phone to 7.1.33 and automagically the trouble is resolved.... To Cut the meat - The Snom 360 release 7.3.7 is the culprit, on inbound calls.....the caller cannot hear the person that answered the phone..... (place that inbound caller on hold and pickup and Voila) and you can make all the outbound calls you want. Additionally from a QOS perspective the web interface needs access to change the Diffserv values as opposed to an XML editor. This occurs on both the 2992 and the 2993 release...... Cheers,

Snom specifically reference the use of 160 and not 184 http://kb.snom.com/kb/index.php?View=entry...&EntryID=13 any chance this setting might make it into the Ports Settings f CS410's also, microsoft suggests that any application can call their QOS API's to set the DSCP settings, in a previous post a Microsoft article is referenced, did that Article hard code in the DSCP setting or simply enable the API's for PBXnSIP to use.

after upgrading check the send calls to option in the trunk, I think the upgrade processes wipes that value.

Additionally you can expand your troubleshooting steps to include attaching the device to yet another OLD router laying around with a functional DHCP server and test against that. The would validate the device's ability to pull an IP. From experience, those that deploy any VoIP appliance, and their are many, without some sort of SIP aware router, will have little to go one when they experience troubles. The (OLD 3COM ADSL MODEM) makes my spine shiver.