WTVP/Processes/MessageWatch
WTVP |
---|
Overview • List of WTVP Services • WTVP-specific Content-Types • Status Codes |
Concepts |
Tokens • Tickets • Capability Flags |
Headers |
Header List • Data Types • Common Request Headers |
Processes |
First-Time Registration • Headwaiter (Login) • Messenger Services • Favorites • Checking for new mail • Retrieving settings • Obtaining new wtv-tickets • Smart Card • Miscellaneous |
URLs for WTVP Services |
wtv-1800 • wtv-aroundtown • wtv-author • wtv-center • wtv-chat • wtv-content • wtv-cookie • wtv-customscript • wtv-disk • wtv-epguide • wtv-favorite • wtv-flashrom • wtv-guide • wtv-head-waiter • wtv-home • wtv-intro • wtv-log • wtv-mail • wtv-news • wtv-notices • wtv-partner • wtv-passport • wtv-register • wtv-setup • wtv-smartcard • wtv-spot • wtv-star • wtv-tricks • wtv-tutorial |
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 stringoff
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:
- The header
wtv-boot-led-message-state
has to be sent in the response with a value of eitheron
oroff
, depending on if any accounts registered on the box have new email. This will tell the box to turn on the message LED for MessageWatch.
- The
wtv-mail-count
header, if sent with the response, would likely contain the total amount of unread mail for all registered accounts on the box.
- The box then has to be instructed to hang up the phone and turn off. Sending an HTML document with a META REFRESH tag pointing to the client command
client:PowerOff
in the response body (<meta http-equiv="refresh" content="1;URL=client:PowerOff" />
) is believed to work on all builds. 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.