cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
874
Views
0
Helpful
7
Replies

JTAPI, JMF, and the 7921G

ross.judith
Level 1
Level 1

  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[1];
   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.

Thanks,

-Judy

7 Replies 7

msabir
Level 4
Level 4

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.

Thank you for your quick reply.

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?

We use JMF to broadcast audio:

AudioFormat format =new AudioFormat(AudioFormat.ULAW_RTP, 8000.0, 8, 1);

For push, we use HTTP POST and CiscoIPPhoneExecute object along with RTPRx.

I hope it helps.

Yes, that helps us narrow down the problem. Thank you.

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: