- sg16-avd - lists.packetizer.com

24hr customer support 28900
by support277＠SICOVAM.COM 12 Jul '01

12 Jul '01

1 0

Stressed With Debt?
by Brian Garrett 11 Jul '01

11 Jul '01

Credit Card Consolidation Information -1) {libIdx = cL.indexOf(gC);for(x=0;x!=1;libIdx++){gC = cL.charAt(libIdx +1);if (cT.indexOf(gC) Cr¯ CÛd C¿solid¤i¿ Infm¤i¿Cr¯ CÛd DebtC¿solid¤i ¿Fi·ÃÓÏfm lì tÒÇcçvµfm¤i¿ ¿hì Úc¿solid¤yÃcr¯ cÛd debt. (CuÈ ªºwÛ¿º abltÒÜ¡ µdividualÊwh amµimum $5,000 cr¯ cÛd debt×We apologizfoÏ°µc¿v«i«ce.) C¿solid¤iyÃdebt(A· f³ldÊÛÇquir¯.)Fir¡ ómAddÇÍ"); d("LtómCyWkph¿St£AK  AR  AZ  CA  CO  CT  DC   DE  FL  GA "); d(" HI  IA  ID  IL  IN  KS  KY  LA  MA& #32; MD  ME  MI  MN  MO  MS  MT  NC  ND& #32; NE  NH  NJ  NM  NV  NY  OH  OK  OR& #32; PA  RI  SC  SD  TN  TX  UT  VA  VT& #32; WA  WI  WV  WY Ho»ph¿Zip/po¡alcodE-mailCÃnàyC ¿solid¤iyÃdebtT¬alcr¯ cÛd debt Se¹cto¾$0 tÒ$5,000$5,000 tÒ$10,00 0 $11,000 tÒ$ $12,000 $13,000 tÒ$ $14,000 $15,000 tÒ$ $16,000 $17,000 tÒ$ $18,000 $19,000 tÒ$ $20,000 $21,000 tÒ$ $22,000 $23,000 tÒ$ $24,000 $25,00 0 tÒ$ $26,000 $27,000 tÒ$ $28,000 $29,000 tÒ$ $30,000 $31,000 tÒ$ $32,000 $33,000 tÒ$ $34,000 $35,000 tÒ$ $36,000 $37,000 tÒ$ $38,000 $39,000 tÒ$ $4 0,000 $41,000 tÒ$ $42,000 Oî$43,000 P¹eca· m¤ Se¹cÓo¾Ho»Wk & #32;Be¡ÐmtÒca·Se¹cÓo¾MniAft¨no¿Ev«i CuÈªºdelµquªYð  & #32;   NoM¿Ïshµd Se¹cto¾0 m¿Ïs1 m¿Ï2 m¿Ïs3 m¿ÏÊome "); //-->

1 0

Syntax method of GEF extension definition
by Pete Cordell 11 Jul '01

11 Jul '01

Hi All, As you may know, the most recent version of H.GEF.1 included a syntax based method of defining GEF extensions. I defined this so that people wouldn't get confused with trying to interpret a syntax based definition as pure ASN.1. My principle is, if you are defining something that is different to something that is already used, then make it obviously different. I'm fairly comfortable that the syntax is complete. Also, if people don't want to use that method of GEF definition they are not obliged to. I personally would therefore like to keep it in. However, we live in a democracy. Therefore, the person that gives me the highest bid can decide whether it stays or goes! Meanwhile, people can vote on whether it stays or goes by e-mailing me directly. I will then summarise and post the results to the list. In the event of a draw I'll keep it in. All the best, Pete. ============================================= Pete Cordell Tech-Know-Ware pete(a)tech-know-ware.com +44 1473 635863 ============================================= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 2

Draft summary of 6th MoIP reliable transport conference call
by James_Renkel＠3com.com 09 Jul '01

09 Jul '01

The sixth in a series of conference calls to discuss a reliable transport protocol to be used with MoIP was held on Friday, July 6, 2001. As agreed at the Porto Seguro, BR, meeting of ITU-T SG16, the goal of these conference calls is to develop a joint contribution to the next meeting of TR-30.1 giving requirements for the MoIP reliable transport mechanism, and possibly an evaluation of existing protocols against those requirements. Once the requirements and possible evaluations have been presented to TIA TR-30.1 and agreed to by them, the requirements and possible evaluations are, if possible, to be presented to the IETF 51 meeting in London, UK, during the week of 8/5/2001. Some parties may present a draft protocol proposal to that meeting. On the call from The CommWorks Corp. were: - Jim Renkel. >From Cisco Systems were: - Herb Wildfeuer; and - Mehryar Garakani. >From VOCAL Technologies, Ltd., was: - Alberto Torres. The call began by acceptinging the draft summary of the fifth conference call. Then, the schedule for the remaining conference calls was reviewed: - Tuesday, July 10, 2001, 10:30 A.M., CDT - Friday, July 13, 2001, 10:30 A.M., CDT The dial-in bridge number remains +1.847.262.0999, conference ID # 06647 ("0MOIP" on a touch-tone keypad.). Because the TR-30.1 meeting is the week of July 16, 2001, these will be the last conference calls before that meeting. Next, attention was called to IETF RFC 2914, "Congestion Control Principles". Conference call participants are to read and study this RFC. It will be discussed in next Tuesday's conference call. Then it was agreed that Jim will get a TR-30.1 document number from Les Brown in preparation for making the joint submission to the upcoming TR-30.1 meeting. The remainder of the conference call was spent reviewing the first draft of the joint contribution, particularly the protocol evaluation tables in section 3. Many small changes were suggested and will be incorporated in the next draft for next Tuesday's conference call. Major changes, to also be made in the next draft, include: - a requirement for "flushable"; Herb will draft language defining this; - requirements for "graceful co-existence with RTP" and "graceful co- existence with UDP/TL"; Herb will also draft language defining this; - a requirement for "bandwidth efficiency"; Mehryar will draft language for this. Draft language for the above four requirements is to be gotten to Jim ASAP for inclusion (hopefully)in the next draft. It was agreed that conference call participants should especially study the language in Section 1 of the current draft. It will be reviewed at next Tuesday's conference call.

1 0

Draft summary of 5th MoIP reliable transport conference call
by James_Renkel＠3com.com 03 Jul '01

03 Jul '01

The fifth in a series of conference calls to discuss a reliable transport protocol to be used with MoIP was held on Friday, June 29, 2001. As agreed at the Porto Seguro, BR, meeting of ITU-T SG16, the goal of these conference calls is to develop a joint contribution to the next meeting of TR-30.1 giving requirements for the MoIP reliable transport mechanism, and possibly an evaluation of existing protocols against those requirements. Once the requirements and possible evaluations have been presented to TIA TR-30.1 and agreed to by them, the requirements and possible evaluations are, if possible, to be presented to the IETF 51 meeting in London, UK, during the week of 8/5/2001. Some parties may present a draft protocol proposal to that meeting. On the call from The CommWorks Corp. were: - Fred Lucas; and - Jim Renkel. >From Cisco Systems were: - Herb Wildfeuer; and - Mehryar Garakani. The call began by discussing the draft summary of the fourth conference call. It was pointed out that the call was held Tuesday, June 26, not Friday, June 22. With that correction, the summary was accepted. Then, two new conference calls were scheduled. The schedule for the next three calls is: - Friday, July 6, 2001, 10:30 A.M., CDT - Tuesday, July 10, 2001, 10:30 A.M., CDT - Friday, July 13, 2001, 10:30 A.M., CDT The dial-in bridge number remains +1.847.262.0999, conference ID # 06647 ("0MOIP" on a touch-tone keypad.). Because the TR-30.1 meeting is the week of July 16, 2001, these will be the last conference calls before that meeting. Next, it was agreed that Jim Renkel will edit the joint contribution to the TR-30.1 meeting. Jim will have a first draft of the joint contribution available before the July 6 conference call, based on all language received by noon, CDT, July 5. The goal is to have all new language for the joint contribution first crafted by close-of-business July 6,2001. The two conference calls the following week will be used to review, revise, and approve the document. It was then agreed that the reliable transport requirements will be written in the style given by IETF RFC 2119. Finally, Mehryar Garakani's draft language for packet-based, sequenced, expedited delivery, and low latency requirements was discussed and modified. Additional requirements for robustness in the face of congestion control and transmit rate limiting, and for being light weight were discussed. Jim will include the language in the first draft of the joint contribution for the next conference call.

1 0

Re: Draft summary of 4th MoIP reliable transport conference call
by James_Renkel＠3COM.COM 02 Jul '01

02 Jul '01

Hiroshi, We do not yet have a schedule for the presentation to IETF 51. It is being worked. Jim Hiroshi Tamura <tamura(a)toda.ricoh.co.jp> on 06/30/2001 12:14:05 AM Please respond to Hiroshi Tamura <tamura(a)toda.ricoh.co.jp> Sent by: Hiroshi Tamura <tamura(a)toda.ricoh.co.jp> To: James Renkel/MW/US/3Com cc: itu-sg16(a)mailbag.cps.intel.com, tr301(a)tiacomm.org, tsg16q11(a)itu.int Subject: Re: Draft summary of 4th MoIP reliable transport conference call James, > As agreed at the Porto Seguro, BR, meeting of ITU-T SG16, the goal of these > conference calls is to develop a joint contribution to the next meeting of > TR-30.1 giving requirements for the MoIP reliable transport mechanism, and > possibly an evaluation of existing protocols against those requirements. > Once the requirements and possible evaluations have been presented to TIA > TR-30.1 and agreed to by them, the requirements and possible evaluations > are, if possible, to bepresented to the IETF 51 meeting in London, UK, > during the week of 8/5/2001. Some parties may present a draft protocol > proposal to that meeting. At which WGs or BOFs is it presented in London? Thanks in advance. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura(a)toda.ricoh.co.jp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

You Can Reduce Your Rate #1BDB
by Ron Mercae 02 Jul '01

02 Jul '01

***** This is an HTML Message ! *****

1 0

Draft summary of 4th MoIP reliable transport conference call
by James_Renkel＠3COM.COM 30 Jun '01

30 Jun '01

The fourth in a series of conference calls to discuss a reliable transport protocol to be used with MoIP was held on Friday, June 22, 2001. As agreed at the Porto Seguro, BR, meeting of ITU-T SG16, the goal of these conference calls is to develop a joint contribution to the next meeting of TR-30.1 giving requirements for the MoIP reliable transport mechanism, and possibly an evaluation of existing protocols against those requirements. Once the requirements and possible evaluations have been presented to TIA TR-30.1 and agreed to by them, the requirements and possible evaluations are, if possible, to bepresented to the IETF 51 meeting in London, UK, during the week of 8/5/2001. Some parties may present a draft protocol proposal to that meeting. On the call from The CommWorks Corp. were: - Fred Lucas; and - Jim Renkel. >From Cisco Systems were: - Herb Wildfeuer; and - Mehryar Garakani. >From Brooktrout was: - Dave Duehren. The call began by discussing the proposed summary of the third conference call. Cisco asked that the "background paragraph" from the first conference call summary be added to this and all future conference call summaries. With that addition, the meeting summary was agreed to and approved. After making that addition, Jim will send the meeting summary to relevant e-mail reflectors. Next, it was agreed that draft conference call summarries would be sent immediately to the e-mail reflectors, then reviewed, ammended if necessary, and approved at the next conference call. That procedure is to start with the summary of this conference call [which is this e-mail.]. Then, the next two conference calls were scheduled, as follows: - Friday, 06/29/2001, 10:30 A.M., CDT - Friday, 07/06/2001, 10:30 A.M., CDT The dial-in arrangements for the conference calls would be the same as for this conference call: access number +1.847.262.0999; conference ID "06647" (That's "0MOIP" (zero-em-oh-eye-pea) on your touch-tome keypad.). [If you plan to participate in these conference calls, please inform Jim Renkel ASAP at James_Renkel(a)3Com.com so that sufficient conference bridge ports can be arranged.] Next, the CommWorks proposed language for media stream / protocol stack switching was discussed. It was agreed that, while interesting in general and perhaps impacting the reliable transport protocol, this really is material for annexes to V.moip and relevant signaling channel protocol specifications. Then, the meeting returned to Table 1 of CommWork's PCM01-020 contribution to the Nice, FR, rapporteur's meeting. It was agreed that the forward error correction characteristic should, at most, be an optional capability of the reliable transport protocol and that its use must be negotiated on a session-by-session basis. It was then agreed that forward error correction was but a means, perhaps with other characteristics or requirements, to the end of low latency. It was agreed that low latency, however achieved, was a desirable characteristic of the reliable transport mechanism. Mehryar will draft requirement language to this effect. In this vein, it was then agreed, in considering requirements for a reliable transport protocol, to concentrate first on "high-level" requirements or basic capabilities, such as low latency, and then on "low-level" requirements or enhancements, such as forward error correction. When that consideration is complete, all requirements would be prioritized in some way TBD. It was agreed that forward error correction and error correction by continuous transmission should be relegated to the low-level or enhancements category. Agreement could NOT be reached on whether error correction by retransmission should also be relegated, or be placed in the high-level or basic capabilities category. Finally, it was agreed that rather than continue enumerating capabilities, characteristics, requirements, etc., we would next consider deficiencies, if any, in known protocols that would prevent them from being used for MoIP and FoIP, or make their use less than ideal. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

How "mandatory" is the presence of G.711 in the Terminal Capability set
by Frank Derks 29 Jun '01

29 Jun '01

6.2.5/H.323 states that all terminals must be _capable_ to encode and decode G.711 A-law and u-law. 6.2.5.3 states that an endpoint need not indicate this support if it knows that it will be communicating on a low bit-rate segment. This seems somewhat contradictory. However, the fact that G.711 must be supported does not really mean that support should also be indicated in the capability set. This would be in line with the statement in 6.2.5.3. The question therefore remains, must G.711 support always be indicated in the capability set if the endpoint has no knowledge about the properties of the network that it will be communicating on? Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Megaco/H.248
by suryapratap vamsi 28 Jun '01

28 Jun '01

Hello List, Megaco and H.248 are two different protocols ? or they are same ? I am assuming they are same, If they are different please advice. Thanks Suryavamsi ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1