- sg16-avd - lists.packetizer.com

Re: request APC for 'Service Zone'
by Sakae OKUBO 25 Oct '00

25 Oct '00

Dear Mr. Michaely, Mr. Baese, Mr. Segers, In response to your requests, the following APC numbers have been allocated tor your contributions. We are approaching a new millennium! APC-1990 Comverse Network Systems H.225.0 Annex G v2: support for Service Zone APC-1991 Comverse Network Systems H.225.0 v4: Enhancing SupportedProtocols to indicate video APC-1992 Siemens {to be advised} APC-1993 Siemens {to be advised} APC-1994 Siemens {to be advised} APC-1995 Lucent Technologies Issues for H.248 implementors' guide Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Sanity check on Packet Sizes....
by Rosen, Brian 25 Oct '00

25 Oct '00

There is the "real" answer, and the practical answer. The real answer is that depending on what kind of network you are on, you could see, in theory, packets of up to 64K bytes. 4K bytes can actually be seen in some Gig-E systems. Whether you will find a video codec using such large packets sizes or not is uncertain; I've never seen one. It used to be that we thought 1510-odd bytes was the biggest practical packet you see on a LAN, but that's no longer the case. There is a lot of code around that fails above that 1500 ish number. Brian > -----Original Message----- > From: Chris Farmer [mailto:cfarmer@smithmicro.com] > Sent: Wednesday, October 25, 2000 9:05 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Sanity check on Packet Sizes.... > > > Okay, > > I was researching an arcane fact on the theoretical and > practical sizes for > RTP packet sizes for > video conferencing. > > What I have come up with is: > There is specific RFC's about implimenting H.263, H.261, > G.723, but I'm > looking for just an overall > practical size to check input buffer sizes. > > RFC 1889 RTP packet structure referes to 768, RFC 791 > RFC 768 UDP refers to obsolete RFC 760. > RFC 791 states in the Glossory, > ARPANET messages max size is about 1012 octets (8096)bits. > ARPANET packet max size is about 126 octets (1008) bits. > > As a client side EP, should I be concerned about the ARPANET > message size or > the ARPANET packet size? > > RFC 760 states: > 65,536 octets theoretically, put not practical > Page 22, every destination should be able to > receive a datagram > of 576 octets in one piece or as fragments to be reassembled > > so my guess here is 4608 bits max? Or is this too low level > and there is > another RFC that I should reference? > > Any help in this direction? > > Thanks, > > > Christopher B. Farmer > Software Engineer > Smith Micro Software, Inc. > (503) 641-1221 ext 28 > ====================================================================== > Daily C\C++ Tidbits at www.EngageUs.com\c > "Challenges in life are inevitable. Failure is optional" - > Roger Crawford > ====================================================================== > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Sanity check on Packet Sizes....
by Chris Farmer 25 Oct '00

25 Oct '00

Okay, I was researching an arcane fact on the theoretical and practical sizes for RTP packet sizes for video conferencing. What I have come up with is: There is specific RFC's about implimenting H.263, H.261, G.723, but I'm looking for just an overall practical size to check input buffer sizes. RFC 1889 RTP packet structure referes to 768, RFC 791 RFC 768 UDP refers to obsolete RFC 760. RFC 791 states in the Glossory, ARPANET messages max size is about 1012 octets (8096)bits. ARPANET packet max size is about 126 octets (1008) bits. As a client side EP, should I be concerned about the ARPANET message size or the ARPANET packet size? RFC 760 states: 65,536 octets theoretically, put not practical Page 22, every destination should be able to receive a datagram of 576 octets in one piece or as fragments to be reassembled so my guess here is 4608 bits max? Or is this too low level and there is another RFC that I should reference? Any help in this direction? Thanks, Christopher B. Farmer Software Engineer Smith Micro Software, Inc. (503) 641-1221 ext 28 ====================================================================== Daily C\C++ Tidbits at www.EngageUs.com\c "Challenges in life are inevitable. Failure is optional" - Roger Crawford ====================================================================== ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.323V4 error (prior message mistitled)
by Wuerfel, Randy P 25 Oct '00

25 Oct '00

(THIS IS A REPEAT MESSAGE, THE FIRST HAD THE WRONG SUBJECT) In reading H.323V4 (from APC-1874), I noticed in the procedures of section 10.4.3 (tunneling of a signalling protocol in H.225.0 call signalling messages) a reference to a tunnelledRequired flag, which doesn't exist. Can the following change be made to H.323V4, or at least captured in the Implementers Guide (assuming this error has not already been corrected)? Section 10.4.3, second paragraph: If an endpoint will only allow the call to proceed if tunneling is supported, it shall set the tunnellingRequired flag in the Setup message; the tunnelledRequired (DELETE) tunnellingRequired (REPLACEMENT) flag shall not be included in any other message than Setup. If an endpoint receives a tunnelledSignallingMessage with the tunnellingRequired flag set in the Setup message and is not able to tunnel the protocol, it shall terminate the call by sending a Release Complete with a reason of tunnelledSignallingRejected; a tunnellingRequired flag in any other message than Setup shall be ignored. Regards, Randy Wuerfel ========================================================== Siemens Information and Broadband, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: PictureTel contributions uploaded
by Wuerfel, Randy P 25 Oct '00

25 Oct '00

In reading H.323V4 (from APC-1874), I noticed in the procedures of section 10.4.3 (tunneling of a signalling protocol in H.225.0 call signalling messages) a reference to a tunnelledRequired flag, which doesn't exist. Can the following change be made to H.323V4, or at least captured in the Implementers Guide (assuming this error has not already been corrected)? Section 10.4.3, second paragraph: If an endpoint will only allow the call to proceed if tunneling is supported, it shall set the tunnellingRequired flag in the Setup message; the tunnelledRequired tunnellingRequired flag shall not be included in any other message than Setup. If an endpoint receives a tunnelledSignallingMessage with the tunnellingRequired flag set in the Setup message and is not able to tunnel the protocol, it shall terminate the call by sending a Release Complete with a reason of tunnelledSignallingRejected; a tunnellingRequired flag in any other message than Setup shall be ignored. Regards, Randy Wuerfel Randy Wuerfel Siemens Enterprise Networks 4900 Old Ironsides Drive Fax: (408) 492-4666 M/S 200 Tel: (408) 492-4375 P.O. Box 58075 E-mail: Randy.P.Wuerfel(a)icn.siemens.com Santa Clara, CA 95052-8075 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

PictureTel contributions uploaded
by Patrick_Luthi＠PICTEL.COM 25 Oct '00

25 Oct '00

Dear experts, The following contributions have been uploaded to the AVC-site/incoming: APC-1988 PictureTel RTP Payload Types in H.245 APC-1989 PictureTel Proposed New H.245 messages for H.263++ Annex U and Annex W.6.3.12 See you in Geneva! Patrick Luthi PictureTel Corp. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Last Call On NAS Package
by Tom-PT Taylor 25 Oct '00

25 Oct '00

There have been no comments on draft-ietf-megaco-naspkg-01.txt. I am therefore submitting it to WG Last Call, expiring Nov. 8/00. I think our intention is that this be a Standards Track item, so speak up if you disagree. Tom Taylor

1 0

Re: Video experts: Proposal to add video to Desired/SupportedProt ocols
by Roni Even 25 Oct '00

25 Oct '00

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(a)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(a)ties.itu.ch> To: <ITU-SG16(a)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(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AW: ASN.1 question on supporting Redirecting Number in Annex G
by Horvath Ernst 25 Oct '00

25 Oct '00

Mr. Michaely, the transport of information elements in their SCN encoded form is also foreseen in H.450 protocols. For this purpose H.450.1 defines the "generic" type H225InformationElement, which is a simple OCTET STRING. Within the octet string, any number of concatenated information elements can be embedded. The idea is that the whole string can be handed over unchanged to the Q.931 parsing process. Ernst Horvath > -----Ursprüngliche Nachricht----- > Von: Logan Modahala [mailto:lmodahal@cisco.com] > Gesendet am: Dienstag, 24. Oktober 2000 22:15 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: Re: ASN.1 question on supporting Redirecting Number > in Annex G > > Mr. Michaely: > > We can define something like this: > > ieInfo IEInfoType OPTIONAL > > IEInfoType ::= SEQUENCE > { > ieID INTEGER (1..255), > ieContent OCTET STRING > ..... > } > > > ieID will identify ProgIndIE, RedirectIE and so forth based > on the IE Id assigned > in PSTN world. > ieContent is the actual encoding of the IE as per the Q.931 spec. > > - Logan > > > > Boaz Michaely wrote: > > > All, > > > > Following up the work started at Lovely Portland, we are > investigating the > > required additions to the AccessRequest et. al. messages of > H.225.0 Annex G. > > I will post a seperate note on that, but along the way, an > interesting question > > poped: > > > > The scenario: A VoIP network that is trying to terminate a > call in PSTN, over > > ISDN. The response from the CO indicates the call diversion > and includes the > > redirecting number element (which also indicates the > diversion reason) > > With H.225.0 v4 addition (TD-45 Osaka), this information > can be naturaly > > translated into H.225.0 setup message, while before that > the only way to convey > > the information was to translate it into H.450.3 > > Now, the network GK wishes to forward the call to the > Service Zone for call > > completion. In order to provide this information over > AccessRequest, we may add > > both H.450 element as well as RedirectingNumber element > (for the questionable > > sake of not mandating H.450 structures to do so). > > > > Now to my question: > > Assuming that indeed there is objection to mandate H.450 > structure for this > > purpose, how does one describe the RedirectingNumber IE > within the ASN.1 > > structure of H.225.0 Annex G ? > > After all, RedirectingNumber is imported from Q.931, and as > such is bitwise > > encoded. (there is probably a proper term for that which, > in my ignorance, I > > am unaware off - sorry). > > I have not seen any similar case, so the only solution I > came up with is to > > embed it in a BIT STRING. Is this realy how it should be > done ? If so, what > > would the exact syntax be ? > > > > Thanks, > > > > 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(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Video experts: Proposal to add video to Desired/SupportedProtocols
by Boaz Michaely 25 Oct '00

25 Oct '00

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(a)mailbag.intel.com

2 1

Re: APC numbers for Geneva
by Sakae OKUBO 24 Oct '00

24 Oct '00

Dear Mr. Fortinsky, Mr. Audet, Mr. Luthi, In response to your requests, the following APC numbers have been allocated to your contributions: APC-1984 Editor (M Fortinsky) H.225.0 Annex G version 2 APC-1985 VocalTec Communications H.225.0 Annex G Profile Negotiation APC-1986 VocalTec Communications Clarifications Related to H.225.0 Annex G Service ID's APC-1987 Editor (F Audet) H.323 Annex M.1 - QSIG tunnelling APC-1988 PictureTel RTP Payload Types in H.245 APC-1989 PictureTel Proposed New H.245 messages for H.263++ Annex U and Annex W.6.3.12 Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

ASN.1 question on supporting Redirecting Number in Annex G
by Boaz Michaely 24 Oct '00

24 Oct '00

All, Following up the work started at Lovely Portland, we are investigating the required additions to the AccessRequest et. al. messages of H.225.0 Annex G. I will post a seperate note on that, but along the way, an interesting question poped: The scenario: A VoIP network that is trying to terminate a call in PSTN, over ISDN. The response from the CO indicates the call diversion and includes the redirecting number element (which also indicates the diversion reason) With H.225.0 v4 addition (TD-45 Osaka), this information can be naturaly translated into H.225.0 setup message, while before that the only way to convey the information was to translate it into H.450.3 Now, the network GK wishes to forward the call to the Service Zone for call completion. In order to provide this information over AccessRequest, we may add both H.450 element as well as RedirectingNumber element (for the questionable sake of not mandating H.450 structures to do so). Now to my question: Assuming that indeed there is objection to mandate H.450 structure for this purpose, how does one describe the RedirectingNumber IE within the ASN.1 structure of H.225.0 Annex G ? After all, RedirectingNumber is imported from Q.931, and as such is bitwise encoded. (there is probably a proper term for that which, in my ignorance, I am unaware off - sorry). I have not seen any similar case, so the only solution I came up with is to embed it in a BIT STRING. Is this realy how it should be done ? If so, what would the exact syntax be ? Thanks, 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(a)mailbag.intel.com

2 1

List of registered documents for the 9-10 November meeting
by Sakae OKUBO 24 Oct '00

24 Oct '00

1 0

Re: APC number request for Nov Rapp Meeting
by Sakae OKUBO 24 Oct '00

24 Oct '00

1 0

Re: APC numbers for November meeting
by Sakae OKUBO 23 Oct '00

23 Oct '00

Dear Mr. Callaghan and Mr. Roy, In response to your requests, the following APC numbers have been allocated to your contributions: APC-1974 Editor (R Callaghan) H.450.12 - Common Information Additional Network Feature for H.323 APC-1975 Editor (R Callaghan) H.323 Annex M.3 - Tunneling DSS1 in H.323 APC-1976 Siemens H.323 Annex M.3 - Tunneling DSS1 in H.323 - Architecture APC-1977 Siemens Deficiencies of H.225.0 for a native transport of DSS1 APC-1978 AT&T Mobility Architecture and Protocol: H.323 Application Specific and Generic Value Added Services APC-1979 AT&T Application Layer QOS Signalling Architecture and Protocol: H.323 Application Specific and Generic Value Added Services APC-1980 AT&T Common Value Added Intelligent Backend Services (BES) Protocols for all Applications Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility:] Reservation of MD-107 and MD-108 & upload o f MD -100
by Roy, Radhika R, ALCOO 23 Oct '00

23 Oct '00

Hi, Jaakko: Let us keep one thing in mind that 3GPP cases are only a part of the overall H.323 mobility. That is, high-speed mobile wireless environments like wireless LANs, indoor Pico- and micro-cells, and others are NOT covered by 3GPP architectures. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Thursday, October 19, 2000 4:14 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: [H.323 Mobility:] Reservation of MD-107 and MD-108 & upload of MD -100 Hi all, I reserve the MD-numbers: MD-107 and MD-108 for myself. The contributions are: MD-107 "3Gfication of H.323 Annex H Terms and Definitions" MD-108 "Comparison of 3GPP R'00 (v4) and H.323 Annex H Architectures". I will upload these contributions to the server probably next week. I will also upload MD-100 "List of MDs", containing the list of currently reserved MD-numbers to the Mobility-AHG folder in the incoming directory of the pictel ftp-site. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AW: test conditions provided
by Baese Gero 23 Oct '00

23 Oct '00

Dear experts and Mr. Li, thank you for your suggestions to further improve the testing conditions. > (1) Video codec > Profile 3 - H.263v2 Interactive and Streaming Wireless Profile > Profile 4 - H.263v3 Interactive and Streaming Wireless Profile It makes a lot of sense to incorporate both of the wireless profiles. There is no problem to remove Annex O from the list as well. > (2) Lower layer testing condition If you read the test conditions carefully you will see we nowhere propose to implement the whole protocol stack. Instead we are using a model with two parameters to keep it uncomplex but realistic. These two parameters are the loss rate of the radio frame and the length of it. Acting on our suggestion makes it easy to generate comparable results quickly. Furthermore, the situation is not as simple as you depicted it. It is not sufficient to only use the frame loss rate p because there is a strong dependency on the length as well. Therefore we proposed the described model. Again, everybody interested in this work is requested to contribute with questions, comments and suggestions. Best Wishes Gero Baese ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H248 Implementors' Guide Draft v3
by Christian Groves 23 Oct '00

23 Oct '00

G'Day all, Attached is a copy of the H.248 Implementors' Guide v3. It "hopefully" contains the corrections and clarifications that have been discussed on the Megaco mailing list until the 19/10/2000. If anything is missed or erroneous please let me (and the list) know. The file will also be upload to the pictel server: ftp://standard.pictel.com/avc-site/incoming/H248_Implementors_Guide_v3.zip Both PDF and Word versions are available. My intention is to make one more update (v4) before sending to the Nov Sg16 meeting for approval. Cheers, Christian PS: Please forgive me sending a 98k file to the list but the Pictel server has been down.

2 3

Re: [H225 Annex G] When to create a new service ID
by Michael Fortinsky 22 Oct '00

22 Oct '00

Paul, Maybe I don't understand your point - I am not sure what you mean when you say "a new ServiceRequest". (I think this is the heart of the matter - what determines what is a NEW ServiceRequest?) New service ID's are allocated and returned in the ServiceConfirmation message, not in the ServiceRequest message. Therefore, it is up to the border element that receives the ServiceRequest message to decide whether to allocate a new service ID or not. The question still remains - how are "keepAlive" ServiceRequests to be treated? Another way of looking at the issue is as follows (maybe this is clearer): If a BE sends a ServiceRequest message that does NOT contain a serviceID field, a new service ID is returned in the ServiceConfirmation message and a new service relationship is defined. If a BE sends a ServiceRequest message that DOES contains a serviceID field, the BE that received the ServiceRequest must determine whether to return the same serviceID or a new one (ie, is there going to be a new service relationship or not) - if the service parameters in the ServiceRequest are the same as those in the existing service relationship, this ServiceRequest message is a refresh of the existing service relationship and the ServiceConfirmation is returned with the same service ID as was in the ServiceRequest - if the service parameters are different, then: - if the BE want to accept the new parameters, it sends a ServiceConfirmation that contains a NEW serviceID - this also indicates that the previous service relationship has ended - if the BE does not want to accept the new parameters, it sends a ServiceRejection (that contains the serviceID from the ServiceRequest message) indicating that the new terms are rejected - the old service relationship is still in effect according to the old service parameters (as per section 1.8.2.7/H.225 Annex G) Comments? Mike "Paul E. Jones" <paulej(a)packetizer.com> 10/22/00 04:02 AM To: <Michael_Fortinsky(a)VOCALTEC.COM>, <ITU-SG16(a)mailbag.cps.intel.com>, <h323implementors(a)imtc.org>, <h323implementors(a)pulver.com> cc: Subject: Re: [H225 Annex G] When to create a new service ID Michael, My opinion is that, given that there is a ServiceRequest and a ServiceRelease and that one can initiate a new service relationship before terminating a previous service relationship, a new service ID shall be introduced with a ServiceRequest message and a BE should not send a new ServiceRequest with the same ID without first releasing the previous relationship. I believe that's in alignment with your interpretation. Paul ----- Original Message ----- From: Michael_Fortinsky(a)VOCALTEC.COM To: ITU-SG16(a)mailbag.cps.intel.com ; h323implementors(a)imtc.org ; h323implementors(a)pulver.com Sent: Wednesday, October 18, 2000 5:40 AM Subject: [H225 Annex G] When to create a new service ID I would like to hear people's interpretation of when a new service ID should be created in H.225.0 Annex G. (A service ID is used to identify a service relationship between two border elements). There are three cases to consider: Case #1: - a BE (border element) receives a ServiceRequest message from a BE with which it does not yet have a service relationship Case #2: - a BE receives a ServiceRequest message from a BE with which it already does have a service relationship, but the terms of the service relationship are to be changed (eg, different security parameters) Case #3: - a BE receives a ServiceRequest message from a BE with which it already does have a service relationship (ie, this ServiceRequest is refreshing the service relationship), and the terms of the service relationship are identical to the previous terms (eg, same security parameters) My impression is that the following should happen in each case: Case #1 - create a new serviceID in the ServiceConfirmation Case #2 - create a new serviceID because we are changing the parameters of the service relationship (it's becoming a new service relationship) Case #3 - do NOT create a new serviceID - the existing relationship is being refreshed, so we should continue to use the same serviceID However, the wording of H.225.0 Annex G does not seem to say this. It seems that in ALL cases, a new serviceID should be created. To me, this seems to be incorrect, and I'm not sure that the original intent took into account case #3. I think that in case #3, we should not be creating a new service ID. The following sections from H.225.0 Annex G are relevant: [from section 1.8.2] service ID - This identifer identifies a particular service relationship session between two border elements. Whenever a border element receives a ServiceRequest message, it allocates a globally unique service ID and returns it to the sender of the ServiceRequest message in the ServiceConfirm message. [from section 1.8.2.5] A border element may send a ServiceRequest message to a border element with which it has an existing relationship, with the intent that the terms of the original relationship be terminated and replaced with the new terms. Service relationships may have limited time to live. A border element may refresh the relationship by sending a new Service Request. [from section 1.8.2.6] Every new service relationship is identified by a service identifier. Whenever a border element receives a new ServiceRequest message, it allocates a unique service ID and returns it to the sender of the service request message in the "service confirm" message. If the border element already has a service relationship with the border element that sent the ServiceRequest message, sending ServiceConfirmation indicates that the terms of the original relationship are terminated and replaced with the new terms. Any comments? If people agree that the wording needs to be changed to unambiguously handle case #3, now is the time to speak up. The deadline for contributions for the Geneva meeting is fast approaching. Michael Fortinsky ----------------------------------------------------------------- Senior Program Manager, IP Telephony Group, VocalTec Communications Ltd. Email: mike(a)vocaltec.com Tel: 972 9 9707768 Fax: 972 9 9561867

2 1

Re: Rapporteur meeting on 9-10 November in Geneva
by Sakae OKUBO 22 Oct '00

22 Oct '00

Dear Mr. Jones, In response to your requests, the following APC numbers have been allocated to your five contributions: APC-1969 Editor (P Jones) Editorial and Technical Corrections to H.323v4 APC-1970 Cisco Systems Signalling of ingress and egress Carrier/Circuit Identifier information in H.225.0 Messages and Annex G Messages APC-1971 Cisco Systems Third Party Re-routing of a Fast Connect Initiated Call APC-1972 Cisco Systems Ported Number Indications in H.225.0 messages APC-1973 Cisco Systems Reserving Resources for Calls Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Error in H.323v3 ASN.1
by Paul E. Jones 22 Oct '00

22 Oct '00

XuPeili and other H.323 Developers, This does appear to be in error. Unfortunately, this was published this way in the H.225.0v3 Recommendation. However, you are correct that a previous H.323v2 Implementers Guide was published which contained the aliasesInconsistent field. So, we have an issue to contend with. I must ask the developer community-- I do not want to make this change without wide support for making such a change. Since the Version 2 field was added via the Implementers Guide, it is entirely possible that H.323v2 vendors did not even include it in their ASN.1 So, I need to hear from all of the developers on this issue. This may have been addressed, but I don't have notes on this matter. A similar issue with the LocationRejectReason was found and I corrected that back in June when discussing with everybody that "I would never change the ASN.1 and more". Well, unfortunately, it appears that we have one last error-- honestly, I'm quite shocked this one slipped through. So... should the "aliasesInconsistent" field be moved above the "routeCallToSCN" element in the AdmissionRejectReason sequence as shown in an earlier H.323v2 Implementers Guide? Please post and debate this publicly. We need to resolve this matter quickly so as to minimize impact on everybody. Best Regards, Paul ----- Original Message ----- From: "XuPeili" <xupeili(a)huawei.com> To: "Paul E. Jones" <paulej(a)packetizer.com> Cc: <h323implementors(a)imtc.org> Sent: Tuesday, October 03, 2000 9:42 PM Subject: ;X84: Multiple Call Proceedings in a H.323 call > hi Paul, > > In the H225.0v3.asn downloaded form www.packetizer.com > the ARJ is specified like this > > AdmissionRejectReason ::= CHOICE > { > calledPartyNotRegistered NULL, -- cannot translate address > invalidPermission NULL, -- permission has expired > requestDenied NULL, -- no bandwidth available > undefinedReason NULL, > callerNotRegistered NULL, > routeCallToGatekeeper NULL, > invalidEndpointIdentifier NULL, > resourceUnavailable NULL, > ..., > securityDenial NULL, > qosControlNotSupported NULL, > incompleteAddress NULL, > routeCallToSCN SEQUENCE OF PartyNumber, > aliasesInconsistent NULL -- multiple aliases in request identify distinct > people > } > > Since the routeCallToSCN is a new choice in H.225.0v3, I think it should be > placed > after the aliasesInconsistent choice which is already exist in v2. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

7 17

[H225 Annex G] When to create a new service ID
by Michael Fortinsky 21 Oct '00

21 Oct '00

I would like to hear people's interpretation of when a new service ID should be created in H.225.0 Annex G. (A service ID is used to identify a service relationship between two border elements). There are three cases to consider: Case #1: - a BE (border element) receives a ServiceRequest message from a BE with which it does not yet have a service relationship Case #2: - a BE receives a ServiceRequest message from a BE with which it already does have a service relationship, but the terms of the service relationship are to be changed (eg, different security parameters) Case #3: - a BE receives a ServiceRequest message from a BE with which it already does have a service relationship (ie, this ServiceRequest is refreshing the service relationship), and the terms of the service relationship are identical to the previous terms (eg, same security parameters) My impression is that the following should happen in each case: Case #1 - create a new serviceID in the ServiceConfirmation Case #2 - create a new serviceID because we are changing the parameters of the service relationship (it's becoming a new service relationship) Case #3 - do NOT create a new serviceID - the existing relationship is being refreshed, so we should continue to use the same serviceID However, the wording of H.225.0 Annex G does not seem to say this. It seems that in ALL cases, a new serviceID should be created. To me, this seems to be incorrect, and I'm not sure that the original intent took into account case #3. I think that in case #3, we should not be creating a new service ID. The following sections from H.225.0 Annex G are relevant: [from section 1.8.2] service ID - This identifer identifies a particular service relationship session between two border elements. Whenever a border element receives a ServiceRequest message, it allocates a globally unique service ID and returns it to the sender of the ServiceRequest message in the ServiceConfirm message. [from section 1.8.2.5] A border element may send a ServiceRequest message to a border element with which it has an existing relationship, with the intent that the terms of the original relationship be terminated and replaced with the new terms. Service relationships may have limited time to live. A border element may refresh the relationship by sending a new Service Request. [from section 1.8.2.6] Every new service relationship is identified by a service identifier. Whenever a border element receives a new ServiceRequest message, it allocates a unique service ID and returns it to the sender of the service request message in the "service confirm" message. If the border element already has a service relationship with the border element that sent the ServiceRequest message, sending ServiceConfirmation indicates that the terms of the original relationship are terminated and replaced with the new terms. Any comments? If people agree that the wording needs to be changed to unambiguously handle case #3, now is the time to speak up. The deadline for contributions for the Geneva meeting is fast approaching. Michael Fortinsky ----------------------------------------------------------------- Senior Program Manager, IP Telephony Group, VocalTec Communications Ltd. Email: mike(a)vocaltec.com Tel: 972 9 9707768 Fax: 972 9 9561867

2 1

Re: Request for APC numbers
by Sakae OKUBO 20 Oct '00

20 Oct '00

Dear Mr. Euchner, Dear Mr. Anderson, In response to your requests, the following APC numbers have been allocated to your contributions: At 09:09 +0200 00/10/20, Euchner Martin wrote: >The following block of contributions relate to corrections of the H.235 >Version 2 white text for decision: APC-1961 >Source Title >Editor Resolution of an inconsistency in Draft H.235 Version 2 >regarding Section B.4.3 APC-1962 >Editor Resolution of an inconsistency in Draft H.235 Version 2 >regarding the use of the password and shared secret APC-1963 >Editor Clarification on the use of sendersID and generalID in >white Draft H.235 Version 2 APC-1964 >Editor REVISED ITU-T RECOMMENDATION H.235 VERSION 2 - SECURITY AND >ENCRYPTION FOR H-SERIES (H.323 AND OTHER H.245-BASED) MULTIMEDIA TERMINALS >- CORRECTED VERSION FOR DECISION >The following block of contributions relate to the new H.235 Version 3: APC-1965 >Source Title >Editor Draft H.235 Version 3 - Security and encryption for >H-Series (H.323 and other H.245-based) multimedia terminals APC-1966 >Editor Draft H.235v3 Annex F: "Hybrid Security Profile" APC-1967 >Editor Draft H.235v3 Annex G: "Security for H.323 Annex H in H.323 >Mobile Environments" At 14:53 -0400 00/10/20, Terry L Anderson wrote: >Please assign me an APC number for APC-1968 >Title: Draft H323 Annex R. >Source: Editor Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: QOS signaling in RAS
by Roy, Radhika R, ALCOO 20 Oct '00

20 Oct '00

Hi, Ilyya and Mike: Please see H.323 Appendix II - Transport Level Resource Reservation Procedure. The "transportQOS" field simply provides a mechanism who "controls" the transport level resource reservation: Endpoint or GK. Accordingly, the resource reservation is made by that particular entity. Then each entity can use couple of things related to the resource reservation: 1. BRQ/BCF/BRJ and 2. RSVP (plus ATM QOS for the ATM network as well). Now, items 1 and 2 are independent. Item 1 is in RAS (pre-call setup phase) and item 2 is in H.245 (call setup phase). Here is my own interpretation: Item 1 has the abstraction of bandwidth (generic) that can be used on end-to-end basis. That is, this abstraction is independent of the lower transport network. In other words, the total bandwidth that is required for the H.323 application (audio, video, and data) is expressed in the bandwidth field. However, item 2 is network specific. If there is a single network (either IP or ATM), it may work. If there are two networks (IP + ATM) between the two H.323 endpoints, we have problems to use either RSVP or ATM QOS on end-to-end basis. In addition, H.323 also provides the abstraction of "circuits: DS0s, etc. (indirectly bandwidth)" in the context of the PSTN-Packet network in Q.931 call setup phase. H.323 Annex N is addressing this problem to provide end-to-end QOS not only for the bandwidth parameter, but for all other parameters including delay, jitter, bit-error-rate/packet losses for both: 1. Pre-call setup phase (RAS) and 2. Call setup phase (Q.931/H.245). AT&T is bringing a contribution related to QOS in the upcoming SG16 November'00 meeting. Best regards, Radhika R. Roy AT&T +1 732 420 1580 -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Friday, October 20, 2000 6:16 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: QOS singaling in RAS Ilya, We are presently reviewing QoS support in H.323 and a new Annex N to H.323 is in preparation. The current H.323 assumes homogeneity of network transport and QoS mechanisms so the only issues to be considered in H.323 are what type if QoS mechanism is supported in the end point. The new work recognises that transport may involve a variety of transport mechanisms e.g. ATM, IP FR, as well as QoS mechanism, e.g. RSVP, DiffServ, MPLS, some of which may be hidden from the end user. Maybe other experts could comment on your specific query. Regards, Mike Buckley Editor Annex N +44-1457-877718 (T) +44-1457-877721 (F) mikebuckley(a)44comms.com ----- Original Message ----- From: "Ilya Freytsis" <ifreytsis(a)CETACEANNETWORKS.COM> To: <ITU-SG16(a)MAILBAG.INTEL.COM> Sent: Thursday, October 19, 2000 7:46 PM Subject: QOS singaling in RAS > Dear experts, > One of the choices of the RegistrationRejectReason (h225 v3) is > "transportQOSNotSupported NULL, -- endpoint QOS not supported". How it should be interpreted since it seems there is nothing > related to transport QOS in registration request PDU itself? > > Ilya Freytsis > Cetacean Networks > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

QOS singaling in RAS
by Ilya Freytsis 20 Oct '00

20 Oct '00

Dear experts, One of the choices of the RegistrationRejectReason (h225 v3) is "transportQOSNotSupported NULL, -- endpoint QOS not supported". How it should be interpreted since it seems there is nothing related to transport QOS in registration request PDU itself? Ilya Freytsis Cetacean Networks ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1