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

Re: H.323 Annex O
by Sakae OKUBO 19 Oct '00

19 Oct '00

Dear Orit, >Please, allocate an APC number for "H.323 Annex O. Draft." APC-1959 has been allocated to your contribution. 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.323 Mobility:] Reservation of MD-107 and MD-108 & upload of MD -100
by Jaakko Sundquist 19 Oct '00

19 Oct '00

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

1 0

Re: Please allocate APC numbers
by Sakae OKUBO 18 Oct '00

18 Oct '00

Dear Mr. Jones, >Please allocate APC numbers for the Implementers Guide and H.323v4 >documents. APC-1957 and 1958 have been allocated to your two contributions, respectively. 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

Rapporteur meeting on 9-10 November in Geneva
by Sakae OKUBO 18 Oct '00

18 Oct '00

Dear Q12-14/16 experts, The subject meeting will be held according to the meeting notice: http://standard.pictel.com/ftp/avc-site/0011_Gen/Notice_0011_Geneva.zip Please note the following and take your actions: 1) Registration Please return to me your registration form by e-mail as soon as possible, by 26 October 2000 at the latest. A sufficient number of participants is one of the requirements to get final approval for holding the meeting. 2) Documents Please register your input documents as soon as possible, by the following deadline at the latest: /// Registration of the document: by 23:59 UTC, 30 October /// /// Distribution of the document: by 23:59 UTC, 2 November /// A sufficient number of contributions is one of the requirements to get final approval for holding the meeting. 3) Delayed contributions for the SG16 meeting When you submit a delayed contribution for the following week SG16 meeting, please submit it also as an APC document. Where it should be discussed is subject to the decision of Rapporteur, with the participants agreement, on a case by case basis. It is important that all documents are available at the Rapporteur meeting. 4) TIES account If you participate in the Rapporteur meeting and are a member of ITU-T, please obtain the TIES account. We will use the TIES ftp site and PictureTel ftp site for document distribution during the meeting. See <http://www.itu.int/TIES/> for registration information. 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

please send information on h.323
by Larry Govedich 16 Oct '00

16 Oct '00

Thank you, Larry Govedich ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

test conditions provided
by Baese Gero 16 Oct '00

16 Oct '00

Dear experts, the long lasting diskussion about the superiority of one of the proposals concerning error resilient transmission of progressive multimedia streams(H.323 Annex I) needs to be decided on an objective basis soon. Therefor we are providing reasonable and fair test conditions. The test conditions are focused on a common UMTS scenario with video input and PSNR as an objective quality measurement. Furthermore every step in between is well defined and a graphic visualization of the outcome is the ideal and easy basis, with not much room for interpretation, for the decision process. Comments, questions and supplements are welcome. Best wishes Gero Baese

3 2

AW: Q12-14/16 Rapporteur meeting on 9-10 November
by Pierre-Andre.Probst＠SWISSCOM.COM 16 Oct '00

16 Oct '00

Federico, Fabio, I suppose somebody gave the green light to the rapporteurs for the three questions and that the rooms are available in Geneva?? Best regards Pierre-André -----Ursprüngliche Nachricht----- Von: Sakae OKUBO [mailto:okubo@giti.waseda.ac.jp] Gesendet am: Samstag, 7. Oktober 2000 18:05 An: Q.12-14/16 Reflector Cc: Probst Pierre-Andre, EXR; George Helder; Federico Tosco; Fabio Bigi Betreff: Q12-14/16 Rapporteur meeting on 9-10 November 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 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 Suite 3500, 4400 Route 9 South Freehold, NJ 07748 USA Tel: +1 732 625 3003, x202 Fax: E-mail: dskran(a)sonusnet.com Glen FREUNDLICH Rapporteur for Q.14/16 in ITU-T SG16 Avaya Communication 1300 W. 120th Avenue Westminster, Colorado 80234 USA Tel: +1 303 538 2899 Fax: +1 303 538 3907 E-mail: ggf(a)avaya.com ------------------------------------------------------------ Subject: Notice of Q.12-14/16 Rapporteur Meeting in Geneva Date: 6 October 2000 ------------------------------------------------------------ Dear Q.12-14/16 experts, The subject meeting of ITU-T SG16 experts will be held in Geneva, Switzerland hosted by ITU-TSB. Please note that this Rapporteur meeting is held in advance of the SG16 meeting during 13-17 November 2000, but the two meetings are managed separately. This notice is only concerned with the Rapporteur meeting during 9-10 November. For the SG16 meeting, separate participation procedures are applied as in TSB Collective-letter 10/16 <http://www.itu.int/itudoc/itu-t/com16/coll/010_ww9.doc> even if the two meeting are held at the same ITU premises. Please also note that non-ITU-T members may attend this Rapporteur meeting, but such attendees are requested to contact one of the rapporteurs. Procedures for contribution from a non-ITU-T member are described below in section 4, item 3. 1. Date ^^^^^^^ 9 (Thursday) - 10 (Friday) November 2000 starting at 9:00 on the first day closing at around 18:00 on the final day 2. Venue ^^^^^^^^ ITU headquarters Place des Nations CH-1211 Geneva 20 GENEVE, Switzerland Tel: +41 22 730 51 11 Fax: +41 22 733 72 56 <http://www.itu.int/aboutitu/reachitu.html> Detailed information concerning the meeting rooms will be displayed on screens at the entrances to ITU headquarters. 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 - Inputs for the SG16 decision/approval * H.323 Implementor's Guide * Other TDs - Toward determination at the SG16 meeting: * 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) - Progress work for: * H.323 Annex N (QoS) * H.323 Annex O (Internet protocols and technologies complementary to H.323) * H.323 Annex P (Modem Relay) * Other new items that may arise 4) Q.14/16 Common protocols, MCUs and protocols for interworking with H.300-series terminals - Inputs for the SG16 decision/approval * H.248 Implementor's Guide * Other TDs - Toward determination in November: * H.248 Annex L * H.248 Annex M - Progress work for: * H.235 V3 * H.235 Annex F * H.235 Annex G * H.245 V8 * H.246 Annex D * H.248 V2 * H.341 V2 * other new items that may arise (e.g., new packages for H.248) 5) Interaction with other groups 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 23:59 UTC, 30 October /// /// Distribution of the document: by 23:59 UTC, 2 November /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify S. Okubo(okubo(a)giti.or.jp) as soon as possible, by 23:59 UTC, Monday 30 October at the latest. Document number (APC-nnnn) will be allocated. Early indication of your submission plan is welcome and encouraged. Please submit all the Delayed Contributions and TDs for the SG16 meeting(13-17 November), except for White Contributions, also to this Rapporteur meeting (9-10 November) 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}| | Geneva, 9-10 November 2000 | | | | SOURCE*: { } | | TITLE : { } | | PURPOSE: {Proposal, Discussion, Information, Report, etc.} | | | | _________________________ | | | | | | | | *Contact: Name, e-mail | ------------------------------------------------------------------ 3) If you are a non-ITU-T member and will contribute by submitting a document, please consult with one of the rapporteurs. (Note - Procedures are to be clarified after consultation with ITU-TSB.) 4) 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, Thursday 2 November 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. 5) Input documents can be retrieved from /0011_Gen directory of the ftp site. 6) The document distribution / presentation at the meeting will be all electronic. Participants must bring along their laptop, 10BASE-T card and cord. 7) The copying service is very limited at the meeting site. 5. Registration ^^^^^^^^^^^^^^^ To register your meeting attendance, please send the attached form to S Okubo (okubo(a)giti.or.jp) by 26 October 2000 by e-mail, with copy to dskran(a)sonusnet.com, ggf(a)avaya.com. 6. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ Please find a hotel yourself. For your information, a hotel confirmation form is attached to this meeting notice (see TSB Circular 259 of 10 March 2000 for the list of hotels<http://www.itu.int/itudoc/itu-t/circ/circ5/259.html>). We are looking forward to meeting with you in Geneva. Sincerely yours, Sakae OKUBO Dale SKRAN Glen FREUNDLICH ---------- Registration form for the Q12-14/16 Rapporteur meeting 9-10 November 2000 Geneva 1. Mr. Mrs. Miss: ___________ Family Name: ______________________________________________ First Name: ______________________________________________ 2. Country: ______________________________________________ 3. Organization: ______________________________________________ 4. ITU-T member (yes/no) ___________________ 5. Official address: _____________________________________________ _____________________________________________ _____________________________________________ Phone: _______________________ Fax: _______________________ E-mail: _______________________ ---------- Attachment: Annex 3 to TSB Collective-letter 10/16 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Get Paid on All Your Bounced Checks #68A7
by Sam Heinsberg 15 Oct '00

15 Oct '00

ATTENTION MERCHANTS: Receive 100% of face value of your NSF checks ABSOLUTELY FREE! Stop your profits from flying away in NSF checks with USASurePay's complete electronic check recovery system!!! USA SurePay is a National Enrollment Office for a nationwide FREE check recovery service. Let our National ACH Network go to work for you!!! · NO SETUP FEE · NO APP FEE · NO DISCOUNT RATE · NO TRANSACTION FEES · NO SERVICE FEE · NO EQUIPMENT NEEDED · NO LEASES · NO TERMINATION FEES · NO STATEMENT FEE We will take any NSF checks, stop payments, and closed account checks going back to Jan.1,2000!!! REFERRALS AVAILABLE ENROLL ONLINE FOR INFORMATION PLEASE CALL: OFFICE 401-351-1350 **************************************************** If you have received this message in error, please remove at: mailto:mprt9f@netscape.net?subject=remove **************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

[Robustness] Some Issues
by Terry L Anderson 12 Oct '00

12 Oct '00

I got no one on the call today - perhaps because of the late notice. Let's try addressing some issues by email. Sec 8.4 discusses H.245 Connection Reestablishment. I think there are a few small issues. 1. While multiple calls can be signaled over a single CallSig connection, I do not believe that this is permitted on H.245 Call Control Signaling channels. So we do not have to be concerned with multiple calls when H.245 fails, right? 2. Assume CallSig channel failed and we have a separate H.245 channel which also failed (tunneled H.245 does NOT have this issue). We say, send "endSessionCommand" on the H.245 channel and then drop the connection. Then reestablish CallSig, send Facility with our h245addr. The other end reestablishes H.245 channel to us. issue 2a. If the endSessionCommand makes it through (we detected failure but it wasn't completely dead?), won't the other end believe that the call is over, hangup, send us ReleaseComplete, etc. so we won't be able to recover? Before these procedures, loss of H.245 ended the call. Do we need a flag in endSessionCommand to indicate that we are "replacing" the channel rather than ending the call? Or can we omit the endSessionCommand - just drop the connection that we believe is dead. The Facility command will tell the other end to re-establish, dropping its end if necessary. issue 2b. How do the two entities with the new h.245 channel know that this is a replacement and NOT do to initialization procedures (master/slave, capabilities exchange)? The end sending Facility knows and could remember this when the channel is established TO it from the other end. How does the end receiving Facility, distingish this from case where a new channel is needed (transition from fastStart or tunnelling)? By the fact that it has or had a distinct h.245 channel for that call already? Is this good enough, or do we need a flag in Facility or a Reason to indicate "RE-establishment"? 3. Assume that CallSig has NOT failed but separate H.245 has failed. This case is not clearly covered by the current wording in the paragraph, but I think the issues are the same. We either send endSessionCommand before dropping the "dead" connection or not as we decided in issue 2a. and then use Facility over the unfailed CallSig channel to re-establish. I will change the wording to clearly cover this case as well. Section 6.4.1. We currently specify that if a CallSig connection fails we re-establish to the BACKUP transport address. There is some chance that the failure does NOT prevent a new connection to the original entity, e.g., failure of a socket listener process or a temporary failure. Recovering the call is easier in the original entity than in the backup since the call state may still be locally available. It would be nice to have a way to try the original entity before trying the backup. But we do not want to wait for the timeout of a TCP connection attempt. Should we consider or at least permit (make optional) a mechanism to probe the original entity with something like ping to test for network connectivity and operating system being alive first and if successful attempt re-establishing TCP to original entity BEFORE trying backup? Section 6.4.3 closing old tcp connections. My notes imply that someone on a previous call may have had a problem with this section, but I have lost who or what the problem was. If someone has a problem with it, repeat the issue. Section 6.3 Editor's note at the end. This describes a case that we discussed in a previous call. The goal was to reduce the number of KeepAlive messages for multiple calls between the same two entities. This is simple for the case where the calls are signaled on a single multiplexed TCP connection (and we discuss that). The issue is to use a single KeepAlive even when there is more than one TCP connection used. The problem we have is to identify all the calls that are truely between the same two entities. Analysis of special cases lead us to conclude that this could NOT be done without adding an additional globallyUniqueId to label the calls that were "clustered" or related to one KeepAlive exchange. The issue was whether a solution requiring an additional id field is worth the benefit. Another solution that I do not believe we considered is for the KeepAlive message to add a field that carries some id of the other channels it applies to, but it is not clear in this case either, how to designate the channels. TransportAddress is not sufficiently unique, nor is the IPAddr of the establishing end. Since multiple calls may be on the channel, one cannot use callId or CRV. So we still have a problem requiring some new globallyUniqueId (note that is must be globally unique, since the connection may well be between two zones). I'd like to hear from folks that think this is worth solving even if it requires maintenance of a new Id or any new solution that might avoid it. -- ------------------------------------------------------------ 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

1 0

still advantage with the UCLA proposal than Siemens proposal
by Adam Li 12 Oct '00

12 Oct '00

Dear Mr. Gero and experts, Thank you very much for your response. But I think there is no difficulty there and ULP is more efficient than interleaving in this aspect. In your email, you stated that > It is one of the favourable characteristics of > our approach to guarantee the recovery within this rules. ^^^^^^^^^ According to the Siemens proposal in APC 1841, if the transmission is hit by errors, some of the *correctly* transmitted data will have to be discarded. It is even after error corretion, because of the way that interleaving is done in the proposal. I would be very curious to know how this is proved with the interleaving scheme. On the other hand, with the UCLA proposal, because the original stream is transmitted unchanged, it is trival to show that all the correctly transmitted media stream is allright. And the help of the extra ULP packets, we can recover some of the lost packets and get more information. > > The statement about the grouping rules in the document > > is describing one important general principles for any > > efficient forward error correction scheme. It is nice > > to know that Mr. Gero agrees on the same principle. We > > are not intending to claim that the grouping rules in > > APC-1905 absolutely guarantees the property. Again, I want to reiterate a statement I made in my last email reply to you. The property described by the statement in our document is a general principle for any efficient forward error correction scheme. It does not say that the proposal in the document absolutely guarantees the property under any condition. And you agreed on this. I don't think we have any problem there. Hope this helps. Please let me know if you have any further question. Adam ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0