- sg16-avd - lists.packetizer.com

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

[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