JTAPI, JMF, and the 7921G

Question

  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

Answer 1

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?