- sg16-avd - lists.packetizer.com

[H.323 Mobility:] Update to Service Definitions for Annex H
by Roelands Marc 20 Jul '00

20 Jul '00

Hi all, I uploaded the updated version of MD-102 to ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/MD-102a_ServiceDefi nitions.zip . (it contains change bars to mark the added text) Regards, Marc Roelands Siemens ICN Dept. NC SD Atealaan 34 B-2200 Herentals Belgium Tel.: +32 14253965 Fax: +32 14222994 E-mail: marc.roelands(a)siemens.atea.be ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.323v4 and Annex D
by Francois Audet 19 Jul '00

19 Jul '00

Francois, The bi-directional TCP support was added during the last Geneva meeting. No issues were raised in Osaka. If there are issues with it, hopefully people will find them before November! We could specify that H.323 use H.245v7-- I do not see any reason why we should not consider that option. The only reason that I did not increase the revision number is that Annex D may be implemented optionally. If somebody chooses to implement H.323v4 without Annex D support, there is nothing they would need from H.245v7. I have no problem with mandating v7 for H.323v4. It is a small editorial change: a "7" instead of a "6" ;^) However, it really makes no difference at all to me. I'll be agreeable with whatever the experts believes makes the most sense. Me too.

1 0

H.323v4 and Annex D
by Francois Audet 19 Jul '00

19 Jul '00

Hi all, H.323v4 Annex D refers to an H.245 codepoint (t38FaxTcpOptions) that is only present in H.245v7 and not in H.246v6. How do we fix this? I think it is too late to fix H.245v6 isn't it? The alternatives would be: * Require H.245v7 for H.323v4, instead fo H.245v6 * Pull out Annex D of H.323 and make it require a different version of H.245. (Extremely bad idea since the Annex has a lot of other useful material) * Pull out the bidirectional TCP thing we added on-the-spot at the last meeting. At least until the next revision. Any views? Am I missing something? Also, there is a reference to something called t38Capability in Annex D: it should be t38Fax. (This is editorial). ----- François Audet Tel:+1 408 565 5675 <mailto:audet@NortelNetworks.com> mailto:audet@NortelNetworks.com Nortel Networks Fax:+1 408 565 2375 <http://www.nortelnetworks.com/> http://www.NortelNetworks.com

2 1

Re: [H.323 Mobility:] Service Definitions for Annex H
by Roy, Radhika R, ALCOO 19 Jul '00

19 Jul '00

Hi, Everyone: Further along the line of service definitions, I like to draw your attention related to AT&T contributions submitted (D.353 and D.354) in the last February'00 (Geneva) meeting. We can also discuss some of the definitions provided there along with Siemens's and Intel's contributions. In this connection, I am enclosing the copy of D.353 only. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Roelands Marc [mailto:Marc.Roelands@SIEMENS.ATEA.BE] Sent: Wednesday, July 19, 2000 3:37 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: [H.323 Mobility:] Service Definitions for Annex H Hi all, I have just uploaded MD-102 on Service Definitions for discussion, at ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/MD-102_ServiceDefin itions.zip . It is the first part of several Siemens/Intel inputs for the new chapter 5 for which input was requested in Osaka. I hope to send an updated/extended version still in a few days (i.e. before my holidays). (Since it is only a 19K file, I attach it here too.) Regards, Marc Roelands Siemens ICN Dept. NC SD Atealaan 34 B-2200 Herentals Belgium Tel.: +32 14253965 Fax: +32 14222994 E-mail: marc.roelands(a)siemens.atea.be

1 0

[H.323 Mobility:] Service Definitions for Annex H
by Roelands Marc 19 Jul '00

19 Jul '00

Hi all, I have just uploaded MD-102 on Service Definitions for discussion, at ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/MD-102_ServiceDefin itions.zip . It is the first part of several Siemens/Intel inputs for the new chapter 5 for which input was requested in Osaka. I hope to send an updated/extended version still in a few days (i.e. before my holidays). (Since it is only a 19K file, I attach it here too.) Regards, Marc Roelands Siemens ICN Dept. NC SD Atealaan 34 B-2200 Herentals Belgium Tel.: +32 14253965 Fax: +32 14222994 E-mail: marc.roelands(a)siemens.atea.be

1 0

Re: Request for an APC number
by Sakae OKUBO 19 Jul '00

19 Jul '00

Dear Rohit Gupta, >Is it possible to register a contribution to ITU-T SG16 for non-ITU >members? I wish to register > a contribution to suggest ammendments in the H.323 standard. > > Rohit Gupta > Hughes Software Systems > India Thank you for your contribution, to which APC-1885 has been allocated. 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

APC documents
by Sakae OKUBO 18 Jul '00

18 Jul '00

Dear Dale, APC-1884 has been allocated to your contribution: >"Decomposition of Gatekeeper Functions inside a Domain" source SONUS To other experts, please note the following contribution has been registered: >APC-1883 >Source: Columbia University >Title: CPL: A Language for User Control of Internet Telephony Services 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

H.225.0 v4 white paper: ASN.1 problem
by Horvath Ernst 18 Jul '00

18 Jul '00

The following definition (added for support of mobile systems) is not correct ASN.1: TBCD-STRING ::= OCTET STRING (FROM ("0123456789#*abc")) The keyword "FROM" indicates a "permitted alphabet" constraint and can only be applied to character string types, not to OCTET STRING. A possible correct definition would be: TBCD-STRING ::= IA5String (FROM ("0123456789#*abc")) The resulting PER encoding is 4 bit per character, but the digits do not represent BCD values since # and * come first in the canonical ordering of characters, i.e. "#" is encoded as '0000', "*" as '0001', "0" as '0010', "a" as '1100', etc. Question to the mobility experts who introduced this ASN.1 type: Is this an acceptable solution? Ernst Horvath Siemens AG ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Contribution number
by Sakae OKUBO 17 Jul '00

17 Jul '00

Dear Mr. Audet, In response to your request, the following APC numbers have been allocated to your two contributions: APC-1881 Nortel Networks Enforcing symmetric operation in the context of slow start for H.323v4 APC-1882 Nortel Networks Minor correction to H.323 Annex M.1 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

Annex E Question.
by Sasha Ruditsky 17 Jul '00

17 Jul '00

> Hi > > I believe that the following paragraph from the H.323 Annex E may be > understood differently by different people: > ------- > E.2.3.5 Session field > The session field shall be present in all payloads. The Session value > shall contain the CRV from the Q.931 messages. Specifically, the call > reference flag shall be included as the most significant bit of the > CallReferenceValue. This restricts the actual CRV to the range of 0 > through 32767, inclusive. > ------- > > I think this means that the Annex E session field is different (in the > Flag bit) for Setup and Connect messages of the same call. (Exactly like > CRV is). > I agree that the alternation of the 16th bit of the Annex E session field > in the messages of the same session (call) moving in different directions > is required, > but I do not think that the described behavior is obvious from the field's > name and its description. > > If there is agreement on the fact that the messages belonging to the same > call but moving in opposite directions shall have different values of the > 16th bit of the Annex E session field, that probably we need to state > this explicitly in the E.2.3.5. I agree that this is ALMOST what is > written their, but we all know how ambiguous may be the CRV-like field > description. > > > Sasha > > *********************************************** > Alexander(Sasha) Ruditsky > RADVision Ltd. > 24 Raul Wallenberg St. > Tel Aviv 69719 Israel > > Tel: +972-3-645-5220 > Fax: +972-3-645-6464 > Direct: +972-3-645-5273 > sasha(a)radvision.rad.co.il > *********************************************** > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 2