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@PACKETIZER.COM] Sent: Wednesday, October 25, 2000 6:44 AM To: ITU-SG16@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@ties.itu.ch To: ITU-SG16@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@ties.itu.int http://people.itu.int/~michaely

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

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

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