Gateway Decomposition Requirements

Dale L. Skran dskran at ASCEND.COM
Sat Nov 21 19:27:39 EST 1998

At 07:54 PM 11/19/98 -0500, Tom-PT Taylor wrote:
>I have been told that APC-1466 states enough requirements for the device
>control interface A, but that we should have requirements for the signalling

It would be more accurate to say that it is a very good start. As mentioned
at the meeting, and as discussed below, the terms of reference are not
fully reflected in the requirements.

>interfaces B, C, and D before committing ourselves to protocol design.  I
>just don't have the same feeling for detailed requirements in those areas
>that I have for interface A.  I can only think of two requirements: these
>interfaces must
>- pass all the signalling content offered to them
Not sure what you mean.
>- do it quickly and reliably.
Of course.

I suggest looking at what IPDC does, but this is what comes to mind:

B Interface:

1)It must be possible to request that the MGW do H.323 signaling to a
specified IP address, which might, for example, be a composed GW. Of
course, this
is an optional feature.

2)It must be possible to do this call by call, ie. for one call request
323 signaling and for the next not request it.

3)Point 2 strongly suggests that the protocol for B and A should be the same,
for example, as in IPDC.

C Interface:

1)It must be possible to bring call signaling up to the controller so that
signaling can be terminated there (optionally). This suggests a need to map
different types of call signaling into a single protocol. Q.931 is an obvious
solution.  See Ascend's "Reliable Gateway Signaling Protocol" for an example.

2)It must be possible to terminate/generate the Q.931, etc. call signaling
on the gateway
(optionally). This is equivalent to having the MGW signal 323 on the packet
This allows a call from a MGW with IMT trunks to talk to a MGW with PRI/T1
under SS7 control.

3)(1) is a kind of tunneling for Q.931, so it is not so clear that this
should be
the same protcol as A/B.

4)(2) seems like it should be a part of the A/B protcol.

X requirements(common requirements on A/B/C):

1)A/B/C signaling must all travel over the same data network to the MGW.

2)It must be possible to use both UDP and TCP

3)Either the protocol is Message/ACK or we must use a reliable UDP like
Annex E.

4)Given the similiarity of B/C to A, all should use a similar message format,
the same ports, etc. to ease implementation. Note that both B/C parts are
optional, but they are part of the same protocol as A. The only exception
is the case
where you want to put SCN call signaling(Q.931, FAS SS7) in the controller,
you need to tunnel it up.  This stuff might be tunneled through the A/B/C
protocol, or it might be a separate protocol/port, i.e. Q.931 on Annex E with
a different port.

5)Part of the A/B/C message set must include an MGW cap set so the controller
knows what to expect

As noted at the meeting, you need to reflect the terms of reference in the A

A couple of obvious ones:

A Interface

1)Must include video/data (i.e. consider the possibility of incoming

2)Must not duplicate H.323 functions, eg. cap exchange, conference
management, etc.

3)Must be elemental. This goes along with (2). cap exchange is not an

4)Must be suitable for connecting an MC (MultiPoint Controller) to an MP
Processer) as defined in H.323.  This implies a need for elemental
primatives, but broken out by media stream, ie. data MP, voice MP, video MP.

I'm sure there is more that could be added by a careful review of the
terms of reference.

Dale Skran
Rapporteur, Q13 WP2 SG16 ITU-T

>Can anyone get us down to another level of detail?
>Tom Taylor
>E-mail: taylor at  (internally Tom-PT Taylor)
>Tel.: +1 613 765 4167     (internally 395-4167)
>FAX: +1 613 763 7236     (internally 393-7236)

More information about the sg16-avd mailing list