
I don't know if it's a peculiarity of the SIP provider, but I found that a no-answer voicemail redirect would fail to transfer calls from the POTS to Exchange if the timeout was set to 20 or more seconds. It was still hitting Exchange and generating 'missed call' emails, though. Crank down the time and answer the phone quicker, slacker.
Voicemail in general takes a bit of planning to do 'right' with CUE. At the installation I took over, everyone had been set up with a mailbox and call forward busy 8000 diversions, where 8000 was the general number for everyone.
A much more flexible method is to make a new dial-peer with a voicemail prefix so that everyone gets a voicemail number (eg 8xxxx, where xxxx is the extension). You'll also need to set everyone's E164 number to the voicemail one. This means you can do tricky things like redirecting calls to specific mailboxes. If you have group mailboxes, this is much better than doing silly hacks like forwarding to an ephone-dn with the group mailbox's number and a call forward all, which I couldn't get working properly at all - I had to set call forward noan instead.
One issue with doing this was that people had to start entering their extension when logging in to the mailbox, and those who'd been too lazy to set up voice mail no longer could. This was because the FNN was being sent to CUE (0882xxxxxx) rather than the extension. Oh, the FNN must have originally been in CUE before I started messing with it. The solution was to set up a simple translation rule that stripped the leading numbers.
Another issue - you can't set the E164 number for group mailboxes through the Web interface. Dive in on the console using the special CUE incantation and set it manually.
Code to come when I can be bothered.
Attaching Cisco IP phones that use SCCP is relatively easy. Getting a third-party SIP softphone to work was much harder!
voice service voip allow-connections h323 to h323 allow-connections h323 to sip allow-connections sip to h323 allow-connections sip to sip supplementary-service h450.12 sip registrar server expires max 1200 min 300 voice class codec 1 codec preference 1 g729r8 codec preference 2 g711ulaw
Some guides suggested using g711ulaw first, but I already had g729r8 on there. I didn't want to fiddle too much and break the existing phone system.
voice register global mode cme source-address 10.252.1.250 port 5060 max-dn 192 max-pool 110 authenticate register file text create profile ! voice register dn 69 number 9095 name 9095 no-reg label Joeltest ! voice register pool 69 id mac xxxx.xxxx.xxxx number 1 dn 69 voice-class codec 1 username 9095 password 9095
I got it working with the free Zopier SIP client, which I intended to use as a temporary fax gateway but couldn't. I tried using Brooktrout's VoIP fax modem thingy, which didn't seem to work well either, and ended up using T.37 fax-to-email offramp on the CME instead. Why pay good money for fax-to-email when you've already bought a freakin' expensive PABX that can do it?
In Zoiper, add a SIP account. Domain is the IP of the CME (10.252.1.250 here), username and password are 9095, auth. username are 9095. The important thing seems to be to use a number for the username. I couldn't get it working with a word and this took me ages to figure out (!). Didn't bother with SIP proxy, though it seemed to work with it.
All this got me going with outgoing calls, but not incoming. My somewhat scummy workaround was to create an ephone-dn for the desired incoming number and call-forward all to the SIP phone's extension.
Note - after trying this I'm not convinced this gives two-way audio, which is only half good.
I installed one of these two port FXS cards and was disappointed to find that only one of the ports worked - one gave a dial tone and could be used to place calls, while the other was dead and/or just made the two in-use lights come on when a handset was plugged in. I raised an RMA and ordered a second card.. which had exactly the same problem. After three hours on the phone to Cisco's TAC, we determined that the phone cable being used to hook up the fax machine I was trying to get working had a reversed centre pair. When replaced with a straight through cable, the second port worked normally.
Even more bizarre was that the handset I was testing with, an old Telstra Touchphone, was being used with a normal straight cable. Once I replaced that with the reversed cable, both ports worked fine!
This leads me to believe that the VIC2-2FXS has its ports wired up the wrong way or has some hardware bug that no-one has ever noticed before for some unknown reason, or that the universe is truly an awful place.
Night service mode works well for forwarding a whole bunch of calls, but it's not easy to manually divert (eg using CFwdAll on a handset) a number of lines that are overlaid on one button. I came across this when someone wanted to be able to divert a customer service line to a "we're all in a meeting" mailbox that had a message different to the "we've all gone home" night message. I investigated using SNMP to set call forwarding (never really understood why SNMP was so hard. Could only find read-only MIB for call forwarding) and writing a TAPI client (poor documentation, way too complex, didn't want to have to support a desktop app) before I created the Devil's own ASP page, which simply telnetted in to the router, issued a conf t and began adding or removing call-forward all lines to the ephone-dn sections.
XML applications are fraught with frustration. Here are a few things I've found.
#!/usr/bin/perl print "Content-type: text/plain\n\n"; print "AUTHORIZED";
Contrary to every other Cisco product, pre-shared keys do not show up in a show running-configuration. They're replaced by * instead. Don't take this to mean "use the globally defined key" or something silly like that - if you clag * in as the key, your key really will be *. It's probably better to copy the config around using tftp, as this preserves keys.
I ran in to a nasty issue where performing a password recovery on an ASA 5510 caused the PPPoE password to be lost. I'm not entirely sure if that's what happened, because show run doesn't give the encrypted passwords, but resetting the password with the ISP and putting the new one in certainly helped. It's a good idea to have all your keys and details stored somewhere safe!
I upgraded an ASA 5510 from 7.2(3) to 8.0(3), or possibly something similar, and no config changes were required! Everything kept on working. My advice: approach such upgrades with reckless abandon. Upgrading a 2851 running CME was a different story - this seemed to break SIP (though contrary to the revelations obtained in earlier paragraphs, I ended up not using it anyway). This appears to be because CME is only integrated into certain IOS versions (maybe). It's probably better to stay within the same release track (eg XW) if you're doing voice things rather than going for the shiny new T series release.
When changing NAT exclusion rules, I found that nothing seemed to be working. I ignored errors that said "Unable to download NAT policy for ACE", but it turns out that these are what stopped it from working. The solution was to either reboot or do a no nat (inside) 0 access-list foo-acl and a nat (inside) 0 access-list foo-acl. This was in the 8.0(3) release and may have been fixed in later interims. Wasted lots of my time.