For many years, we have been using the Gigaset C610A-IP VoIP phones with a SipCity VoIP service, which has been for the most part stable, reliable and high quality. When our Melbourne office activated its FTTC NBN service from Vodafone though, a strange problem started to occur: we could hear callers, but they couldn’t hear us. After an intensive round of reconfiguration and settings changes, it became apparent that there wan’t anything wrong with our local setup, but that the outbound voice packets being sent by our phone weren’t being received by SipCity. Perhaps most frustratingly, when we set up a software based VoIP client on the same connection, everything worked as it should. So what was happening here, and what was the solution?
The NBN operates a little differently from ISP’s of days gone by. In order to offer a reliable phone service over the same connection as internet data, the NBN decided to use a technology called Quality of Service (QoS) to differentiate voice packets from regular data packets. QoS would tag each voice packet in a way that would be recognised by the NBN’s routers, and they would know this data should be delivered before anything else. After all, voice traffic is highly time sensitive.
Taking this a step further, the NBN wanted to provide for future business grade services, whose traffic could be separated out and sent over priority pathways. At a wholesale level, the NBN is currently offering three traffic classes, TC-1 for voice, TC-2 for symmetrical services with the same upload and download speed, and TC-4 for regular data. On the NBN network, traffic in each class is identified using a Differentiated Services Code Point (DSCP) tag, added to each IP packet; the idea being that the QoS that prioritises the traffic are implemented on the NBN routers by reading the DSCP tag of each packet and applying the appropriate rule.
In its default state, a little packet analysis with tcpdump reveals the Gigaset marks each packet with a DSCP value of 34, which is reported by tcpdump as tos value 0x88. The problem is that Vodafone, and apparently other NBN operators, simply drop traffic marked in this way. The audio stream from the phone gets to the NBN network, but rather than arriving at your VoIP provider, seems to get sent into a black hole. In one way, this makes sense – the NBN want to ensure priority traffic is being paid for, and as Vodafone aren’t offering a VoIP service, maybe this is seen as an attempt to circumvent the system. The problem for Gigaset users is that there is no simple way in the web configuration to set the traffic class.
Fortunately, super smart cookie Thunderbird 1 posted a tutorial over at Whirlpool that describes how to use an XML file to configure the default traffic class, and when it is set to DSCP 26, or tos 0x68, which in the NBN world appears to be the equivalent of “normal Internet traffic,” all of a sudden the voice started to flow and callers were able to hear us again.
This is certainly an issue for Gigaset users migrating to the NBN, and would be a difficult problem for most users to resolve. Gigaset could include a traffic class option in their web interface, Vodafone or NBN could stop dropping the packets. Until then though, it appears this is the solution.
