July 2000 - sg16-avd - lists.packetizer.com

H.225 white draft
by Terry L Anderson 07 Aug '00

07 Aug '00

I am looking over the "GenericData" related fields in the ASN.1 and saw one asymmetry. Several commands (e.g., Alerting, ARQ, etc) contain featureSet FeatureSet OPTIONAL while Setup contains neededFeatures SEQUENCE OF FeatureDescriptor OPTIONAL, desiredFeatures SEQUENCE OF FeatureDescriptor OPTIONAL, supportededFeatures SEQUENCE OF FeatureDescriptor OPTIONAL, which with the exception of the replacementFeatureSet BOOLEAN is exactly the contents of FeatureSet. Is there a reason for having these separately in Setup rather than having featureSet in Setup? -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572(a)skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

3 4

Re: Notice of the Portland meeting in August 2000
by Meyer, Greg W 31 Jul '00

31 Jul '00

Q.11-14/16 Experts: This is the last week to register for the Portland meeting before the block of hotel rooms is released on August 7th. Please see the links below to download the PortlandInfoPack.zip file. Fill out the form on the last page of the document and fax it to Intel Meeting Services. Please contact me if you have any questions. Thank you, Greg Meyer Intel Corportation +1.503.264.9506 mailto:greg.w.meyer@intel.com -----Original Message----- From: Sakae OKUBO [mailto:okubo@GITI.WASEDA.AC.JP] Sent: Sunday, July 02, 2000 11:54 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Notice of the Portland meeting in August 2000 Dear Q12-14/16 experts, Please find attached the notice of the Portland meeting during 21-25 August 2000 as well as the logistic information from the host, Intel. The two files are also placed at the PictureTel ftp site: http://standard.pictel.com/ftp/avc-site/0008_Por/Notice_ITU-T_Portland.txt http://standard.pictel.com/ftp/avc-site/0008_Por/PortlandInfoPack.zip Please note that you are required to send your participation registration and hotel room reservation by 7 August 2000. 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 *********************************************************** To Experts of ITU-T SG16 Q.12/16, Q.13/16 and Q.14/16 Cc Mr. P-A. Probst, Chairman of SG16 Mr. G. Helder, Vice-Chairman of SG16 Mr. F. Tosco, Chairman of WP2/16 Mr. F. Bigi, ITU-TSB Mr. T. Geary, Rapporteur for Q.11/16 Mr. G. Sullivan, Rapporteur for Q.15/16 Mr. G. Meyer, Intel De Sakae OKUBO Rapporteur for Q.12/16 in ITU-T SG16 TAO Waseda Research Center 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 3204 8194 Fax: +81 3 5287 7287 E-mail: okubo(a)giti.or.jp Dale SKRAN Rapporteur for Q.13/16 in ITU-T SG16 Sonus Networks 4400 Route 9 South Suite 1000 Freehold, NJ 07748 USA Tel: +1 732 409 5107 Fax: +1 732 409 5172 E-mail: dskran(a)sonusnet.com Glen FREUNDLICH Rapporteur for Q.14/16 in ITU-T SG16 Lucent Technologies 11900 N. Pecos Westminster, Colorado 80234 USA Tel: +1 303 538 2899 Fax: +1 303 538 3907 E-mail: ggf(a)lucent.com ------------------------------------------------------------ Subject: Notice of Q.12-14/16 Rapporteur Meeting in Portland Date: 3 July 2000 ------------------------------------------------------------ Dear Q.12-14/16 experts, The subject meeting of ITU-T SG16 experts will be held in Portland, USA at the kind invitation of Intel Corporation. Please note that Q.11/16 and Q.15/16 will meet concurrently at the same place and have joint session(s) with Q.12-14/16. 1. Date ^^^^^^^ 21 (Monday) - 25 (Friday) August 2000 starting at 9:00 on the first day closing at 18:00 on the final day 2. Venue ^^^^^^^^ The Resort At The Mountain 68010 East Fairway Welches, OR 97067 Tel: +1-503-662-3101 (for messages) 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ 1) Review of the relevant group meetings 2) Q.12/16 B-ISDN multimedia systems and terminals - Work with Q.13 on high quality video transmission over IP - Future AV communication systems 3) Q.13/16 Packet switched multimedia systems and terminals - Toward determination in November: * H.323 Annex H (User, Service, and Terminal Mobility in H.323) * H.323 Annex I (Packet based MM Telephony over Error Prone Channels) * H.450.10 (Call Offer Supplementary Services) * H.450.11 (Call Intrusion) * H.450.12 (Common Information Additional Network) * H.225.0 Annex G V2 (Inter-domain) * H.323 Annex R (Robustness) * H.323 Annex M.3 (DSS1 Tunneling) * H.323 Annex E V2 (UDP call signaling) - Progress work for: * H.323 Annex N (QoS) * H.323 Annex O (Internet protocols and technologies complementary to H.323) * Other new items that may arise 4) Q.14/16 Common protocols, MCUs and protocols for interworking with H.300-series terminals - Toward determination in November: * H.248 Annex L * H.248 Annex M * H.235 V8 - Progress work for: * H.246 Annex D * H.248 V2 * H.341 V2 * other new items that may arise (e.g., new packages for H.248) 5) Coordination with Q.11/16 and Q.15/16 - System aspects - Video coding aspects 6) Interaction with other groups 7) Future work plan 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 23:59 UTC, 11 August /// /// Distribution of the document: by 23:59 UTC, 14 August /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify S. Okubo as soon as possible, by 23:59 UTC, Friday 11 August at the latest. Document number (APC-nnnn) will be allocated. Early indication of your submission plan is welcome and encouraged. Note - Prefix "APC" comes from Atm (Q.12/16), Packet based (Q.13/16) and Common protocols (Q.14/16) based on the coordination with Q.1 ("Q1City"), Q.3 ("T120"), Q.11 ("Q11"), Q.15 ("Q15") groups. 2) You are advised to include a header as follows: ------------------------------------------------------------------ | | | ITU Telecommunication Standardization Sector Document APC-{nnnn}| | Study Group 16 {Version m if relevant}| | Q.12-14/16 Rapporteur Meeting {Date}| | Portland, 21-25 August 2000 | | | | SOURCE*: { } | | TITLE : { } | | PURPOSE: {Proposal, Discussion, Information, Report, etc.} | | | | _________________________ | | | | | | | | *Contact: Name, e-mail | ------------------------------------------------------------------ 3) All the contributors are requested to distribute their documents as early as possible, at least 7 calendar days in advance of the meeting (23:59 UTC, Monday 14 August or before) by posting them at either of the following: - PictureTel ftp site (please advise S. Okubo of your posting) Site: standard.pictel.com/avc-site Login name: anonymous Directory: Incoming - Q.12-14/16 experts reflector e-mail address: itu-sg16(a)mailbag.intel.com Please avoid the use of reflector when your document is voluminous. 4) Input documents can be retrieved from /0008_Por directory of the ftp site. 5) The document distribution / presentation at the meeting will be all electronic. Participants must bring along their laptop, 10BASE-T card and cord, and optionally wireless LAN card (please follow the host's advice). 6) The copying service is very limited and expensive at the meeting site. 5. Logistic information ^^^^^^^^^^^^^^^^^^^^^^^ Please see the attached document provided by the meeting host (http://standard.pictel.com/ftp/avc-site/0008_Por/PortlandInfoPack.zip) 6. Registration ^^^^^^^^^^^^^^^ To register your meeting attendance, please send the attached form to the meeting secretariat by 7 August 2000: Intel Meeting Service ATTN: Valerie Nester Fax: +1 480 554 7775 AND advise Rapporteurs of your attendance by e-mail: To: okubo(a)giti.or.jp, dskran(a)sonusnet.com, ggf(a)lucent.com, tom.geary(a)conexant.com, garysull(a)microsoft.com Subject: Portland meeting registration Name: Company: Arrival: Departure: 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ Please send the attached form to the meeting secretariat together with the meeting registration. Special package room rate is $149.18 (single or double occupancy) per night including breakfast, tax and gratuity. The block reservation is held until 7 August. We are looking forward to meeting with you in Portland. Sincerely yours, Sakae OKUBO Dale SKRAN Glen FREUNDLICH ---------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

[Robustness] Minutes of the 7/20 call
by Terry L Anderson 31 Jul '00

31 Jul '00

Attendence (correct me if I missed anyone): Terry Anderson - Lucent Maureen Stillman - Nokia Sasha Ruditsky - Radvision Archana Nehru (and another?) - Trillium We discussed the 7/11 draft and the following points were made: 10.1 Detecting Failure - KeepAlive - callIdentifier should be optional - for multiplexed channels, CRV should be set to 0 and callIdentifier omitted. - the need for keepAlive in Method B may be unclear 10.2 Transport Address and ... -the new fields are not needed in Alerting and Call Proceeding. 10.3 Sychnronizing State -section is not needed. 11.3.1.4 An old TCP Connection Closure - I may have missed a point in this section. If you raised an issue here, please bring it up again. ASN.1 changes - RecoveryCallSignalPoint should be SEQUENCE OF SEQUENCE [The current white draft of H.225.0v4 has only SEQUENCE of has SEQUENCE OF RecoveryCallSignalPoint in each message so I believe we do NOT need a change] [I also want to change the name to BackupCallSignalAddress to better match our text] 11.5 - we need a similar SDL for Method B. 12 Method B: State Recovery... - clarify lack of need for KeepAlives 12.3 - detecting failure for case where backup establishes connection to a neighbor that has not yet detected failure. I also changed all instances of "Fault Tolerant Repository" to "Shared Repository" "element" or "component" to "entity" "IE" or "element" when referring to a part of the ASN.1 structure to "field" to be consistent with the language H.323 and H.225 are trying to move to. I checked our changes in the white draft of H.225.0v4 and removed all our ASN.1 that has already been incorporated. I now show only changes that are still needed. I have not yet done the similar check with H.323v4. A new draft, addressing most of the above, is available at: ftp://standard.pictel.com/avc-site/Incoming/Robustness-AHG/AnnexRdraft0720.… We will continue our discussion at our future calls: Thursday: July 27, Aug 3 11:00 EDT (15:00 UT) for 2 hr Phone: 1 888 559 7255 (calling from US) Phone: 1 908 860 0000 (calling from outside US) code: 531480 -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572(a)skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

4 7

Re: [H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H & a question about BEs
by Francois-Xavier Derome 31 Jul '00

31 Jul '00

hi all, Like the other I fully support the usage of annex G for mobility, but as I said before, It must be done without changing the current implementation. The interface between BE should not change. Here is the draft of the contribution I wanted to present in portland. This is in line with what was said. (See attached file: apcxxx.zip)

1 0

Re: [H.323 Mobility:] Update to Service Definitions for Annex H - > a question
by Roelands Marc 31 Jul '00

31 Jul '00

Hi Jaakko, Hi all, Here is an attempt to answer your question(s). As you say, the text is about requirements and so does not specify how 5.1.2 bullet 1 can be implemented. However, the text says "verification of the authenticity of the Terminal" and this is literally what is intended. So no association identifier of some sort, as you mention as a second interpretation, is directly meant. (However this might turn out to be an element for realization of this bullet.) Important however, is the fact that the authentication of a terminal is not useful for the Domain (taken out the indicated special purposes) _unless_ it can be associated with particular Users. Thus, an authenticated Terminal can do certain (restricted) things on behalf of Users that have registered with it. What is further assumed by the text is that some element in the Domain (likely a GK) knows which Users are registered at that (authenticated) Terminal. As mentioned in footnote 7, a way to transfer this association knowledge (possibly indexed by some identifier) between these Domain elements is needed in order to enable the Terminal to act on behalf of the User also when roaming. Hope this clarifies. (Thinking again about the temporary identifier issue you bring up, things can become more complex when one considers that for privacy reasons one may not want to have a straightforward way of finding out which Users are "linked" by means of their registration at the same Terminal, but I'm sure that we don't want to cope with such issues already in this first phase Annex H.) 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 -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] Sent: Monday, July 24, 2000 10:14 To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] Update to Service Definitions for Annex H - > a question Hi Marc et al, I just finished reading MD-102a and I have a couple of questions. First of all, though, I want to thank you guys for the excelent contribution, I really liked it. Actually I have just one thing that I don't quite understand. In section 5.1.2 you talk about the Authentication of a H.323 Mobile Terminal and say that it enables the verification of the authenticity of the terminal is context of the association it has with the Mobile User. You also explain this a bit further by adding that this is used to verify that the terminal can act on behalf of the authenticated User using it but you still state that the identity of the terminal is only relevant for the purposes of denying the usage of stolen terminals, etc. (black lists). So my question is that are you talking here about authenticating the terminal or are you referring to authenticating some sort of identifier that is used for the association between the terminal and the user? Your statement in item 3. about not needing to authenticate the user in subsequent terminal re-registrations would also seem to indicate the latter. Thus are you thinking of implementing a way to avoid the User authentication at least in Intra-zone location changes by introducing some sort of temporary local identifier for the terminal/user pair? I know that these are just requirements, but these statements seem to lead to that direction, if I have understood them correctly. The idea seems to be worth while to consider and we should discuss this further, but I don't quite see, how the terminal/user pair could really be authenticated, i.e. you can authenticate the User (by contacting the AuF) and you can authenticate the terminal (if proper cryptographic methods are specified also for the terminal), but how can you authenticate their association? Or am I just reading too much into this? Otherwise the contribution seems fine and I would suggest the addition of its contents to the draft Annex H. Let's have a bit of discussion before that, however. ------------------------------------------------ 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

APC s
by Roy, Radhika R, ALCOO 30 Jul '00

30 Jul '00

Dear Mr. OKUBO: I would appreciate if you would resubmit the following AT&T contributions of the Osaka meeting in Portland because we could not discuss those last time due to lack of time: APC-1765: Scope of H.323 QOS APC-1766: Requirements of H.323 QOS APC-1767: Architecture of H.323 QOS APC-1768: Specification of H.323 QOS Characteristics Best Regards, Radhika R. Roy AT&T +1 732 420 1480 rrroy(a)att.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

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

30 Jul '00

Dear Mr. Luthi, In response to your request, APC number has been allocated to your contribution as follows: APC-1893 >Source: PictureTel >Title: Proposed H.242/H.245 text for dynamicPictureResizingByFour >Purpose: Proposal >Question: 14 > >Already has Q11 number Q11-M-03 ! A Q15 number will also be assigned. 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

alternateGk mechanism?
by Johan Gerhardsson (ETX) 29 Jul '00

29 Jul '00

Hello all, my name is Johan Gerhardsson and I was wondering if any one could help me with a couple of questions regarding the of the alternateGk machanism (h.323v2). How is it possible to make an endpoint (gw) gracefully switch over registration and new calls to another gk without loosing existing calls on the current GK? I.e. how can the Gk tell the gw that it should send its SETUP messages (and keep alive RRQ) to another Gk? I see two possible ways that is almost working: 1) ARQ/ARJ with altGkInfo: What if one wants to use pregranted ARQ? Is the registration (keep alive RRQ) also applied? 2) keep alive RRQ/RRJ with altGkInfo: What happens with existing calls on the GW if the registration is rejected by GK? My scenario is this: Two GK's (Gk1 and Gk2, h323v2) is together working in a load sharing mode. Registration data are duplicated. Calls are not duplicated. The two GK knows that the endpoint Gw shall have Gk1 as primary GK. 1. Gw: RRQ -> Gk1 2. Gk1: RCF (alternateGk=[Gk2's rasaddress,<gkid>,needToRegister = FALSE,prio=1], pregranted=yes) -> Gw 3. Gw sends keep alive RRQ to Gk1. 4. Gw sends SETUP messages to Gk1 and calls are now ongoing (gkrouted) through Gk1. 5. Gk1 goes down (calls are cleared by the Gw). 6. Gw detects that Gk1 has gone down. 7. New call: Gw sends ARQ to Gk2 to get Gk2's call signaling address which is saved for further use. 8. Gw routes new calls through Gk2 (no ARQ is used since pregranted is used). 9. Gw sends keep alive RRQ to Gk2. 10. Gk2: RCF (alternateGk=[Gk2's rasaddress,<gkid>,needToRegister = FALSE,prio=0]) -> Gw 11. Gk1 comes up again. 12. Gk2 detects that Gk1 is up again and wants to tell the Gw that it shall go back to "normal operation" (step 3-4) as this is the wanted scenario with this load shared network setup. Questions: 1) If pregranted was not in use, the Gk2 could use the alternateGk mechanism with ARQ by sending ARJ with altGkInfo = altGkIsPermenent = TRUE, alternateGk=[Gk1,<gkid>,needToRegister=FALSE,prio=0],[Gk2,<gkid>,needToRegister=FALSE,prio=1], but the ARQ is only valid for new calls, not calls AND registration (or?). In the case above, pregranted is wanted to reduce SETUP time, so what shall the Gk2 do? 2) In step 9. the Gw has begun to send keep alive RRQ to Gk2. How shall Gk2 tell the Gw to send keep alive RRQ to Gk1 when it is up and running again? (By using RRJ and altGkInfo you might think, but how is the GW handling the active calls that is routed through Gk2? Is it safe to make the assumption that the Gw will not clear these calls?) Thanks in advance for your comments. Johan Gerhardsson Software developer Ericsson Telecom AB Data Backbone & Optical Networks, IP telephony Phone: +46 (0)8 719 2396 email: Johan.Gerhardsson(a)ericsson.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

H323-URL is on the IPTEL Agenda for IETF, Pittsburgh
by Orit Levin 28 Jul '00

28 Jul '00

Hi all! I would like to let you know, that H323-URL is a topic to be discussed on the IPTEL working session next week during the IETF. (Despite the fact, that it was not listed on the official Agenda, posted on July 23rd) For those, who will be participating in the IETF, please join the forum : Thursday, August 3, 9:00-11:30 AM Best Regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com

1 0

Re: Expediting H.245
by Callaghan, Robert 28 Jul '00

28 Jul '00

Bob, For the record, what you call "Fast Open" was rejected during the Santiago de Chile meeting. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Bob Gilman [mailto:rrg@LUCENT.COM] Sent: Thursday, July 27, 2000 6:55 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Expediting H.245 Paul- In trying to think about ways to avoid adding the earlyH245 element to SETUP, I overlooked the fact that it could be used just as well to initiate the Fast Open procedures in a way that was backward compatible. That would permit us to offer both Fast Connect and Fast Open - the called endpoint could accept either one (or would see only the fastStart if it were an older endpoint). The advantage of Fast Open in this case would arise from it's use later on in the call (e.g., to switch to FAX or to redirect audio). -Bob ---------------------------------------------------- Bob Gilman rrg(a)avaya.com +1 303 538 3868 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

2 1