Using third party SIP phones (basic) with CallManager 5.1.3
The phones have their own built-in DND feature. Basically, when you activate the phone's Do Not disturb, they respond to all incoming call attempts with a SIP 480 "temporarily Unavailable" message.
The expected behavior is that the callmanager would see this message and then forward the calls to voicemail based off the line configuration. However, instead, it appears that the callmanager just drops the call and plays fast busy to the caller.
Does anyone know if that is the correct behavior that the callmanager is expected to do on a 480 SIP response? Previously we were using these same phones with some different SIP PBX vendors and they had no problem forwarding the call to voicemail on a SIP 480 message.
Checked that the callmanager is properly configured to forward the call to voicemail on no answer, busy, no coverage, cti failure. Verified that on a no answer situation, the caller does indeed get forwarded to voicemail; so it appears that the voicemail profile is configured correctly.
Normal (non DND calls) all work fine. There's a valid registered user and the phone is registered correctly. The problem only presents itself when the phone is in DND mode and returns message 480 to the callmanager.
This is callmanager 5.1, not CME, so there's no show run or show tech involved. No router/gateway between the devices, all devices are on the same subnet.
Turns out that most SIP phones use 480 for DND, including 7940/60 phones (when in SIP mode). So apparently, almost no third party, or even Cisco's own, SIP phones will work with DND active on a 5.1 install of callmanager.
Interestingly enough, Linksys phones use message 486 (busy here) instead of 480 (temporarily unavailable) for DND. According to the SIP RFC, either message is valid for DND. I don't know if the callmanager would handle 486 properly or not. Don't have a Linksys phone to test with.
All lines on the CCM can be configured with a âbusy triggerâ. After the number of active calls to that line reaches the busy trigger, the CCM will prevent further calls from being presented to that phone by initiating a Call Forward Busy without sending another INVITE to the phone.
However, due to mis-configuration or the potential for calls to exist on the phone of which the CCM is not aware (for example, a phone in a dialing state that hasn't yet sent an INVITE), it may be necessary for the phone to manage its own âbusy triggerâ and autonomously throttle calls. This is accomplished by sending a 486 response code to an INVITE.
Although the CCM may have Call Forward Busy behavior configured for a line (e.g., forward to DN or forward to voicemail), that behavior will not be exercised when a 486 is received from the phone. Instead, the 486 will be passed back to the original called party
Let me know if you see behaviour described above and if CFB is configured.
That sounds very much like what might be happening, although instead of a 486 message (which is what Linksys uses for DND); the phone is sending back a 480 message (which is what 79XX series phones use).
CFB is configured on the callmanager, however the CFB doesn't seem to be getting excercised. Instead, the original caller is getting fast busy from the Callmanager.
I would have thought that on a 480 (temporarily unavailable) or a 486 (busy here) message, the callmanager would exercise the CFB and forward the call to voicemail. All other SIP PBX systems that I'm aware of handle this 'correctly'.
Is there a way to configure the callmanager to properly handle this case? If not, then I have to think that this is really not correct behavior, as even the SIP RFC refers to using messages 480 and 486 for purposes of DND. Heck, even Cisco phones in SIP mode use the 480 message for handling DND. How else would you get it to work?
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...
The below trick might come handy when you have to add a new node to a cluster but you don't have or is unsure of the security password for the publisher. This procedure has been around for ages.
1) Login into the CLI of the Publisher.