PTTH

[Maitland Bottoms]

The remainder of this text in an encore presentation...

>From aa4hs at amrad.org Thu, 16 Nov 2000 14:28:29 -0500
Date: Thu, 16 Nov 2000 14:28:29 -0500
From: Maitland Bottoms aa4hs at amrad.org
Subject: PTTH

>>>>> "w4ri" == Paul L Rinaldo <prinaldo at mindspring.com> writes:

    w4ri> Particularly for Dave Borden, A year or so ago, one of us
    w4ri> (Dave, George or I) had some discussions about a basic
    w4ri> digital communications protocol that would serve as a
    w4ri> protocol identifier for digital modulation schemes.
    ...[6]
    w4ri> PS: Anyone else who might have it in private archives please
    w4ri> cough it up.  It's time has come.
 
Ah yes, I had some ideas along this line....[1]

Packet Transmission Type Handshake

Protocol to determine shared modulation modes between communicating
radios.

The set of possible modes is represented by a list of Modulation
Envelope Mode Identity types that enable communication identifying
shared modes for the actual transmission of data.

Also the handshake can specify protocol versions, and might take place
on a spread spectrum link, the SPTTH [2] variant. The PTTH protocol is
extensible, so that as new radios become available, they merely
negotiate their common MEMI types, which might not exist at the
present time.

Thus radios become Bandwidth Enhanced Wireless servers, and create BEW
links between themselves. The protocol can be more efficient if
information is saved, so that two radios that have previously been
through the PTTH negotiation can exchange Tokens About Cached
Objects. These TACOs should be optional.[3]

Example:
Here the Packet Transmission Type Handshake is used to negotiate a
traditional analog modulation scheme...

Station A			Station B

CQ PTTH	DE W3URL
				PTTH/1.0 QRZ? DE W3WWW
				Allow: QSO QSY

From: w3url at ampr.net		
Accept: QSO/audio BW<6kHz	
Accept: QSO/video		
Accept-Encoding: AM, FM, usb	
User-Agent: ICOM IC-xxx		

				Server: Yaesu YYYY
				Content-Type: QSO/audio
				Content-Encoding: FM dev=5kHz

OK
 (sends FM transmission)
K

				R
				 (sends FM transmission)
				73

RST: 599
QSL: Please
Closing: 73 OM
Connection: Closed

				RST: 599
				QSL: Please
				Connection: Closed


Example discussion: Station A calls a general CQ. Station B responds,
indicates the version of PTTH supported, and the either the stations
may communicate in a QSO or optionally go to another
frequency. (Crystal controlled stations would not respond with the QSY
option.) Station A's radio can do various forms of audio and
video. Station B's cannot do everything, but can respond with an
acceptable FM mode. The communication takes place in FM with
procedural data packets. The contact ends with standard PTTH protocol
closings.

Notes:
[1] These ideas mainly come from applying Cepstral Analysis[4] to a
system described in http://www.w3.org/Protocols/rfc2616/rfc2616.html
(see also [5]) while drinking beer.

[2] Spread PTTH, (SPTTH) is thought to be more private and resistant
to evesdropping.

[3] TACOs are a tasty alternative to Cookies.

[4] What's the quefrency Kenneth?

[5] http://www.w3.org/Protocols/Classic.html[7]

[6] Comments to parts snipped above:

    w4ri> Neither George nor I can find the paper describing this
    w4ri> concept. In fact, we can't remember who (for sure) wrote it
    w4ri> but believe it was written.

A draft was started by Tim Berners-Lee, I believe.

    w4ri> Dave: Are you harboring such a paper? Can you send it to me
    w4ri> electrically?

What, you mean on the World Wide Web?

    w4ri> The reason for this is that the League is establishing a
    w4ri> digital voice committee with Doug Smith, KF6DX, in the
    w4ri> chair. I mentioned this concept to him and he'd like the
    w4ri> details.

    w4ri> 73, Paul, W4RI


[7] Why not use Internet RFCs for radio projects. Isn't the LF effort
really in support of RFC 1216?