The Lightweight Telephony Protocol

Ashhar Farhan
Hyderabad September 1999

Status of this memo

This document specifies an Internet standards draft for the Internet community and requests for discussion and suggestions for improvements. Distribution of this memo is unlimited.

Abstract

The Lightweight Telephony Protocol (LTP) is an application-layer control NAT friendly, lightweight signaling protocol for creating, modifying and terminating RTP(RFC 1889) sessions with one or more participants. These sessions include TCP/IP based telephone calls, multimedia conferences, push to talk, etc. In addition to sessions, the protocol also supports out-of-session Instant Messaging and Presence.

1. Introduction

The LTP is a simple, flexible binary protocol that provides the following Internet telephony services:

1.1 Fully patent free telephony stack that works exclusively with free codecs.

1.2 UDP based signaling and media with stateless proxies and servers.

1.3 NAT friendly, simpleprovisioning of users.

1.4 Integrated Presence, Instant Messaging, Push-to-talk, voice and video between Internet hosts.

1.5 Lightweight protocol specially suited for low cost, self-provisioned, Internet telephony services.

1.6 SIP (RFC 3261) inspired protocol that aims works on the same principles with narrower functionality.

2. LTP Definitions:

2.1 USER-ID: Every LTP client has a unique USER-ID of up to 64 octets encoded in UTF-8 format. Note that the LTP does not insist on any particular syntax of User-IDs except that they be limited to 64 octets or less.

2.2 END-POINT: Every entity in the LTP network is uniquely identified by its IPv4 address and 16-bit UDP port number. Together, each pair of an IP address and a port that can receive and send LTP/RTP traffic is known as an end-point. Note: A single IP address may have multiple end-points at multiple ports as an end-point is defined by the pair of IP address and UDP port and not the IP address alone.

2.3 REQUESTS: An LTP end-point (like the client) can send REQUEST packets to another end-point (like another client) repeatedly until either it times out or a response is received.

2.4 RESPONSE: An LTP end-point may, upon receiving a request, decide to send back a response. It can also decide to either silently discard the request or forward the request to another end-point (for instance, an incoming call.s packet maybe forwarded to another client). A response packet is matched to a request by the TO, FROM, SESSIONID and MSGID fields.

2.5 CLIENT: Clients (also known as USER-AGENTS) represent an end-point with an assigned LTP User-Id. They can serve as the final recipient or the original sender of LTP packets. The Clients usually do not forward LTP or media packets any further. For instance: an IP telephone device, a soft-phone or a PSTN gateway is an LTP client. Each client is logged onto an LTP server.

2.6 SERVER: LTP server stores LTP user-ids, passwords, presence state, last known end-point and relay assigned to each User-id, etc. LTP servers can directly respond to LTP request packets.

2.7 RELAY: LTP relays are used for forwarding packets between end-points that are behind NATs. The LTP packets carry their own forwarding information. The relays are very lightweight agents that serve to blindly forward packets (stateless behavior).

2.8 SESSION: A context of media (RTP) and/or presence (LTP) packets between two End-points. It is possible that two User-IDs may engage in multiple sessions simultaneously (for instance, trunking between media gateways). Parallel sessions are identified by their SESSION IDs that are unique.

3. Network Topology

3.1 The LTP is an application layer signaling protocol that runs on top of UDP and shares the same data stream as the media (RTP) thereby eliminating NAT traversal issues. The LTP packets are identified from the RTP stream by checking that their most significant bit of the first octet of the UDP packet set to 0.

3.2 Each LTP network consists of an LTP server that is listening at a well-known end-point address and port (usually, the LTP servers listen on UDP port 5004).

3.3 Each LTP server keeps track on one or more LTP relays.

3.4 Each LTP client is logged onto the LTP server through an LTP relay (unless an LTP client is on a public IP address and it can receive and send UDP packets from and to any host).

4. Routing LTP packets

All LTP packets are repeatedly sent until either a response is obtained or the end-point times out. The protocol does not specify any set timings or algorithms to determine the time of next retry or number of retries.

The following sequence routes a packet from one client to another:

4.1 When an LTP client wants to send a packet to another client, it sets the packet.s CONTACT fields with the address of the destination client.s end-point address.

4.2 The packet is then sent to the relay associated with the destination client.

4.3 The relay notes the end-point address of the client from which it received the packet.

4.4 The relay retrieves the destination.s address from the packet.s CONTACT fields.

4.5 The relay sets the CONTACT fields to the end-point from which it received this packet (retrieved in step 3.3).

4.6 The relay then forwards the packet to the address of the destination retrieved in step 4.4

4.7 The destination receives the forwarded packet and notes the address of the relay from which it received the packet.

4.8 To send a packet back to the sender, it has to set the reply packet.s CONTACT fields same as that on the received packet and send it to the relay that it received the packet from.

4.9 Strictly speaking, the relays are optional (required only where sending and receiving end-points are behind restrictive NATs). However, in real world, the relays are almost always required in general usage.

5. LTP Packets

All LTP packets are packed as a binary structure of fixed 170 octets header followed by a UTF-8 encoded text payload that extends to the end of the UDP packet. All numeric fields except CONTACT fields are formatted in little-endian order to make them easier to handle on the most popular host architectures. Every LTP packet MUST contain all of the following fields:

5.1 VERSION: 16-bit (2 octet) value of current version of LTP protocol (set to 1 in this draft). This field MUST be set in all packets.

5.2 COMMAND: 16-bit (2 octet) numeric id of the request type. The following commands are defined at the moment. Only the following ids are defined in the LTP protocol at the moment. Note: A compliant LTP implementation should not only handle these command types but must not define any further types without the author.s approval. This is done to prevent the protocol from being embraced and extended.

Some ids like 2, 7, 11 are no longer used in the current draft and they have been deprecated. This field MUST be set in all packets.

5.3 RESPONSE: 16-bit (2 octet) numeric response code. A value of 0 in this field indicates that the packet is a request. A non-zero value in this field will accordingly defines the packet to be a response (to a previous request). The following response codes are defined:

These response codes bear resemblance to HTTP and SIP response codes. Special note is to be made of RESPONSE_OK_RELAYED as it implies the future packets should be relayed (Section 4). This field MUST only be set in the response packets.

5.4 TO: (64 octet wide) field that holds zero terminated UTF-8 encoded User ID of the packet.s intended recipient. Note that standard ASCII is fully compatible with UTF-8 and regular development environment can use standard string libraries to handle this field. This field MUST be set in all packets.

5.4 FROM: (64 octet wide) field that holds zero terminated UTF-8 encoded User ID of the packet.s sender. Note that standard ASCII is fully compatible with UTF-8 and regular development environment can use standard string libraries to handle this field. This field MUST be set in all packets.

5.5 SESSION: (4 octets) field that uniquely specifies a particular session between two User IDs. This field MUST be set in all packets

5.5 MSG: (4 octets) field that uniquely specifies a particular LTP request within a session. An LTP session can have multiple requests simultaneously. A request within a session is matched to its response packet with the MSD ID. This field MUST be set in all packets.

5.6 AUTHENTICATE: (16 octets) field that can carry a digest challenge in response packets (with response code 407) or an MD5 digest reply in the subsequent requests. (Section xxx). This field is interpreted as a 128-bit binary block.

5.7 CONTACT-IP: 32-bit (4 octet) field that MAY contain a valid IPv4 host address that belongs to a valid LTP end-point. This field is stored in network byte order (most significant byte first). This field should be set to all zeros if it is not used.

5.8 CONTACT-PORT: 16-bit (2 octet) field that MUST contain a valid UDP port number ONLY if CONTACT-IP is set. This field is stored in network byte order (most significant byte first).

5.9 WPARAM: 16-bit (2 octet) field that MAY hold 16 bits of information that is request specific. For instance, the RING packet sends the preferred codec ID in this field. IF a particular packet does not use this field, its value MUST be set to zero.

5.10 LPARAM: 32-bit (4 octet) field that MAY hold 16 bits of information that is request specific. For instance, the NOTIFY packet sends the presence status ID in this field. IF a particular packet does not use this field, its value MUST be set to zero.

5.11 DATA PAYLOAD: A UTF-8 encoded, zero terminated text payload MAY follow the 170 octet LTP header. The contents of the payload are not interpreted by the LTP protocol but it is passed to the application layer. For instance, it can carry the text of a chat message.

6. Login Transaction

The Login transaction is described in the ladder diagram of Figure 1. The steps shown in this section refer to it.

A successful login will automatically expire after 15 minutes at the server. Hence, a client MUST perform this transaction at least every 15 minutes. In order to keep the NAT associations alive, a client MAY login more frequently. The current implementations of the LTP clients choose to login every 5 minutes.

A login transaction serves many functions:

i) Authenticate the client with the server and update their IP location with the server.

ii) Keep the NAT association between the relays (on the pubic Internet outside the NATs) and the clients open.

iii) Propagate and update the presence status of the client (carried as the presence ID in LPARAM field and a label message as the DATA payload).

6.1 A client will send an LTP LOGIN request packet to the server with its User ID set in the TO field. The server will respond back with a challenge set in the AUTHENTICATE field. The client must now calculate an MD5 digest (RFC 1321) of the entire original request, the password and the issued challenge, set it in the AUTHENTICATE field and retransmit the request back to the server. If the server will confirm that the client was able to respond with the correct MD5 digest to it.s response and send back a response packet to the client.

6.2 The server, upon receiving an LOGIN request directly from a client MAY respond back with RESPONSE_REDIRECT (code 302) and the address and port of a relay set in the contact fields. In such a case, the client should reset it.s end-point address of LTP server to that of the relay and send all future requests meant for the LTP server to the relay.

6.3 The exact steps of logging in are as follows:

6.3.1 The client constructs a LTP packet as follows:

6.3.2 The client sends this packet to the LTP server. (F1)

6.3.3 The server MAY respond with response 302 and a relay.s IP address and port in the CONTACTIP and CONTACTPORT fields (F2). In such a case, the client SHOULD accept the end-point set in the contact fields as the LTP server for all purpose and re-transmit the LOGIN packet. Alternatively, the server can process the request as in section 6.3.3 onwards. (F3)

6.3.2 IF a relay receives a LOGIN request from a client, it MAY either decline to process the request (with a RESPONSE_OFFLINE) otherwise it MUST forward the packet to the server. Before forwarding the packet to the server, the relay MUST set the CONTACT fields to the address and port from which it received the request. (F4)

6.3.3 If the User-ID set in the TO field is not found anywhere in the network, the server MUST return the packet back to the end-point it received it from with RESPONSE_NOT_FOUND (code 404).

6.3.4 If the User-ID set in the TO field is valid and the AUTHENTICATE field is set to all zeros, , the server MUST return the packet back to the end-point it received it from with RESPONSE_AUTHENTICATION_REQUIRED (code 407) and AUTHENTICATE field should be set to an randomly generated set of 16 octets that are associated with the User-ID for a duration of a minute. (F5)

6.3.5 A login response from the server that arrives at a relay will still contain the IP address and port of the end-point that had originally sent the packet (step 6.3.2). The relay will then forward this packet back to the client using this address and port. (F6)

6.3.7 Upon receiving a login response with RESPONSE_AUTHENTICATION_REQUIRED (code 407), the client MUST reset the CONTACTIP, CONTACTPORT and RESPONSE fields to zero and compute an MD5 checksum over the entire packet followed by the password followed by the challenge. The final MD5 checksum is then set in the AUTHENTICATE field of the packet and the packet is resent to the relay. (F7)

6.3.8 The relay will forward the LOGIN packet to the server after updating the CONTACTIP and CONTACTPORT fields of the packet to reflect the actual end-point that it received the packet from (just like step 6.3.2). (F8)

6.3.9 The server, upon receiving a LOGIN packet with AUTHENTICATE field set, MUST check that its last issued challenge was not more than a minute old. If the challenge was older, then it must end the LOGIN transaction by sending a response packet with RESPONSE_ERROR (code 401) back to the end-point that it received the request from.

6.3.10 The server, having established that the challenge is still valid (less than a minute old) will proceed to compute the check sum just like the client did in step 6.3.7. If the password at the client matches with the password with the server, then the MD5 checksum will also match with the checksum in AUTHENTCIATE field and in such a case the server MUST send the login packet back to the end-point it received the request from with response field set to RESPONSE_OK (code 200) (F9). If the checksum computed by the server does not match the AUTHENTICATE field, then the login has failed and the server MUST send the login packet back to the end-point it received the request from with response field set to RESPONSE_ERROR (code 401).

6.3.11 Upon receiving the final login response from the server, the relay will forward it client and it will also store the end-point IP address and port of the client that has successfully logged for future packet routing.

7. Presence Architecture

The LTP presence is designed to provide end-users presence in the context of enabling multimedia, real-time, RTP based sessions between them. Hence, presence state is maintained by constantly exchanging packets between LTP clients through relays. This architecture radically moves from the centralized concept of .presence servers. of other types of instant messaging networks, making LTP very resource efficient.

7.1 All clients are considered keep a list of peers, their current presence state, end-point IP address and ports and the IP address and ports of the relays through which each is logged in.

7.2 When a new client comes online, it retrieves its list of peers, their current presence state and end-point addresses of from the server through any method which is not in this protocol.s purview. The current LTP implementations use HTTP protocol to retrieve this list.

7.3 The client then sends NOTIFY packets to only those peers that are not offline as per the list retrieved in step 7.2. The online peers receive NOTIFY packet from this client and update their own list of contacts.

7.4 All clients periodically update each other with their presence details. The periodicity is not defined in this standard but set to 300 seconds in the current implementations.

7.5 Except for the initial deliver of the contact list from the server, the LTP implementation of presence does not require any intelligence or stateful behavior on part of either the server or the relays.

7.6 When a peer fails to respond to a NOTIFY request after sufficient number of retransmissions, the client MUST assume that the peer is offline and stop periodic NOTIFY requests to that peer.

7.8 It is always the responsibility of a peer that changes its status (for instance, coming online) to send NOTIFY requests to all the online peers.

8. Presence transaction

The presence transaction is illustrated in the ladder diagram of Figure 2.

8.1 A client.s propagates its presence state by sending out a NOTIFY request to its peers (called .Buddies. in instant messaging parlance). The WPARAM of the request will carry the numeric id of the presence state. The following presence IDs are predefined in the protocol:

NOTIFY_OFFLINE 0

NOTIFY_ONLINE 1

NOTIFY_BUSY 2

NOTIFY_AWAY 3

NOTIFY_SILENT 4

NOTIFY_ROAMING 6

NOTIFY_DRIVING 7

NOTIFY_SLEEPING 8

NOTIFY_ONLINE_MOBILE 9

NOTIFY_BUSY_MOBILE 10

NOTIFY_SILENT_MOBILE 11

(Note that ID 5 is not defined here as it is a special case chat notificiation. See Section 9)

8.2 A client constructs a NOTIFY packet with the following data:

8.3 The client sends the NOTIFY packet to the peer.s associated relay (that was used by the peer to login). (F1)

8.4 The relay, upon receiving a NOTIFY packet, will retrieve IP address and port of the peer from the contact fields and rewrite the contact fields with the IP address and port of the end-point that it received the packet from. This packet is forwarded to the peer. (F2)

8.5 The peer on receiving the packet MAY respond by sending the packet back to the relay with just the response field set to REPONSE OK (code 200) and update the presence status of the sending client within it.s own contact list.

8.6 The peer MAY also decide to ignore the NOTIFY packet and let the sending client time out thereby appearing .offline..

9. Chat Message Transaction

The LTP defines chat as session-less, special case of NOTIFY message. Hence, a client follows the same steps to send a chat message as regular notify requests. With the following changes:

9.1. The WPARAM is set to NOTIFY_CHAT (numeric code 5).

9.2 The DATA PAYLOAD holds the text message to be delivered in UTF-8, null terminated format (compatible with ASCII, null terminated strings).

9.3 Each successive chat request has a monotonically incrementing MSGID.

9.4 Figure 2 that illustrates the regular NOTIFY request propagation also applies to chat requests.

10. Phone Calls

The LTP phone calls refer to any negotiated media session between two LTP clients. It does not necessarily imply a voice call, though that is the only case in the current implementation.

The usual practice in current protocols like SIP is to have a three-way handshake to establish a session (INVITE/OK/ACK). The LTP splits this into two two-way transactions in order to limit all LTP transactions to a two-way handshake.

The state diagram of LTP calls is given in Fig 3.

10.1 An LTP client wishing to initiate a session sends a RING request towards the called client setting.s is own state to RING_SENT.

10.2 The called client receives the RING packet, moving to RING_RECEIVED state and alerts the subscriber of an incoming call. The called client MUST immediately send back a RESPONSE_OK if it can process the call further or a RESPONSE_BUSY if it cannot handle the call.

10.3 The caller, upon receiving a RESPONSE_OK to the RING message moves to RING_ACCEPTED state. If the response to the ring packet is 400 or above it MUST destroy the call object and move back to IDLE state.

10.4 The called subscriber MAY choose to answer the call by sending an ANSWER request to the calling client and moving its own state to CONNECTED.

10.5 Upon receiving the ANSWER request, the calling client too moves to CONNECTED state and sends back RESPONSE_OK to the called client.

10.6 At any time while both the clients are in connected state, any of the clients can send further ANSWER requests that can be used to update the codecs being used, or any change in the end-points (like moving from one access point to another). This functionality is a limited form of what is available on SIP in re-INVITES.

11 Ring transaction

The Ring transaction performs the following functions:

a) Alerts the called client about the incoming call.

b) Establishes a UDP stream between the clients that can be used for subsequent traversal of the RTP media (optionally using UDP hole-punching).

c) Communicates the preferred codec to the called client.

A client wishing to setup an LTP call constructs a RING request with the following data:

11.1 The LTP allows simultaneous multiple calls between two end points. The each LTP packet refers to a particular session by a unique combination of TO, SESSION and FROM fields. It is sufficient that each client MUST not reuse the same SESSION number for any calls that are setup or cleared within a minute (REQUEST time-out period) of being hung up.

11.2 This draft specifies only a-law, u-law, GSM 6.10 and Speex codecs as part of the LTP protocol. Using any other codec will render an implementation incompatible with LTP compliance. The list of codecs will be revised from time-to-time to keep all implementations backward compatible with each other.

11.3 The LTP allows the client to specify only one preferred codec in its RING message. The answering client can choose either the offered codec or a codec of lesser value. For instance, if the RING offers Narrow-band Speex (8000), the answering client cannot choose Wide-band Speex (21000).

11.4 All clients MUST implement GSM 6.10 codec as common codec to ensure basic interoperability.

11.5 The RING transaction follows as thus:

11.5.1 The initial RING request is sent to the local relay of the calling client. If the same relay also happens to be the local relay of the called client, then the RING transaction skips the step and continues from step 11.5.4.

11.5.2 The calling client.s local relay will send back a RESPONSE_REDIRECT with the IP address and port of another relay or server set in the CONTACT fields. The calling client MUST then retransmit the RING request to the new end-point. There maybe further redirects from other relays and servers too. The RING can continue for fixed number (but not specified within this document) of redirects until the local relay of the called client is located or it can time-out.

11.5.3 The RING request arrives at called client.s relay. It will now generate two packets: one towards the calling client and one towards the called client as in the next two steps.

11.5.4 The called client.s relay MUST return a RESPONSE_REDIRECT packet to the calling client with the CONTACT fields set to the IP address and port of the called client.

11.5.5 The called client.s relay MUST also forward the RING request to the called client with the CONTACT field set to the IP address and port of the calling client.

11.5.6 The calling client, upon receiving the RESPONSE_REDIRECT with the called client.s IP address and port in the CONTACT fields MUST now retransmit the RING request directly to the called client.

11.5.7 The called client, upon receiving the RING request with the IP address and port of MUST directly send the appropriate response (either RESPONSE_OK or RESPONSE_BUSY) to the calling client.s IP address and port.

11.5.8 The calling client MUST wait for sufficient time between repeating the steps from 11.5.3 to 11.5.7 several times. Usually, performing these steps 3 times is sufficient to test if UDP hole-punching has worked. If the calling client receives a direct RESPONSE_OK from the called client, it assumes that both can directly stream media between each other and the relays are not required. The calling client MUST cease further retransmission of RING requests after receiving a RESPONSE_OK.

11.5.9 If the called client gets a RING request even after 3 attempts, the called client MAY send a RESPONSE_OK_RELAYED to the local relay. The local relay MUST set the CONTACT fields of the RING/RESPONSE_OK_RELAYED packet to the IP address and port of the called client and forward the response to the calling client.s address and port. With this, the called client and the calling client have received the address and port of the local relay (from the source address of the UDP client) as well each other.s IP addresses and ports (from the CONTACT fields). All the future transactions with this call session MUST use the same relay and end-point IP addresses and ports.

12. Answer Transaction

The answer transaction performs the following functions:

a) Informs the calling client about called client.s willingness to join the call session.

b) Opens the RTP stream between the called and the calling clients.

c) Communicates the chosen codec to the called client.

The called client, wishing to answer an LTP call, constructs an ANSWER request with the following data:

12.1 If the direct response to the earlier RING request had failed to cease further reception of RING requests leading to sending of at least one RING/RESPONSE_OK_RELAYED response, the answer packet is sent to the local relay of the answering client with the CONTACT fields set to the IP address and port of the calling client.

12.2 If the direct response to the earlier RING request was received by the calling client leading to no further RING requests being received by the called client, the ANSWER request is directly sent to the calling client.s IP address and port.

12.3 The calling client, upon receiving the ANSWER request MUST move to CONNECTED state and send back the ANSWER/RESPONSE_OK to the same end-point that it received the call from and with the same set of remaining fields. If the calling client cannot progress the call, it MUST move to DISCONNECTING state and send back ANSWER/RESPONSE_BUSY instead.

12.4 An ANSWER request can be received by either of the parties in a call session in the CONNECTED state to notify each other of hand-over from one IP sub-net to another or to notify of change in codecs.

13. Real Time media

The LTP adds an extension to RTP as per RFC 1889 which helps it carry the relaying information within the packet. The LTP uses extension-ID 786 with that has two 32-words. The first word carries the remote client.s IP address and the second word carries the remote client.s port in the upper 16-bits, the lower 16-bits are reserved in this version.

13.1 The RTP packets are sent to the local relay. These are simply forwarded by the relay to the remote client at the address and port specified in the RTP extension header.

13.2 The SSRC field of the RTP header must carry the same SESSION ID as that of the SESSION field of the RING or TALK message that started the media session.

14. Hangup Transaction

A client wishing to end a call session will create a HANGUP request with the following data:

14.1 If the call is not relayed, the HANGUP request is direct sent to the other client.s IP address and port as determined during the call setup (Section 11).

14.2 If the call is being relayed, the HANGUP request is sent towards the relay that is being used to relay the call with the CONTACT fields set to the address and port of the other client.s IP address and port.

14.3 The relay MUST forward the HANGUP requests to the other client.

14.4 The client sending the HANGUP request MUST cease all further RTP traffic towards the other client.

14.5 When a client receives HANGUP request, it MUST confirm that the SESSION ID T0 and FROM fields do match with that of a valid and on-going call. If the client is able to locate such a current call, it MUST respond back with HANGUP/RESPONSE_OK with the same HANGUP request fields and to the same destination that it received the request from. It must cease all further RTP traffic for this call.

14.6 If the SESSION ID, TO and FROM fields of the received HANGUP request do not match with that of any ongoing calls, it MUST respond back with HANGUP/RESPONSE_NOT_FOUND with the same HANGUP request fields and to the same destination that it received the request from.

15. Talk Transaction

The Push to Talk (PTT) transaction essentially establishes semi-duplex, persistent session between clients that already have the information regarding each other.s presence.

15.1 The PTT session is established by a client sending a TALK request with the following data:

15. 1 If the destination client (as established by presence NOTIFY transaction) is reachable only via its local relay, the TALK request is sent to the local relay with CONTACT fields set to the destination client.s IP address and port.

15.2 If the destination client is directly reachable, the talk request is sent directly to the destination client.

15.3 Upon receiving a TALK request, the recipient client SHOULD send and immediate response with either a RESPONSE_OK (code 200) or RESPONSE_BUSY (code 404). The response packet MUST follow the same path (direct or relayed) that the original request followed. The recipient MUST also move to CONNECTED state.

15.5 Upon receiving a RESPONSE_OK to a previously sent TALK request, a client MUST move to a CONNECTED state. Other 4xx responses MUST result in destruction of the call.

15.6 The RTP traffic MAY flow intermittently and under the control of either of the client.s users (operated by a button leading to the name .Push to talk.). If the initial TALK request was relayed, then all the subsequent LTP and RTP packets must be relayed using the same relay (See Section 13).

15.7 The Talk call is ended with a regular HANGUP transaction.