Solved: Jabber Client 12.9.2 Configuration on CUCM 12.5.1

Cale Montgomery · ‎10-01-2020

Several of our Jabber Mobile clients have updated to 12.9.2 (build 304238 for Android, 304231 for iOS). I'm thrilled to see that support for recording tones has been added, but I'm having an issue configuring this new feature. From the release notes:

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/12_9/cjab_b_release-notes-cisco-jabber-129/cjab_b_release-notes-cisco-jabber-129_chapter_00.html

In particular, this section:

After enabling recording tones, choose a Jabber client configuration profile in User Management > User Settings > UC Service. Add the following jabber-config.xml parameters to the profile:

EnableRecordingTone Enables recording tones for the user. Defaults to true.

LocalRecordingToneVolume Specifies the volume at which the client plays the recording tone locally. The range is 0-100 and defaults to 10.

NearEndRecordingToneVolume Specifies the volume of the recording tone which Jabber sends to the remote device and to the near-end recording server. The range is 0-100 and defaults to 10.

RecordingToneInterval Specifies the milliseconds between consecutive tones. The range is 8000-32000 and defaults to 11500.

Those parameters are not available to me under the jabber-config.xml UC Service Configuration. Do they need to be added through the 'Add Custom' operation? If so, do they need to be added under any specific Section (Policies, Phone, Voicemail, CUCM, Options, Directory, Client, or Presence)?

We're using Cisco Unified CM Administration 12.5.1.11900-146

Cale Montgomery · ‎10-19-2020

Okay. Jabber Configuration source files are detailed in the Jabber application log files that can be generated through the Problem Reporting page. There should be three involved:

<devicename>.cnf.xml created from the BOT device configuration in CUCM administration.

SP<key generated ID>.cnf.xml as a Service Profile generated by CUCM connection settings.

JAB<key generated ID>.cnf.xml created by the UC Service Configuration.

All three are sent to the TFTP server and you can watch them update there. Configurations are isolated into Common, Desktop, and Mobile sections.

<Config>
<Common></Common>
<Desktop>
<Client><Disable_IM_History>false</Disable_IM_History><spell_check_enabled>false</spell_check_enabled></Client><Directory><DirectoryServerType>UDS</DirectoryServerType><DirectoryUri>mail</DirectoryUri><SipUri>mail</SipUri><UriPrefix>sip%3A</UriPrefix><UseSipUriToResolveContacts>true</UseSipUriToResolveContacts></Directory><Options><StartCallWithVideo>false</StartCallWithVideo></Options><Phone><EnableDSCPPacketMarking>true</EnableDSCPPacketMarking></Phone><Policies><Disallowed_File_Transfer_Types>.exe%3B.msi%3B.com</Disallowed_File_Transfer_Types><EnablePromoteMobile>false</EnablePromoteMobile><EnableRecordingTone>true</EnableRecordingTone><EnableSIPURIDialling>true</EnableSIPURIDialling><NearEndRecordingToneVolume>100</NearEndRecordingToneVolume><TelemetryEnabled>false</TelemetryEnabled><VoiceServicesDomain>fhlbdm.com</VoiceServicesDomain></Policies><Presence><CalendarWebExMeetingPresence>true</CalendarWebExMeetingPresence><LocalRecordingToneVolume>100</LocalRecordingToneVolume></Presence>
</Desktop>
<Mobile>
<Policies><EnableRecordingTone>true</EnableRecordingTone><LocalRecordingToneVolume>1</LocalRecordingToneVolume><NearEndRecordingToneVolume>1</NearEndRecordingToneVolume></Policies>
</Mobile>
</Config>

I've set the Mobile configuration to only make use of the recording settings. Once the .cnf.xml file is updated, wait a few minutes for it to propagate to... wherever else it needs to go? Then Refresh Configuration on mobile Jabber app. I have not yet been able to enable the local recording tone. Which is fine. We don't want that, and it goes against our CUCM service parameter anyway, which is probably why it isn't applying.

What I have been able to do is lower the volume on the NearEnd, which was the point of this entire exercise. I did create a unique UC Service Configuration for the mobile settings, just in the event that some parameters there were incompatible with the mobile configuration and causing a conflict. The Section that I used for the Recording Tone parameters is Policies, but I have not yet experimented to see if they will work under other Sections as well.

jabber-config.xml does not need to be removed from the TFTP server. These adjustments are being pushed through the key-specific cnf.xml files, and through the <devicename>.cnf.xml file. Not everything seems to be working just yet, but NearEndRecordingToneVolume does, and that's good enough for me.

Roger -- thank you for your help. I do appreciate your time.

View solution in original post

Roger Kallberg · ‎10-01-2020

Any parameters that are not present in the UI need to be added as custom parameters and it needs to be set in the appropriate type. You should be able to find what type to use in the parameter guide for 12.9.

Roger Kallberg · ‎10-01-2020

Looked for these in the latest parameter guide. None of them are listed. As all of these have a default value and the one that controls if the tone is enabled has true as it’s default you should not need to add them to your configuration. Only if you need to modify the defaults you would need to add them.

Cale Montgomery · ‎10-02-2020

Roger,

Thank you for your reply. I should have stated that my question was not purely academic. The tone volume is louder and more intrusive than would be indicated by the default value of 10. I would like to adjust this through the LocalRecordingToneVolume and NearEndRecordingToneVolume parameters if possible.

You're correct in that the latest CUCM parameter guide does not provide information on these. They can be found in the Jabber 12.9(2) release notes as I indicated in my original post, as well that I can add them through the Add Custom operation in the jabber-config.xml UC Service Configuration.

You note that they need to be added as the correct type of parameter, which I take to mean Section as indicated in the Configuration interface. The 12.9(2) Jabber release notes do not acknowledge that Section is a part of the configuration process. Do you have any suggestions as to which might apply?

Also, I have experience with pushing TFTP files to SIP devices, but not to Jabber clients. It's my understanding that updating the jabber-config.xml UC Service will make changes to that file on our TFTP server. Are there any steps which should be taken to ensure that the updated jabber-config.xml file will be pushed from Cisco TFTP to individual Jabber clients?

Again, thank you for your time.

Cale Montgomery

Roger Kallberg · ‎10-02-2020

Let's start with the last one first. There is actually no file as such when you use the UC Service option to configure Jabber clients. It does away with the hated XML file that required the TFTP service to be restarted any time you did an update to the configuration. Not to mention the hassle with manually uploading the file to your TFTP storage. From what I know there is no step to get it out to the clients, it would be pulled down next time the client connects.

I did see your point that these new parameters are in the release note for 12.9.2. To your point in that there is no reference to what section they apply to I also see that this is missing and unfortunately I don't know where they would fit. If I where to guess it would be Polices or Client. You could I guess simply try to see if it has any effect or not. If your not comfortable with this you're best bet would be to open a SR with TAC and ask them where they belong.

Cale Montgomery · ‎10-07-2020

Created a quick test environment for this. So far I've cycled through all available Sections and have not been able to produce any change to an Android or iOS client using the new Recording Tone variables. This includes turning the tone on and off entirely. But at least I now know that adding a custom parameter without any Section entered will create an error condition on the UC Service Configuration requiring it to be deleted and recreated from scratch. Good to know.

Actually, I've not been able to demonstrate any sort of change to an Android or iOS client. This includes elements such as Spell Check and Disable IM History. Two parameters which are immediately evident and which do not require Custom Add. Although I have been able to demonstrate these changes being pushed to Desktop Clients.

Roger -- is it possible that I'm missing something? I have the new test UC Service Configuration attached to a new test UC Service Profile, which is attached to End User accounts. I can see Phone Services on Jabber Mobile reconnect when I make updates to this test Service Configuration. I've also tried forcing a restart through BOT/TCT devices, and I've tried full Resets on the mobile applications themselves. I'm just not seeing any configuration changes show up on the mobile applications.

Roger Kallberg · ‎10-07-2020

Have you checked on the UC service profile that there are different fields for what Jabber configuration to use for common, mobile and desktop?

Cale Montgomery · ‎10-07-2020

Yes. All three fields in my test UC Service Profile are set to the test Jabber Service Configuration. And the test UC Service Profile is set in the End-User accounts for my testers.

Roger Kallberg · ‎10-07-2020

One other thing to check, have you removed any Jabber XML file you might have in your TFTP file storage?

Cale Montgomery · ‎10-07-2020

I have not done that. Deleting the jabber-config.xml file from our TFTP server would be a production change, and I'm trying to avoid doing that until I have a solution that's confirmed to be applicable. Please note that having that file in place did not prevent UC Service changes from being pushed to the Jabber Desktop clients.

Is it possible to direct specific Jabber Mobile clients to a test TFTP server? That's how I've tested 8861 changes in the past.

Roger Kallberg · ‎10-07-2020

Not that I know of.

If you have all settings in the XML defined in your UC service for Jabber it would be no difference to using the file. We did this exact thing as soon as we had upgraded our system to CM 12.5 and have not had any issues related to this.

In your case with the XML file still being in your system and not willing to remove it you would need to work out where in the file the new parameters should go and do the old school method of uploading the new file to TFTP and then restart the service.

Cale Montgomery · ‎10-08-2020

Created a brief window where I could remove jabber-config.xml from our TFTP server. Re-saved the UC Service Configuration, refreshed the Jabber Mobile configuration and still nothing. So I've started pulling log files with interesting results...

Configuration changes are making it to the devices. This is both with and without jabber-config.xml present on TFTP (EDIT: I should probably note that this is the jabberAllConfig.xml file pulled from an Android device):

I've been able to swap those local and near volume levels as well. They're being distributed to the device just fine. And here's a call made while jabber-config.xml had been deleted:

2020-10-08 10:01:55,474 DEBUG [0x0000007a3ec0f4f0] [nal/nativeapp/sipcc/core/gsm/lsm.c(7312)] [csf.sip-call-control] [lsm_update_monrec_tone_action] - SIPCC-LSM: 1/3, lsm_update_monrec_tone_action: Start request for tone: 23. Set monrec_tone_action: 2
2020-10-08 10:01:55,474 DEBUG [0x0000007a3ec0f4f0] [tiveapp/sipcc/core/submgr/rccapp.c(1297)] [csf.sip-call-control] [rcc_process_play_tone_request] - SIPCC-RCC: rcc_process_play_tone_request: Check if cancel ringback delay timer.
2020-10-08 10:01:55,474 DEBUG [0x0000007a3ec0f4f0] [nal/nativeapp/sipcc/core/gsm/lsm.c(8236)] [csf.sip-call-control] [lsm_util_tone_start_with_speaker_as_backup] - SIPCC-MED_API: 1/3, lsm_util_tone_start_with_speaker_as_backup: tone=23: direction=2
2020-10-08 10:01:55,474 DEBUG [0x0000007a3ec0f4f0] [honewrapper/CC_SIPCCVcmBinding.cpp(3029)] [csf.ecc.vcm.api] [vcmToneStart] - tone=VCM_RECORDERWARNING_TONE, alert_info=VCM_ALERT_INFO_OFF, call_handle=65539, group_id=3, stream_id=5, direction=VCM_PLAY_TONE_TO_NET
2020-10-08 10:01:55,474 DEBUG [0x0000007a3ec0f4f0] [ftphonewrapper/CC_SIPCCService.cpp(4759)] [csf.ecc] [isMediaBindingStreamAllowed] - isMediaBindingStreamAllowed for call: 65539
2020-10-08 10:01:55,474 INFO [0x0000007a373054f0] [nts/ecc/src/common/thread/Timer.cpp(160)] [csf.ecc] [run] - Started thread: TimeoutData_timer_vcmToneStart
2020-10-08 10:01:55,474 DEBUG [0x0000007a3ec0f4f0] [ftphonewrapper/CC_SIPCCService.cpp(4767)] [csf.ecc] [isMediaBindingStreamAllowed] - isMediaBindingStreamAllowed for call: 65539, isFeatureCall: 0
2020-10-08 10:01:55,475 DEBUG [0x0000007a3ec0f4f0] [c/media/cpve/CpveAudioProvider.cpp(1890)] [csf.ecc.media.term.audio] [toneStart] - toneStart(0, 65539, 5, RECORDERWARNING_TONE, PLAY_TONE_TO_NET)
2020-10-08 10:01:55,475 DEBUG [0x0000007a3ec0f4f0] [c/media/cpve/CpveAudioProvider.cpp(1923)] [csf.ecc.media.term.audio] [toneStart] - pcm volume: 100; stream volume: 1
2020-10-08 10:01:55,475 INFO [0x0000007a3ec0f4f0] [s/ecc/src/media/cpve/CpveEngine.cpp(207)] [csf.ecc] [getStreamGroup] - Entering []
2020-10-08 10:01:55,475 INFO [0x0000007a3ec0f4f0] [s/ecc/src/media/cpve/CpveEngine.cpp(212)] [csf.ecc] [getStreamGroup] - Find group.
2020-10-08 10:01:55,475 INFO [0x0000007a3ec0f4f0] [s/ecc/src/media/cpve/CpveEngine.cpp(220)] [csf.ecc] [getStreamGroup] - Existing. Return 0x7a469a8fe0
2020-10-08 10:01:55,475 INFO [0x0000007a3ec0f4f0] [cpve/src/main/SessionGroupImpl.cpp(708) ] [cpve] [startNotificationTone] - Entering [sessionGroup=0x43986e80 tone=0 volume=1].
2020-10-08 10:01:55,475 INFO [0x0000007a3ec0f4f0] [PME(0) ] [pme] [<PME>] - pme_media_session_manager_send_notification_tone Entering
2020-10-08 10:01:55,475 INFO [0x0000007a3ec0f4f0] [PME(0) ] [pme] [<PME>] - pme_media_session_manager_send_notification_tone after unlock
2020-10-08 10:01:55,476 INFO [0x0000007a3ec0f4f0] [PME(0) ] [pme] [<PME>] - pme_media_session_manager_get_session_id Entering
2020-10-08 10:01:55,476 INFO [0x0000007a3ec0f4f0] [PME(0) ] [pme] [<PME>] - pme_media_session_manager_get_session_id Exiting
2020-10-08 10:01:55,477 INFO [0x0000007a3ec0f4f0] [PME(0) ] [pme] [<PME>] - pme_media_session_manager_send_notification_tone Exiting
2020-10-08 10:01:55,477 INFO [0x0000007a3ec0f4f0] [cpve/src/main/SessionGroupImpl.cpp(727) ] [cpve] [startNotificationTone] - Exiting. Returning true : NotificationTone started
2020-10-08 10:01:55,477 INFO [0x0000007a3ec0f4f0] [s/ecc/src/media/cpve/CpveEngine.cpp(207)] [csf.ecc] [getStreamGroup] - Entering []
2020-10-08 10:01:55,477 INFO [0x0000007a3ec0f4f0] [s/ecc/src/media/cpve/CpveEngine.cpp(212)] [csf.ecc] [getStreamGroup] - Find group.
2020-10-08 10:01:55,477 INFO [0x0000007a3ec0f4f0] [s/ecc/src/media/cpve/CpveEngine.cpp(220)] [csf.ecc] [getStreamGroup] - Existing. Return 0x7a469a83a0
2020-10-08 10:01:55,477 INFO [0x0000007a3ec0f4f0] [cpve/src/main/SessionGroupImpl.cpp(708) ] [cpve] [startNotificationTone] - Entering [sessionGroup=0x45d96b00 tone=0 volume=1].
2020-10-08 10:01:55,477 INFO [0x0000007a3ec0f4f0] [PME(0) ] [pme] [<PME>] - pme_media_session_manager_send_notification_tone Entering
2020-10-08 10:01:55,477 INFO [0x0000007a3ec0f4f0] [PME(0) ] [pme] [<PME>] - pme_media_session_manager_send_notification_tone after unlock
2020-10-08 10:01:55,477 INFO [0x0000007a3ec0f4f0] [PME(0) ] [pme] [<PME>] - pme_media_session_manager_get_session_id Entering
2020-10-08 10:01:55,478 INFO [0x0000007a3ec0f4f0] [PME(0) ] [pme] [<PME>] - pme_media_session_manager_get_session_id Exiting
2020-10-08 10:01:55,478 INFO [0x0000007a3ec0f4f0] [PME(0) ] [pme] [<PME>] - pme_media_session_manager_send_notification_tone Exiting
2020-10-08 10:01:55,478 INFO [0x0000007a3ec0f4f0] [cpve/src/main/SessionGroupImpl.cpp(727) ] [cpve] [startNotificationTone] - Exiting. Returning true : NotificationTone started
2020-10-08 10:01:55,478 DEBUG [0x0000007a3ec0f4f0] [c/media/cpve/CpveAudioProvider.cpp(1953)] [csf.ecc.media.term.audio] [toneStart] - stream tone start success
2020-10-08 10:01:55,479 INFO [0x0000007a3ec0f4f0] [s/ecc/src/commonphone/MediaCall.cpp(538)] [csf.ecc] [setMediaBindingStreamToneType] - Entry
2020-10-08 10:01:55,479 INFO [0x0000007a3ec0f4f0] [s/ecc/src/commonphone/MediaCall.cpp(547)] [csf.ecc] [setMediaBindingStreamToneType] - Exit
2020-10-08 10:01:55,479 WARN [0x0000007a3ec0f4f0] [s/ecc/src/common/thread/Timeout.cpp(143)] [csf.ecc] [cancel] - Cancelling Timer: vcmToneStart, Thread ID: 0x7a3ec0f4f0
2020-10-08 10:01:55,479 INFO [0x0000007a373054f0] [nts/ecc/src/common/thread/Timer.cpp(193)] [csf.ecc] [run] - Finishing thread: TimeoutData_timer_vcmToneStart
2020-10-08 10:01:55,479 INFO [0x0000007a373054f0] [nts/ecc/src/common/thread/Timer.cpp(199)] [csf.ecc] [run] - Signal work is done

Tone levels are appearing in the call log from the device. But, for some reason, are just not being reflected in the actual call. Local tone does not sound at any volume level, and near-end tone remains at the same intrusive volume. Can anyone spot anything here that I might be missing? I'm going to start experimenting with possible undocumented 'mobile' versions of those parameters.

Cale Montgomery · ‎10-19-2020