WTVP/Processes/MessageWatch

WebTV and MSN TV boxes can be configured to check for new mail periodically while powered off. Officially referred to as MessageWatch, this feature would make the box turn on at an hour every day that was selected by the subscriber to dial into the WebTV/MSN TV service and get information on if any registered accounts have new mail before hanging up and turning off. If the service reports that the box has new mail during MessageWatch, then it will illuminate the message LED at the front to let the user know that new mail is waiting for them.

Configuring MessageWatch

In the final headwaiter response sent on successful login, a couple of the WTVP headers sent with it are used to configure MessageWatch. These headers are wtv-messagewatch-checktimeoffset and wtv-messagewatch-url:

• wtv-messagewatch-checktimeoffset either contains the number of seconds after midnight relative to the subscriber's time zone to check for new mail or the string off if MessageWatch is not enabled. Strangely enough, the offsets for MessageWatch in the last two headwaiter responses saved from the original service on their wiki page do not match up with the predefined times WebTV/MSN TV provided for MessageWatch to check mail at, but it is unclear why this is the case.

• wtv-messagewatch-url contains the URL the box must contact when turning on for MessageWatch. This is usually a URL to the headwaiter login service with an extra query attached to it: wtv-head-waiter:/login?MessageWatch=1. This header is only sent if MessageWatch is enabled on the subscriber's account.

Connecting for MessageWatch

When the box detects that it is time to connect for MessageWatch, it will turn on with audio output disabled, dial into any available local POPs, and attempt to log in using the URL specified in wtv-messagewatch-url, which in this case is the headwaiter login service. For New Classic clients, the presence of both the wtv-datadownload-checkoffset and wtv-datadownload-url headers are required for them to connect to MessageWatch, despite MessageWatch and DataDownload not having any direct correlation with each other.

The behavior of the first stage login service between MessageWatch and a normal login attempt are identical: the box is still expected to solve a challenge sent by the server to prove its identity and the server sends it a response to go to login-stage-two with the MessageWatch query added (wtv-head-waiter:/login-stage-two?MessageWatch=1):

200 OK\n
Connection: Keep-Alive\n
Expires: Wed, 09 Oct 1991 22:00:00 GMT\n
wtv-expire-all: wtv-head-waiter:\n
wtv-service: name=wtv-log host=xxx.xxx.xxx.xxx port=1609 connections=1\n
wtv-log-url: wtv-log:/log\n
wtv-challenge: L8Cb/nF0E3FJPU2HGvruA3shXjwyHs7tIOTqZX77uMsNjJ8DGkLtz0kS9FfuokgvtylkU/1wEFp1gJTGv5/U74xEyk6+dX0pr5MRpzDTYfMdUOdbFHBh496fAUyBqxNFqRdYCxh2oURfloQpZaQxFg==\n
wtv-relogin-url: wtv-head-waiter:/login?relogin=true\n
wtv-reconnect-url: wtv-head-waiter:/reconnect\n
wtv-visit: wtv-head-waiter:/login-stage-two-wtv-token-3776008786-EEFD06DA2CB23A82F740F98FC79905D2?MessageWatch=1\n
Content-length: 0\n
Content-type: text/html\n
\n

Once the box reaches login-stage-two and sends the server a valid challenge response, the exact responses the server would send are currently unknown. Based on work done by nitrate92, though, an approximation of how MessageWatch would have most likely worked can be made.

The response sent by login-stage-two for MessageWatch would have likely been similar to a typical final headwaiter response sent to a box with a single password-less subscriber account (at least the language and time headers would be present along with everything else), but the MessageWatch URL header would not be sent for obvious reasons. The important parts of the response that'd actually tell the box whether it has new mail or not are as follows:

• For all boxes, the header wtv-boot-message-led-state has to be sent in the response with a value of either on or off, depending on if any accounts registered on the box have new email. It's likely that later clients (around 2.5 and later) also need the wtv-mail-count header present in the response with the total of unread messages on all registered accounts. These will tell the box to turn on the message LED.

• Regardless of if any registered accounts have new mail, the response also has to send the header wtv-messagewatch-checktimeoffset: off. This tells the box that the MessageWatch request succeeded and stops it from making any further connections to MessageWatch.

• The box then has to be instructed to hang up the phone and turn off. Sending a wtv-visit header with the client command client:hangupphone is known to work for some builds, but for other builds (likely builds released very late into WebTV/MSN TV's lifespan), an HTML document with a META REFRESH tag pointing to the same client command has to be sent in the response body (<meta http-equiv="refresh" content="1;URL=client:hangupphone" />). How this step was handled on the original MessageWatch service is currently unknown.

If the MessageWatch connection fails for any reason, WebTV/MSN TV will pop up an error message and attempt to retry every 30 minutes.