draft-ietf-sigtran-cstp

Last Version:	draft-ietf-sigtran-cstp-00.txt		Tracker Entry
Date:	04-Nov-2000
Disposition:	expired

Network Working Group
INTERNET-DRAFT

Gur Kimchi - VocalTec Communications Ltd

Submitted 26 February 1999  -  Expires 25 August, 1999

CALL SIGNALLING TRANSPORT PROTOCOL

<draft-sigtran-CSTP-00.txt>

. 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.
. 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 <ackRequested> 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 <ackRequested> field is set.
NOTE:
Applications can create a completely reliable transport by setting the <ackRequested> 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
 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
 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
 ms
time-out between sending the message and 
assuming it is lost (which triggers re-sending)
N-W1
 OCTETs
maximum number of OCTETs in the window
N-W2

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 [<M><T>] address identifying the source 
node of the packet, and the [<M><T>] 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.

R
 Bits: Reserved for future use, shall be set to zero by 
sender, and shall be ignored by the receiver.

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.

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.

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)

A
Boolean: TRUE indicates that an Ack is requested for this 
PDU 

SEQNUM
Unsigned Integer between 0 and 16,777,215: the sequence 
number of this PDU

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.)

LENGTH
total length in OCTETs of all payloads (excluding header).

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

S
Signifies the presents of a Session Field

A
Signifies the presence of a Source/Destination address field

R
Reserved for future use, shall be cleared by senders

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.

COOKIE LENGTH
The length (in BYTEs or OCTETs) of the COOKIE field

P
Reply Requested

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

SEQNUM 0..N
The Sequence Number(s) of the PDUs that are being 
ACKed for
 x n
RESERVED
Reserved for future use.
 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

SEQNUM 0..N
The Sequence Numbers of the PDUs that is being NACKed 
for
 x n
LENGTH 0..N
Length of Nack-specific data
 x n
REASON 0..N
The reason for the NACK
 x n
OCTETs
Nack-specific data octets
n
Image/Table 18: Nack Reasons
Value
Meaning
Length of 
Nack Data 
in OCTETs
Data

non-standard reason
1+n
LENGTH OCTET followed by 
OBJECT IDENTIFIER OCTET(s)

request the sender to use 
an alternate port for the 
specified static payload type

as defined in Image/Table 19.



request the sender to use 
an alternate port for the 
specified ObjectID payload 
type
1+n+6
as defined in Image/Table 20.

transport-payload not 
supported

unsigned integer

static-payload type not 
supported

Unsigned Integer;
Payload as defined in the static-
typed protocol that is not 
supported

Object-ID payload not 
supported
1+n
LENGTH OCTET followed by 
OBJECT IDENTIFIER OCTET(s)

Payload Corrupted

the Payload number in the 
message that was corrupted.
.. 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 
 (zero) for all static-typed messages.   The next octet shall signify what static-
payload is present:
Image/Table 21: Static-Typed Payloads
Value
Interpretation

octet-stream contains a Q.931 message as defined in H.225.0
..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

LENGTH
Unsigned Integer: The length (in OCTETS or BYTES) of the 
payload data.

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

SESSION
Unsigned Integer:  the meaning of the session field is 
protocol dependent.

PAYLOAD LENGTH
Unsigned Integer: The length (in OCTETS or BYTES) of the 
payload data

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

SESSION
Unsigned Integer:  the meaning of the session field is 
protocol dependent.

SOURCE / DEST
ADDRESS
Unsigned Integer:  the meaning of the source/destination 
address field is protocol dependent.

PAYLOAD LENGTH
Unsigned Integer: The length (in OCTETS or BYTES) of the 
payload data

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

ObjectID
Object Identifier OCTETs
n
LENGTH
Unsigned Integer: The length (in OCTETS or BYTES) of the 
payload data.

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

ObjectID
Object Identifier OCTETs
n
SESSION
Unsigned Integer:  the meaning of the session field is protocol 
dependent.

LENGTH
Unsigned Integer: The length (in OCTETS or BYTES) of the 
payload data.

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

ObjectID
Object Identifier OCTETs
n
SESSION
Unsigned Integer:  the meaning of the session field is 
protocol dependent.

LENGTH
Unsigned Integer: The length (in OCTETS or BYTES) of the 
payload data.

SOURCE / DEST
ADDRESS
Unsigned Integer:  the meaning of the source/destination 
address field is protocol dependent.

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
 

. 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.
. Contact Information
Gur Kimchi
VocalTec Communications Ltd.
 û 768 9400
gur.kimchi@vocaltec.com
http://www.vocaltec.com
sigtran-CSTP-00 Expires 25 August, 1999	page 1 of 1	CSTP