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 size. This allows a call from a MGW with IMT trunks to talk to a MGW with PRI/T1 trunks 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 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

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)