[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

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>

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


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/