I had a Customer who had an existing CUCM workflow that required a different Directory Number and User ID. As noted in the main CUCM article, the best way to make a SIP login on CUCM for LQ is to have the 10 digit directory number be the user ID. This way, you can just use “1234567890” as the user in the LQ.

It is, however, possible to make LQ be able to talk to CUCM when these are different using an authorization ID, but first I want to lay the groundwork for what that is.

Breaking down the SIP packet - what does the “#” do?

Here is an example registration packet.

Open

In the case of this SIP provider, RingCentral, you are required to use an auth ID in addition to your username. When looking at the packet, the “to” and “from” field are what we’d consider the “user ID” on an LQ and the “digest username” under the authorization line is what we’d consider the auth ID. Here’s another way of visualizing this same data.

Open

This is the settings page of microSIP, a very common open source softphone app based on PJSIP. Here what we’d call the user ID is called username, and what we’d call the auth id is called Login, but these are fundamentally the same thing, and will express in the registration packet in the same way. Last thing to note is how to express this in the LQ or IPA, we do this with the # sign in the user field.

Open

The above info is made up, hence the connection status failure, but you get the idea, it goes “username#authid”, and then your registration packet will appear the exact same as above. Same for the IPA.

Open

Cisco Call Manager

Now that we have the background out of the way, the purpose of this page is to explain a workaround for a user who had to use a directory number with of “\+1” in front of the 10 digit code. Here’s screencaps from their CUCM config, illustrating the difference between the directory number, which is the actual number used at the telco, and the user ID, which is just used for login of the LQ or other SIP phone. Colors are the same as above, where Yellow is what we’d call “user ID” and green is what we’d call “auth ID”, however don’t get confused, because CUCM calls the text marked in green “user ID” and yellow the “directory number”. These are different terminologies, but all that matters is how the SIP packet is ultimately generated.

Open

Open

Open

Open

Open

As you can see, the Directory number is “\+1410XXXXXXX” vs the user ID, which is 10 digit, “410XXXXXXX”. Going in to what the backslash does for the CUCM side is a bit outside of scope of this explanation, but it’s important for the workflow of this CUCM instance, and so can not be removed from the Directory Number, which is the number actually being used upstream from CUCM to the telco provider.

There’s a few gotchas here to be aware of. First as I said, the directory number is what we would call the “UserID”, and what Cisco calls “User ID” we call “Auth ID”, so the syntax in the LQ or IPA should be “DirectoryNumber#UserID”. In this case the syntax that allowed us to log in an LQ as this user was “+1410XXXXXXX#410XXXXXXX”.

But hang on, there’s a backslash in the directory number right? Why is that not included? In short, a backslash is an invalid character in the “user id” field of a sip packet. MicroSIP simply won’t allow you to put the backslash in there at all for example. The LQ will let you put it in, but because it’s an invalid character, we found you’ll never be able to log in when including it. But fortunately, for log in purposes, CUCM is happy to let you in when you drop the backslash, while still causing the behavior the backslash is there for when the number is used. Hence why for this set up, “+1410XXXXXXX#410XXXXXXX” ended up being the working syntax.

I want to be very clear that this was an article about lessons learned about this particular install, so your mileage may vary. If I could give one piece of advice, microSIP is an excellent testing tool, and matching up a working microSIP instance with how microSIP generates its SIP messages is how we figured out the solution and syntax for the LQ. I would recommend if you have a complicated CUCM workflow like this one, you start with getting microSIP connected to the user in question, and then use that to engineer the correct syntax for your LQ. Another useful troubleshooting step is to look at the SIP packet in wireshark, like in the first screencap in this article, to see how the syntax you are using ends up effecting the output data in there.

https://www.microsip.org/
Wireshark · Go Deep

Hopefully this information will give you a starting place if you have a system like this one.