WTVP/Processes/MessageWatch

From WebTV Wiki
Jump to navigation Jump to search
WTVP
OverviewList of WTVP ServicesWTVP-specific Content-TypesStatus Codes
Concepts
TokensTicketsCapability Flags
Headers
Header ListData TypesCommon Request Headers
Processes
First-Time RegistrationHeadwaiter (Login)Messenger ServicesFavoritesChecking for new mailRetrieving settingsObtaining new wtv-ticketsSmart CardMiscellaneous
URLs for WTVP Services
wtv-1800wtv-aroundtownwtv-authorwtv-centerwtv-chatwtv-contentwtv-cookiewtv-customscriptwtv-diskwtv-epguidewtv-favoritewtv-flashromwtv-guidewtv-head-waiterwtv-homewtv-introwtv-logwtv-mailwtv-newswtv-noticeswtv-partnerwtv-passportwtv-registerwtv-setupwtv-smartcardwtv-spotwtv-starwtv-trickswtv-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 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:

  • The header wtv-boot-led-message-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. 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.
    • It's known that MessageWatch would also trigger a download on clients that support the feature (WebTV Plus), at least for a video ad. This likely required the server to send a client command for the client to do this. What command it used for this purpose is unknown at the moment.


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