I have the following lab setup in place to test Cisco 7925 IP phones with Singlewire's Push to Talk (PTT) application.
WLC connected to a 3750 switch.
Single 1131AG access point registered with the WLC.
UCM version 8.6.2 with 9 x 7925 IP phones.
Singlewire PTT application running on a Windows 2003 server.
7925 phones have a dedicated WLAN and are registered with UCM. Normal phone to phone operation is ok.
When I initiate a PTT session from any phone, the phones in the group all play the alerting sound and join the session.
••· I can see the phone displays changing from talking, listening, waiting ok. This is the correct behaviour.
••· When the first person in the session presses the talk button, no audio is heard. This is true when the first person who tries to talk is the session initiator or any of the called phones.
••· When a second attempt to talk is made from another phone in the session, audio is played successfully from that phone and subsequently from any phone in the session.
••· Using Wireshark I’ve captured packets between the WLC and the 3750 switch. In the scenario described above, I can see phones transmitting multicast packets to 220.127.116.11 ok, even when no audio is being played.
Further testing has revelaved another pattern in the behaviour:
Initiate the PTT session, all phones in the group play the alerting tone and are active in the session.
Wait for approximately 10 seconds before attempting to press the talk button any phone.
From any phone in the session, press the talk key and after about a one second delay, audio is played ok. Previously I had been pressing the talk key as soon as the session had been initiated, which is what a user would do in the real world.
This suggests that some kind of timer is at work here where, if I wait for 10 seconds before trying to talk, audio is played ok (albeit with a further one second delay).
If anyone has seen PTT deployed with UCM and 7925 phones I would like to hear about it.
We're running into the same scenario but, it is also tied to our wired side. It does not happen on all devices. It seems like it does happen on devices that cannot download (via TFTP) the control audio wav files. If you have one phone in the group that cannot obtain the file then it affects the whole group. If you find that device and remove it from the group your audio should cut through right away.
I resolved the problem by downgrading the phone firmware from 1.4.2 to 1.3.4. Using the 1.4.2 firmware I ran some wireless traces and noticed that for the first 10 seconds of the session, the data in the multicast packets appeared to be corrupted. On downgrading the firmware, no corruption occurred and the voice stream kicked in immediately.
Transferring Crash file from standby: Login to the Active WLC in HA.
From CLI: (Cisco Controller) >transfer upload datatype crash (Cisco
Controller) >transfer upload filename (Cisco
Controller) >transfer upload mode tftp (Cisco Controller) >transfer
This is the start of a display filter cross reference between Wireshark
and OmniPeek. The 1st installment is a table of advanced filters. More
filters will be added as time allows. It is a living doc, so check back
for changes every so often Please feel f...