Free the mouse Replay IvsProtocol
Home | Changes | Index | Search | Go
The InternetVideoSharing protocol is used to transfer recorded shows from one ReplayTV4000? to another, via the internet. It differs from RemoteStreaming in several ways, including capabilities, user interface, and protocol.

The IvsProtocol can be split into several pieces:

Address lookup

Address lookup is handled via the RDDNS protocol, which is quite different from the rest of the IvsProtocol and is documented separately.

Address verification

It's not yet clear where in the process this actually occurs, and which side (or if both sides) of the transfer perform it.

The ReplayTV that wishes to verify it has a correct address makes an HTTP request to the address it has been given:

  http://replay-address:port/ivs-IVSGetUnitInfo

The expected response is an XML document (content-type text/plain) like:

<?xml version='1.0' encoding='UTF-8'?>
<UnitInfo isn="00055-09166-55204" nickname="Jtl" />

Sending Notification

When one Replay has been told to send a show to another one, what it actually does is make a send notification request:
  http://recipient-address:port/ivs-IVSSendNotification?isn=00055-09166-55204&size=1044&data=00000001000000000000000000000001
The actual data is much longer - 1044 characters, as specified by the size argument. The isn argument is the recipient's ISN, presumably so that it can triple check that its the intended target; this triple checking isn't actually done, however.

The data in the data argument is a hex encoded structure. It's decoded as if it were variable-sized, but it seems to be fixed in the current version; the offsets aren't correct for simply loading it in memory and using it as-is: it's actually stored in a file and read in in pieces.

4.1 and 4.3:

Offset Size Name Notes
0 4 unknown1 Always '1'. Possibly a version code for the rest of the structure
4 4 unknown2 Always '0'
8 4 unknown3 Always '0'
12 4 unknown4 Always '1'
16 4 isn_field_length Always '18', but this is actually checked and used by the receiver to parse the rest of the structure
20 18 recipient_isn The recipient's ISN, as a NUL-terminated ASCII string in the standard output format
38 4 magic1 Always '0'; verified by recipient when decoding the ReplayShow member. Possibly a sub-version for this part of the struct, or for the AddressBookEntry.
42 4 magic2 Always '3'; verified by recipient when decoding the ReplayShow member. Possibly a version for the ReplayShow structure itself (compare with the 'ReplayChannels/3/' directory).
46 32 sender_abe AddressBookEntry for the sender
78 444 replay_show ReplayShow structure for the show being sent, with the index_size and mpeg_size members filled in

4.5 and 5.0:

Offset Size Name Notes
0 4 unknown1 Always '1'. Possibly a version code for the rest of the structure
4 4 unknown2 Always '0'
8 4 unknown3 Always '0'
12 4 unknown4 Always '1'
16 4 isn_field_length Always '18', but this is actually checked and used by the receiver to parse the rest of the structure
20 18 recipient_isn The recipient's ISN, as a NUL-terminated ASCII string in the standard output format
38 4 magic1 Always '0'; verified by recipient when decoding the ReplayShow member. Possibly a sub-version for this part of the struct, or for the AddressBookEntry.
42 4 magic2 Always '5'; verified by recipient when decoding the ReplayShow member. Possibly a version for the ReplayShow structure itself (compare with the 'ReplayChannels/5/' directory).
46 32 sender_abe AddressBookEntry for the sender
78 512 replay_show ReplayShow structure for the show being sent, with the index_size, mpeg_size, and evt_size members filled in

Program retrieval

Program retrieval is accomplished via a series of requests from the recipient to the sender (thus, the sender must have an open addressable port); the index file is retrieved, then the mpeg file.

Each request looks like:

   http://replay-address:port/ivs-IVSGetFileChunk?isn=00055-09166-55204&start=0&chunksize=4194304&filepath=/name/mpeg/108822343.ndx

The isn argument is the sender's ISN; like the isn argument in the sending notification request, this could be used to verify that the proper RTV is being talked to.

The start argument is the file offset to begin sending at. Compare with HTTPFS's readfile =pos= argument.

The chunksize argument is the amount of data requested for this request. Compare with HTTPFS's readfile =size= argument.

The filepath argument is the full, Replay-internal, filename being requested. These always start with /name/mpeg.

There's an optional crc argument that the Replay doesn't actually use; it defaults to the value '0'.

The response is sent using HTTP 1/1 chunking in its standard way. Ignoring that, the response body is simply a chunk start line, a chunk of the file, and a chunk end line.

The chunk start line looks like #####REPLAY_CHUNK_START#####4194304#####0 and is terminated by a CRLF. The first number is the requested chunk size (which may be larger than the chunk actually returned, if the file is shorter); the second number is the value supplied by the requesting crc argument, defaulting to 0.

The chunk end line looks like #####REPLAY_CHUNK_END##### and is also terminated by a CRLF.

The end of a file seems to be signalled by a chunk start line with no chunk end line, as the full contents of an HTTP response body.

-- ToddLarason - 31 Mar 2002


The last line of the Program Retrieval section makes it sound like the end-of-file marker is a REPLAY_CHUNK_START line terminated by a CRLF and then followed by another CRLF. It is in fact just a normal REPLAY_CHUNK_END line with one CRLF at the end.

-- TWikiGuest - 24 Apr 2002

Thanks, I'd misread my packet dump -- the second CRLF I was seeing was terminating the HTTP chunk, not part of it.

-- ToddLarason - 29 Apr 2002

Added 5K information.

-- HenryDonzis - 23 Oct 2008


Your post will appear before this form in chronological order (newest at bottom)

Topic IvsProtocol . { Edit | Attach | Ref-By | Printable | Diffs | r1.5 | > | r1.4 | > | r1.3 | More }
Revision r1.5 - 01 Apr 2003 - 04:44 GMT - TWikiGuest

Copyright © 2001 by the contributing authors. All material on this collaboration tool is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback.