Cisco 79X5 Devices with Kazoo

[Chris Labonne]

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>"

Edited February 10, 2023 by Chris Labonne (see edit history)

[RuhNet]

I did quite a bit of experimentation with similar Cisco phones in the past. After much work, I was never able to get them to send the domain, rather than the IP in requests. This is of course generally fine with single-tenant PBX systems, but doesn't work with Kazoo.  Modifying the headers with Kamailio/OpenSIPS is of course an option as you mention. However, the issue is that unless your system only has a single account, or at least only a single account is using Cisco phones, you'd have to have some sort of dynamic way to figure out which account/realm to associate the incoming Cisco phone with.

You could write a little external API service that handled this, and have Kamailio use HTTP (or AMQP if you wanted) to lookup the proper realm from the API by either using the incoming IP, or from a code of some sort included in the username, or possibly from the MAC address on the request (I don't remember if Cisco phones send MAC along with all requests or not.)

I'm not aware of any way to be able to lookup a realm/account for a particular device from the Kazoo API, since most things require the account or realm as the starting point for Kazoo to know which DB to search for the device in to begin with. So it's likely that a fully integrated solution isn't possible, without some custom code somewhere that keeps track of which devices belong where. 

Actually, now that I think about it, you could maybe encode the realm in the username, and have Kamailio strip it off and rewrite the domain using it.

So for example, you could set your username to:

cisco101_customer.sip.domain.com

and have Kamailio treat anything past the underscore as the realm when useragent is Cisco, extract it, and rewrite.

I don't know if the periods would give a problem with SIP user but if so you could always substitute them for two underscores or something like that and have Kamailio do a regex substitution on it before using as the realm.

This should be reasonably easy to implement in the native Kazoo Kamilio config script.

Edited February 18, 2023 by RuhNet (see edit history)

[Chris Labonne]

You are correct, in our environment, we have only one tenant using these Cisco 79x5 phones, so we just assume the domain/realm substitution for IP address is for that tenant.

Your idea of encoding the realm in the username is workable.  Seems like this is allowed according to the standards. RC 3261 defers to RFC 2396. Encoding dots as %2E may work eg

cisco101_customer%2Esip%2Edomain%2Ecom

Reading https://datatracker.ietf.org/doc/html/rfc2396#section-2.3 and section 2.4 that follows leads me to believe that this scheme would work.