You can find specifics regarding the required CUCM ringtone file type in your phones administration guide. One example is here: http://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/7965g_7945g/6_1/english/administration/guide/7965cst.html#wp1h088184
Download a ringtone to a SFTP server. I am using FreeFTPd from http://www.freesshd.com/ on a Win7 laptop.
Just a note about FreeFTPd... I would suggest NOT installing it as a service if you only run it occasionally as administration is much easier, and if on Win7, when starting the application, right click and run as administrator to allow changes being committed to the FreeFTPd config (i.e. users, home directories, etc.).
Here's an example of how to download a ringtone (in this case, Vibe) via the CUCM CLI:
login as: platformadministrator
platformadministrator@10.11.12.13's password:
Command Line Interface is starting up, please wait ...
Welcome to the Platform Command Line Interface
VMware Installation:
2 vCPU: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz
Disk 1: 80GB
4096 Mbytes RAM
admin:file get tftp Vibe.raw
Please wait while the system is gathering files info ...done.
Sub-directories were not traversed.
Number of files affected: 1
Total size in Bytes: 16080
Total size in Kbytes: 15.703125
Would you like to proceed [y/n]? y
SFTP server IP: 192.168.111.112
SFTP server port [22]:
User ID: sftp
Password: ********
Download directory: /
.
Transfer completed.
admin:
Since the ring files are in a headerless / RAW format, you'll need an application to open, play and manipulate them, accordingly. I use Audacity from http://audacity.sourceforge.net/.
Audacity will not know the format of the file, so rather than simply using File | Open, use File | Import | Raw Data.
There you will need to change the Encoding to U-Law and the sample rate to 8000.
At that point, you should have the file open, and be able to play or modify it to your liking.
When you are happy with the modifications, rather than simply saving, you will need to use the File | Export menu option.
When prompted with the Export File dialog box, enter a file name and location for your modified ringtone. The Save as type should be Other Uncompressed files. Then click the Options button.
When prompted with the Specify Uncompressed Options dialog, set the header to RAW and the Encoding to U-Law. Click OK and Save.
You now have a new ringtone that can be uploaded to your CUCM server(s).
Diary of technical happenstance, simple Internet accessible scratchpad, and brain dump to save myself later
Pages
▼
Friday, December 13, 2013
Wednesday, December 04, 2013
Cisco CUCM SIP CUBE calls fail early media
This fix is documented in various places on Cisco's site, but a common point of confusion.
See Update below for symptoms found after first resolution
I've run into two different scenarios where a users on a CUCM deployment with CUBE routers as the demarcation point to the PSTN via SIP trunks has had problems dialing numbers terminating on IVR or automated attendants. One, frighteningly, was calls to 911, the emergency number in the US. The callers would either experience continuous ringing, or no audio although the call did not appear to be dropped.
You don't want emergency calls going to dead air.
CUCM -> SIP trunk -> CUBE -> SIP trunk -> PSTN
The short story is that "early media" cut-through needed to be enabled.
This is enabled by default on the CUBE routers but could be potentially disabled or modified on the router using the "disable-early-media" command. After reviewing the configuration, I found no variations of the command applied to the CUBE configuration.
The answer then is to send a PRACK via the CUCM configuration. This is disabled by default in CUCM.
In CUCM, navigate to Device | Device Settings | SIP Profile.
Find the profile associated with the SIP trunk between CUCM and CUBE.
Modify the SIP Rel1XX Options. I've found Send PRACK for all 1XX messages to be universally successful.
From CUCM help:
This field configures SIP Rel1XX, which determines whether all SIP provisional responses (other than 100 Trying messages) get sent reliably to the remote SIP endpoint. Valid values follow:
Disabled (default) — Disables SIP Rel1XX.
Send PRACK if 1XX contains SDP — Acknowledges a 1XX message with PRACK, only if the 1XX message contains SDP.
Send PRACK for all 1XX messages — Acknowledges all1XX messages with PRACK.
Update:
Found with this configuration above, users had issues with transferring incoming PSTN calls to external PSTN calls. Incoming PSTN call could not be transferred or conference with another off premise call until until the callee answered.
I found disabling the SIP Rel1XX options and simply checking Early Offer support for voice and video calls (insert MTP if needed) allowed both successful calls to the network based IVRs and transfer / conferencing in a timely basis.
See Update below for symptoms found after first resolution
I've run into two different scenarios where a users on a CUCM deployment with CUBE routers as the demarcation point to the PSTN via SIP trunks has had problems dialing numbers terminating on IVR or automated attendants. One, frighteningly, was calls to 911, the emergency number in the US. The callers would either experience continuous ringing, or no audio although the call did not appear to be dropped.
You don't want emergency calls going to dead air.
CUCM -> SIP trunk -> CUBE -> SIP trunk -> PSTN
The short story is that "early media" cut-through needed to be enabled.
This is enabled by default on the CUBE routers but could be potentially disabled or modified on the router using the "disable-early-media" command. After reviewing the configuration, I found no variations of the command applied to the CUBE configuration.
The answer then is to send a PRACK via the CUCM configuration. This is disabled by default in CUCM.
In CUCM, navigate to Device | Device Settings | SIP Profile.
Find the profile associated with the SIP trunk between CUCM and CUBE.
Modify the SIP Rel1XX Options. I've found Send PRACK for all 1XX messages to be universally successful.
Before:
After:
From CUCM help:
This field configures SIP Rel1XX, which determines whether all SIP provisional responses (other than 100 Trying messages) get sent reliably to the remote SIP endpoint. Valid values follow:
Disabled (default) — Disables SIP Rel1XX.
Send PRACK if 1XX contains SDP — Acknowledges a 1XX message with PRACK, only if the 1XX message contains SDP.
Send PRACK for all 1XX messages — Acknowledges all1XX messages with PRACK.
Update:
Found with this configuration above, users had issues with transferring incoming PSTN calls to external PSTN calls. Incoming PSTN call could not be transferred or conference with another off premise call until until the callee answered.
I found disabling the SIP Rel1XX options and simply checking Early Offer support for voice and video calls (insert MTP if needed) allowed both successful calls to the network based IVRs and transfer / conferencing in a timely basis.
After: