Quality Management Suite

Cisco Forked Audio Extension Setup

1.    In the Cisco Forked Audio environment, it is important to have a consistent mapping of the user's extensions between Cisco CM and QMS Call Recording. In simple terms, a User in Call Manager who has three extensions, must also have three extensions in their QMS profile.

Example: Tom Jones has a phone with extension 1234, 5678 and 9090. Extension 1234 is the line 1 appearance in Cisco Call Manager. In QMS, extension 1234 should be the primary extension of the user's profile in QMS, while extensions 5678 and 9090 will be in the list of that user's additional extensions.

Note that extension 1234 should be unique and not be a line 1 appearance on any other phone.

To verify that the QMS user account is in sync with Cisco CM, use Windows dialer. Open Windows dialer to the list of Mac Addresses / Extensions. Find the user's extension in the list. Note the associated MAC address. Extension 03016 is associated with a phone with the Mac Address of SEP2C3ECF860E62. Since extensions are in Mac Address order, check to see if there is more than one extension with the same MAC address. In the image below, the user in QMS has a primary extension of 03016 and has no additional extensions.

2.     Setting up phones without extension mobility

When users are, for the most part, anchored to one desk and one phone, extension mobility is not employed. It is relatively easy to setup the user in Cisco Call Manager for forked audio. Add the MAC address of the phone into the Controlled Devices list. That's it. Otherwise, follow the directions in the integration guide or help website.

Now go the user’s extension setup in Cisco Call Manager.  Below we see two extensions: 5025 and 5721.  The line 1 (5025) appearance must be the primary extension in QMS.  The other line (5721) must appear in the additional extension field in the QMS user’s setup.

3.     Setting up phones ‘with’ extension mobility. 

With extension mobility, you are assigning the user’s mobility profile to the CTI controlled devices ‘not’ the extension.  Add the mobility profile of the user in the ‘CTI Controlled Device Profiles.  Do ‘not’ add the phones MAC address to the Controlled Devices list. Below, see that one user has been added to CTI Controlled Device Profiles. 

If you have some users who use extension mobility and some who do not, add the users with extension mobility to the CTI Controlled Device Profiles and add the non-mobile extension's MAC address to the Controlled Devices list. 

4.     In the photo below, notice that the MAC address of extension 3230 is SEPD4BED9653043. Notice that there are five other extensions associated with Mac Address SEPD4BED9653043. This means that all five extensions must appear in the QMS user's account. Only one of those extensions is the line one appearance in Cisco Call Manager. The line 1 appearance must be the primary extension in the user's QMS profile. In this case, we are saying that extension 3230 is the line one appearance. Please note that the extensions are not listed in button order. Extension 3230 does not have to be the line 1 appearance in Call Manager.

For our example, we are assuming that extension 3230 is line 1. That means that extensions 4065, 5075, 5722 and 8932 are also buttons on that same phone. So in QMS, extension 3230 would be the primary extension and 4065, 5075, 5722 and 8932 would be added as additional extensions.

If you do not have all 5 extensions in the QMS user's profile, then the extension mapping is incorrect and none of the extensions will record. If 5 extensions appear in the Windows dialer, but the QMS user has 4 extensions in the user's profile, then the mapping is not correct and those extensions will not record. If 5 extensions appear in the Windows dialer, but the QMS user has 6 extensions in the user's profile, then the mapping is not correct and those extensions will not record.

This extension mapping is critical to differentiate shared extensions and which phone QMS must monitor to record a call on a shared extension. Example, notice in the picture above that there is another extension 4065 in the list with a different Mac address. Can you find it? This is legal. This indicates that extension 4065 exists on another phone. This does not indicate a problem.

If the mapping is incorrect, the user will appear as idle during a phone call that should be recorded even though: the correct SIP packets and correct RTP packets will be visible in a packet capture, the Consolidated Recording log will show that QMS acknowledges the sip packets and that the DHCP updates will write the correct IP address to the user's account. In other words, everything will appear as normal, except the call is not being recorded. If the mapping between the Cisco Call Manager and the QMS user is not consistent, you will have a problem and calls will not be recorded.

5.     Things get more complicated with extension mobility. When a customer uses extension mobility, the user can login to any phone with their assigned extensions. This means that Tom Jones who has extensions 1234, 5678 and 9090 assigned to him, can sit at any phone, login, and his three extensions will appear on that phone.

In one fail scenario, Tom logs into a phone with three buttons and records. Later that day, he logs into a phone with only two buttons. Only extensions 1234 and 5678 are assigned to the phone so extension 9090 will not appear in dialer. This means that the extension mapping is incorrect and that none of Tom's extensions will record.

Another fail mode is when a user has two extension mobility profiles. In Call Manager profile TomA, Tom has 3 extensions: 1234, 5678 and 9090. In Call Manager profile TomB, he has 4 extensions: 1234, 5678, 9090 and 7777. When Tom is sitting at his desk, his phone has four buttons. At that phone, Tom can login with either profile and he will record. However when Tom sits at another desk with a phone with just three buttons, if he logs in as TomA, he will record. If he logs in as TomB, he will not record. This is because TomA only has 3 extensions, so correct mapping with take place. TomB has a fourth extension, 7777 which cannot appear on that three button phone. The mapping will not be correct and calls will not be recorded on any of the four extensions.

This can all be confusing, so the key is the Windows dialer. If the extensions displayed in Windows dialer match the extensions in the QMS user's profile, then the calls will be recorded. If not, then calls will not be recorded.

6.     Here is an actual example. Extension 6307 is not recording. During a phone call, in real time view, we only see idle. The packet capture shows that we are receiving valid SIP messages and the RTP stream is there and correct. In looking through the logs, I found this:

11:00:18.6 DEBUG [PhoneSignatureMapping.LogPhone2SignatureMap]: _phone2SignatureMap Entry: SEP649EF3C24826 = "6307 6507"

11:03:37.0 TRACE [BaseTapiCallControlProvider.HandleLineAddedEvent]: No Callrex user for signature: 6307 6507.

When I checked dialer, I found extensions 6307 and 6507 had the same Mac address. When we checked the user setup in QMS, we found that the user had a primary extension of 6307 but had no additional extensions. After adding 6507 as an additional extension, the user started recording.

7.     Here is another example. Extension 6460 is not recording. Like the previous example, the user appears idle during the call, and we are receiving valid SIP messages.

07:55:28.8 TRACE [BaseTapiCallControlProvider.HandleLineAddedEvent]: LineAddedEvent(Name: "Cisco Line: [SEP5067AEE361DF] (6460)", DevSpecExtId: -1900189104.327160274.-1873084320

07:55:28.8 DEBUG [PhoneSignatureMapping.AddMappingElement]: Updated _phone2SignatureMap entry SEP5067AEE361DF with address 6460. signature: "6460 9650"

07:55:28.8 TRACE [BaseTapiCallControlProvider.HandleLineAddedEvent]: No Callrex user for signature: 6460 9650

So we see 6460 associated with 9650.ÿ This means that the user in QMS needs to be setup as having one of these as the main extension and one of these as an additional extension.

but, then we see:

07:55:28.8 TRACE [BaseTapiCallControlProvider.HandleLineAddedEvent]: LineAddedEvent(Name: "Cisco Line: [SEP5067AEE361DF] (4299)", DevSpecExtId: -1900189104.327160274.-1873084320.-133

07:55:28.8 TRACE [BaseTapiCallControlProvider.HandleLineAddedEvent]: No Callrex user for signature: 4299.

Extension 4299 has the same Mac address as extensions 6460 and 9650. How is this possible? Extension 4299 is the default extension of the phone before an extension mobility user logs into it.  Extension 4299 was mistakenly added to the CTI Controlled Devices.  When a user logs into the phone with their mobility profile , it adds new extensions to the phone. So 4299 will have the same MAC address as the mobility user's extensions. This must be avoided.