Knowledge Search


[WLC] Ascom VoIP handsets occasionally experience one-way calls

  [KB24029] Show Article Properties

This article describes a current interoperability issue between Ascom VoIP handsets and WLC/WLC wireless products, which can lead to one-way VoIP calls. This article will also cover a WLC configuration that can mitigate this issue.

WLAN VoIP users may experience a one-way voice call when establishing or receiving call on a Ascom handset.

Issue reported and workaround validated in:

  • WLC MSS, MP-522

  • Ascom i62 VoWIFI, phone version 2.5.7

This issue may also apply to other models of Ascom handsets; however, this has not been directly confirmed nor has the workaround been validated with other handset models.

In this case, the one-way audio calls is due to a difference in implementation of the U-APSD QoS mechanism between the WLC and Ascom. After an Ascom handset has associated to the WLAN and received a valid session, it will first initiate the SIP signaling to setup the call, then ARP for the call end-point (or Gateway), and finally start the RTP (voice) stream to the call end-point.

Analysis of wireless traffic captures of this issue has found that, under certain circumstances, the ARP response destined back to the Ascom handset may become queued at the WLA in a manner preventing the handset from retrieving the ARP response in a timely fashion.

Specifically, by default, the WLA will queue the ARP response in the Best Effort (BE) queue of the radio and due to a difference in implementation of U-APSD QoS between the WLC and Ascom, the handset may not receive the ARP response; until the WLA radio has no more packets in the Voice Queue (VO).  In the time that the ARP response is queued at the WLA radio, the handset will not be able to send the upstream RTP traffic.
Juniper is currently investigating a fix for this issue in software; however, as this requires a substantial change to the current U-APSD QoS implementation, this work is being prioritized accordingly. In the meantime, Juniper has found a WLC configuration, which may be used to work around this specific issue.

The workaround for this issue involves re-mapping the ARP traffic to the Voice Queue of the WLA radio versus the Best Effort, so that the ARP response is delivered in a timely fashion. The most specific way to implement this is to create a Layer 2 ACL, which matches ARP traffic and reclassifies it as COS 7. The following excerpt is an example of such an ACL:

set security acl name ARP_ACL permit cos 7 mac 00:00:00:00:00:00 ff:ff:ff:ff:ff:ff 00:00:00:00:00:00 ff:ff:ff:ff:ff:ff ethertype 806
set security acl name ARP_ACL permit mac 00:00:00:00:00:00 ff:ff:ff:ff:ff:ff 00:00:00:00:00:00 ff:ff:ff:ff:ff:ff ethertype any

The first line of this ACL matches Layer 2 frames with an Ethertype of 806 (which corresponds to ARP traffic) and reclassifies this traffic at COS 7, so that it will end up in the VO queue of the WLA radio. The second line of this ACL matches all other Layer 2 traffic and does not modfiy the COS value.  

This ACL may be mapped to either the VLAN for the VoIP users or to the Wireless Service Profile being used by the VoIP users (for performance considerations the ACL should be mapped to the VLAN; unless other reasons prevent this). For either of the mapping, the ACL should be mapped/applied in the out direction; so that the ARP traffic, which is going out to the AP, is reclassified.

Related Links: