Going to publish some info in stages about Cisco 7945, 7965, and 7985 phones. The company I work for uses these as our standard desk phone on campus. They are pretty old, but good phones that can take some abuse and still work reliably. Even better, there is an ample supply of these phones on eBay and elsewhere. I'm sure you can order a pallet of them when a company clears out an office building. I just browsed eBay for 7945, which is a 2-line model, and they were varied in price but many listings were there for $20 or less per device.
My intent here is to publish several posts. The first will describe our current solution which uses OpenSIPS as a B2BUA to receive Cisco traffic in SIP and fix it up to work well with Kazoo and vice-versa. I could just give you my OpenSIPS script, but really the ultimate goal would be to integrate these SIP fix-ups into the Kamailio scripts provided by Kazoo, so in later posts that is what we will do. Also, really not trying to promote OpenSIPS over Kamailio. The guilt would be too heavy for my conscious. So wait for it.
Our current solution for Cisco includes a means to pull device information from Kazoo, merge that information with an XML template for the Cisco devices, and stage the configuration files on a TFTP server. This is some custom code written in PHP that implements the Kazoo APIs. depending on your feedback, we will see if I should publish some or all of this solution for the community. Our network team makes it easy for the phones to boot up and find our TFTP via DHCP. I don't think there is anything we are doing that most of you have not already solution-ed on your own LAN.
Step 1: Identify when a SIP message is coming from a Cisco phone
We examine the user agent using this RegEx '^Cisco.*'
Step 2: Filter out some of the noise
I lack a lot of knowledge wrt Cisco's own solutions and these devices were built to work with Cisco CallManager or CallManager Express. For example, we see a lot of noise coming from the phones like power reports where the phone is using SIP to communicate what might be better done using SNMP. So if method is REFER or PUBLISH and it is a Cisco device, we generally ignore the messages. But here is a problem, if you don't at least acknowledge these reports, the phone will keep restarting. So send reply 200 OK, and then ignore the report.
Step 3: Setup routing for fix-ups to support Cisco
We will discuss in the next step how to fix up the SIP headers. But here we need to consider when to do a fix-up. There are a couple of scenarios where this is needed:
1) When the phone REGISTERs, do a fix-up
2) When a request has a TO-tag, we don't fix-up ACKs
3) When a request has TO-Tag, we don't fix-up 404 due to record-routing issues
4) Other than #2 and #3, we fix-up requests with a TO-tag
5) CANCELs are not fixed-up
6) as mentioned in Step 2, reply 200 OK and then ignore REFER and PUBLISH, no fix-ups
7) other PUBLISH and SUBSCRIBES, we just send 503 (no fix-ups)
8) all other requests are fixed-up
Step 4: Fix-up operation --> Insert a proper domain in Request-URI From and To Headers
These Cisco's seem to prefer IP addresses in SIP headers rather than a domain name. Could I fix this in the provisioning of the phone? Maybe, but I have not figured that out. So here is what worked for us.
To fix-up the From and To headers we use the UAC Module's uac_replace_from and uac_replace_to
If user agent is '^Cisco.*' then:
1) rewritehost() eg "your.businessfqdn.com" The alters the Request-URI domain name but leaves everything else unchanged.
2) build a FROM header that preserves the user part eg "sip:ChrisL_Cisco7945@" but replaces the phone's IP address with a domain name. So the FROM header will look like this "From: <sip:ChrisL_Cisco7945@your.businessfqdn.com>"
3) build a TO header in the same way we just fixed up the FROM header eg "To: <sip:ChrisL_Cisco7945@your.businessfqdn.com>"