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

[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 (not to the reflector) to suggest times that would be good for you. You will find a new draft of Annex R in out subdirectory of incoming on the draft server: ftp://standard.pictel.com/avc-site/incoming/Robustness-AHG/AnnexRdraft1010.… I have revised the section order to better fit the format for Annexes, included Scope with our Introduction section and cleaned up several other sections, but there are still several areas that need our attention before it can be considered for determination in Geneva. Robustness Teleconf Oct 12 11:30 EDT (15:30 UT or GMT) Bridge Telephone Number: +1 630 713 3333 Conference Code: 255390 -- ------------------------------------------------------------ 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 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 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. > 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 Of course we agree on that. It is one of the favourable characteristics of our approach to guarantee the recovery within this rules. > For example, in a interleaving scheme proposed in APC-1841, even correctly > transmitted data will have to be discarded because of the holes in > rearranged packets. In opposition to the UCLA proposal this data are not protected in a special way(normal regressive profile). Within the UCLA proposal the packets are first processed completely and then discarded anyway. Best Wishes Gero Baese ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

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 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

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: 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

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 for H.246 Annex C I do not think you need to forward it to TSB, SG11 group should have done so if they think it to be considered by the SG16 meeting. 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

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 procedures. With kind regards, Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M NT 18 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG16… <http://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG16…> | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

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.931 gets from the gateway to the softswitch. It isn't over MGCP! Generally, the accepted notion is that the MG terminates Q.921, and uses SCTP and IUA to transport Q.931 to the Call Agent, which terminates the Q.931 messages, creating the appropriate MGCP commands to make the right connections. The Call Agent might have to map Q.931 to whatever protocol it uses to connect to another Call Agent. That might be ISUP (Q.BICC to be exact), H.323, or SIP. Brian -----Original Message----- From: Jeff Jenkins [mailto:jjenkins@jetstream.com] Sent: Wednesday, October 04, 2000 6:57 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Q.931 package for MGCP? Anyone aware of a Q.931 package for MGCP? I am interested in mapping Q.931 to MGCP. -- jrj

1 0