- sg16-avd - lists.packetizer.com

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

20 Oct '00

Dear experts, Mr. Li, we want to proceed with a technical and objective discussion. Everybody is solicited to suggest further improvements for the provided test conditions to become as realistic as possible. Any constructive criticism is welcome as well. Concerning your point Mr. Li, if you read the test conditions carefully you will see it is one item out of a list where you have the choice to take what you think is suitable. You will find the H.263 Wireless Profile also. Furthermore we … [View More]want to discuss the main points of the test conditions (bearer service, ...). What is your opinion about the UMTS scenario ? We are still convinced, the provided test conditions are fair and reasonable. Best Wishes Gero Baese > -----Ursprüngliche Nachricht----- > Von: Adam Li [mailto:adamli@icsl.ucla.edu] > Gesendet am: Montag, 16. Oktober 2000 07:00 > An: Mailing list for parties associated with ITU-T Study Group 16 > Cc: Baese Gero; Yung Lyul Lee; Jeong-Hoon Park; John D. Villasenor > Betreff: RE: test conditions provided > > Dear experts and Mr. Gero, > > It seems that the conditions described in the document can hardly be > called "reasonable and fair conditions". > > For example, for Media codecs, it specifies H.263 with Annex O. As we > all know, Annex O (with spatial, temporal and SNR scalability) is NOT > in the Wireless Profiles of H.263. Indeed, it is not in ANY of the > profiles defined in H.263. > > The whole Annex O is such a very complex algorithm, that it is NOT > even in the most complex profiles where complexity is not that much a > concern. It is really unimaginable that any mobile applications will > use Annex O. > > If the Siemens proposal needed such a un-realistic scenario to provide > any possible gain, the wireless connection oriented Annex I seems is > not the right place for it. > > Since Mr. Gero have just proposed the condition now, he may have > enough resource to test it before the document submission date. Maybe > you can test it also without Annex O, Mr. Gero? > > Sincerely, > > Adam Li > > ---------- > Adam H. Li, Ph.D. > Image Communication Lab (310) 825-5178 (Lab) > University of California, Los Angeles (310) 825-7928 (Fax) > > > > > -----Original Message----- > > From: Mailing list for parties associated with ITU-T Study Group 16 > > [mailto:ITU-SG16@mailbag.cps.intel.com]On Behalf Of Baese Gero > > Sent: Friday, October 13, 2000 7:38 AM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: test conditions provided > > > > > > 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 > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com [View Less]

2 1

Re: APC Number Request
by Sakae OKUBO 20 Oct '00

20 Oct '00

Dear Mr. Ratta, >Please assign an APC number to the following document directed >to the Q14/16 rapporteur's meeting in November: > >Source: Lucent Technologies >Title: Proposal to create an SDL representation of H.248 APC-1960 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 … [View More]

1 0

IEEE PACRIM 2001 CALL FOR PAPERS
by agullive＠ENGR.UVIC.CA 19 Oct '00

19 Oct '00

**************** CALL FOR PAPERS *************** 2001 IEEE Pacific Rim Conference on Communications, Computers and Signal Processing (PACRIM'01) August 26-28, 2001, Victoria, B.C., Canada Sponsored by IEEE Canada (Region 7) & IEEE Victoria Section Co-sponsored by the University of Victoria Established in 1987, Pacific Rim Conference is the premier IEEE biennial event in the Pacific Northwest. It is our pleasure to … [View More]invite you to participate in this event. The scope of PACRIM'01 encompasses but is not limited to: Mobile and Personal Communications Computer Architecture Coding, Modulation and Spread Spectrum Parallel and Distributed Computing ATM Networks Internet Applications Multimedia Communications Neural Networks and Genetic Algorithms Optoelectronic Systems and Devices Hardware/Software Codesign Broadband Satellite Communications Database and Knowledge-Based Systems DSP Applications in Telecommunication Adaptive Filters and Algorithms Image and Video Processing Wavelets and Filter Banks Digital Filters VLSI Speech and Audio Processing Nonlinear Signals and Systems DEADLINES 1000 word summary: March 1, 2001 Acceptance/Rejection: April 1, 2001 Camera Ready Copy: May 1, 2001 Please submit your summary General enquires on PACRIM'01 (by March 1, 2001) to the can be addressed to either of the Technical Program Chair: General Co-Chairs: Dr. Panajotis Agathoklis Dr. Aaron Gulliver or Dr. Kin Li Dept. of Electrical & Computer Eng. Dept. of Electrical & Computer Eng. University of Victoria University of Victoria P.O. Box 3055, STN CSC P.O. Box 3055, STN CSC Victoria, BC, Canada V8W 3P6 Victoria, BC, Canada V8W 3P6 Fax: +1-250-721-6052 Fax: +1-250-721-6052 Email: pan(a)ece.uvic.ca Email: agullive(a)ece.uvic.ca or kinli(a)ece.uvic.ca Accepted papers will be published by the IEEE in the Conference Proceedings. They will be available for worldwide post conference sales from the IEEE. Further information on the conference may be found on the Website: http://www.citr.ece.uvic.ca/pacrim01/ ------------------------------------------------------------------------ We apologize if you have received this notice more than once. ------------------------------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com [View Less]

1 0

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 … [View More]

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. ----------------------------------------… [View More]

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) +… [View More]

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 … [View More]

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 … [View More]

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 … [View More]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 [View Less]

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 … [View More]

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 … [View More]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 [View Less]

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. … [View More]

1 0

[Robustness] teleconf for Oct 12
by Terry L Anderson 10 Oct '00

10 Oct '00

We need a few teleconf to finish work on Annex R before Geneva. I would like to start our first call Thur, Oct 12 at 11:30-12:30 EDT. I apologize for the short notice, but our working time is short. On that call we will talk about additional meeting times during October. I would like to have future calls on a day other than Thurs (either Tue or Wed), but I want to hold the first call at our previous meeting times. If you cannot meet this first call but wish to join later ones, send me email … [View More]

1 0

still difficulty within the UCLA proposal "Generic Uneven Level P rotection(ULP)"
by Baese Gero 10 Oct '00

10 Oct '00

Dear Mr. Li, dear experts, thank you very much for your response but the question remains unsettled still. Your answer is concentrated on the Packet #3. With no doubt this packet is non-critical. Therefore, our questions was about Packet #2 and the protection with ULP #2. Here is the scenario in doubt again: + However, when considering your example in Figure 1 on the next page, we found + a simple loss situation, for which the above statement does not seem to hold anymore: + Let us assume … [View More]

1 0

difficulty within the UCLA proposal "Generic Uneven Level Protect ion(ULP)"
by Baese Gero 08 Oct '00

08 Oct '00

Dear authors, While studying your last ITU-proposal APC-1905, "Generic Uneven Level Protection (ULP)" for Annex I of H.323, which had been submitted for the Portland meeting in August, we discovered a mismatch between one of the major features stated and the simple example given in Figure 1. On page 3, you state in section "Protection procedure" that "In order to achieve more efficient usage of the channel bandwidth, the protection levels need to be grouped in such a way that when data in one … [View More]packet protected by level p are recoverable, all the data of the same packet protected by level below p are recoverable." We definitely agree on this feature, since we are both interested in protecting any type of progressive or prioritized media stream most efficiently! However, when considering your example in Figure 1 on the next page, we found a simple loss situation, for which the above statement does not seem to hold anymore: Let us assume that out of the seven given packets, exactly (information) packets #2 and #3 are lost, but all the others have been received correctly. Since packets #1-#3 are only protected with one single FEC packet, ULP #1, at level L_0, the leftmost part of the lost packets #2 and #3 can definitely not be recovered anymore. If we now consider the protection strategy for level L_1, we see that the second part of packets #1, #2, #4, and #5 are protected via the respective part of FEC packet, ULP #2. But only the part belonging to packet #2 has been lost (packet #3 is not related to ULP #2), which should definitely be recoverable then. Thus, we would be able to overcome the loss in packet #2 at protection level L_1, but not at level L_0, which is a contradiction to the above statement. Can you please tell us (and possibly all other interested participants), if this conclusion is correct, or if we have misunderstood something? Although Figure 1 only contains a simple example, we think that obeying the above statement at each step while constructing a suitable and effective protection strategy can be quite difficult. If you think that this is not the case at all for your proposal, it would be probably best to specify your coding principle in more detail, such that all participants of the group can evaluate how complex the choice of a good protection scheme can be. Thanks a lot in advance, Gero Baese Guenther Liebl ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com [View Less]

2 1

VoIP (Using ALL5) and VoIP (Using 100BaseT Ethernet or 1G Etherne t)
by James Dam 08 Oct '00

08 Oct '00

Dear all, Could you please comments on the advantage and disadvantage of : VoIP (Using ATM-ALL5) vs VoIP (Using 100BaseT Ethernet or 1G Ethernet) Any issues with interworking for IP features/applications specially. Best Regards James Dam

1 0

Q12-14/16 Rapporteur meeting on 9-10 November
by Sakae OKUBO 07 Oct '00

07 Oct '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 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: … [View More]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 [View Less]

1 0

APC-1952 liaison from BICC/11
by Glen Freundlich 06 Oct '00

06 Oct '00

Dear Colleagues, I have uploaded APC-1952 to the Pictel site for consideration during the November meetings. Source: SG 11 Joint Special Rapporteurs for BICC Title: Support of directionality in "H.248 Annex K - Announcement Package" Regards, Glen

1 0

Re: Fw: Update of H.323 implementors guide
by Sakae OKUBO 06 Oct '00

06 Oct '00

Dear Mr. Jones, >ITU-T SG11 has delivered this Liaison statement to me and wanted to make >sure that it was reviewed during the next Rapporteur's meeting. [...] >Can you make this available as an APC for the November meeting or should I >send this to the TSB for the SG16 meeting? This has been uploaded to /0011_Gen directory as follows: APC-1951 Study Group 11 BICC Special Rapporteurs Liaison to SG 16 proposing some additional clarifications in the H.323 Implementers Guide … [View More]

1 0

MGCP interop
by ajays 05 Oct '00

05 Oct '00

Hello! I wanted to know, when the next MGCP interop is going to be and where can I find information on it ? Regards Ajay ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

[H.323 Mobility:] Draft H.235 Annex G - "Security for H.323 Mobil e Environments" uploaded
by Euchner Martin 05 Oct '00

05 Oct '00

Hi all, you may find the uploaded draft MD-109 at the following URL: ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/MD-109.zip <ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/MD-109.zip> This is the initial draft of new H.235v3 Annex G. The draft has been created from Portland APC-1937. The authentication and key management procedures may be accomplished either during GK discovery or during registration phase. The draft provides also some more detailed security … [View More]

1 0

Re: Q.931 package for MGCP?
by Rosen, Brian 05 Oct '00

05 Oct '00

This might be the wrong email list for this kind of question. The MGCP list at the Softswitch Consortium ( www.softswitch.org <http://www.softswitch.org> ) or at pulver.com would be more appropriate. The answer is -- wrong idea. MGCP is a device control protocol, not a signalling protocol. You wouldn't try to map Q.931 to MGCP except some simplistic notions of connections. This would be local to a particular softswitch implementation, and thus not standardized. You can ask how the Q.… [View More]

1 0

Re: MGCP interop
by Rosen, Brian 05 Oct '00

05 Oct '00

There are several possible answers to this: 1. The PacketCable folks have a schedule for testing that includes their MGCP profiles 2. The ISC will sponsor MGCP testing "soon". We (the ISC) are working out exactly how to do that. I'd say we will have an ISC sponsored MGCP test within the next 4-6 months. Brian > -----Original Message----- > From: ajays [mailto:ajays@miel.mot.com] > Sent: Thursday, October 05, 2000 6:25 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: … [View More]

1 0

Q.931 package for MGCP?
by Jeff Jenkins 04 Oct '00

04 Oct '00

Anyone aware of a Q.931 package for MGCP? I am interested in mapping Q.931 to MGCP. -- jrj

1 0