cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2414
Views
0
Helpful
3
Replies

U-APSD Problem with Ascom VoWIFI Device

Marc Aemmer
Level 1
Level 1

Hi everybody,

We are facing problems when enabling U-APSD on our Ascom i62 VoWifi Phones. When receiving a call and picking it up, then sometimes there is no incoming voice traffic for the first 1-2 seconds. We're using a 5520 WLC (8.2.151.0) and 2802 AP's. There is also a special SSID for VoWifi Clients where WMM and QoS is configured as described in the Interoperability Guides from Ascom. DTIM Period is set to 5. QoS is set to Platinum and WMM to “Required”. EDCA profile for 802.11b/g/n is set to "Voice Optimized" and low latency MAC is disabled. 802.1p Tag (Wired QoS Protocol) is set to 6 for Platinum QoS Profile.

Have you got any ideas what the issue could be?

thanks,
Marc

3 Replies 3

Ric Beeching
Level 7
Level 7

Hi Marc,

Sounds like a potential SIP issue on the wired side rather than wireless... you would probably need to wireshark the ingress/egress to the 5520 (if central switching) and confirm that the signalling traffic is being marked as EF all the way through. You would need to confirm that across the whole infrastructure and also that SIP inspect is working on the FW if so.

That's my guess anyway... either way a wireshark should help determine the sequence of events and where the delays may be introduced.

Cheers,

Ric

-----------------------------
Please rate helpful / correct posts

Leo Laohoo
Hall of Fame
Hall of Fame

What is the TSPEC configuration of the Ascom server?  Is it Required or Optional?  Compare the settings with Admission Control (ACM) and see if it's Enabled or not.

Ameulen01
Level 1
Level 1
we have the same issue with Mitel 5624 phones on a 5520 controller, 2802 AP's and version 8.2.151.0. What we can see in the wireless capture is after the SIP call setup the wireless handset is doing a SIP SDP request to the voice controller, it does not respond right away and sends it another 3 times. on the voice controller we see in a capture that it responds right away on the SIP SDP request. Only on the wireless handset it receives the SIP SDP ack in delay for around 4 a 5 seconds and receives all 4 SIP SDP ack at the same time (as it is buffered in the AP somehow). But on the same moment the wifi handset is already receiving the RTP stream, maybe because of the higher 802.11e priority of 6.

did you have a solution for the Ascom I62?
Review Cisco Networking products for a $25 gift card