Â Â We have a JTAPI application that uses the JMF library to send audio. The streaming audio stream can be heard on the desktop phones (e. g. 7941, 7961), wireless 7920 phones, and the Cisco IP Communicator but cannot be heard on the wireless 7921G or 7925G phones. There are no errors encountered in the programming logs when the audio is streamed with JMF to these phones.Â
Â Â To try to pinpoint the problem, we have gathered a number of traces and logs using the Cisco Real-Time Monitoring Tool and Wireshark. Â The only suspicious thing that we saw was in the Call Statics on the 7921G itself. Â The received packets showed 38 and the discarded packets also showed 38. Â But, we have no idea what the discarded packets are or why the 7921G would discard packets to begin with. Â We don't see discarded packets during a normal phone call.
Â Â People that we have talked to about this problem have indicated that they think it's a codec problem, but when we look at the codec in the traces, the phone status log and the events that we get back at the programmatic level, everything indicates that we are sending and receiving with the G.711 u-law with a 30msec packets size, and this matches the codec of the streaming application. Â We have even turned off the CUCM Service parameter "G722 Codec Enabled" to make sure that this setting was not overriding the G.711 negotiation. Â Changing the parameter had no effect on the problem.
Â Â We have checked the more obvious problems such as the volume on the 7921G phone and the volume of the original recording. Â In addition, we tried to rule out a WAP problem by using the CIPC on a wireless laptop connected to the same WAP as the 7921G phone. Â The announcement played just fine on the CIPC on the wireless laptop. Â
Â Â At the programming level,Â the audio is being streamed over a CTI port by the application when the call is connected to the destination phone. So, essentially, once the JTAPI application receives theÂ CiscoRTPOutputStartedEvÂ event, we set up the remote connection and start the stream.Â
The CTI port is set with:â¨Â Â Â CiscoMediaCapability caps = newÂ CiscoMediaCapability;â¨Â Â Â caps[Â 0] = CiscoMediaCapability.G711_64K_30_MILLISECONDS;
â¨ The audio stream is set for format ULAW_RAW (codec G.711 u-law):Â â¨Â Â FormatÂ audioFormatÂ = newÂ AudioFormat(Â AudioFormat.ULAW_RTP, 8000, 8, 1 );
â¨ I've adjusted the packet size to 20ms for the CUCM defaults as well as for theÂ CiscoMediaCapabiltiesÂ thinking that something might not be in sync. While making those adjustments effected the quality of the audio for the phones that were working, it did not effect being able to hear the audio on the 7921G. Â This problem occurs on the CCM 4.X, CUCM 6.0 and CUCM 7.0.1 platforms
Â Â Hopefully, there is a setting that we've overlooked, and there is a simple solution to the problem.
We had a similar problem, turns out wireless access point was blocking the audio. We use IP multicast to broadcast live page or wave file. In fact I just tested sending a live page via PhoneTop Messenger and it worked fine on 7921.
We used CIPC on a wireless laptop through the same WAP as the 7921G and heard the announcement fine, so we thought we'd ruled out the WAP. However, what about the WAP in your situation was blocking the audio transmission?
Also, when you multicast a wav file, are you using JMF and pushing the audio out directly to the destinations and using the CallManager port obtained through the RTPOutputProperties, or are you pushing a PhoneExecute to the destinations and telling them where to get the audio?
I believe this issue is more related to mid-call audio as opposed to a multicast real-time stream to the phone. Putting this problem a different way -- "the problem is that prompts don't play on a 7921 in an IVR application built using JMF -- is this an accurate way to state this?
Yes, your statement is an accurate way to state it. We wait until the receiving phone has been answered and use the remote port obtained from the RTPOutputProperties to stream a unicast announcement to the phone. Then, we wait for a DTMF response from the user in IVR fashion.
We'd assumed that other people were streaming announcements to the 7921G and not having a problem but wondered if anyone was doing it the way that we are. The previous post is helpful in trying to understand more about the phone. But, the question remains, what is different about how the 7921G reacts to the stream and how CIPC reacts to the stream going through the same WAP such that the announcement is not heard on the 7921G?
I found the problem in the JMF related code of our application. Per another thread on this forum, the codec packet size needed to be set specifically when setting up the audio track. For whatever reason, the 7921 seems to be more sensitive to this setting than the other phones.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...