Thanks for getting this started. I have some discussion points for further
clarification.
-----Original Message-----
From: Dale L. Skran [SMTP:dskran@ASCEND.COM]
Sent: Saturday, November 21, 1998 7:28 PM
To: ITU-SG16@MAILBAG.INTEL.COM
Subject: Re: Gateway Decomposition Requirements
[Taylor, Tom [CAR:B318-I:EXCH]] [snip]
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.
[Taylor, Tom [CAR:B318-I:EXCH]]
Aside from its call by call operation, it seems to me that the chief
requirement on B, C, and D is encapsulation of signalling protocol elements.
This suggests you have to have stuff like call identifiers, endpoint
identifiers, protocol identifiers, and provision for shipping across large
blocks of opaque data. I'm not sure that is logically linked with the
device control stuff (interface A). Could we come up with sample message
flows that demonstrate an increase in efficiency through use of a common
[Taylor, Tom [CAR:B318-I:EXCH]] The one misgiving I had when
documenting the "H.323 Endpoint Type" in IPDC was that the SETUP message
contains a lot more than we provided for, and in fact IPDC probably was
broken for GW to GW operation (because of missing address information). In
effect, the requirement is that interface B should pass all of the relevant
contents of the SETUP message. Some things such as the CRV can obviously be
left to the Media Gateway to handle.
protocol?
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.
[Taylor, Tom [CAR:B318-I:EXCH]]
This seems to be a pretty good consensus on this for trunk
signalling, except that apparently some R2 information has to be carried
some other way. Our terms of reference don't cover line-side signalling.
P.S. I thought the Ascend/Bay RSGP was intended for the D interface.
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
size.
This allows a call from a MGW with IMT trunks to talk to a MGW with PRI/T1
trunks
under SS7 control.
[Taylor, Tom [CAR:B318-I:EXCH]]
Implications for interface C?
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
probably
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,
and
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
[Taylor, Tom [CAR:B318-I:EXCH]]
This can be argued two ways. If it's there, then as you suggest
below we are looking at H.245. Alternatively caps could be set by other
means (i.e. configuration). We're talking about boot-up messaging here, not
per-call operation.
As noted at the meeting, you need to reflect the terms of reference in the
A
requirements.
A couple of obvious ones:
A Interface
1)Must include video/data (i.e. consider the possibility of incoming
H.320/H.324
calls).
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
elemental
function.
4)Must be suitable for connecting an MC (MultiPoint Controller) to an MP
(Media
Processer) as defined in H.323. This implies a need for elemental
conferencing
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@nortelnetworks.com (internally Tom-PT Taylor)
Tel.: +1 613 765 4167 (internally 395-4167)
FAX: +1 613 763 7236 (internally 393-7236)