Network Working Group INTERNET-DRAFT Gur Kimchi - VocalTec Communications Ltd Submitted 26 February 1999 - Expires 25 August, 1999 CALL SIGNALLING TRANSPORT PROTOCOL 1. Status of This Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract CSTP (Call-Signalling-Transport-Protocol) describes a packetization format and a set of procedures (some of which are optional) that are appropriate for the implementation of UDP and TCP based call-signalling protocols. CSTP has been determined by the ITU-T SG16 as ôH.323 Annex Eö, allowing H.323 call signalling (H.225.0 / Q.931) to work over UDP. ITU-T SG16 is scheduled to decide this document at the May-1999 meeting. The first part of CSTP describes the signalling framework and wire-protocol, and subsequent sections detail specific use cases. The only use case currently included is for ITU-T H.225.0 Q.931 signalling transport. 2.1 Introduction 2.1.1 Multiplexed Transport CSTP provides a multiplexed transport layer that can be used to transmit multiple protocols (with optional reliability) in the same PDU. Often-used protocols have specific code points (also called ôpayload typesö). Other protocols can be carried and identified using the ObjectID-typed payloads. 2.1.2 Multiple Payloads in a single PDU CSTP PDUs can contain multiple ôpayloadsö, each a different protocol and targeted at a different session (the definition of a ôsessionö is protocol dependent). Note that there is no implicit relation between payloads when they arrive in the same PDU. 2.1.3 Flexible Header Options CSTP PDU and Payload headers are configurable. Minimum header size can be as small as 8 OCTETs, and may grow up to 20 OCTETs when all optional fields are present. 2.1.4 Ack Message Messages carried using UDP can get lost. If the application needs assurance that a sent message arrived successfully, It may request an Ack message for the PDU. A sender shall specify in the field whether it wants to receive an Ack message for a PDU being sent, and the receiver shall reply with an Ack Payload if the field is set. NOTE: Applications can create a completely reliable transport by setting the field of every message and waiting until the Ack message is received. This however will be very much like TCP, with the exception of the application controlling the retransmission timers more correctly for call-signalling operations then TCP does. NOTE: CSTP allows implementers to choose which messages are requiring an Ack. Some protocols (such as H.225.0) that assume serial operation require that the Ack bit to always be set. 2.1.5 Nack Message A Nack message shall be used to signify some error condition. Such errors may be the inability to support a specific payload type, the arrival of a malformed PDU, and others. These messages may or may not have the effect of dropping an on-going call. 2.1.6 Sender Sequence Number Policy Assigned per host-address + source-port, Sending applications shall start with some random value, incrementing by 1 for every PDU sent. If the sequence number reaches 224 (16,777,216) it shall wrap around to 0. 2.1.7 Receiver Sequence Number Policy When receiving a UDP packet, the application should check the host-address + source-port + sequence number to recognise duplicate messages. The application may recognise packet-loss when finding gaps in sequence numbers. 2.1.8 Retransmissions When messages get lost (and an Ack was requested and not received) the sender may retransmit the message. The retransmission policy attempts to combat first- message lost by re-transmitting quickly, but if that message is lost too, the sender is required to back-off the retransmission delay by a factor of more then two. Image/Table 1: Retransmission Timers & Counters Item Value Comments T-R1 800 ms A reasonably small value is chosen here to compensate for possible 1st packet loss. T-R2 (T-R1*2) * 1.1 If the first packet is lost, apply some back-off. N-R1 <= 6 Maximum number of retransmissions before abandoning the connection. Image 2: PDU Retransmission When there is a known request/reply interval value (RTT) from a previous transmission, timer T-R1 should be set to that value + 10%. 2.1.9 Connection Keep-Alive When running over TCP, the presence of a persistent TCP connection can insure that one side is aware of the remote side failures (by observing TCP failures). When running over UDP, there is no such ôstateö associated, and another procedure must be used. The solution is for one side of the call (usually the ôserverö or ômasterö side if such classification is relevant) to send an ôI-Am-Aliveö message to the other side, to let the remote application know the host is still up. The remote side will answer with an I-Am-Alive message of itÆs own as proof that it too is up. A cookie may be provided by the originator of an I-Am-Alive sequence, and if made available, shall be returned in the answer I-Am-Alive. Image/Table 3: I-Am-Alive Transmission The retransmission timer of the I-Am-Alive messages may be reset on receiving other relevant message, as it is proof the remote end is alive. This saves bandwidth, as I-Am-Alive messages will be sent only when really needed. This capability is decided on a per-protocol basis. Generating I-Am-Alive messages is optional, however, all entities shall support the ability to reply to I-Am- Alive messages (e.g. the ability and requirement to answer an I-Am-Alive message is not optional, and when such a message is received, it shall be answered according to the procedures defined in this annex). Image/Table 4: I-Am-Alive Timers Item Value Comments T-IMA1 6 seconds I-Am-Alive transmission interval. 2.1.10 Forward Error Correction CSTP messages may be sent more then once to enable forward error correction. If the arrival of a message is crucial, the application may choose to send the same message twice (without incrementing the sequence number). If both messages arrive, the second one will be treated as normal message duplication. 2.1.11 Reply Hints It is advisable for CSTP implementers to add a slight delay before an Ack message is sent back, to allow the application to attach a protocol payload to accompany the Ack payload. An Header option is available to allow senders to Hint to the remote transport layer that a reply is expected for a given message. NOTE: For example, when a H.225.0 SETUP message is sent, the stack can delay the reply of the Ack payload slightly when the ReplyHint bit is set to insure the application will have time to provide the return CONNECT payload (for example). The returning PDU will then contain both an Ack (for the SETUP) and the CONNECT payload. 2.1.12 Well-Known Port and Port Spawning CSTP supports one well-known port: UDP/TCP port 2517. Applications supporting CSTP operations when receiving a payload that the main well-know port does not support (identified either using the static payload type or the object-ID payload type) may reply with a Nack message that instructs the sender to send this specific payload type to a different port and IP address. 2.2 Signalling Models Signalling may follow many models. Each protocol implementation using CSTP shall support one of the models (as described below) or choose a different signalling model that suits its requirements. 2.2.1 Real-Time Model In the real-time model, if a PDU is lost, there is no use to re-send the PDU as the information may already be irrelevant. An example of such a protocol is RTP when used for real-time audio or video streaming. For such protocols the delay caused by retransmission is worse then losing the information. When using this model, the Ack-flag shall always be cleared. 2.2.2 Serial Model In the serial-model, when a PDU is sent, the application (or rather the CSTP stack) waits until a positive reply is returned. This behaviour is used for protocols that cannot sustain out-of-order message arrival and require real-time operations while sending small amounts of information. An example of such a protocol is Q.931. When using this model, the Ack-flag shall always be set. Unless otherwise specified, CSTP implementations shall use the default retransmission timers (T-R1 and T-R2) and counter (N-R1). 2.2.3 Window Model The window model is useful for application transmitting large amount of non real- time data. The window is both size (in OCTETs) and message-count limited, and messages not positively acknowledged for after a time-out are retransmitted. An example of a protocol that uses the window model is TCP - but the interface of CSTP is packet-based, while TCP is based on a byte-stream session. When using this model, the Ack-flag shall always be set. Protocols shall either use the default retransmission timers (T-R1 and T-R2) and counter (N-R1) or specify alternative values that better support their service. The size (in OCTETs and number of messages) of the window may be protocol specific. When not specified, the following values (T-W1, N-W1, and N-W2) shall be used: Image/Table 5: Default Window Values Item Value Comments T-W1 3872 ms time-out between sending the message and assuming it is lost (which triggers re-sending) N-W1 16384 OCTETs maximum number of OCTETs in the window N-W2 8 maximum number of PDUs in the window 2.2.4 Mixed Model The mixed model may imply that the protocol state machine and the CSTP state- machine are intertwined. Such implementations may use the Ack-bit where appropriate. When using this model, use of the Ack-flag can be forbidden, optional, or mandatory, as prescribed by the protocol. 2.2.5 CSTP over TCP CSTP may be used over TCP. When used over TCP, the Ack message shall not be used. In addition, the L-bit in the PDU header shall be set, triggering the availability of the payload-count or PDU-length fields. 2.3 Optional Payload Fields 2.3.1 Session Identifier CSTP payloads support an optional Session field that may be used to identify a session within the multiplexed transport that the payload belongs to. The Session field is 16-bits long. NOTE: This field may be used for example to carry the CRV (e.g. Call-Reference-Value as defined in Q.931) in H.225.0 messages. The interpretation of the session field is protocol specific. 2.3.2 Source/Destination Address Identifier CSTP payloads support an optional Source/Destination field that may be used to identify the source, the destination (or both) of the payload. The Source/Destination field is 32-bits long. NOTE: This field may be used for example to express the [] address identifying the source node of the packet, and the [] address identifying the destination node of the packet. The interpretation of the source/destination field is protocol specific. 2.4 Wire Protocol (Section not to be translated) CSTP transport uses binary encoding as defined in the rest of this section. Structures shall use network-byte-ordering (e.g. big-endian). 2.4.1 Header Structure The following structure shall be used to encode the CSTP Header. If the L-bit is cleared (hence there is no payload-count or PDU length indication), The length of the payloads within the message, and their number can be inferred from the message size as reported by the transport layer. Image/Table 6: Header Structure when the L-bit is cleared Image/Table 7: Content of Fields Field Contents bits VERSION Unsigned Integer; senders shall set this field to zero. Version number 7 is reserved for experimental use and shall be ignored by commercial implementations. 3 R 1 Bits: Reserved for future use, shall be set to zero by sender, and shall be ignored by the receiver. 1 M Multicast bit. If set, the PDU was sent using Multicast, if cleared, the PDU was unicast. Senders shall set this bit if the PDU was multicast, otherwise they shall clear the bit. 1 H Reply-Hint bit - when set, this message will result in a reply, e.g. when set, the Ack message should be delayed to give the application a chance to provide an answer payload with the Ack payload. 1 L Length indicator. If present, an additional 4 OCTETs are present that contain the number of Payloads in the PDU (8 bits) and the total length (in OCTETs) of the PDU (24 bits) 1 A Boolean: TRUE indicates that an Ack is requested for this PDU 1 SEQNUM Unsigned Integer between 0 and 16,777,215: the sequence number of this PDU 24 PAYLOAD(s) Sequence of payload structures n Image/Table 8: Header Structure when the L-bit is set Image/Table 9: Content of L-bit supplementary Fields Field Contents bits PAYLOAD COUNT total number of payloads in PDU -1 (e.g. 0 means there is one payload, 1 means there are two, etc.) 8 LENGTH total length in OCTETs of all payloads (excluding header). 24 2.4.2 Payload Structure The following structures shall be used to encode CSTP payloads. 2.4.2.1 Payload Header Flags Every payload begins with a Flags OCTET, that describes what optional fields are in the payload header. Image/Table 10: Payload Flags Image/Table 11: Content of Fields Field Contents bits T Two bits defining the payload identification type: 00: CSTP Transport Messages 10: Static-Payload typed messages 01: OBJECT IDENTIFIER typed messages 11: Reserved for Future Use 2 S Signifies the presents of a Session Field 1 A Signifies the presence of a Source/Destination address field 1 R Reserved for future use, shall be cleared by senders 4 2.4.2.2 CSTP Transport Messages Both T bits in the Payload header flags OCTET shall be set to 0 (zero) for all CSTP Transport Messages. The next octet shall signify what CSTP transport message is following. Both S and A bits shall be cleared. 2.4.2.2.1 I-Am-Alive Message The following structure shall be used to encode CSTP I-Am-Alive payloads. The transport-message octet shall be set to 0 (zero). The validly period is expressed in 100s of milliseconds. ? If the replyRequested bit (P) is set, the receiver shall reply with an I-Am-Alive message with the cookie (if provided). ? replyRequested is not the same as ackRequested in the PDU header, which results in an Ack Message. replyRequested results in an I-Am-Alive Message. ? If a validity period is set to ZERO (0), timer T-IMA1 shall be used. ? PDUs that contain only an I-Am-Alive Payload shall clear the Ack-bit in the PDU header. Image/Table 12: I-Am-Alive message Image/Table 13: Content of Fields Field Contents bits VALIDITY Unsigned Integer: The time in 100s of Milliseconds that this I-Am-Alive is valid for. 16 COOKIE LENGTH The length (in BYTEs or OCTETs) of the COOKIE field 15 P Reply Requested 1 COOKIE BYTEs or OCTETs of the cookie n 2.4.2.2.2 Ack Message The following structure shall be used to encode Ack messages. The transport- message octet shall be set to 1 (one). PDUs that contain only an Ack Payload shall clear the Ack-bit in the PDU header. Image/Table 14: Ack payload Image/Table 15: Content of Fields Field Contents bits ACK COUNT The number of SEQNUM fields that follow 16 SEQNUM 0..N The Sequence Number(s) of the PDUs that are being ACKed for 24 x n RESERVED Reserved for future use. 8 x n 2.4.2.2.3 Nack Message The following structure shall be used to encode Nack messages. The transport- message octet shall be set to 2 (two). Image/Table 16: Nack message Image/Table 17: Content of Fields Field Contents bits NACK COUNT The number of SEQNUM fields that follow 16 SEQNUM 0..N The Sequence Numbers of the PDUs that is being NACKed for 24 x n LENGTH 0..N Length of Nack-specific data 8 x n REASON 0..N The reason for the NACK 16 x n OCTETs Nack-specific data octets n Image/Table 18: Nack Reasons Value Meaning Length of Nack Data in OCTETs Data 0 non-standard reason 1+n LENGTH OCTET followed by OBJECT IDENTIFIER OCTET(s) 1 request the sender to use an alternate port for the specified static payload type 8 as defined in Image/Table 19. 2 request the sender to use an alternate port for the specified ObjectID payload type 1+n+6 as defined in Image/Table 20. 3 transport-payload not supported 1 unsigned integer 4 static-payload type not supported 1 Unsigned Integer; Payload as defined in the static- typed protocol that is not supported 5 Object-ID payload not supported 1+n LENGTH OCTET followed by OBJECT IDENTIFIER OCTET(s) 6 Payload Corrupted 1 the Payload number in the message that was corrupted. 7.. 65535 Reserved for future use - - Image/Table 19: Nack Reason 1 Structure Image/Table 20: Nack Reason 2 Structure If the IP address is set to zero, the IP address of the sender shall be used (as identified by the TCP/IP layer). If the port is set to zero, the port transmitted from shall be used (as identified by the TCP/IP layer). 2.4.3 Static-Typed Messages The first T bit in the Payload header flags OCTET shall be set to 1 (one) for all static- typed messages. The second T bit in the Payload header flags OCTET shall be set to 0 (zero) for all static-typed messages. The next octet shall signify what static- payload is present: Image/Table 21: Static-Typed Payloads Value Interpretation 0 octet-stream contains a Q.931 message as defined in H.225.0 1..255 Reserved for future use 2.4.3.1 Basic Static-Typed Message (S-bit and A-bit cleared) When both the S and A bits are cleared, the following payload format shall be used: Image/Table 22: Basic Static-Typed Payload Image/Table 23: Content of Fields Field Contents bits TYPE Unsigned Integer: the type of the payload, as defined in Table 19 8 LENGTH Unsigned Integer: The length (in OCTETS or BYTES) of the payload data. 16 DATA The actual payload data OCTETs n 2.4.3.2 Extended-1 Static-Typed Message (S-bit set and A-bit cleared) When the S bit is set and the A bit is cleared, the following payload format shall be used. The S-bit signifies the presents of a SESSION field. Image/Table 24: Extended-1 Payload Format Image/Table 25: Content of Fields Field Contents bits TYPE Unsigned Integer: the type of the payload, as defined in Table 12 8 SESSION Unsigned Integer: the meaning of the session field is protocol dependent. 16 PAYLOAD LENGTH Unsigned Integer: The length (in OCTETS or BYTES) of the payload data 16 DATA The actual payload data OCTET(s) n 2.4.3.3 Extended-2 Static-Typed Message (S-bit and A-bit set) When both the S-bit and the A-bit is set, the following payload format shall be used. The A-bit signifies the presents of a Source/Destination Node Field. Image/Table 26: Extended-2 Payload Format Image/Table 27: Content of Fields Field Contents bits TYPE Unsigned Integer: the type of the payload, as defined in Table 12 8 SESSION Unsigned Integer: the meaning of the session field is protocol dependent. 16 SOURCE / DEST ADDRESS Unsigned Integer: the meaning of the source/destination address field is protocol dependent. 32 PAYLOAD LENGTH Unsigned Integer: The length (in OCTETS or BYTES) of the payload data 16 DATA The actual payload data OCTET(s) n 2.4.3.4 Extended-3 Static-Typed Message (S-bit cleared, A-bit set) When the S-bit is cleared and the A-bit is set, the following payload format shall be used. The A-bit signifies the presents of a Source/Destination Node Field. Image/Table 28: Extended-3 Payload Format 2.4.4 ObjectID-Typed Messages The first T bit in the Payload header flags OCTET shall be set to 0 (zero) for all ObjectID-typed messages. The second T bit in the Payload header flags OCTET shall be set to 1 (one) for all ObjectID-typed messages. The next two octet shall signify the length of the Object-ID that follows. 2.4.4.1 Basic ObjectID-Typed Message (S-bit and A-bit cleared) When both the S and A bits are cleared, the following payload format shall be used: Image/Table 29: Basic ObjectID-Typed Payload Image/Table 30: Content of Fields Field Contents bits OID LENGTH Unsigned Integer: the length in OCTETs of the Object Identifier following 8 ObjectID Object Identifier OCTETs n LENGTH Unsigned Integer: The length (in OCTETS or BYTES) of the payload data. 16 DATA The actual payload data OCTETs n 2.4.4.2 Extended-1 ObjectID-Typed Message (S-bit set and A-bit cleared) When the S bit is set and the A bit is cleared, the following payload format shall be used. The S-bit signifies the presents of a SESSION field, which is used by the application to associate payloads with a specific session. The definition of a session is protocol specific. Image/Table 31: Extended-1 ObjectID-Typed Payload Format Image/Table 32: Content of Fields Field Contents bits OID LENGTH Unsigned Integer: the length in OCTETs of the Object Identifier following 8 ObjectID Object Identifier OCTETs n SESSION Unsigned Integer: the meaning of the session field is protocol dependent. 16 LENGTH Unsigned Integer: The length (in OCTETS or BYTES) of the payload data. 16 DATA The actual payload data OCTETs n 2.4.4.3 Extended-2 ObjectID-Typed Message (S-bit and A-bit set) When both the S-bit and the A-bit is set, the following payload format shall be used. The A-bit signifies the presents of a Source/Destination Address Field. Image/Table 33: Extended-2 ObjectID-Typed Payload Format Image/Table 34: Content of Fields Field Contents bits OID LENGTH Unsigned Integer: the length in OCTETs of the Object Identifier following 8 ObjectID Object Identifier OCTETs n SESSION Unsigned Integer: the meaning of the session field is protocol dependent. 16 LENGTH Unsigned Integer: The length (in OCTETS or BYTES) of the payload data. 16 SOURCE / DEST ADDRESS Unsigned Integer: the meaning of the source/destination address field is protocol dependent. 32 DATA The actual payload data OCTETs n 2.4.4.4 Extended-3 ObjectID-Typed Message (S-bit cleared, A-bit set) When the S-bit is cleared and the A-bit is set, the following payload format shall be used. The A-bit signifies the presents of a Source/Destination Address Field. Image/Table 35: Extended-3 ObjectID-Typed Payload Format 3. H.225.0 Call Signalling over CSTP This section describes how to carry H.225.0 Call-Signalling messages using the CSTP transport, over UDP. The CSTP is used to provide a ôreliable-UDPö transport, to allow H.225.0 implementations to work over CSTP largely unchanged. 3.1 Rational H.323 version 2 introduces the concept of ôFast Connectö, which allows media cut- through in as little as in 2 round trips from callee to caller (including TCP messages), and in 2.5 round-trips from caller to callee. This can be reduced to 1rt and 1.5rt respectively by using UDP as the transport for H.323 messages, instead of TCP. This is especially important when using the Gatekeeper-Routed-Model. 3.2 H.323 Call-Setup Using CSTP H.323 version 2 uses the TCP transport to carry H.225.0 messages, which means the least number of round trips possible to get media cut-through is 2 from Callee to Caller, and 2.5 from Caller to Called party. Image/Table 36: Information Flow for H.323 version 2 FastConnect. NOTE: Some messages in the TCP handshake procedure has been omitted for clarity. 3.2.1 UDP-Based Procedure To get faster media cut-through, it is possible to use UDP for call-signalling transport, which effectively enables media cut-through in a single round trip: Image/Table 37: Information Flow for UDP-based Call-Setup Applications should retransmit a lost packet if it does not get a reply after some time. The precise retransmission procedure is detailed later in this document. 3.2.2 Mixed TCP & UDP Procedure The procedures for TCP-based and UDP-based call setup are not mutually exclusive. Either UDP-based call setup may be attempted prior to TCP-based call setup or UDP- based and TCP-based call setup may be carried out in parallel. If the UDP-based setup succeeds, the TCP connection shall be released. If UDP-based call setup fails (because the remote peer does not support the CSTP procedures) the TCP-based setup shall be used ù thus acting as fallback. As soon as the TCP-based call setup has completed, UDP-based communication shall no longer be used. Image/Table 38: Information Flow for Mixed TCP & UDP Procedure This insures that if the UDP procedure fails, usual TCP-based procedures can take over immediately: Image/Table 39: Information Flow when UDP is not supported This means that backwards compatibility when calling H.323 version 1 or 2 entities is transparent, as the v1/v2 application will not be aware of the UDP packet. NOTE: It is recommended for entities that initiate a call and do not know if the remote side supports CSTP operations to use the procedure detailed above. If the calling entity knows by some means that the remote callee supports UDP-based operations, it may use a UDP only call- setup. 3.3 Specifics 3.3.1 Message Identification H.225.0 over CSTP payloads shall use static payload type 0 (zero). 3.3.2 Well-Known-Port UDP port 1720 shall be used for the well-known port. Entities may transmit from any random port. NOTE: The well-known port registered with IANA to allow H.323 entities to listen to incoming TCP call signalling connections (port 1720) has been also registered with IANA for H.225 use on the UDP port-space. 3.3.3 Signalling Model H.225.0 over CSTP shall use the serial-model as described in section 1.2.2. 3.3.4 Timers H.225.0 over CSTP shall use the default timers values for T-R1, T-R2, T-IAM1, and N-R1. The use of the I-Am-Alive message is optional, but when used, the default timer value (T-IMA1) shall be used. If more then 5 consecutive I-Am-Alive messages are not replied to, the session may be dropped. The T-IMA1 timer shall be reset upon reception of any Call-Signalling message (e.g. but not when receiving RTP packets). 3.3.5 Session Field The session field shall be present in all payloads. The Session value shall conform to the CRV structure as specified in Q.931. Specifically, the call reference flag shall be included as the most significant bit of the CallReferenceValue. This restricts the actual CRV to the range of 0 through 32767, inclusive. 3.3.6 Source/Destination Address Field Use of the Source/Destination field is optional, but is shall be present in all messages originating, or destined to an MCU or when a Gatekeeper acts as an MC. 4. Contact Information Gur Kimchi VocalTec Communications Ltd. 201 û 768 9400 gur.kimchi@vocaltec.com http://www.vocaltec.com sigtran-CSTP-00 Expires 25 August, 1999 page 1 of 1 CSTP