Last Call On NAS Package

Tom-PT Taylor taylor at NORTELNETWORKS.COM
Wed Oct 25 10:42:52 EDT 2000


Paul & Boaz,
The supported protocol structure was defined for registering gateways at the
gatekeeper. This enabled the gateway to define which protocol it supports
and which rates - see gatewayinfo structure. In version 4 Orit has asked
have the same capability for MCU and to add supported protocols to the
mcuInfo structure. As Paul states the use of this structure was added to
other RAS calls for different reasons, to signal which protocols will be
needed for the call, mostly Fax so it can be routed through a gateway with
the right support. The voice part that Boaz mention is to specify the
capability to support non multiplexed voice (not H.320) or PSTN call on the
switched network side and not for voice only in H.323. Notice that all the
information is about protocols and rates and not about video or audio
algorithms.
I understand what Boaz is suggesting but agree with Paul that the structures
today are not supporting it. Furthermore I would claim that the initial
design requires that H.320/ H.323 gateways will be able to route at least
G.711 and H.261 CIF the mandatory codec and that is why there will be no
problem with routing the call. Fax support is not mandatory and that is why
the information is needed.
I think that the idea of the originating endpoint trying to define the call
capability will be a problem with the protocol and with the end to end
solution. The capability negotiation is there to find the optimal
communication mode.
If the gateway support H.323 and voice protocols only it means that it can
do only voice calls. So if the endpoint will request, according to the
current proposal, in the requested protocol voice and not H.320 then the
gatekeeper will not need to route it to a gateway supporting H.320.
To summarize I cannot see a need for such information.
Thanks
Roni Even


-----Original Message-----
From: Paul E. Jones [mailto:paulej at PACKETIZER.COM]
Sent: Wednesday, October 25, 2000 6:44 AM
To: ITU-SG16 at MAILBAG.INTEL.COM
Subject: Re: Video experts: Proposal to add video to
Desired/SupportedProtocols


Boaz,

I agree with such a proposal-- I need to look at the details a bit more
closely, but there is definitely a need to be able to signal at the outset
of a call what kind of resources are needed.

One of the primary reasons for this original text was so that, when a fax
call was going to be placed, we could better guarantee that we would get
routed to a gateway that supports fax.  The names of the structures and
fields were derived from already existing structures.

One thing to note is that you also need to consider capacity.  Endpoints
have the ability to report capacity.  We would need to be able to report on
what "video capacity" is available.

Also, the "SupportedProtocols" is a choice.  I would guess, though, that you
would want to include "voice" and "video" at the same time-- certainly,
H.320 and video at the same time makes sense.  In any case, we need to have
some way of logically indicating the capacity and also indicating what
resources are expected to be consumed in a call.

Paul

----- Original Message -----
From: "Boaz Michaely" <boaz.michaely at ties.itu.ch>
To: <ITU-SG16 at mailbag.cps.intel.com>
Sent: Tuesday, October 24, 2000 3:14 PM
Subject: Video experts: Proposal to add video to Desired/SupportedProtocols


> Hi all,
> I would like some feedback from the video experts for a contribution I
wish to
> make to expand SupportedProtocols, which has recently been added for use
in
> ARQ, LRQ,  SETUP, and Annex G Access Request messages. (ref: D-347 of
0200_Gen)
>
>
> "desiredProtocols - Identifies the type of protocols, in order of
preference,
> the originating endpoint desires for its call (e.g., voice or fax).  A
> resolving entity may use this field to locate an endpoint that also
supports
> the protocol, giving consideration to the order of preference."
>
> Correct me if I'm wrong, but it seems that the objective of this addition,
as
> documented in D-347 is not fully achieved, since video capabilities cannot
be
> expressed. (it also strikes me that *protocols* may not be the best
description
> of the capabilities being negotiated here.)
>
> If we were to complete the proposal, the change would probably look as
below.
> My specific question to the video experts: What should the VideoCaps
structure
> contain and how would it be used (clearly we do not intend to replace
H.245
> here). Thus, is there any good reason to conform to the structure of
VoiceCaps -
>  including the location of the '...' and the inclusion of
'SupportedPrefixes' ?
> (is it ever used ?)
>
>
> SupportedProtocols ::= CHOICE
> {
>         nonStandardData         NonStandardParameter,
>         h310                            H310Caps,
>         h320                            H320Caps,
>         h321                            H321Caps,
>         h322                            H322Caps,
>         h323                            H323Caps,
>         h324                            H324Caps,
>         voice                           VoiceCaps,
>         t120-only                       T120OnlyCaps,
>         ...,
>         nonStandardProtocol             NonStandardProtocol,
>         t38FaxAnnexbOnly                T38FaxAnnexbOnlyCaps
> ---BEGIN
>         ,
>         video                           VideoCaps
> ---END
> }
>
> VoiceCaps ::= SEQUENCE
> {
>         nonStandardData         NonStandardParameter OPTIONAL,
>         ...,
>         dataRatesSupported              SEQUENCE OF DataRate OPTIONAL,
>         supportedPrefixes               SEQUENCE OF SupportedPrefix
> }
>
> ---BEGIN
> VideoCaps ::= SEQUENCE
> {
>         nonStandardData         NonStandardParameter OPTIONAL,
>         ...,
>         dataRatesSupported              SEQUENCE OF DataRate OPTIONAL,
>         supportedPrefixes               SEQUENCE OF SupportedPrefix
> }
>
> ---END
>
>
> Boaz Michaely
> Senior System Architect, Corporate
> Comverse Network Systems
> Tel: +972 (3) 766-3844 , Mobile +972 (51) 62-58-44
> mailto:boaz.michaely at ties.itu.int
> http://people.itu.int/~michaely
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com



More information about the sg16-avd mailing list