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

Retire in 2-4 Years #1E44
by Diane R 26 May '00

26 May '00

Dear Friend, I know your time is valuable so I will get right to the point. I'm looking for a few key individuals who are absolutely serious about achieving financial independence in the next 2-4 years. Before you are quick to judge, I ask you to put your skepticism aside for just one minute as you read on. It will be time well spent. Are you serious about: Finding a home/internet based business built around a professional product of real value? Creating a multiple SIX FIGURE lifestyle and helping others achieve the same? Do you feel you are: Committed enough to your goals to spend 10-20 hours a week building your own enterprise? Open-minded and teachable to new and innovative ways of doing business? If you answered YES to any of the above questions then we can help you. I am part of an organization whose mission is to foster financial freedom in the lives of those who truly seek to do so. In today's information age, knowledge is truly a valuable commodity. What if you had the exclusive rights to cutting-edge information that could teach average people all about money? How to make it...how to save it.. and most importantly, how to make it grow itself? Our program: Is not MLM or a franchise, but provides associates with all the training, tools, and personal support one needs to be successful. Can you: Simply return a phone call and direct our qualified prospects through an automated information system that truly does all the explaining for you? See yourself profiting 80% per sale and earning no less than $1000 on every purchase? Recognize a real opportunity when you see one and then call to learn more! YOU HAVE NOTHING TO LOSE AND SO MUCH TO GAIN!!! For more details, call our toll free information line 24 hrs a day. 1-800-320-9895 ext 8702 (2 min msg) There is absolutely no obligation. Please serious inquiries only. We look forward to hearing from you. ///////////////////////////////////////////////////////// Please remove at: mailto:ttbel@myrealbox.com?subject=remove ///////////////////////////////////////////////////////// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility] clarification
by Reddy, Paul K 25 May '00

25 May '00

Hi Francois-Xavier, If we assume that calling and called party numbers are UPT (universal personal telecommunication) numbers then according to European numbering plan mobile phone numbers are distinguishable, according to American Number plan there is no distinction between mobile and non-mobile phone number. Based on telecommunication industry trends towards adopting number portability, which means end-user carry the number with him when changing location, service provide in the same location etc. I would suggest that there should not be a distinction of calling or called party number as mobile or non-mobile, let the H.323 Mobile network figure out routing to the end-user who could be mobile or non-mobile user. -Paul Paul K. Reddy Intel Corporation Office Phone# +1 (503)-264-9896 Mobile Phone# +1 (503)-807-9564 Email: paul.k.reddy(a)intel.com -----Original Message----- From: Francois-Xavier Derome [mailto:Francois-Xavier.Derome@ALCATEL.FR] Sent: Thursday, May 25, 2000 4:13 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: [H.323 Mobility] clarification hi, Before writing a contribution for the annex H, I have a question for clarification. I didn't see a requirement that the calling party and the calling GK should not be aware that the called party is a mobile user and is eventually at a visiting location. What is the feeling of the group ? Shouldn't we add this requirement in the annex or does anybody disagree with it ? fx ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

[H.323 Mobility] clarification
by Francois-Xavier Derome 25 May '00

25 May '00

hi, Before writing a contribution for the annex H, I have a question for clarification. I didn't see a requirement that the calling party and the calling GK should not be aware that the called party is a mobile user and is eventually at a visiting location. What is the feeling of the group ? Shouldn't we add this requirement in the annex or does anybody disagree with it ? fx ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility:] A new editor's draft H.323 Annex H
by Roy, Radhika R, ALARC 24 May '00

24 May '00

Hi, Everyone: We appreciate Jaakko for his quick update about the H.323 Annex H draft (TD-47). This draft is providing us a baseline document (yet to be reviewed and agreed by all of us) against which we need to bring contributions suggesting additions and modifications. In the last SG16 Q.11-15/16 Osaka meeting (May 15-19, 2000), we requested the editor to edit document based on the contributions discussed in the meeting. However, we decided that there was not enough time to review the H.323 Annex H (APC-1816) presented by the editor and the editor will produce a draft that would be reviewed later by all of us. Now Jaakko (Editor) has produced the draft (TD-47) for our review and bringing contributions. In the meantime, we will also address our issues via emails to resolve our issues. In fact, we have already started this process. Let us extend our sincere thanks to the editor. Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com > -----Original Message----- > From: Jaakko Sundquist [SMTP:jaakko.sundquist@nokia.com] > Sent: Wednesday, May 24, 2000 2:15 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] A new editor's draft H.323 Annex H > > Hi, > > Sorry for the late response, but I wasn't able to read my mails during the > last week. > > The latest version of H.323 Annex H is the TD-47 from the Osaka meeting, > ftp://standard.pictel.com/avc-site/0005_Osa/TD-47.zip . TD-56 includes the > meeting notes from the Ad hoc group meetings in Osaka, but I'm afraid that > no meeting minutes from the last teleconference are available. I can tell > you, though, that in the last teleconference the H323AnnexH_EditorsDraft > was > presented by me and some minor changes were introduced by the group after > which the result of that was produced as the contribution APC-1816 for the > Osaka meeting. > > I hope this helps. > > -Jaakko > > > -----Original Message----- > > From: EXT Tiruthani, Saravanakumar > > [mailto:Saravanakumar.Tiruthani@ICN.SIEMENS.COM] > > Sent: 18. May 2000 1:15 > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: [H.323 Mobility:] A new editor's draft H.323 Annex H > > > > > > Hi, > > > > Do we have the latest version of Annex H after the recent > > tel conference on mobility? Is the editor's draft > > standards.pictel.com/avc-site/Incoming/Mobility-AHG/H323AnnexH > > _EditorsDraft. > > zip > > the latest? Is the minutes available for the teleconference? > > > > Any help will be greatly appreciated. > > Thanks, > > Saravanakumar V. Tiruthani > > Siemens ICN > > > > > > -----Original Message----- > > From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] > > Sent: Tuesday, May 09, 2000 7:45 AM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: [H.323 Mobility:] A new editor's draft H.323 Annex H > > > > > > Hi, Jaakko: > > > > 1. Home/Visited/Target/Visiting Network Address > > > > A quick reply related to your comment about mobile IP. > > > > The mobile IP cannot do the job of H.323 in the application > > layer deals with > > multimedia: audio, video, and/or video. > > > > However, if hooks are already there in the H.323 layer, only > > then mobile IP > > or other methods as appropriate can be used in the lower > > layer (e.g., IP, > > ATM) to do the job. > > > > So, the abstraction of home/visiting/foreign/target network > > address (or > > NPoA) should be there in the H.323 application layer. > > > > I hope that this will clarify the FUNDAMENTAL points of > > mobility management > > that AT&T contributions have explained. > > > > 2. GK Discovery > > > > MGA is another alternative option for the GK discovery. It is > > also very > > efficient when compared to the GRQ mechanisms. MGA is an OPTION, not > > mandatory. > > > > If some people do NOT like this, they may use the GRQ > > messages if they feel > > they are happy with it in the cellular environment. AT&T does > > NOT like to > > use the inefficient GRQ messages. > > > > 3. Centralized/Distributed HLFs > > > > AT&T contributions show message flows for all configurations of HLFs: > > Centralized and Distributed. The contributions show that it > > is the same > > messages that used for all cases. > > > > 4. Location_Req > > > > You are now using NEW messages location_req messages for > > mobility messages. > > AT&T contributions propose the new messages like mobility > > binding updates. > > > > You are requested to look into these contributions instead of > > going too. > > > > 5. Communications between HLFs for inter-domain communications. > > > > AT&T contributions show that this is NOT the scope of H.323. It is a > > protocol between the servers. This is nothing to do with the > > H.323 protocol. > > The same is true for directory server to directory server > > protocol, billing > > server to the billing server protocol, etc. > > > > 6. Other comments > > > > We will discuss in the conf call and Osaka. > > > > Best regards, > > Radhika R. Roy > > AT&T > > > > > > > > > -----Original Message----- > > > From: Jaakko Sundquist [SMTP:jaakko.sundquist@nokia.com] > > > Sent: Tuesday, May 09, 2000 8:10 AM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: [H.323 Mobility:] A new editor's draft > > H.323 Annex H > > > > > > Hi Radhika, > > > > > > Find my comments embedded... > > > > > > > > > > > I hope that you have been enjoying the ice-hockey.... > > > > Section 9.1.1: > > > > > > > > Like home domain, AT&T contribution has provided the detail > > > > description of > > > > home GK/zone from a user point. Accordingly, home network > > > > address (network > > > > point attachment) has been explained. In a given zone, a > > > > mobile may move > > > > from one NpoA to another. Like foreign (or > > > > visited/visiting/target) domain, > > > > AT&T contribution has also explained the foreign (or > > > > visited/visiting/target) network address (or NpoA). The > > > > subsequent emails > > > > have also been sent explaining the things. > > > > > > With regards to the home GK, I am considering that it may be a good > > > concept > > > to introduce for some purposes (mainly because of GK > > discovery issues and > > > the Virtual Home Environment concept), but I have not yet > > introduced in > > > the > > > draft, because I want to have a clearer picture of how the > > concept would > > > be > > > used. I certainly do not like the idea of always having to > > contact the > > > home > > > GK in order to be able to use the H.323 services, nor do I > > like having to > > > contact the HLF through the (home) GK. In other words I am > > willing to add > > > the concept as soon as we have agreed on the semantics of > > it. I still do > > > not > > > see the merit of the home NPoA concept, I do not think it > > adds anything > > > that > > > could not be achieved by using e.g. mobile IP. > > > > > > > > > > > > > > > Hope to discuss the same in tomorrow's conf call. > > > > > > > > I am also curious to know which the team won the ice-hockey..... > > > The Hentunen-Kapanen-Lind attacking line was quite superb... > > > > > > > > > - Jaakko > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > For help on this mail list, send "HELP ITU-SG16" in a message to > > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility:] A new editor's draft H.323 Annex H
by Jaakko Sundquist 24 May '00

24 May '00

Hi, Sorry for the late response, but I wasn't able to read my mails during the last week. The latest version of H.323 Annex H is the TD-47 from the Osaka meeting, ftp://standard.pictel.com/avc-site/0005_Osa/TD-47.zip . TD-56 includes the meeting notes from the Ad hoc group meetings in Osaka, but I'm afraid that no meeting minutes from the last teleconference are available. I can tell you, though, that in the last teleconference the H323AnnexH_EditorsDraft was presented by me and some minor changes were introduced by the group after which the result of that was produced as the contribution APC-1816 for the Osaka meeting. I hope this helps. -Jaakko > -----Original Message----- > From: EXT Tiruthani, Saravanakumar > [mailto:Saravanakumar.Tiruthani@ICN.SIEMENS.COM] > Sent: 18. May 2000 1:15 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: [H.323 Mobility:] A new editor's draft H.323 Annex H > > > Hi, > > Do we have the latest version of Annex H after the recent > tel conference on mobility? Is the editor's draft > standards.pictel.com/avc-site/Incoming/Mobility-AHG/H323AnnexH > _EditorsDraft. > zip > the latest? Is the minutes available for the teleconference? > > Any help will be greatly appreciated. > Thanks, > Saravanakumar V. Tiruthani > Siemens ICN > > > -----Original Message----- > From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] > Sent: Tuesday, May 09, 2000 7:45 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: [H.323 Mobility:] A new editor's draft H.323 Annex H > > > Hi, Jaakko: > > 1. Home/Visited/Target/Visiting Network Address > > A quick reply related to your comment about mobile IP. > > The mobile IP cannot do the job of H.323 in the application > layer deals with > multimedia: audio, video, and/or video. > > However, if hooks are already there in the H.323 layer, only > then mobile IP > or other methods as appropriate can be used in the lower > layer (e.g., IP, > ATM) to do the job. > > So, the abstraction of home/visiting/foreign/target network > address (or > NPoA) should be there in the H.323 application layer. > > I hope that this will clarify the FUNDAMENTAL points of > mobility management > that AT&T contributions have explained. > > 2. GK Discovery > > MGA is another alternative option for the GK discovery. It is > also very > efficient when compared to the GRQ mechanisms. MGA is an OPTION, not > mandatory. > > If some people do NOT like this, they may use the GRQ > messages if they feel > they are happy with it in the cellular environment. AT&T does > NOT like to > use the inefficient GRQ messages. > > 3. Centralized/Distributed HLFs > > AT&T contributions show message flows for all configurations of HLFs: > Centralized and Distributed. The contributions show that it > is the same > messages that used for all cases. > > 4. Location_Req > > You are now using NEW messages location_req messages for > mobility messages. > AT&T contributions propose the new messages like mobility > binding updates. > > You are requested to look into these contributions instead of > going too. > > 5. Communications between HLFs for inter-domain communications. > > AT&T contributions show that this is NOT the scope of H.323. It is a > protocol between the servers. This is nothing to do with the > H.323 protocol. > The same is true for directory server to directory server > protocol, billing > server to the billing server protocol, etc. > > 6. Other comments > > We will discuss in the conf call and Osaka. > > Best regards, > Radhika R. Roy > AT&T > > > > > -----Original Message----- > > From: Jaakko Sundquist [SMTP:jaakko.sundquist@nokia.com] > > Sent: Tuesday, May 09, 2000 8:10 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: [H.323 Mobility:] A new editor's draft > H.323 Annex H > > > > Hi Radhika, > > > > Find my comments embedded... > > > > > > > > I hope that you have been enjoying the ice-hockey.... > > > Section 9.1.1: > > > > > > Like home domain, AT&T contribution has provided the detail > > > description of > > > home GK/zone from a user point. Accordingly, home network > > > address (network > > > point attachment) has been explained. In a given zone, a > > > mobile may move > > > from one NpoA to another. Like foreign (or > > > visited/visiting/target) domain, > > > AT&T contribution has also explained the foreign (or > > > visited/visiting/target) network address (or NpoA). The > > > subsequent emails > > > have also been sent explaining the things. > > > > With regards to the home GK, I am considering that it may be a good > > concept > > to introduce for some purposes (mainly because of GK > discovery issues and > > the Virtual Home Environment concept), but I have not yet > introduced in > > the > > draft, because I want to have a clearer picture of how the > concept would > > be > > used. I certainly do not like the idea of always having to > contact the > > home > > GK in order to be able to use the H.323 services, nor do I > like having to > > contact the HLF through the (home) GK. In other words I am > willing to add > > the concept as soon as we have agreed on the semantics of > it. I still do > > not > > see the merit of the home NPoA concept, I do not think it > adds anything > > that > > could not be achieved by using e.g. mobile IP. > > > > > > > > > > > Hope to discuss the same in tomorrow's conf call. > > > > > > I am also curious to know which the team won the ice-hockey..... > > The Hentunen-Kapanen-Lind attacking line was quite superb... > > > > > > - Jaakko > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Problems with GRQ/GCF messages for the GK discovery
by Roy, Radhika R, ALARC 23 May '00

23 May '00

Hi, Everyone: Just to remind that we have to address the problems of the GK discovery using the GRQ/GCF messages in the H.323 mobile environments. I like point out that an alternative method was suggested to use the MGA Message. Both GRQ and MGA messages have problems to discover the GK in mobile environment. However, the meeting report (TD-56, TD-22c) shows that, as if, MGA mechanism cannot be used in any H.323 mobile communications environment. It is NOT simply true because H.323 mobile communications environments include: Wire-line (copper, cable, fiber), Wireless LAN (multi-megabits to multi-gigabits), and/or Cellular Wireless (picocell, microcell, macrocell) Networking environments. The problem for the MGA comes up when the bandwidth is very scarce if the MGA message is multicast periodically. For example, in the ellular wireless (macrocell) network, the bandwidth is very scarce. However, this kind of problem is being addressed by sending the "advertise" message in a UNICAST fashion. For example, 3GPP has proposed mobile IP's "agent advertisement message" to be sent in a unicast fashion (instead of multicast) for their cellular wireless (macrocell) networking environment. The price they are paying is to make the mobility solution a quasi-dynamic (instead of truly dynamic). For all other communications environments [e.g., Wire-line (copper, cable, fiber), Wireless LAN (multi-megabits to multi-gigabits), and/or Cellular Wireless (picocell, microcell)] where the bandwidth is NOT scarce, like mobile IP, the MGA mechanism can be used as appropriate. However, the use of the MGA message is an OPTION, not mandatory. (This mechanism will help the mobile H.323 to interwork with the mobile IP should anyone to implement mobile IP in the lower network layer.) So, both GRQ/GCF/GRJ and MGA mechanisms can be used in a complementary manner as appropriate depending on pros and cons of different networking environments. We will discuss this further. In the meantime, please let me know if you have any questions. Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Srini Beereddy 23 May '00

23 May '00

Pete, It was specified in section 6.3 of H.450.1 specification - a FACILITY message shall not be sent if a SETUP message previously sent or received has not been answered. Srini, Trillium Digital Systems, Inc. -----Original Message----- From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] Sent: Monday, May 22, 2000 12:12 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 Paul, Francois, I stand corrected... I thought I read an e-mail a while back that didn't allow you to send facility before a certain stage in the call setup process. After searching I can't find it, and the context might have been different anyway (i.e. Sending SETUP and then SENDING Facility, rather than sending SETUP and then RECEIVING Facility.) I'm happy now! Pete ============================================= Pete Cordell pete(a)tech-know-ware.com ============================================= ----- Original Message ----- From: Paul Long <Plong(a)SMITHMICRO.COM> To: <ITU-SG16(a)MAILBAG.INTEL.COM> Sent: 21 May 2000 01:21 Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > Pete, > > This is already covered in H.323, so there is no need to say it again or in > another way. Do you think that the text, below, is deficient in some way? > Seems pretty clear to me. > > 8.2.2/H.323v3: "...intermediate entities shall ensure that H.245 messages > encapsulated in Q.931 messages are forwarded to the other endpoint even if > the Q.931 message in which the H.245 message is encapsulated would be > consumed and not forwarded to the other endpoint. This is accomplished by > transferring the encapsulated H.245 message into a Facility message with the > h323-message-body set to empty." > > Paul Long > Smith Micro Software, Inc. > > -----Original Message----- > From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] > Sent: Saturday, May 20, 2000 12:57 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > I note that TD-26 has been accepted to show how TCS can be conveyed in > parallel with fast start. > > However, the example shows the use of call proceeding for receiving TCS > back > from the remote endpoint. This is not typically an end-to-end message, > and > therefore how the procedure works with the gatekeeper routed model needs > to > be addressed. > > Possible solutions are: > > 1. Refer to the new text that says it is the responsibility of the > gatekeeper to forward any tunnelled message for which none is available > using FACILITY. (There might be some objection from some to using a > facility message this early in the call setup process though.) > > 2. Restrict the tunnelling (and probably the fast start info) to > Alerting, > Connect and Facility, which generally are end-to-end. I believe this is > compatible with the latest procedures for deciding when fast start has > been > ignored. > > Which ever option is chosen, it would also be nice to have a picture for > it > also! > > Pete > > ============================================= > Pete Cordell > pete(a)tech-know-ware.com > ============================================= > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

PictureTel ftp server clogged
by Gary Sullivan 22 May '00

22 May '00

Mr. Luthi and Experts, The PictureTel ftp server appears clogged by too much use. The following three addresses seem to be contributing to much of the traffic. The first one in particular seems to be connecting over and over again. If anyone knows who is responsible for these accesses, please let me and Patrick Luthi (luthip(a)pictel.com) know. 202.106.175.147 ghittino.csp.it 202.98.127.17 The additional addresses listed below are also listed in the server's records as potential contributors. However, these appear less likely to be the source of the problem. dl9181.research.kpn.com magicland gwa3.fe.bosch.de www-cache.fh-giessen.de tide78.microsoft.com (that was me) 202.102.72.29 202.104.121.218 202.109.11.36 210.180.127.2 210.205.14.70 211.35.158.253 211.39.4.158 okigate2.oki.co.jp namesvr.giti.or.jp inet-gw2.toshiba.co.jp proxy.indria.es -Gary S. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

For All #64F6
by Niko Tusta 21 May '00

21 May '00

FREE E-COMMERCE MERCHANT ACCOUNT AND A $200 CASH COUPON!! Tired of expensive e-commerce software, set up fees and leasing contracts? Here is the deal: Sign up for our E-Commerce Package and get a free merchant account + a $200 cash coupon. WE MEAN IT! THIS IS A REAL CASH COUPON! YOU PAY IN FACT $200 DOLLARS LESS DURING THIS SPECIAL PROMOTION. THIS OFFER IS ONLY GOOD FOR 7 DAYS. DON'T MISS THIS OPORTUNITY. NOBODY BEATS OUR PRICE! While others charge you hundreds of dollars to get a merchant account or put you on a 48 months non-cancelable lease agreement we charge you NOTHING for your merchant account when you sign up for one of our e-commerce hosting plans. If you wish to stay with your current hosting company or have already a merchant account our offer is even better. We have 7 different E-Commerce plans to suit your individual needs. We have a solution for U.S. beased merchants and international merchants. Wherever you are on this planet, we get your online store up and running within a few days. Check it out first and make an informed decision. You have never seen a package deal like this before: * Your own merchant account with one of the lowest rates in the industry * Real-Time software to accept VISA, MASTERCARD, AMEX, DISCOVER/NOVUS , DINERSCLUB/CARTE BLANCHE, JCB * Direct deposit within 48 hrs into your checking account * Shopping Cart store front software with an easy to use web based interface * Real-Time Credit Card Processing software * Virtual terminal for phone/fax/mail orders * Automated E-mail receipts to your clients * Recurring billing feature with batch uploads * Automatic batch closing * Address verification system (AVS) * Back office to 24/7 access account history * 75 MB (megabytes) of disk space * 30 GB (gigabyte) of data transfer per month * 25 POP3 E-mail accounts * Unlimited alias E-mail addresses * Live web site statistics * Unlimited FTP uploads * Anonymous FTP * CGI directory for your own scripts * Site control panel * Installation included * Tech support included All this and more when you sign up for our E-Commerce Hosting plan for ONLY $69.95 per month and a one time set up fee of $199.00. That 's right. NO ADDITIONAL SET UP FEES or application fees for your merchant account, real-time software or shopping cart storefront. A one-stop E-Commerce solution. And the best is: NO LEASING, NO LONG TERM COMMITMENT. YOU CAN CANCEL ANYTIME. In addition you get a FREE listing in our mall and FREE advertising to promote your store. We drive traffic to your site and help you to become a successful .com business. REQUEST OUR FREE E-MAIL INFORMATION IMMEDIATELY! REMEMBER: THIS SPECIAL OFFER IS ONLY GOOD FOR 7 DAYS! Please reply to: mailto:mtpk@writemail.com?subject=INFO-PLEASE to receive our FREE e -mail information package without obligations. ********************************************************* Remove at mailto:yykpm@usa.net?subject=remove ********************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Francois Audet 21 May '00

21 May '00

We've made it even clearer in v4. Including H.245 and H.225.0 elements. > -----Original Message----- > From: Paul Long [mailto:Plong@SMITHMICRO.COM] > Sent: Saturday, May 20, 2000 5:21 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > Pete, > > This is already covered in H.323, so there is no need to say > it again or in > another way. Do you think that the text, below, is deficient > in some way? > Seems pretty clear to me. > > 8.2.2/H.323v3: "...intermediate entities shall ensure that > H.245 messages > encapsulated in Q.931 messages are forwarded to the other > endpoint even if > the Q.931 message in which the H.245 message is encapsulated would be > consumed and not forwarded to the other endpoint. This is > accomplished by > transferring the encapsulated H.245 message into a Facility > message with the > h323-message-body set to empty." > > Paul Long > Smith Micro Software, Inc. > > -----Original Message----- > From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] > Sent: Saturday, May 20, 2000 12:57 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > I note that TD-26 has been accepted to show how TCS can be conveyed in > parallel with fast start. > > However, the example shows the use of call proceeding for > receiving TCS > back > from the remote endpoint. This is not typically an > end-to-end message, > and > therefore how the procedure works with the gatekeeper routed > model needs > to > be addressed. > > Possible solutions are: > > 1. Refer to the new text that says it is the responsibility of the > gatekeeper to forward any tunnelled message for which none is > available > using FACILITY. (There might be some objection from some to using a > facility message this early in the call setup process though.) > > 2. Restrict the tunnelling (and probably the fast start info) to > Alerting, > Connect and Facility, which generally are end-to-end. I > believe this is > compatible with the latest procedures for deciding when fast start has > been > ignored. > > Which ever option is chosen, it would also be nice to have a > picture for > it > also! > > Pete > > ============================================= > Pete Cordell > pete(a)tech-know-ware.com > ============================================= > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

1 0