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