UCM 7-1-3 Service Update 3 Media Resource issues

[gsidhu]

Hi

New installation of UCM 7.1.3 with latest Service Update (Release 2).

Two issues related to media resources:

1) When a user is put on hold instead of hearing MOH the user hears beep every few seconds

2) Fast busy when attempting to conference a call. Phone 1 calls Phone 2 then Phone 1 presses conf soft key then dials Phone 3. When Phone 1 presses the conf key again, the conference fails, Phone 2 hears fast busy.

The MOH servers and conference bridge is provided by UCM (Pub and a single Sub).

On both Pub and Sub MOH and conference bridges showing as registered and IP Voice Media Steaming service is running.

MOH and CFB in MRG/MRGL.

The MRGL applied to phone at device level and to user device profile.

Powered down Sub to force phones to register with Pub - I get the same issue

Has anybody come across this issue before?

Is there anything that I am missing in the configuration or this issue likely to be a software defect?

Thanks

[William Bell · Accepted solution]

I think you are missing something in the configuration.  I have 7.1(3b)SU2 and I have not seen issues as you describe them.  To check this out:

1. Make sure that the IP Voice Media Streaming service is enabled and running on the servers you want to use for media resources.

2. Go to the media resource in question (conference or MoH server) and check to see if the media devices are registered to the cluster.   For MoH, check to make sure the Run Flag is set to Yes.

Now, up to this point you know you have resources running and registered.  In other words, they are available for use.  Now, check the other end of the equation.

Are the media devices part of a media resource group?

- If yes, make sure that the MRG is in a Media Resource Group List (MRGL) that the phone trying to use the service has configured.  The MRGL can either be assigned to the phone directly or via the Device Pool

- If no,  then the media resource is part of the "default" media resource group which is part of every MRGL.  I recommend assigning media resources to MRGs but it should still work in the "default" MRG.

The last thing to check is the CODEC and regions.  For MoH, the default CODEC that is played out is G711.  You know, I am not sure what would happen if a phone in a G729 region were placed on hold and the MoH server is only streaming G711.  I think you would get ToH but I haven't tested that particular misconfiguration out.   Hmmm.  Anyway, for conferencing (software conferencing on CUCM) the only CODEC supported is G711.  So, if you tried to start a conference from a phone and your inter-region configuration is such that G729 is the only CODEC permitted -- then your conferencing would fail.

One last thing related to regions.  The default inter-region CODEC is G729.  So, if you set up your phones in RegionA and your CUCMs are in RegionB or the Default region then you are using G729 by default and your MoH/Conferencing/etc. will fail to function.  You can remedy this in a few ways, depending your particular design requirements.  You can ensure that the region your CUCM media resources are in is setup to use G711 to every other region or you can modify the Call Manager service parameter "Interregion Audio CODEC Default" is set to G711/G722.

Somewhere in the above spaghetti is your answer.  If not, then let me know and we will give it another shot.

HTH.

Regards,
Bill

Please remember to rate helpful posts.

[gsidhu]

Bill,

Thank you for taking the time to provide me with a detailed response.

I've checked everything that you mention.

Currently I MRG and 1 MRGL configured at Device Pool, phone device and UDP. Cisco 7961 phones.The MoH and CFB resources are part of the same MRG/MRGL).

MoH and CFB status with Pub and Sub is registered. IP Voice Media Streaming service is enabled and running on both servers.

Currently only one region with G711 codec.

Its interesting that you have not experienced this issue with the same version. There must be some differences which may explain why I am getting the problem.

I'm going to run a trace when I continue working on this issue next week; I would find it very useful if you could tell me:

Where you configured the MRGL (phone device, device pool)?

Were you using Extension Mobility?

What phone model(s) were you working with?

Did you upgrade the firmware on the phones or did you leave them running with the 7.1(3b)SU2 default phone loads.

Many Thanks

Gurmakh

[William Bell]

Gurmakh,

In answer to your questions:

1. I assign the MRGL to the Device Pool

2. I have phones with EM, but most aren't.  No issues seen on EM phones (logged in or logged out)

3. Phone models:  7961, 7942, 7962, 7965, 7906, CIPC

4. Firmware:  I am using 8.5(3) across the board  (all phones are running SCCP)

Oh, I have also tested MoH via unicast and multicast.  Both work.

The other I would like to ask:

Are you using any ACLs or firewall filters that would restrict RTP port ranges to the CUCM?

HTH.

Regards,
Bill

[Jaime Valencia]

This is a little old but if you're familiar to CUCM you can relate all the stuff to 7.1 config

Q. Why do users hear a beep sound (Tone on Hold) instead of Music on Hold?

http://www.cisco.com/en/US/partner/products/sw/voicesw/ps556/products_qanda_item09186a0080094766.shtml#q16

When you attempt the conference if you press the ? button twice on the phones what codec do you see??

Also, do you reset the phones after MRGL changes at DP or device level?

HTH

java

If this helps, please rate

www.cisco.com/go/pdihelpdesk

[gsidhu]

Thanks Java - I tried resetting phones, restarting both CM ...no joy!

[gsidhu]

Thank you Bill - you've been a great help (I've rated your post to show my appreciation).

The fact that you have'nt had any issues with the same CM version certainly narrows down the possible causes.

There are no ACL or F/W at the moment (pre stage phase).

I think that the problem is with the phone configuration.......

CM is integrated with Verint DMS call recording solution which (on phone device configuration) requires Built-In-Bridge to be enabled and Privacy to be turned off.

When I'm back on the customer site next week I'll set Privacy back to the default value (which is on) and see if this makes any difference . If it does'nt then I'll open a TAC case with the CCM traces.....once the Smatnet is in place (thats another story!!!)

G

[gsidhu]

I would like to share how this issue got resolved in case anybody comes across this issue in the future:

Even if you set G.711 codec for a region phones within that region will advertise G.722 codec and if both phones support that codec they will use it.

For internal calls between users/phones in the same 'G.711 region' with recording disabled:

When you put a call on hold the the recieve codec on the phone receiving MoH changes to G711. The MOH server is in the same 'G711 region' and since the MoH server does not support G.722 codec, the audio stream between the phone and MoH server is negotiated to use the G.711 codec. This can be verified when you look at the status of the phone ((Settings>Phone Status>Call Statistics).

Likewise when you use ad-hoc conferencing, the audio from the phones will terminate on the UCM conference bridge using G.711 (even though the call between the the original two parties started as G.722).

For users/phones with recording enabled:

The Verint Voice recorder does not support G.722 codec and this was not recording. This was also preventing MoH and conferencing (I'm not sure why but from the ccm/IPVMSA trace, UCM tried to insert a transcoder but failed).

A very useful document that helped me resolve this issue:

http://www.cisco.com/en/US/partner/docs/voice_ip_comm/cucm/admin/6_0_1/ccmfeat/fsmr.html

Resolution

1) Turn off 'Adertise G.722 codec' from phone configuration or Service Parameters (not the best option)

Or

2) On change the Service Parameter 'G722 Codec Enabled' to ‘Enabled for All Devices Except Recording-Enabled Devices'. This is a better solution than 1) as it allows users/phones with recording disabled to take advantage of the increased quality of wideband codec.

HTH anyone who may come across this issue...

Please rate helpful posts

[William Bell]

Gurmakh,

I was offline for a bit, just trying to catch up on e-mail.  Thanks for replying to this thread with the eventual resolution.  Good info (+5 for you)!

Regards,
Bill

[gsidhu]

Thank you Bill

I know a lot more about media resources and recording than I did a month ago - I've got the wireshark and ccm traces to prove it!