- sg16-avd - lists.packetizer.com

Re: Mob ad hoc group progress
by Guram Paul-LPG019 03 Apr '00

03 Apr '00

Mob group and Vineet Vineet is most probably right. If when discussing the intra-network scenario, it is seen that the H.323 inter-network scenario can also be specified at the same time, and that there is nothing extra special to consider, we shall state so and log it as such for the base-line text. MD00 has been reserved as the contribution list and allocation file for the MDs. Paul -----Original Message----- From: Kumar, Vineet [mailto:vineet.kumar@INTEL.COM] Sent: 03 April 2000 02:30 To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Mob ad hoc group progress Paul, I think that we should look at both intra- and inter-network scenarios together. I don't see anything special in the intra-network scenario that would require us to look for its solution first. vineet

1 0

Re: [Robustness] H.225 & H.245 state info
by Maureen Stillman 03 Apr '00

03 Apr '00

Terry, thanks for compiling on this important state information for H-323. For those of us who are nit-picking could you give us a definition for the elements in the table? x o t new(???) n/a (blank), etc. I'm not really sure what they mean. The labels at the top of the table, why they are there also need some definition, although I think I know what they mean. A paragraph on the scope of the table would also clarify, for example, are conference calls included? Also, if you could take us thru one scenario in the table that has different elements in it, that would be helpful. I want to make sure I have the right interpretation of the table before we talk about it on Thursday at the teleconference. Thanks. -- maureen -----Original Message----- From: EXT Terry L Anderson [mailto:tla@LUCENT.COM] Sent: Friday, March 31, 2000 5:14 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: [Robustness] H.225 & H.245 state info I have been working on collecting the call state information present in various H.323 network elements. The goal is to: 1. see what data is present 2. suggest what data must be re-established if a new element takes over (or an element recovers but has lost call state data) in order to allow the call to continue at various specified levels of recovery: - call can continue but billing data lost - call can continue with full billing data - etc. I have certainly not completed this study, but have collected a fairly complete set of call state data items and put them into a table indicating which element(s) they reside in. The plan is to choose a notation to indicate how vital each element is for various levels of recovery and which other element has the data that can be used to restore it in the new element. I will share this much at this time and perhaps we can begin a discussion about - completeness (what I have missed) - presentation (is there another format that could make the information more understandable) I am attaching it as a word document. -- ------------------------------------------------------------ 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

2 1

Q12-14/16 Rapporteur meeting in Osaka
by Sakae OKUBO 03 Apr '00

03 Apr '00

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. M. Wada, KDD 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 Sonusnet USA Tel: +1 732 972 2653 Fax: +1 732 972 6389 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 Osaka Date: 31 March 2000 ---------------------------------------------------------- Dear Q.12-14/16 experts, The subject meeting of ITU-T SG16 experts will be held in Osaka, Japan at the kind invitation of Group of Interested Organizations in Japan. Please note that Q.11/16 and Q.15/16 will meet concurrently at the same place and have joint sessions with Q.12-14/16. 1. Date ^^^^^^^ 15 (Monday) - 19 (Friday) March 2000 starting at 9:00 on the first day closing at 18:00 on the final day 2. Venue ^^^^^^^^ Osaka International Convention Center 5-3-51 Nakanoshima, Kita-ku Osaka-shi, 530-0005 Tel: +81 6 4803 5555 Fax: +81 6 4803 5620 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 - Issue white papers for: * H.323 V4 * H.225.0 V4 * H.323 Annex J * H.323 Annex K * H.323 Annex L * H.323 Annex M.1 and M.2 * H.450.8 [may have been issued already] - Progress work for: * H.323 Annex N (QoS) * H.323 Annex H (Mobility) * H.323 Annex I (Error prone channels) * More robust operations * H.225.0 Annex G V2 * T.38-like protocol for modems & related H.323 signaling * H.450.x new recommendations * SS7 interworking 4) Q.14/16 Common protocols, MCUs and protocols for interworking with H.300-series terminals - Issue white papers for: * H.235 V2 * H.245 V7 * H.248 Annex F * H.248 Annex G * H.248 Annex H * H.248 Annex I * H.248 Annex J * H.248 Annex K * H.246 Annex E - Progress work for: * H.246 Annex D * H.248 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 5 May (Friday) /// /// Distribution of the document: by 8 May (Monday) /// /// 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 5 May (Friday) at the latest. Document number (APC-1nnn) 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-{1nnn}| | Study Group 16 {Version m if relevant}| | Q.12-14/16 Rapporteur Meeting {Date}| | Osaka, 15-19 May 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 (8 October 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 /0005_Osa directory of the ftp site. 5) The document distribution / presentation at the meeting will be all electronic. Participants must bring their laptop and 10BASE-T cord along. 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/0005_San/Information_ITU-T_Osaka.zip). 6. Registration ^^^^^^^^^^^^^^^ To register your meeting attendance, please send the attached form to the meeting secretariat by 24 April: Ms. Noriko Hosokawa Global Information and Telecommunication Institute Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: nonko(a)giti.waseda.ac.jp Tel & Fax: +81 3 5286 9863 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: Osaka meeting registration Name: Company: Arrival: Departure: 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ Please send the attached form to the meeting together with the meeting registration. Special room rate is 12,600 Yen (single) or 18,900 Yen (twin room, single use) per night including breakfast, service charge, local tax and consumption taxes. The block reservation is held until 24 April. 8. Meeting Fee ^^^^^^^^^^^^^^ To support the meeting organization, about 20,000 Yen meeting fee is collected by the secretariat (exact amount will be announced later). We are looking forward to meeting with you in Osaka. Sincerely yours, Sakae OKUBO Dale SKRAN Glen FREUNDLICH ----------

1 0

Re: subscribe
by Sebestyen Istvan ICN M CS 27 03 Apr '00

03 Apr '00

Dale, any news about the status of the August/September SG16 Q.11-14 Rapp. Meeting? Regards, Istvan -------------------------------------------------------------------------- Dr. Istvan Sebestyen Siemens AG, ICN M CS27, Hofmannstr. 51 D-81359 Munich Tel:+49-89-722-47230 Fax:+49-89-722-47713 E-Mail office: istvan.sebestyen(a)icn.siemens.de; istvan(a)sebestyen.de E-mail private: istvan_sebestyen(a)yahoo.com; Siemens Intranet:http://netinfo.icn.siemens.de/es/team/essp/team/essp4 Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de ---------------------------------------------------------------------------- ---------------- > ---------- > From: Skran, Dale[SMTP:DSkran@SONUSNET.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Monday, April 03, 2000 3:00 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: subscribe > > dskran(a)sonusnet.com > > Dale Skran >

1 0

NetMeeting & T.120
by Stevie Gray 03 Apr '00

03 Apr '00

Hi, I am currently implementing a program which essentially passes T.120 data from one endpoint to another. I am doing this over H.245 using dynamic ports. The program basically joins the two T.120 bi-directional channels together via Winsock and lets the two endpoints get on with it. What I have discovered so far is that NetMeeting only seems to initiate a T.120 conference if it originated the Q.931 call. I have a scenario where I initiate the calls to each of the NetMeeting endpoints and join them together. However, in this scenario NetMeeting does not initiate the T.120 conference, I'm assuming they are both waiting for the Q.931 call initiator (i.e. me) to initiate the T.120 conference. I have tried various combinations of the T120SetupProcedure flag in the OLC Ack but to no avail. Is this a limitation of NetMeeting or is there a way to get this working. Here are a list of scenarios I have working NetMeeting --> MyProg --> NetMeeting NetMeeting --> MYProg <-- NetMeeting The one I can't get working is NetMeeting <-- MyProg --> NetMeeting I am using NetMeeting 3.01. Regards, Stevie. ========================================================== Stevie Gray sgray(a)ridgeway-sys.com Senior Software Engineer Ridgeway Systems & Software www.ridgeway-sys.com Tel +441189381124 Fax +441189354444 ==========================================================

1 0

Use of IRR by Gateways
by Mohamed Mustafa 03 Apr '00

03 Apr '00

Hi All, H.323 requires all endpoints to transmit an IRR message in response to an IRQ message from a Gatekeeper (or some other entity), and also to send unsolicited IRR messages to the Gatekeeper's RAS address at specific intervals if requested by the Gatekeeper in the ACF or RCF messages. As I understand it, an endpoint must provide the details of all active calls in a single IRR response if the callReferenceValue field in the IRQ is set to 0. This is clearly not possible if the endpoint supports thousands (or even hundreds!) of simultaneous calls. Can anyone provide any guidance on what to do in such a situation? Also, in the case of unsolicited IRR messages, I can't find anything which states that an endpoint must provide details of all active calls in each unsolicited IRR message. Therefore, an endpoint can either send a separate IRR message for each call, or it combine details of a number of calls (but not necessarily all) into each IRR message. Is my interpretation correct? Thanks, Mohamed

5 11

[Fwd: Force remote to start H.245 session?]
by Chris Wayman Purvis 03 Apr '00

03 Apr '00

Reply intended for the list unintentionally sent to Paul personally, so here you all are! Chris Chris Wayman Purvis wrote: > > Paul, > > First of all, sorry for the fact that this seems to be a week-old mail I'm > finally responding to... > > I may have misunderstood, but I don't understand why this is necessary. If > both endpoints have expressed willingness to use tunnelled H.245, why can an > endpoint not simply start sending H.245 messages (of COURSE starting with TCS, > and potentially tunnelled in purpose-built FACILITY messages) when it wishes to > start a tunnelled H.245 session? I would have thought that would be a pretty > clear indication of intent to start a tunnelled H.245 session! > > FACILITY/reason=startH245 is required for separate H.245 connections because an > endpoint may not know an address at its interlocutor to use to initiate an > H.245 connection. This problem doesn't exist in tunnelled H.245, so I see no > necessity for the extra interpretation! > > We may want some extra text specifying behaviour at the start of an H.245 > session, to ensure that the destination of the initial tunnelled H.245 message > actually does something constructive (sends a TCS) rather than non-constructive > (merely Acking the TCS it's been sent and not advancing anything useful). > > Regards, > Chris > > Paul Long wrote: > > > > How does an EP force the remote EP to bring up a tunneled H.245 session? > > > > Consider this call scenario: Fast Connect was enough to establish the > > desired media between two EPs. Both support H.245 Tunneling but neither has > > initiated an H.245 session because neither had any need to. One EP now needs > > to use H.245 procedures. It doesn't matter, but reasons include DTMF > > transmission via UII and requesting a different video format or different > > audio bit-rate via RequestMode. That EP can initiate its own H.245 > > procedures, e.g., TCS and MSD, but how does it force the other EP to bring > > up an H.245 session? > > > > H.323 and H.225.0 say that Facility/reason=startH245 is just for switching > > from Fast Connect or H.245 Tunneling to a separate H.245 channel, not for > > initiating an H.245 session via tunneling. Is it just hoped that when an EP > > sees that the other EP is bringing up an H.245 session, it will do the same? > > Seems like a pretty weak assumption. It would be nice if > > Facility/reason=startH245 without an h245Address meant to bring up an H.245 > > session on whatever transport is already established, i.e., tunneled or > > separate channel. Seems like we could do this in v4 because startH245 > > without an h245Address currently has no meaning. Whadya think? -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001

1 0

subscribe
by Skran, Dale 03 Apr '00

03 Apr '00

dskran(a)sonusnet.com Dale Skran

1 0

Re: Mob ad hoc group progress
by Kumar, Vineet 02 Apr '00

02 Apr '00

Paul, I think that we should look at both intra- and inter-network scenarios together. I don't see anything special in the intra-network scenario that would require us to look for its solution first. vineet -----Original Message----- From: Guram Paul-LPG019 [mailto:lpg019@EMAIL.MOT.COM] Sent: Sunday, April 02, 2000 12:52 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Mob ad hoc group progress Radhika, Conf call is for Annex H only as before...nothing has changed...change can only take place when the group agrees. Please do not read into the email more than what it says. I was only trying to highlight, in a high level report, the plight of Annex I since nothing much has moved in it, and it is an Annex which together with Annex H covers the mobility aspects. As far as Annex E is concerned, the point was that the mapping was the work of one individual or one company, thus could have errors or omissions (more than likely)...again only highlighting to people to check out this mapping. Contributions for next conf call to be for All H.323 intra-network scenario for: Registration procedures, Gatekeeper discovery, Location update, Call establishment, Mid-Call scenarios (e.g. supplementary services, user interaction), Call release. Also contributions on any impacts on the already specified architecture in the light of the present work are welcome. Paul -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] Sent: 01 April 2000 00:00 To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Mob ad hoc group progress Hi, Paul and Mobility Group: I like to see that it should be clarified via emails whether H.323 Annex I and H.246 Annex E will be a part of the conference call. My personal preference is not to discuss annexes I and E during the conference call although email discussions will be preferred. If Annex I and E are included in the conference call, I like to see the actual time in the agenda when these items will be discussed so that people can best use their time in joining the particular time slot for each Annex. The proposal is as follows: 1. The upcoming conference call to be dedicated for H.323 Annex H. 2. Let both editors of H.323 Annex I and H.246 Annex E propose via emails whether any issues to addressed. 3. If annex I and E are included in the agenda of the upcoming conference call, I like to the time slots when these annexes will be discussed so that people can join the particular time slots of interest. Alternatively, separate conference calls can be arranged for annexes I and E. 4. Are editors or any members of the mobility group sure what would be the scope of work (I guess that Annex E is stable for now - thanks to the editor) for those annexes? Paul: Would you please clarify what specific area that we need to discuss for the next conference call for H.323 Annex H? My guess is that we may start with intra-zone communication first. I am planning to bring contribution(s) describing this for mobility management: Discovery, Registration, Location Updates, and Call Establishment. I would appreciate comments form all members. Best regards, Radhika R. Roy AT&T H.323 Ad Hoc Mobility Group

1 0

Re: Mob ad hoc group progress
by Guram Paul-LPG019 02 Apr '00

02 Apr '00

Radhika, Conf call is for Annex H only as before...nothing has changed...change can only take place when the group agrees. Please do not read into the email more than what it says. I was only trying to highlight, in a high level report, the plight of Annex I since nothing much has moved in it, and it is an Annex which together with Annex H covers the mobility aspects. As far as Annex E is concerned, the point was that the mapping was the work of one individual or one company, thus could have errors or omissions (more than likely)...again only highlighting to people to check out this mapping. Contributions for next conf call to be for All H.323 intra-network scenario for: Registration procedures, Gatekeeper discovery, Location update, Call establishment, Mid-Call scenarios (e.g. supplementary services, user interaction), Call release. Also contributions on any impacts on the already specified architecture in the light of the present work are welcome. Paul -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] Sent: 01 April 2000 00:00 To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Mob ad hoc group progress Hi, Paul and Mobility Group: I like to see that it should be clarified via emails whether H.323 Annex I and H.246 Annex E will be a part of the conference call. My personal preference is not to discuss annexes I and E during the conference call although email discussions will be preferred. If Annex I and E are included in the conference call, I like to see the actual time in the agenda when these items will be discussed so that people can best use their time in joining the particular time slot for each Annex. The proposal is as follows: 1. The upcoming conference call to be dedicated for H.323 Annex H. 2. Let both editors of H.323 Annex I and H.246 Annex E propose via emails whether any issues to addressed. 3. If annex I and E are included in the agenda of the upcoming conference call, I like to the time slots when these annexes will be discussed so that people can join the particular time slots of interest. Alternatively, separate conference calls can be arranged for annexes I and E. 4. Are editors or any members of the mobility group sure what would be the scope of work (I guess that Annex E is stable for now - thanks to the editor) for those annexes? Paul: Would you please clarify what specific area that we need to discuss for the next conference call for H.323 Annex H? My guess is that we may start with intra-zone communication first. I am planning to bring contribution(s) describing this for mobility management: Discovery, Registration, Location Updates, and Call Establishment. I would appreciate comments form all members. Best regards, Radhika R. Roy AT&T H.323 Ad Hoc Mobility Group

1 0