Gateway Decomposition Requirements

[Tom-PT Taylor]

Thanks for getting this started.  I have some discussion points for further
clarification.

> -----Original Message-----
> From: Dale L. Skran [SMTP:dskran at ASCEND.COM]
> Sent: Saturday, November 21, 1998 7:28 PM
> To:   ITU-SG16 at 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 at nortelnetworks.com  (internally Tom-PT Taylor)
> >Tel.: +1 613 765 4167     (internally 395-4167)
> >FAX: +1 613 763 7236     (internally 393-7236)
> >