Search code examples
iosiphonecocoavoipqos

TOS to 802.11 QOS Control on iPhone


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?


Solution

  • 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.