1

We have an audio over IP app based on the iPhone, and we're currently playing with setting the TOS level and seeing how this is reflected in the 802.11 Qos Control field.

We're doing this simply setsockopt call:

    int tos = 0xB8; // VOICE
    status = setsockopt(socketFD, IPPROTO_IP, IP_TOS, &tos, sizeof(tos));

    if (status == -1)
    {
        if (errPtr)
            *errPtr = [self errnoErrorWithReason:@"Error setting TOS (setsockopt)"];
    }

The theory is that this would tag all the packets as VOICE on the WLAN link, but we're ending up with a TID of 5, which indicates VIDEO (at least according to Wireshark).

This is traffic FROM iPhone TO the wireless AP, so there's no in-WAP mapping we can do.

We've been able to set a TOS of 0xC8, and this does result in a VOICE classification, but the rest of the network seems to get confused when a TOS value of C8 ends up in the IP headers.

Anyone know what value we're supposed to use to get VOICE over 802.11, on packets sourcing from the iPhone?

Chuck D
  • 313
  • 2
  • 13

1 Answers1

3

You are looking at two different values - one is the layer 1 value and the other is a layer 2 value. There is no direct correspondence between the two - some mapping needs to be provided.

In your case this mapping must be performed by the Access Point (or by a Wireless Lan Controller if lightweight access points are used) and by the network stack on the originating device and therefore you don't have direct control over this mapping.

You are operating at the IP layer, not the network link layer, so all you can do is set an appropriate DSCP (via the TOS value) and trust the lower layers to do the right thing.

DSCP 46 (EF) (TOS value 0xB8) is the most appropriate for voice traffic. It seems that the iOS stack puts this into 802.11e UP 5. While you may prefer 6 you have no control over this. Other equipment will map things differently. For example, Cisco APs will map EF to UP 6

The main thing is that by nominating DSCP EF you are giving the best indication to all network elements, end-to-end, as to how this traffic should be treated.

QoS from the originating wireless device is reasonably useless anyway - generally the WiFi within the device won't be congested so QoS isn't necessary and you have no control over other devices that are sending on the network - WiFi is a shared access medium.

QoS in the Access Point can be a benefit as the overall wireless link may be congested and the AP can use QoS to make a decision as to which packet from its input queue should be sent next.

Paulw11
  • 108,386
  • 14
  • 159
  • 186
  • I've seen 'other' products use a TOS setting of 0xC0 to accomplish the UP 6 value on the iPhone. My concern was that this is 'supposed' to be reserved for inter-network control, and that might confuse some other equipment somewhere. Also our prior value of 0xC8 is totally non-standard, and we were worried that this would really mess things up somewhere. – Chuck D May 11 '15 at 20:53
  • Correct. A value of 0xC0 will map to an IP precedence of 6, which it seems the iOS IP stack will map (naively) to a UP of 6 - you are then at the whim of the Access Point mapping to map UP6 to IP EF (TOS 0xB8). You need to understand how the WiFi infrastructure you are using will map things. Given the relative ineffectiveness of UP values from the phone you are better of using TOS 0xB8 – Paulw11 May 11 '15 at 20:56
  • We've probably been getting away with the fact that our Ruckus AP's detect audio traffic heuristically and classify outgoing traffic correctly as voice, even though we've been using 0xC8. You also mentioned the 'relative ineffectiveness' of UP values from the phone. Can you elaborate slightly on this? Thanks! – Chuck D May 11 '15 at 21:19
  • Yes, mapping UP6 to IP EF is a reasonable thing for an AP to do as well, but unfortunately the behaviour isn't defined anywhere - it is up the AP implementation as to what they do. – Paulw11 May 11 '15 at 21:20
  • QoS only comes into play when a network link is congested. When the user is talking on a VoIP app they are unlikely to generating a lot of traffic from other apps, so their network card won't be congested. The UP value has no effect on other devices that are sending - they can still use all of the available WiFi bandwidth. In the case of the AP it has a queue of packets to be sent so it can use QoS to determine which ones should be prioritised – Paulw11 May 12 '15 at 01:57
  • Thanks Paul, this is great info! – Chuck D May 12 '15 at 15:11