WTVP/Processes/MessageWatch - Revision history

Wtv-411: /* Connecting for MessageWatch */ Mention download step for MessageWatch

2023-07-13T19:26:52Z

Connecting for MessageWatch: Mention download step for MessageWatch

← Older revision		Revision as of 15:26, 13 July 2023
Line 42:		Line 42:

	* 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 <code>client:PowerOff</code> in the response body (<code><meta http-equiv="refresh" content="1;URL=client:PowerOff" /></code>) is believed to work on all builds. How this step was handled on the original MessageWatch service is currently unknown.		* 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 <code>client:PowerOff</code> in the response body (<code><meta http-equiv="refresh" content="1;URL=client:PowerOff" /></code>) 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.		If the MessageWatch connection fails for any reason, WebTV/MSN TV will pop up an error message and attempt to retry every 30 minutes.

Wtv-411: Fix name for message LED header

2023-07-03T00:16:40Z

Fix name for message LED header

← Older revision		Revision as of 20:16, 2 July 2023
Line 37:		Line 37:
	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 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 <code>wtv-boot-message~~-led~~-state</code> has to be sent in the response with a value of either <code>on</code> or <code>off</code>, 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 header <code>wtv-boot-led-message-state</code> has to be sent in the response with a value of either <code>on</code> or <code>off</code>, 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 <code>wtv-mail-count</code> header, if sent with the response, would likely contain the total amount of unread mail for all registered accounts on the box.		* The <code>wtv-mail-count</code> header, if sent with the response, would likely contain the total amount of unread mail for all registered accounts on the box.

Wtv-411: Update info on MessageWatch service

2023-07-02T22:18:40Z

Update info on MessageWatch service

← Older revision		Revision as of 18:18, 2 July 2023
Line 37:		Line 37:
	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 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 <code>wtv-boot-message-led-state</code> has to be sent in the response with a value of either <code>on</code> or <code>off</code>, 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 <code>wtv-mail-count</code> 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.		* The header <code>wtv-boot-message-led-state</code> has to be sent in the response with a value of either <code>on</code> or <code>off</code>, 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.

	* ~~Regardless of if any registered accounts have new mail, the response also has to send the header~~ <code>wtv-~~messagewatch~~-~~checktimeoffset: off~~</code>~~. This tells~~ the box ~~that the MessageWatch request succeeded and stops it from making any further connections to MessageWatch~~.		* The <code>wtv-mail-count</code> 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 a ~~<code>wtv-visit</code> header with~~ the client command <code>client:~~hangupphone~~</code> 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 (<code><meta http-equiv="refresh" content="1;URL=client:~~hangupphone~~" /></code>). How this step was handled on the original MessageWatch service is currently unknown.		* 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 <code>client:PowerOff</code> in the response body (<code><meta http-equiv="refresh" content="1;URL=client:PowerOff" /></code>) 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.		If the MessageWatch connection fails for any reason, WebTV/MSN TV will pop up an error message and attempt to retry every 30 minutes.

Wtv-411: Fix a typo

2023-07-02T16:26:23Z

Fix a typo

← Older revision		Revision as of 12:26, 2 July 2023
Line 13:		Line 13:
	== Connecting for MessageWatch ==		== 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 <code>wtv-messagewatch-url</code>, which in this case is the headwaiter [[WTVP/Processes/Headwaiter\|login]] service. For New Classic clients, the presence of both the <code>wtv-~~daatdownload~~-checkoffset</code> and <code>wtv-datadownload-url</code> headers are required for them to connect to MessageWatch, despite MessageWatch and DataDownload not having any direct correlation with each other.		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 <code>wtv-messagewatch-url</code>, which in this case is the headwaiter [[WTVP/Processes/Headwaiter\|login]] service. For New Classic clients, the presence of both the <code>wtv-datadownload-checkoffset</code> and <code>wtv-datadownload-url</code> 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 (<code>wtv-head-waiter:/login-stage-two?MessageWatch=1</code>):		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 (<code>wtv-head-waiter:/login-stage-two?MessageWatch=1</code>):

Wtv-411: Create page for MessageWatch

2023-07-02T16:13:05Z

Create page for MessageWatch

New page

{{WTVPNav}}

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 [[WTVP/Processes/Headwaiter/Final Responses|final headwaiter response]] sent on successful login, a couple of the WTVP headers sent with it are used to configure MessageWatch. These headers are <code>wtv-messagewatch-checktimeoffset</code> and <code>wtv-messagewatch-url</code>:

* <code>wtv-messagewatch-checktimeoffset</code> either contains the number of seconds after midnight relative to the subscriber's time zone to check for new mail or the string <code>off</code> 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.

* <code>wtv-messagewatch-url</code> 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: <code>wtv-head-waiter:/login?MessageWatch=1</code>. 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 <code>wtv-messagewatch-url</code>, which in this case is the headwaiter [[WTVP/Processes/Headwaiter|login]] service. For New Classic clients, the presence of both the <code>wtv-daatdownload-checkoffset</code> and <code>wtv-datadownload-url</code> 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 (<code>wtv-head-waiter:/login-stage-two?MessageWatch=1</code>):

<pre>
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
</pre>

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 <code>wtv-boot-message-led-state</code> has to be sent in the response with a value of either <code>on</code> or <code>off</code>, 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 <code>wtv-mail-count</code> 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 <code>wtv-messagewatch-checktimeoffset: off</code>. 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 <code>wtv-visit</code> header with the client command <code>client:hangupphone</code> 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 (<code><meta http-equiv="refresh" content="1;URL=client:hangupphone" /></code>). 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.