By the Summer 2000 upgrade, WebTV introduced a new protocol into their firmware that was used to track how long clients were online for. The protocol runs on top of UDP, and does not have an official name. It will be referred to as the Metering protocol on this page.
Metering was introduced in WebTV by client version 2.5 for all box models. This protocol and Mail Notify do not work on a hacked WebTV Viewer.
Once a WebTV/MSN TV client receives the final headwaiter response, it will check for the presence of a few headers from it to decide if it can connect to the Metering server. The following headers have to be in the headwaiter response in order for the client to connect to Metering:
wtv-metering-pricing-interval: [number of seconds]
wtv-metering-pricing-sessionID: [30-byte ID string]
These headers tell the client to enable metering, set the interval in seconds to wait in between sending packets, a 30-byte session ID to use to identify itself to the Metering server, and a "track-as-free" header which serves an as of yet unknown purpose. A wtv-service with the name
wtv-census-udp also has to be present, which is a UDP server running on port 1657 that the client will connect to for Metering. The client will then connect to the Metering server and start sending packets to it.
The packets sent to the Metering server are in a binary format. All packets sent to the Metering server are 58 bytes long. All integer values sent in these packets are packed in big endian.
|Type of packet. This is
0x0002 for reporting metering data, and
0x0003 for an unclear purpose (restarting the metering session?)
|Likely a 16-bit sequence ID. Increments by 1 for every unique packet sent to Metering
|Integer. Seconds elapsed since logged into WebTV/MSN TV. Increases by the number specified in the
wtv-metering-pricing-interval header for every new packet
|The session ID specified in
|MD5 hash of the first WTVP session key sent to the client in the challenge response and the first 0x2A bytes of the packet
Official clients (at least build 2.6) will send a single packet 3 times to the UDP server, possibly to ensure that the packet actually goes through. The server also does not appear to have to send any responses back to the client, as official clients do not respond to any packets sent from the server, and a decompilation of the firmware reveals that the callback for receiving data does not do anything for Metering.