Megaco WG J. Bouwen
Internet Draft B. Van Doorselaer
Document: <draft-bouwen-megaco-isdn-00.txt> M. Dekeyser
Category: Informational Alcatel
March, 2000
Issues for Megaco - Sigtran Interworking in ISDN Access Gateways
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
1. Abstract
This document introduces the concept of an ISDN access gateway in
the context of Megaco/H.248 and Sigtran protocols. For these ISDN
access gateways, the ISDN B channels may be controlled by the Media
Gateway Controller using megaco/H.248 while the User-to-Network
signaling running over the D channels may be relayed to the Media
Gateway Controller using either megaco/H.248 or the Sigtran
protocols.
The main issues involved are:
* Megaco/H.248 and Sigtran protocols may interwork in different ways
in ISDN access gateways, leaving room for non - interoperable
solutions;
* Megaco needs additional packages in order to support ISDN
terminations in the ISDN access gateway;
* A data service may be offered to ISDN users via the ISDN D-
channel, introducing the need to introduce a NAS package for the
D-channel.
This document addresses these issues, proposes and explains
different solutions and suggests best practice guideline for megaco
/ sigtran interworking in ISDN access gateways.
2. Conventions used in this document
Bouwen, Van Doorselaer, Dekeyser 1
Internet Draft ISDN Access Gateways Issues March 2000
3. Introduction
The Megaco/H.248 protocol [1] defines a framework for the control of
ISDN Access Gateways by Media Gateway Controllers. Packages specify
extensions for a specific type of termination in the Media Gateway.
This Internet Draft investigates issues involved with the support of
ISDN terminations in ISDN Access Gateways. An important set of
issues are related to the interaction between Megaco/H.248 and
Sigtran [2,3] protocols that can be used for the transport of ISDN
signaling between the ISDN Access Gateway and the Media Gateway
Controller.
This document lists several alternative approaches for the
Megaco/H.248 - Sigtran interworking. It proposes Megaco/H.248
extensions for the description of ISDN termination properties in the
form of an ISDN package. However, not all issues can be solved by a
new package definition, and it is felt that a best common practice
document is needed to guarantee interoperability. We hope this
internet draft can start the discussion that will eventually lead to
such a document.
Following topics are addressed in this draft:
* A general naming scheme for ISDN terminations;
* Alternative backhaul mechanisms for Q.931 [6] signaling;
* Levels of interworking between Megaco/H.248 and Sigtran. Different
levels can be discerned, depending on the visibility of the
signaling transport for Megaco/H.248;
* Required new termination properties for ISDN;
* Alternative mechanisms for the control of termination properties;
* A preliminary discussion on support for packet data transfer in an
ISDN D-channel.
This draft does not pretend to present an exhaustive treatment of
the subject, and several sections require further study. Fax and
ISDN modems are not addressed. The package definitions are examples
containing partial functionality tied to a particular implementation
option. A future complete ISDN package would consist of a
combination of selected package definitions in this draft. The draft
focuses on the text-encoded version of the Megaco/H.248 protocol.
4. ISDN Termination Terminology and ISDN Media Gateway Architecture
This section defines basic ISDN terminology based on Q.920 [5] and
I.412 [9].
An ISDN termination typically exists of a number of B channels and
one D channel.
A B-channel is a 64 kbit/s channel for the transfer of user
information streams
Bouwen, Van Doorselaer, Dekeyser 2
Internet Draft ISDN Access Gateways Issues March 2000
A D-channel carries signaling information for circuit switching by
the ISDN.
Typical ISDN interface structures are:
Basic access (BA)
2B+D
ETSI, ANSI
The bit rate of the D-channel in this interface structure is 16
kbit/s)
2048 kbit/s Primary rate access (PRA):
30B+D
ETSI
The bit rate of the D-channel in the primary rate access
structure is 64 kbit/s)
1544 kbit/s Primary rate interface (PRI)
23B+D
ANSI
The bit rate of the D-channel in the primary rate interface
structure is 64 kbit/s)
The D-channel uses a layered protocol according to ITU-T
recommendations Q.920, Q.921, Q.930 and Q.931. The Q.921 Data Link
uses the DLCI to identify a connection. Figure 1 shows the use of
the DLCI.
DLCI Data Link Connection Identifier
An address conveyed in a Q.921 message which indicates
the source and destination of an intended instance of
communication at the data link layer
The DLCI is the combination of the TEI and the SAPI
SAPI Service Access Point Identifier
Portion of the DLCI associated with the service access
point on the network side or the user side of the user-
network interface. The Service Access Point is the point
at which the Q.921 data link layer provides services to
layer 3.
TEI Terminal Endpoint Identifier
Portion of a DLCI associated with one (point-to-point
data link) or more than one (broadcast data link)
terminal equipment. The TEI is used to identify a
specific connection endpoint within a Service Access
Point.
Bouwen, Van Doorselaer, Dekeyser 3
Internet Draft ISDN Access Gateways Issues March 2000
########################### ########################### C P
# Terminal 1 # # Terminal 2 # U R
# # # # S E
# +--------+ +--------+ # # +---------+ # T M
# | Packet | | Q.931 | # # | Q.931 | # O I
# | Data | | Sign. | # # | Sign. | # M S
# +--------+ +--------+ # # +---------+ # E E
# | | # # |...| # R S
# /|\ SAPI /|\ SAPI # # /| |\ SAPI # '
# \|/ 16 \|/ 0 # # \|...|/ 0 # S
# | | # # | | #
######|###########|######## ###########|###|###########
| | | |
|TEI88 |TEI88 TEI3| |TEI8
| | | |
| +--------+ +------------+ |
+------------------+ | | +--------------+
| | | |
| | | |
-->| | | |<--D-Channel
| | | |
| | | +---------------+ N
+-----------+ | +-------------+ | E
| +-----------+ | | T
| | | | W
/ \ SAPI /|'''|'''|\ SAPI O
\ / 16 \|...|...|/ 0 R
| | | | K
+--------+ +---------+
| Packet | | Q.931 |
| Data | | Sign. |
+--------+ +---------+
DLCI = SAPI + TEI
Figure 1 - Relationship between SAPI, TEI and DLCI (based on [5])
Signaling information arrives in the ISDN Access Gateway over the D-
channel, and has to forwarded to the call control intelligence in
the Media Gateway Controller. In this way an ISDN Access Gateway
contains Signaling Gateway functionality.
5. Naming of ISDN Terminations
5.1 Complete provisioning
The Megaco/H.248 protocol specification doesn't contain any
recommendation for the naming of terminations. The attribution of
names is considered a matter of implementation. An arbitrary naming
Bouwen, Van Doorselaer, Dekeyser 4
Internet Draft ISDN Access Gateways Issues March 2000
scheme necessitates a complete pre-provisioning in both Media
Gateway and Media Gateway Controller of:
* A table of ISDN B-channel terminations in Media Gateway and Media
Gateway Controller, for use in Megaco/H.248 commands for media
connection establishment.
* A table of ISDN D-channel terminations in Media Gateway and Media
Gateway Controller, for transfer of Q.931 message contents between
Media Gateway and Media Gateway Controller. (See further for
possible transfer mechanisms)
* A binding table in the Media Gateway Controller between B-channels
and the associated D-channels (i.e. a view of the BRI and PRI
structures).
5.2 Advantages of a general ISDN Naming Scheme
The adoption of a consistent naming scheme of ISDN terminations
would simplify configuration of Media Gateways and Media Gateway
Controllers, and facilitate their interoperability. The extension of
a Media Gateway with new terminations - a current practice in Access
Gateways - could be more easily automated. And finally the use of
one naming pattern in Megaco/H.248 and IUA/SCTP protocols (see
further) is almost a prerequisite for a transparent Media Gateway
Controller implementation.
5.3 Proposal for an ISDN Termination Naming Pattern
A possible naming pattern for ISDN terminations could be:
ISDNTerm / [BA[1-{#BA}] / [D, B[1-2]],
PRI[1-{#PRI}] / [D, B[1-23]],
PRA[1-{#PRA}] / [D, B[1-30]]
]
Examples of termination names constructed according to this scheme:
ISDNTerm/BA93/B1
ISDNTerm/PRI17/B18
ISDNTerm/PRI22/D
ISDNTerm/PRA88/B28
5.3 Visibility of the D-channel for Megaco/H.248
The advantages of a naming scheme are coupled to the visibility of
D-channels to the Megaco/H.248 implementation. Megaco/H.248 can be
unaware of the existence of D-channels, and only be involved with
the establishment of media contexts containing B-channels. It's also
possible to treat D-channels similarly to B-channels, and allow all
Megaco/H.248 operations on D-channels. This draft discusses a set of
implementation options, which translate to an increasing visibility
of the D-channels to Megaco/H.248:
Bouwen, Van Doorselaer, Dekeyser 5
Internet Draft ISDN Access Gateways Issues March 2000
* Megaco/H.248 is unaware of the existence of D-channels (par. 7.1)
* Reference to D-channels is used in Megaco/H.248 for management
purposes (e.g. blocking/unblocking) (par. 6.1, 6.2, 7.2)
* Reference to D-channels is used in Megaco/H.248 for Q.931 backhaul
(par. 6.1, 6.2)
* Megaco/H.248 references D-channels to set up signaling connections
(par. 7.3)
* Megaco/H.248 references D-channels to set up media (packet data)
connections over the D-channel (par. 10)
6. ISDN Signaling Backhaul Mechanisms
In the decomposed architecture of Media Gateways and Media Gateway
Controllers, the call control intelligence resides in the Media
Gateway Controller. This implies the call control signaling, which
is transported in the SCN over the D-channel as Q.931 messages, has
to be relayed from the Media Gateway to the Media Gateway Controller
and vice versa. One can think of two main approaches to tackle this
backhauling problem:
* Using the Megaco/H.248 protocol to transfer the Q.931 information,
as a set of newly defined events and signals, or as a binary
attachment to the Megaco/H.248 message.
* Using the signaling transport protocols developed in the Sigtran
WG: SCTP [2] and IUA [3] (ISDN Q.921 Adaptation Layer)
The use of Megaco/H.248 for the transfer of Q.931 messages may be
considered a sub-optimal solution, as Megaco/H.248 was never
designed/intended to be a transport protocol. The solution can be
defended for small residential gateways, when the vendor wishes to
limit the number of implemented protocol stacks.
The next paragraphs discuss in more detail the identified options.
6.1 Translating Q.931 into Megaco/H.248 Events and Signals
6.1.1 Translation Mechanism
In a first approach, new events and signals are defined for every
type of Q.931 message. Events are used to notify the Media Gateway
Controller of an incoming Q.931 message (from the user to the Media
Gateway). The Media Gateway translates incoming Q.931 messages into
the appropriate event, and fills the defined additional event
parameters with the information elements of the Q.931 messages. The
Media Gateway Controller instructs the Media Gateway to send out
Q.931 messages with the use of signals. The Media Gateway constructs
an outgoing Q.931 message from the information in the received
signal additional parameters.
Bouwen, Van Doorselaer, Dekeyser 6
Internet Draft ISDN Access Gateways Issues March 2000
6.1.2 Package Definition
The next partial package description gives examples of events and
signals in a possible Q.931 Translation Package. The example only
defines additional parameters for the 'Incoming Q.931 SETUP' event.
Q.931 Translation Package
Package ID: q931transl
Version: 1
Extends: none
Description:
This package defines events for every type of Q.931 message
received by the Media Gateway, and signals for every type of
Q.931 message the Media Gateway Controller wishes to send
out to the user via the Media Gateway. Additional event and
signal parameters are defined for the information elements
specified in Q.931.
EVENTS
Incoming Q.931 SETUP
EventID: setup (Ox0001)
Q.931 SETUP message received from user
ObservedEventsDescriptor Parameters
Protocol Discriminator
ParameterID: protdiscr (0x0001)
Type: String
Default value = Q931UN
Call Reference Length
ParameterID: crl (0x0002)
Type: Integer
Length of call reference value in octets
Call Reference Value
ParameterID: crv (0x0003)
Type: Integer
Numerical value of call reference parameter
Called Party Number
ParemeterID: cldpty
Type: String
Calling Party Number
ParameterID: clgpty
Type: String
Incoming Q.931 SETUP ACKNOWLEDGE
EventID: setupack (0x0002)
Q.931 SETUP ACK received from user
Bouwen, Van Doorselaer, Dekeyser 7
Internet Draft ISDN Access Gateways Issues March 2000
Incoming Q.931 ALERTING
EventID: alerting (0x0003)
Q.931 ALERTING message received from user
Incoming Q.931 CONNECT
EventID: connect (0x0004)
Q.931 CONNECT message received from user
Incoming Q.931 CONNECT ACKNOWLEDGE
EventID: connectack (0x0005)
Q.931 CONNECT ACKNOWLEDGE received from user
etc.
SIGNALS
Outgoing Q.931 SETUP
SignalID: setup (0x0001)
Instruction to send Q.931 SETUP message to user
SignalType: Brief
Additional Parameters
Protocol Discriminator
ParemeterID: protdiscr (0x0001)
etc.
Although straightforward, this mechanism leads to the definition of
a huge ISDN package, and puts a considerable processing burden on
the Media Gateway. It is therefore not further developed in this
draft.
6.2 Embedding Q.931 messages in Megaco/H.248
6.2.1 Generic Q.931 event and signal
Q.931 messages can be embedded in Megaco/H.248 messages as binary
data. The event/signal mechanism is used to define a generic Q.931
event/signal. The Media Gateway uses the 'q931in' event to notify an
incoming Q.931 message has been received. The Q.931 message itself
is appended to the Megaco message containing the notify as a binary
attachment. The Media Gateway Controller uses a similar process to
convey Q.931 messages to the Media Gateway. With a modify command
containing the 'Q931out' signal, the Media Gateway Controller
requests the Media Gateway to send out the Q.931 message that is
attached to the Megaco/H.248 message.
Bouwen, Van Doorselaer, Dekeyser 8
Internet Draft ISDN Access Gateways Issues March 2000
6.2.2 Embedding mechanism
This draft proposes to use the MIME mechanism to embed binary Q.931
message into the Megaco/H.248 message. The current practice to
define MIME attachments for SIP is the main reason for this choice.
Content-type of the attachment is defined as q931/application. The
content-type is an additional parameter for the q931in event and
q931out signal. Other additional parameters are the Content Length
and the Content Transfer Encoding method.
6.2.3 Q.921 Addressing
To ensure the outgoing signaling message is addressed to the proper
Terminal Endpoint and Service, the Media Gateway has to receive from
the Media Gateway Controller the TEI and SAPI for a particular Q.931
message. For incoming Q.931 messages, the Media Gateway has to
include the Q.921 addressing (DLCI) in the to the Media Gateway
Controller forwarded Q.931 message. The Q.921 DLCI can be included
in the Megaco/H.248 messages at two positions: in additional
parameters for the q931in event and q931 signal, or it can be
prepended to the binary Q.931 attachment. The additional parameter
mechanism is preferred because it also allows identification of the
DLCI when no MIME attachment is present, as required in some layer
management events/signals described in paragraph 6.2.7.
6.2.4 Package definition
Q.931 Tunneling Package
Package ID: q931tunn
Version: 1
Extends: none
Description:
This package defines a generic event for an incoming Q.931
message, and a generic signal for an outgoing Q.931 message.
The binary Q.931 messages (supplemented by the Q.921 DLCI)
are appended to the Megaco/H.248 message as binary MIME
attachments. Additional parameters for the description of
the MIME content are defined accordingly.
EVENTS
Incoming Q.931 Message
EventID: q931in (0x0001)
Media Gateway reports an incoming Q.931 message has been
received
ObservedEventsDescriptor Parameters
Q.921 Terminal Equipment Identifier
ParameterID: tei (0x0001)
Type: Integer
Bouwen, Van Doorselaer, Dekeyser 9
Internet Draft ISDN Access Gateways Issues March 2000
Q.921 Service Access Point Identifier
ParameterID: sapi (0x0002)
Type: Integer
Content Length
ParameterID: contlen (0x0003)
Type: Integer
The length of the mime attachment containing
the Q.931 message (and Q.921 DLCI) in number of
bytes
Content Type
ParameterID: conttype (0x0004)
Type: String
The type of the embedded MIME attachment:
q931/application
Content Transfer Encoding
ParameterID: encod (0x0005)
Type: String
The encoding method for the MIME attachment:
binary
SIGNALS
Outgoing Q.931 Message
SignalID: q931out (0x0001)
Media Gateway Controller requests Media Gateway to send out
Q.931 message that is contained in the MIME attachment
SignalType: Brief
Additional Parameters
Q.921 Terminal Equipment Identifier
ParameterID: tei (0x0001)
Type: Integer
Q.921 Service Access Point Identifier
ParameterID: sapi (0x0002)
Type: Integer
Content Length
ParameterID: contlen (0x0003)
Type: Integer
The length of the mime attachment containing
the Q.931 message (and Q.921 DLCI) in number of
bytes
Content Type
ParameterID: conttype (0x0004)
Type: String
The type of the embedded MIME attachment:
q931/application
Content Transfer Encoding
ParameterID: encod (0x0005)
Type: String
The encoding method for the MIME attachment:
binary
Bouwen, Van Doorselaer, Dekeyser 10
Internet Draft ISDN Access Gateways Issues March 2000
6.2.5 Example Megaco message 1: DLCI in binary MIME attachment
Following message is an example of a notification by a Media Gateway
of an incoming Q.931 setup message. As is clear from the
Megaco/H.248 message contents, the Media Gateway is not aware of the
type of Q.931 message it received.
+--------------------------------------------------------------+
|MEGACO/1 [124.124.124.222]:55555 |
|Transaction = 10004 { |
| Context = - { |
| Notify = ISDNTerm/BA17/D { |
| ObservedEvents = 2222 { |
| Q931tunn/q931in { |
| contlent 187, |
| conttype application/q931,|
| encod binary |
| } |
| } |
| } |
| } |
|} |
+--------------------------------------------------------------+
| Q.921 DLCI (SAPI + TEI) |
+--------------------------------------------------------------+
| |
| Q.931 Binary Message |
| |
+--------------------------------------------------------------+
6.2.6 Example Megaco message 2: DLCI in ObservedEventsDescriptor
+--------------------------------------------------------------+
|MEGACO/1 [124.124.124.222]:55555 |
|Transaction = 10004 { |
| Context = - { |
| Notify = ISDNTerm/BA17/D { |
| ObservedEvents = 2222 { |
| Q931tunn/q931in { |
| contlent 187, |
| conttype application/q931,|
| encod binary, |
| tei 88, |
| sapi 0} |
| } |
| } |
| } |
|} |
+--------------------------------------------------------------+
| |
| Q.931 Binary Message |
| |
+--------------------------------------------------------------+
Bouwen, Van Doorselaer, Dekeyser 11
Internet Draft ISDN Access Gateways Issues March 2000
6.2.7 Q.921 Management and Error Messages
In addition to the backhauling of Q.931 from the ISDN access gateway
to the Media Gateway Controller and vice versa, it is also a
requirement that during operation Q.921 management messages can be
exchanged between the ISDN access gateway and the Media Gateway
Controller. This can be achieved by extending the Q.931Tunneling
package with a Q.921 management event and signal.
The approach described in this section creates a specific Q.921
adaptation layer for Q.931, to be transported inside Megaco messages
with the event/signal mechanism. The following package description
is based on the Q.921
Q.931 Tunneling Package - Continued
EVENTS
Q.921 Data Link Establishment Confirmation
EventID: q921estabconf (0x0002)
Media Gateway confirms data link has been established
ObservedEventsDescriptor Parameters
Q.921 Terminal Equipment Identifier
ParameterID: tei (0x0001)
Type: Integer
Q.921 Service Access Point Identifier
ParameterID: sapi (0x0002)
Type: Integer
Q.921 Data Link Release Confirm
EventID: q921relconf (0x0003)
Media Gateway confirms data link has been released
ObservedEventsDescriptor Parameters
Q.921 Terminal Equipment Identifier
ParameterID: tei (0x0001)
Type: Integer
Q.921 Service Access Point Identifier
ParameterID: sapi (0x0002)
Type: Integer
Q.921 Data Link Release Indication
EventID: q921relind (0x0004)
Media Gateway reports data link has been released
ObservedEventsDescriptor Parameters
Q.921 Terminal Equipment Identifier
ParameterID: tei (0x0001)
Type: Integer
Bouwen, Van Doorselaer, Dekeyser 12
Internet Draft ISDN Access Gateways Issues March 2000
Q.921 Service Access Point Identifier
ParameterID: sapi (0x0002)
Type: Integer
Reason
ParameterID: reason (0x0003)
Type: String
Possible Values:
Management Layer generated release
Physical Layer Alarm generated release
Other messages for further study
Q.921 Unit Data In
EventID: q921udin (0x0005)
Media Gateway reports an incoming Q.921 unit data message. The
Protocol Data Unit is contained in the MIME attachment
ObservedEventsDescriptor Parameters
Q.921 Terminal Equipment Identifier
ParameterID: tei (0x0001)
Type: Integer
Q.921 Service Access Point Identifier
ParameterID: sapi (0x0002)
Type: Integer
Content Length
ParameterID: contlen (0x0003)
Type: Integer
The length of the mime attachment containing
the Q.921 unit datat message in number of bytes
Content Type
ParameterID: conttype (0x0004)
Type: String
The type of the embedded MIME attachment:
q921/application
Content Transfer Encoding
ParameterID: encod (0x0005)
Type: String
The encoding method for the MIME attachment:
binary
SIGNALS
Q.921 Data Link Establishment Request
SignalID: q921estreq (0x0002)
Media Gateway Controller requests Media Gateway to establish
data link in D-channel
SignalType: Brief
Additional Parameters
Q.921 Terminal Equipment Identifier
ParameterID: tei (0x0001)
Type: Integer
Bouwen, Van Doorselaer, Dekeyser 13
Internet Draft ISDN Access Gateways Issues March 2000
Q.921 Service Access Point Identifier
ParameterID: sapi (0x0002)
Type: Integer
Q.921 Data Link Release Request
SignalID: q921relreq (0x0003)
Media Gateway Controller requests Media Gateway to release the
data link
SignalType: Brief
Additional Paremeters
Q.921 Terminal Equipment Identifier
ParameterID: tei (0x0001)
Type: Integer
Q.921 Service Access Point Identifier
ParameterID: sapi (0x0002)
Type: Integer
Reason
ParameterID: reason (0x0003)
Type: String
Possible Values:
Management Layer generated release
Other messages for further study
Q.921 Unit Data Out
SignalID: q921udout (0x0004)
Media Gateway Controller requests Media Gateway to send out
Q.921 unit data message that is contained in the MIME
attachment
SignalType: Brief
Additional Parameters
Q.921 Terminal Equipment Identifier
ParameterID: tei (0x0001)
Type: Integer
Q.921 Service Access Point Identifier
ParameterID: sapi (0x0002)
Type: Integer
Content Length
ParameterID: contlen (0x0003)
Type: Integer
The length of the mime attachment containing
the Q.921 unit data message in number of bytes
Content Type
ParameterID: conttype (0x0004)
Type: String
The type of the embedded MIME attachment:
q921/application
Content Transfer Encoding
ParameterID: encod (0x0005)
Type: String
The encoding method for the MIME attachment:
binary
Bouwen, Van Doorselaer, Dekeyser 14
Internet Draft ISDN Access Gateways Issues March 2000
This package needs further study. At the moment no events/signals
for error messages have been defined. Analysis is required to assess
to what extent Megaco/H.248 ErrorDescriptors cover required error
reporting.
6.3 Using Sigtran protocols: IUA over SCTP
The third solution for the backhauling problem is the use of the
signaling transport protocols developed in Sigtran. It involves the
generic signaling transport protocol SCTP [2], and the ISDN Q.921
Adaptation Layer (IUA) [3]. Figure 2 shows the envisaged
architecture. An SCTP association is set up between the Media
Gateway and the Media Gateway Controller for the relay of Q.931
signaling and Q.921 management information. The SCTP association
contains unidirectional streams. Every D-channel is mapped to an MG-
>MGC stream and an MGC->MG stream, as proposed in [3]. The mapping
of a particular D-channel to an SCTP stream is a matter of
implementation, but the use of the same stream identification number
in both directions seems a logical choice.
The Media Gateway Controller uses Megaco/H.248 to create and remote
media contexts containing B-channel terminations. Signaling
associated with the B-channels is transferred between Media Gateway
and Media Gateway Controller as unmodified Q.931 binary messages.
Megaco/H.248 is not directly concerned with the Q.931 backhaul
mechanism. However, some interaction between the two protocols is
required. References to D-channels can show up in both Megaco/H.248
and IUA messages. Some synchronization is needed between the
Megaco/H.248 ServiceChange messages and the initiation/release of
SCTP associations. These issues are explored in more detail in the
next chapter
Figure 3 shows the contents of a message conveyed over an SCTP
stream. Only some elements of the SCTP message header are shown. The
IUA header contains a reference to the relevant D-channel, and the
Q.921 addressing information.
Bouwen, Van Doorselaer, Dekeyser 15
Internet Draft ISDN Access Gateways Issues March 2000
SCTP Association |
|
################ | ################
# # v # +--------+ #
# *************#********************#*** Q.931 | #
# * ***********#********************#*** Sign. | #
D*********#** * # ^ # +--------+ #
B1---------#- * +-----+ # # | IUA | #
B2---------#---*-|-o o-|--#--------> RTP # +--------+ #
# * +-----+ # (Media) # | SCTP | #
# * # # +--------+ #
D*********#**** # # #
B1---------#- +-----+ # # #
B2---------#-----|-o o-|--#--------> RTP # #
. # +-----+ # (Media) # #
. # # # #
B31---------#- # # #
# # # #
################ ################
Media Gateway Media Gateway
Controller
Figure 2 - Megaco + IUA/SCTP Architecture
+-------------------------------------+ ^
! ... ! !
! ! !
+------------------+------------------+ !
! Originating Port ! Destination Port ! !
+------------------+------------------+ !
! StreamID = 17 ! ! !
+-------------------------------------+ !
! ! !
! +-----------------------------+ ! ^ !
! ! Adaptation Layer ! ! ! !
! ! Common Header ! ! ! !
! +-----------------------------+ ! ! !
! ! 'ISDN/PRI17/D' ! ! ! !S
! +-----------------------------+ ! !I !C
! ! SAPI ! ! !U !T
! +-----------------------------+ ! !A !P
! ! TEI ! ! ! !
! +-----------------------------+ ! ! !
! ! Q.931 ! ! ! !
! ! DATA ! ! ! !
! +-----------------------------+ ! v !
+-------------------------------------+ v
Figure 3 - Contents of IUA/SCTP Q.931 Backhauling Message
Bouwen, Van Doorselaer, Dekeyser 16
Internet Draft ISDN Access Gateways Issues March 2000
7. Megaco - Sigtran interworking
7.1 Minimal interworking
A first scenario encompasses minimal interworking between
Megaco/h.248 and IUA/SCTP. The Megaco/H.248 implementation is
unaware of the existence of D-channels and the backhauling
mechanism. At start-up the Media Gateway informs the Media Gateway
Controller of its existence with a Megaco/H.248 ServiceChange
message. The next step is the initiation of an SCTP association for
the signaling backhaul. assuming that no SCTP association has been
created between the Media Gateway Controller and the ISDN acces
gateway as a transport layer for the megaco/H.248 protocol). In case
the megaco/H.248 protocol uses one or more SCTP streams, one should
take care that different stream identifiers are used for the Q.931
backhauling and for the streams used by the megaco/H.248 protocol.
Table 1 lists the dependencies between ServiceChange messages and
the management of the SCTP association.
+==================================================================+
| Megaco/H.248 ServiceChange | SCTP Association |
+==================================================================+
| RESTART (Root or all ISDN terms)| INIT SCTP Association |
| | by Media Gateway |
+------------------------------------------------------------------+
| GRACEFUL Shutdown (Root or all | TERMINATE SCTP Association |
| ISDN terminations) | by Media Gateway |
+------------------------------------------------------------------+
| FORCED Shutdown (Root or all | ABORT SCTP Association |
| ISDN terminations) | by Media Gateway |
+------------------------------------------------------------------+
| DISCONNECTED | Check if SCTP Association is |
| | still operational, INIT other- |
| | wise |
+------------------------------------------------------------------+
| HANDOFF (sent by MGC1 to MG, to | 1. MG TERMINATEs SCTP Assoc. |
| hand off from MGC1 to MGC2) | to MGC1 |
| | 2. MG INITs SCTP Association |
| | to MGC2 |
+------------------------------------------------------------------+
| FAILOVER (sent by MG1 to MGC, to| 1. If SCTP Association between |
| change from MG1 to MG2) | MG1 and MGC was not aborted,|
| | ABORT by MGC |
| | 2. INIT SCTP Assoc. by MG2 |
+------------------------------------------------------------------+
Table 1 - Synchronization between ServiceChange and SCTP Association
Management for minimal Megaco - SCTP interworking
Bouwen, Van Doorselaer, Dekeyser 17
Internet Draft ISDN Access Gateways Issues March 2000
Remarks:
1. The table assumes Megaco/H.248 itself doesn't run over SCTP. If
this is the case, the same SCTP association could also be used for
signaling backhaul.
2. The synchronization requirements for a Restart, a Graceful or
Forced Shutdown are valid when the complete Media Gateway is
affected (i.e. the referenced termination is 'root'), or when the
complete set of available ISDN terminations is involved (i.e. the
ISDN part of the Media Gateway). For the restart of shutdown of one
ISDN termination, no changes in the SCTP association are required
(since once the SCTP association has been established, there is no
need to set up or tear down the flows inside the association).
7.2 Referencing D-channels for management
In a second scenario D-channels are visible for the Megaco/H.248
implementation, and can hence be addressed in Megaco/H.248 messages.
This would be a logical situation if a standardized naming pattern
is used, which is downloaded by the Media Gateway Controller from
the Media Gateway when it restarts (a feature scheduled for the next
Megaco/H.248 version).
If D-channels are only used for the transfer of Q.931 signaling, D-
channel terminations will not be added to Megaco/H.248 contexts.
They can however be audited to get their current status (see par.
for ISDN termination properties), and can be referenced in
ServiceChange commands (to block/unblock a D-channel).
When D-channels can contain packet data, visibility of the D-channel
for Megaco/H.248 is clearly a necessity. In this case, a specific
type of NAS package could be foreseen. See chapter 10 for a
preliminary discussion of this topic.
The synchronization requirements between Megaco/H.248 ServiceChange
and the establishment/release of the SCTP association are identical
to the ones presented in paragraph 7.1 (Table 1).
7.3 Megaco/H.248 controlled SCTP stream set-up
In this scenario the set-up of the SCTP association is controlled by
the Media Gateway Controller. The Media Gateway Controller
furthermore uses Megaco/H.248 commands to explicitly bind D-channels
to SCTP streams. It creates contexts for this purpose that contain
the D-channel and the associated SCTP streams. The properties of the
SCTP terminations are described with SDP. Extensions to SDP are
required to indicate the transport protocol is SCTP, the format is
IUA (Q.921 Adaptation Layer), and to reference the SCTP stream
identifier. The example Megaco message below creates a signaling
context:
Bouwen, Van Doorselaer, Dekeyser 18
Internet Draft ISDN Access Gateways Issues March 2000
MEGACO/1 [123.123.123.4]:55555
Transaction = 10003 {
Context = $ {
Add = ISDNTerm/BA17/D,
Add = $ {
Media { Stream = 65 {
LocalControl { Mode = SendReceive},
Local { v=0
c=IN IP4 124.124.124.22
m=control 7777 sctp iua
a=stream:17 }
Remote { v=0
c=IN IP4 123.123.123.4
m=control 7777 sctp iua
a=stream:17 }
}
}
}
}
}
A few new items are introduced in this message:
Stream = 65
A number different from 1 has been chosen, as this is reserved
for audio.
M = control 7777 sctp iua
control: already defined in the SDP specification
7777: sctp port number for this association
sctp: transport protocol, new protocol in SDP
iua: format, new protocol in SDP
a= stream:17
New SDP attribute specifying the SCTP stream to be added to the
newly created context
The Media Gateway will assign a name to the SCTP ephemeral
termination in its response, as is defined for RTP sessions.
This mechanism offers the Media Gateway Controller detailed control
of the binding between D-channels and SCTP streams. The advantages
for the backhauling application are not immediately clear. However,
future applications may require the by the Media Gateway Controller
managed establishment of SCTP streams (for further study).
Remark that Megaco/H.248 is not used for the establishment/release
of an SCTP association. Only SCTP streams are addressed with
Megaco/H.248 commands. The requirements for synchronization between
Megaco/H.248 ServiceChange and the management of the SCTP
association are listed in Table 2.
Bouwen, Van Doorselaer, Dekeyser 19
Internet Draft ISDN Access Gateways Issues March 2000
+==================================================================+
| Megaco/H.248 ServiceChange | SCTP Association |
+==================================================================+
| RESTART (Root or all ISDN terms)| INIT SCTP Association |
| | by Media Gateway Controller |
+------------------------------------------------------------------+
| GRACEFUL Shutdown (Root or all | TERMINATE SCTP Association |
| ISDN terminations) | by Media Gateway |
+------------------------------------------------------------------+
| FORCED Shutdown (Root or all | ABORT SCTP Association |
| ISDN terminations) | by Media Gateway |
+------------------------------------------------------------------+
| DISCONNECTED | Check if SCTP Association is |
| | still operational, INIT other- |
| | wise |
+------------------------------------------------------------------+
| HANDOFF (sent by MGC1 to MG, to | 1. MGC1 TERMINATEs SCTP Assoc |
| hand off from MGC1 to MGC2) | to MG |
| | 2. MGC2 INITs SCTP Association |
| | to MG |
+------------------------------------------------------------------+
| FAILOVER (sent by MG1 to MGC, to| 1. If SCTP Association between |
| change from MG1 to MG2) | MG1 and MGC was not aborted,|
| | ABORT by MGC |
| | 2. INIT SCTP Assoc. by MGC |
+------------------------------------------------------------------+
Table 2 - Synchronisation between ServiceChange and SCTP Association
Management for MGC controlled association set-up
7.4 Data in D-channel
When D-channels can contain packet data, visibility of the D-channel
for Megaco/H.248 is clearly a necessity. See chapter 10 for a
preliminary discussion of this topic.
8. Properties of ISDN Terminations
8.1 ISDN Termination type
It may be interesting for the Media Gateway Controller to find out
the channel type of a particular ISDN termination, if it is not able
to deduce it from its name. (In cases where no self-explanatory
naming pattern is used, or when Media Gateway Controller doesn't
support implicit definition of channel type by the naming pattern.)
Bouwen, Van Doorselaer, Dekeyser 20
Internet Draft ISDN Access Gateways Issues March 2000
PROPERTIES
Channel Type
PropertyID: chantype (0x0001)
Identifies the type of ISDN channel for a ISDN termination
Type: Enumeration
Possible Values:
"BA D" D-channel in basic access interface
"BA B" B-channel in basic access interface
"PRA2048 D" D-channel in 2048kbit primary rate interface
"PRA2048 B" B-channel in 2048kbit primary rate interface
"PRI1544 D" D-channel in 1544kbit primary rate interface
"PRI1544 B" B-channel in 1544kbit primary rate interface
Defined in: TerminationState
Characteristics: Read
8.2 Interface Identifiers and Associated D-channel
A D-channel in one PRI may be used to transfer signaling for a set
of PRI's. The other PRI's have in this case 24 or 31 B-channels. The
Q.931 messages received on the D-channel refer to the relevant B-
channel in the Interface Identifier information element [6]. The
Interface Identifier is a binary provisioned identifier for the
primary rate interfaces. The ISDN package 'Interface Identifier'
property contains this value. Another B-channel property 'Associated
D-channel' contains the associated D-channel, in the naming
convention used by the Media Gateway to refer to ISDN terminations.
These properties are defined as read-only, as it is not the
intention to use Megaco/H.248 to make such configurations.
PROPERTIES
Q.931 Interface Identifier
PropertyID: interfaceid (0x0002)
Contains the binary interface identifier used in Q.931 messages
when a D-channel in a PRI has been provisioned to act as
signalling channel for several PRIs.
Type: Integer
Possible Values:
Defined in: TerminationState
Characteristics: Read
Associated D-channel
PropertyID: assocd (0x0003)
Contains the name of the D-channel termination that is
associated with this B-channel
Type: String
Possible Values:
Defined in: TerminationState
Characteristics: Read
Bouwen, Van Doorselaer, Dekeyser 21
Internet Draft ISDN Access Gateways Issues March 2000
8.3 Layer 1 Activation
In current ISDN access gateway architectures, the layer 1
functionality for Basic Interfaces is split between the access
gateway and the entity containing call control (the local exchange).
In this draft we model the required interaction related to layer 1
between the Media Gateway and the Media Gateway Controller on the
existing decomposition practice in the SCN. More specifically, the
control protocol messages defined in V5 [7,8] are used as a basis
for the information exchange within Megaco/H.248.
The Media Gateway Controller is informed by the Media Gateway about
the layer 1 availability of the ISDN termination (operational/non-
operational). In addition, the Media Gateway Controller supports the
activation/deactivation procedure for Basic Interfaces, as defined
in ITU Recommendation I.430 [4]. Primary Rate Interfaces are
permanently activated.
Maintenance of the Access Digital Section and customer lines is the
responsibility of the Media Gateway. The operation of loopbacks or
activation/deactivation of the digital section is only controlled by
the Media Gateway. No information related to these functions
is transmitted to the Media Gateway Controller.
The transfer of messages for the layer 1 management with the
event/signal mechanism is discussed in paragraph 9.3.1.
Primary Rate Interfaces are permanently activated and don't make use
of the activation/deactivation procedure. Also Basic Interfaces can
be permanently activated. The activation policy for a Basic
Interface is specified in a new ISDN termination property:
PROPERTIES
Activation Policy
PropertyID: permact (0x0004)
Specifies if the Basic Interface is permanently activated, or
if the activation/deactivation procedure should be followed.
Type: Boolean
Possible Values:
True: permanent activation is installed
False: activation/de-activation procedure
Defined in: TerminationState
Characteristics: Read
8.4 Blocked/Unblocked States
The blocked/unblocked states for ISDN terminations are directly
mapped onto the Megaco/H.248 defined termination states of inservice
and outofservice.
Bouwen, Van Doorselaer, Dekeyser 22
Internet Draft ISDN Access Gateways Issues March 2000
See paragraph 9.2 for the related Megaco/H.248 messages
9. Controlling ISDN Termination Properties
9.1 Modifying Termination Properties
Megaco/H.248 offers three methods to modify and retrieve the state
of terminations:
1. The Media Gateway Controller can change the state of a
termination with the Modify method, and can read it with the
Audit method. This mechanism doesn't allow the Media Gateway to
report changes in state.
2. The event/signal mechanism allows the Media Gateway Controller to
order the Media Gateway to modify a termination state (signal),
and to report state changes (event notification). It is the
appropriate mechanism for call-related states.
3. The ServiceChange method is used by the Media Gateway Controller
to modify states that are not call-related (inservice,
outofservice). The Media Gateway can use it to send unsolicited
state change reports.
9.2 ServiceChange for Blocking/Unblocking
The ServiceChange methods and servicechange reasons currently
defined in Megaco/H.248 seem sufficient to support the
blocking/unblocking capabilities currently offered by the V5
specification. Table 3 maps Megaco ServiceChange methods and reasons
on the V5 control function elements for the management of ISDN
terminations.
Remark 1: Termination reference
Blocking and unblocking messages refer to the complete ISDN
termination (B-channels and D-channel), and will for example contain
a termination identifier of the form ISDNTerm/BA17/*.
D-channel blocking and unblocking only influences the D-channel. The
termination identifier will look like ISDNTerm/BA17/D.
Remark 2: performance grading
Performance Grading allows the Media Gateway to inform the Media
Gateway Controller predefined performance thresholds have been
passed. New ServiceChange reasons 'Normal Performance' and 'Degraded
Performance level X' can be defined for this purpose, to be used
with Restart and Forced ServiceChange methods.
Bouwen, Van Doorselaer, Dekeyser 23
Internet Draft ISDN Access Gateways Issues March 2000
Alternatively, a new event can be defined, with an additional
parameter specifying the performance grade (remark that this
contradicts the earlier defined philosophy to use signals and events
for call-related state exchange).
EVENTS
Performance Grade
EventID: perfgrade (0x0001)
Media Gateway reports change in performance grade
Additional Parameters
Grade
ParameterID: grade (0x0001)
Type: Enumeration
Possible Values: normalGrade, degraded
+==================================================================+
!Direct! V5 ! Megaco/H.248 ServiceChange !
!MG-MGC! Function Elements ! Method ! Reason !
+======+=========================+========+========================+
! <- !FE201 Unblock !Restart ! 903:MGC Directed Change!
+------+-------------------------+--------+------------------------+
! -> !FE202 Unblock !Restart ! 900:Service Restored !
+------+-------------------------+--------+------------------------+
! <- !FE203 Block !Forced ! 903:MGC Directed Change!
+------+-------------------------+--------+------------------------+
! -> !FE204 Block !Forced ! 905: Termination taken !
! ! ! ! out of service !
+------+-------------------------+--------+------------------------+
! -> !FE205 Block Request !Graceful! 905: Termination taken !
! ! ! ! out of service !
+------+-------------------------+--------+------------------------+
! -> !FE206 Performance Grading! ? ! See remark 2 !
+------+-------------------------+--------+------------------------+
! <- !FE207 D-channel Block !Forced ! 903:MGC Directed Change!
+------+-------------------------+--------+------------------------+
! <- !FE208 D-channel Unblock !Restart ! 903:MGC Directed Change!
+------+-------------------------+--------+------------------------+
! -> !FE209 TE out of service !Forced ! 904/905/906 ... !
+------+-------------------------+--------+------------------------+
! -> !FE210 Failure inside !Forced ! Additional reasons can !
! ! network ! ! be defined in required !
+------+-------------------------+--------+------------------------+
Table 3: ServiceChange for blocking/unblocking of ISDN Terminations
Bouwen, Van Doorselaer, Dekeyser 24
Internet Draft ISDN Access Gateways Issues March 2000
9.3 Messages for Layer 1 Activation
9.3.1 Megaco/H.248 Signals/Events
Following package description defines the events and signals for
layer 1 management by the Media Gateway Controller:
ISDN Layer 1 Management Package
Package ID: isdnlay1
Version: 1
Extends: none
Description:
This package defines signals/events for the activation/de-
activation procedure for ISDN Basic Interfaces, as defined
in ITU-T Recommendation I.430 [4].
EVENTS
Event name: Activation initiated by user
EventID: useract(0x0001)
Description:
Event name: DS activated
EventID: dsact (0x0002)
Description:
Event name: Access activated
EventID: accessact (0x0003)
Description:
Event name: Access deactivated
EventID: accessdeact (0x0004)
Description:
SIGNALS
Signal name: Activate access
SignalID: activaccess (0x0005)
Description:
SignalType: OO
Signal name: Deactivation access
SignalID: deactivaccess (0x0006)
Description:
SignalType: OO
PROCEDURES
See G.964 chapter 14 [7]
Bouwen, Van Doorselaer, Dekeyser 25
Internet Draft ISDN Access Gateways Issues March 2000
9.3.2 SCTP Transport of Activation Messages
An alternative approach is to exchange layer 1 management messages
within the SCTP streams that are used for the layer 2 management.
Messages for this purpose are based on the format for Sigtran
adaptation layer messages, as shown in Figure 4.
0 7 8 15 16 31
+---------------+---------------+
| Vers | Spare | Msg Type |
+-------------------------------+
| Tag (0x1) | Length |
+-------------------------------+
| Interface Identifier |
+-------------------------------+
Figure 4 - Layer 1 Activation Management Messages
Version: version of layer 1 activation management protocol = 01
Spare
Msg Type: see further
Tag: code for Interface Identifier information element
Length: length in number of octets of Interface Identifier
Interface ID:String identifier for the ISDN termination, constructed
According to the ISDN termination naming pattern
The defined messages are:
Activation Initiated by User 0101
DS Activated 0102
Access Activated 0103
Access Deactivated 0104
Activate Access 0105
Deactivate Access 0106
A protocol id for the layer 1 activation management protocol will
have to be defined in SCTP.
9.4 ServiceChange for new Terminations
To support the on-line installation of new (ISDN) terminations in
the Media Gateway, and new ServiceChange reason is defined "New
Termination(s)", to be used with the Restart method.
10. Packet data in the D-channel
Data connections over the B-channel (e.g. for Internet access) are
not discussed in this draft. The D-channel however can also be used
for the transport of packet data. In this way an always-on internet
Bouwen, Van Doorselaer, Dekeyser 26
Internet Draft ISDN Access Gateways Issues March 2000
connection can be offered to the user. An internet connection over
the D-channel can be used to signal the arrival of new messages in
the user's mailbox. A B-channel will be opened for download of the
packet data.
This section addresses required extensions to the Megaco/H.248
protocol and SDP to support the use of the D-channel for packet data
different from Q.931 signaling.
The Q.921 SAPI differentiates between Q.931 signaling and packet
data. The SAPI has the value of 0 for Q.931, and 16 for packet data.
The presence of both Q.931 signaling and packet data necessitates
the creation of ephemeral terminations on top of the ISDN B-channel
termination.
The Megaco/H.248 message below shows a possible approach to the
problem.
MEGACO/1 [123.123.123.4]:55555
Transaction = 10003 {
Context = $ {
Add = ISDNTerm/BA17/D/$ {
Media { Stream = 66 {
LocalControl { Mode = SendReceive},
Remote { v=0
c=ISDN DLCI 88
m=data 16 ppp }
}
},
Add = $ {
Media { Stream = 66 {
LocalControl { Mode = SendReceive},
--Remote and Local descriptors for
IP network data session-- }}
}
}
}
The message contains the following new items:
Add = ISDNTerm/BA17/D/$
Requests the Media Gateway to create an ephemeral termination
within the D-channel. The Media Gateway will indicate in its
response the assigned termination identifier. This is new
functionality in Megaco/H.248 for SCN terminations.
Stream = 66
A value different from 1 has been selected, as this one is
reserved for audio
Bouwen, Van Doorselaer, Dekeyser 27
Internet Draft ISDN Access Gateways Issues March 2000
c=ISDN DLCI 88
The network is the ISDN, with Q.921 DLCI as addressing scheme
The Terminal Equipment Identifier is 88.
m=data 16 ppp
A data stream is set up to Service Access Point 16, over PPP.
The creation of an ephemeral termination on the IP side is basically
no different from dial-in connections from analogue lines, and is
not further discussed.
11. Conclusion - Recommendations
This draft discusses issues related to the support of ISDN
terminations in Access Gateways. Several approaches to the
identified problems have been introduced. We propose to follow the
next guidelines for the further development of this effort:
11.1 VoIP Residential Gateways
For residential gateways (implementing ISDN Basic Access) the use of
the Megaco - MIME tunneling mechanism for Q.931 signalling backhaul
(discussed in paragraph 6.2) is a viable approach. A residential
ISDN BA gateway package should contain the following components:
* The signals/events defined in paragraphs 6.2.4 (Q.931) and 6.2.7
(Q.921), with Additional Parameters for TEI and SAPI.
* The ISDN channel type termination property (paragraph 8.1)
* Layer 1 management events/signals (paragraph 9.3)
11.2 General VoIP ISDN Access Gateways
For all non-residential ISDN Access Gateways the IUA/SCTP Sigtran
protocols should be used for Q.931 signaling backhaul. The
interwoeking scenario of paragraph 7.2 is preferred: D-channels are
visible for the Megaco/H.248 protocol, but Megaco/H.248 is not used
for the establishment of SCTP backhauling streams.
An ISDN Access Gateway ISDN package should contain the following
components:
* The ISDN termination properties defined in paragraph 8;
ISDN ChannelType (paragraph 8.1)
Q.931 Interface Identifier (paragraph 8.2)
Associated D-Channel (paragraph 8.3)
Activation Policy (paragraph 8.4)
* Layer 1 management events/signals (paragraph 9.3).
New ServiceChange reasons should be registered with IANA for
* Performance Grading reporting (if possible within the ISDN
package) (paragraph 9.2 Remark 2, ServiceChange option);
Bouwen, Van Doorselaer, Dekeyser 28
Internet Draft ISDN Access Gateways Issues March 2000
* Installation of new terminations (paragraph 9.4).
Furthermore, a best practice document should contain:
* A standardized naming pattern for ISDN terminations (paragraph
5.2);
* Synchronization between ServiceChange and SCTP association
management (Table 1);
11.3 Packet Data in D-Channel Applications
This subject needs additional study. Procedures have to be defined
to interoperate with NAS packages (for ISDN terminations). The
preliminary proposal in this draft requires:
* An extension of SDP for the description of packet data streams in
ISDN D-channels;
* The possibility in the next version of Megaco/H.248 to define
ephemeral terminations on top of SCN terminations (D-channels).
12. Security Considerations
For further study.
13. References
[1] Megaco Protocol
draft-ietf-megaco-protocol-07.txt, February 2000
[2] Simple Control Transmission Protocol (SCTP)
draft-ietf-sigtran-sctp-06.txt, February 2000
[3] ISDN Q.921-User Adaptation Layer (IUA)
draft-ietf-sigtran-iua-01.txt, October 1999
[4] ITU-T Recommendation I.430 (1995), Basic user-network interface
- layer 1 specification
[5] ITU-T Recommendation Q.920 (1993), ISDN user-network interface
data link layer - General Aspects
[6] ITU-T Recommendation Q.931 (1998), ISDN user-network interface
layer 3 specification
[7] ITU-T Recommendation G.964 (1994), V-Interfaces at the digital
local local exchange - V5.1-interface for the support of access
network
[8] ETSI Standard ETS 300 324 (1994), V interfaces at the digital
Local Exchange - V5.1 interface for the support of Access Network
Bouwen, Van Doorselaer, Dekeyser 29
Internet Draft ISDN Access Gateways Issues March 2000
[9] ITU-T Recommendation I.412 (1998), ISDN user-network interfaces,
interface structures and access capabilities.
14. Acknowledgements
15. Author's Addresses
Jan Bouwen
Alcatel Bell
F. Wellesplein 1
B-2000 Antwerpen
Belgium
Email: jan.bouwen@alcatel.be
Bart Van Doorselaer
Alcatel Bell
F. Wellesplein 1
B-2000 Antwerpen
Belgium
Email: bart.van_doorselaer@alcatel.be
Miek Dekeyser
Prins Boudewijnlaan 47-49
B-2650 Edegem
Belgium
Email: miek.dekeyser@alcatel.be
Bouwen, Van Doorselaer, Dekeyser 30
Internet Draft ISDN Access Gateways Issues March 2000
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into
Bouwen, Van Doorselaer, Dekeyser 31