September 1999 - sg16-avd - lists.packetizer.com

Queries related to H.341 !!
by Aparna Saha 07 Sep '99

07 Sep '99

Hello , I have a few queries related to H.341- Draft 7 ( dated May 1999 ) 1. What is the concept of an interface in H.341 ? For instance, the callSignalConfigEntry in the callSignalConfigTable is indexed by the ifIndex i.e. the interface index. What does this imply ? 2. Why is the field callsignalConfigAvailableConnections in callSignalConfigTable ? ( Page 29 ) The information about available connections should not be a part of the configuration info. 3. The explanation for the field rasRegistrationRasAddressTableIndex in rasRegistrationRasAddressTableEntry is incorrect. What is the correct explanation ?? ( Page 47 ) 4. Why is rasRegistrationTableEntry indexed by both the callSignallingAddress and the srcRasAddress ? ( Page 43 ) Thanks and regards, Aparna.

2 1

Video Conference Sept 12-15, 1999
by videoconf＠nfmail.com 07 Sep '99

07 Sep '99

ANNUAL CONFERENCE September 12 - 15, 1999 Sacramento Convention Center Sacramento, California http://www.pug.com/apug/conf.htm

1 0

Re: RAS to INAP
by Edgar Martinez [1] 07 Sep '99

07 Sep '99

Dear Chatras, Thank for your comments, but the Terminal ARQ/ACF can easily be mapped to the ssf-BCSM (reference q.1124). If the H.323 terminal had a subset of the ssf-BCSM. Below is just an example, these issues would best be handle by SG11/5 or ETSI SPAN3. But, this was the idea I had, wend I proposed the mapping of RAS messages to the INAP messages. The H.323 terminal BCSM for example, would start a call from: PIC: O_Null Start DP: action (Terminal ARQ is send to GK) Terminal go to DP: Orgination_Attempt PIC: Authorize_Origination_Attempt. Wait ..for next DP: action (GK ACF is returned to the terminal ) Terminal go to DP: Origination_Attempt_Authorized, PIC: Collect _Infromation. then to (opitonal DP) DP: Collected _Information. PIC: Analyze_information then to (opitonal DP) DP: Analyzed _Information. PIC: Authorize_Call_Setup then to action (H.225 Setup to EP or GK) PIC: Send_Call Wait ..for next DP: action (H.225 Call Proc/Alert from EP or GK to terminal) Terminal go to DP: O_Term_Seized PIC: O_Alerting Wait ..for next DP: action (H.225 Connect from EP or GK) DP: O_Answer PIC: O_Active Terminal is in call Wait ..for next DP: action (Disconnect, etc..) Regards, Ed CHATRAS Bruno CNET/DAC/ISS wrote: > Dear All, > > The mapping proposed in this document (i.e. ARQ/ACF mapped to IDP/Connect) > suggests that the RAS procedures are included in the BCSM. I do not think > that this is valid, because the admission procedure occurs before call > set-up initiation (i.e. it is too early for creating a BCSM instance). > Indeed, in case the "direct" call model is used, no BCSM instance will be > created after completion of the admission procedure. Moreover, it is almost > impossible to find an obvious mapping between many of the ARQ/ACF parameters > and the IDP/Connect parameters. > > Before trying to map the RAS messages on to INAP operations, we should first > study how the RAS procedures can be modelled in terms of state machines. At > a first glance, it seems that the RAS procedures might be considered as > being some sort of non call related feature very much like a CCBS procedure. > Therefore, it would be wise to study their mapping on to the BCUSM/CUSF > model. If this model appears to be suitable, the ARQ/ACF message will > naturally be mapped to the InitialAssociationDP and ContinueAssociation > operations. However the mapping of parameters will still need to be > considered. > > Alternatively, a deeper analysis may reveal that a completely new kind of > state model (and associated set of operations) would better suit such kind > of procedures. > > Regards, > > > ---------- > > De : Edgar Martinez [1][SMTP:martinze@cig.mot.com] > > Répondre à : Edgar Martinez [1] > > Date : mardi 10 août 1999 16:26 > > A : TSG11Q5 > > Cc : TIPHON : Entirely; Entirely SG16 > > Objet : RAS to INAP > > > > <<Fichier : 13td049.doc>> > > Dear All, > > > > Attached is part of a document I presented in TIPHON 13 and > > the Santiago ITU-SG16 meeting to support > > INAP interworking in H.323. Which help to start the groups > > (TIPHON and SG16), to look at INAP-IPT interworking. > > The reason I sending this out I promise some reps. from > > TSG11 to send the Mapping of the RAS to INAP messages > > as a start. > > > > Regards, > > -- > > Edgar Martinez - Principal Staff Engineer > > Email mailto:martinze@cig.mot.com > > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > > 1501 West Shure Drive, Arlington Hgts. IL 60004 > > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ > > > > > > -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Re: Queries related to H.341 !!
by Irina Suconick 06 Sep '99

06 Sep '99

I added my comments below. Irina > -----Original Message----- > From: Pratima Shah [SMTP:shahp@agcs.com] > Sent: Tuesday, September 07, 1999 11:32 AM > To: ITU-SG16(a)mailbag.cps.INTEL.COM > Subject: Re: Queries related to H.341 !! > > Hi Aparna, > > See my answers below. > > Aparna Saha wrote: > > > Hello , > > > > I have a few queries related to H.341- Draft 7 ( dated May 1999 ) > > > > 1. What is the concept of an interface in H.341 ? For instance, the > > callSignalConfigEntry in the callSignalConfigTable is indexed by > > the ifIndex i.e. the interface index. What does this imply ? > > > > Pratima - Here the ifIndex applys to the H.225 call signaling channel. > Each call > signaling channel will have a unique ifIndex. > [Irina Suconick] interface index is used as a logical number representing an interface to a particular H.323 entity. An example of a multiple entities in one system could be several gateways and a gatekeeper. The interfaces to these entities will be system specific and will be numbered from 1 to n. Therefore each row of a particular table contains the variables that represent a particular entity in a system. Therefore configuration table will contain a row for each entity in a system. If the system consists of only one entity there will be only one row in configuration table. > > 2. Why is the field callsignalConfigAvailableConnections in > > callSignalConfigTable ? ( Page 29 ) The information about available > > connections should not be a part of the configuration info. > > Pratima - Each call signalling channel may support the finite number of > payload > connections and out of these max. number how many are available at a given > time. > > > 3. The explanation for the field rasRegistrationRasAddressTableIndex in > > rasRegistrationRasAddressTableEntry is incorrect. What > > is the correct explanation ?? ( Page 47 ) [Irina Suconick] This is cut and paste error and should be fixed. Instead of the aliases it should be ras addresses. > > 4. Why is rasRegistrationTableEntry indexed by both the > callSignallingAddress > > and the srcRasAddress ? ( Page 43 ) > > Pratima - A Gateway supporting multiple endpoints may register all > endpoints with > the Gatekeeper. And a Gateway may have one signalling address for multiple > RAS > addresses. > > > > > > > Thanks and regards, > > Aparna. > > Theese are my understandings. Someone can correct me if I am wrong. > > Pratima Shah > > -- > =============================================================== > Pratima Shah AG Communication Systems > Phone: (602) 581-4710 -A subsidiary of Lucent Technologies- > Fax: (602) 581-4636 2500 West Utopia Road > Email: shahp(a)agcs.com Phoenix AZ 85027 > =============================================================== > "Expand The Power Of Your Network" > http://www.agcs.com > =========

2 1

Re: ASN.1 Syntax of H.245
by Hidenobu Harasaki 06 Sep '99

06 Sep '99

Dear Mike, > An error has been found in the ASN.1 syntax of H.245 version 5. I support the correction of the error on genericModeParameters. But another correction should be made. TTC (The Telecommunication Technology Committee), Japan has reported me that H.245 version 5 does not have section 6 but eighteen "defined in section 6" descriptions are found in Annex C. They should be corrected as "defined in Annex A". It might be a good chance to correct them before the publication of version 5. I also found that H.245 version 4 draft (included in h245_f.zip) has the same errors. :-< Best regards, Hideh Hidenobu Harasaki harasaki(a)ccm.CL.nec.co.jp Manager, Research C&C Media Research Labs., NEC Corporation Phone: +81 44 856 8083 Fax: +81 44 856 2232

1 0

H.323 mobility aspects
by Edgar Martinez [1] 06 Sep '99

06 Sep '99

Dear Mr. OKUBO, Please (delete/remove) h323mob01.zip. and accept the updated contribution h323mob01a.zip for our next Study Group 16, Q.12-14/16 Rapporteur Meeting in New Jersey, 18-22 October 1999 I have put h323mob01a.zip , in http://standard.pictel.com/ftp/avc-site/Incoming/ The contribution deals with H.323 user and service mobility aspects. Thank you, -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

2 1

RTP session related
by Sunil Chandra 05 Sep '99

05 Sep '99

Hi All, I have few doubts on the RTP session. 1. In any RTP direction of transmission, the destination TA that identifies the session, is also associated with a single RTP payload type. Let us say there is a MCU connected to three terminals a, b and c. a & b are transmitting G.711 A-law and c is transmitting G.729, then a & b can transmit to the same destination TA and for MCU be participant in the same session, whereas c has to transmit to a different TA and will be a participant in a separate session. Is it corret? 2. Can the session in the reverse direction have same session ID even if the payload type is different? If yes, why is this co-relation required? What is the criteria on which the master will decide the same session ID in both directions? 3. Is it required to have same session ID if the payload type is same in both directions? 4. Why the standard has fixed the session IDs for first session of each media type? Why these have to be same in each direction of transmission? 5. What happens to these sessions when a call is converted into an ad-hoc conference and GK becomes the active MC. The original sessions are closed but can the session Ids be reused this way? with regards, Sunil

1 0

Re: MC/MCU related
by Sunil Chandra 05 Sep '99

05 Sep '99

Hi Chris, >> 5. If a call signalling is routed through Gatekeeper, and there exists an >> MCU which is not involved in this call. Is it possible for the Gatekeeper >> to involve this MCU to create an ad-hoc conference from this call. If yes, >> what is the procedure? If not, why? > > You leave the biggest question until last... > And one close to my heart. > I've written a number of documents on this, and now I can't find any of them... > > The tricky bit is working out that this is what you want to do. > I assume you have a gatekeeper which routes both H.225.0 (extended Q.931) call > signalling and H.245 control signalling. > > First off, the gatekeeper uses terminal type for master-slave determination as > if it had the MCU functionality built-in. This is permitted because wherever > the standard talks about a gatekeeper having an MCU it uses the phrase "access > to an MCU". > When the gatekeeper decides a call needs to be split out into a conference (for > example, one of the parties in the call sends a setup using the same > conferenceID and different CallID & CRV) - or even on ARQ for this new call - > the gatekeeper does the following: > 1. Make two calls to the MCU, and get them to state "connected". > 2. Send the MCU the terminal capability sets for the endpoints in the existing > call (one on each call). > 3. Do master-slave determination on each call (the gatekeeper will be "master" > on the original calls, otherwise you're stuffed - but in this case there was > already an MCU in the call, so no problem) - in which the gatekeeper will end > up as "slave" (all MCUs beat all GKs). > 4. "Wire things up" internally such that instead of all the Q.931 and H.245 > messages going directly from one endpoint to the other, each endpoint talks to > the MCU on a different call. > ...and you have a two-party conference (as opposed to a call). The MCU will > now generate various exotic messages, and the endpoints will respond > beautifully - the gatekeeper just passes things through transparently now. Assume that the gatekeeper uses the half call model. Let us say that the callId of the original call was CIo, and callIds of the new calls from gatekeeper to the MCU are CIn1 and CIn2. Now, at the gatekeeper, there are two calls in the conference, one call has one call leg with callId CIo and other call leg with callId CIn1, and the other call has one call leg with callId CIo and the other call leg with callId CIn2. Now, if one of the terminals, want to send any call signalling message e.g. facility to its peer (terminal does not know it is connected to MCU), it will send this message with callId CIo. In this case, gatekeeper has to interpret the message and change its contents to reflect the new callId. This will make the gatekeeper very complex and lead to many interoperability issues as it will be very specific implementation of this feature as opposed to a well defined scenario in the protocol itself. > > Alternatives/extras: > If you trust people to have implemented H.450.2, or you care about everybody > paying properly for everything, > How are various charging models for supplementary services like H.450.2 and H.450.3. Are these very much same as SCN or some other models totally different from SCN models? How does charging issues affect the conversion of call into ad-hoc conference? > you could transfer the calls to the MCU using > H.450.2. > You could send some "CloseLogicalChannel"s to the endpoints in the original > call before connecting them up to the MCU, so that the MCU starts from a "clean > sheet". > > What I've given is a bit of an outline, and it does need a little refinement, > but essentially it should give you a call-to-conference transition with the > endpoints concerned having little or no knowledge of what's going on!!! > > Regards, > Chris > -- > Dr Chris Purvis -- Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > Winkfield Row, Berkshire. RG42 6LY ENGLAND > Phone: +44 1344 899 007 > Fax: +44 1344 899 001

1 0

Redundant silenceSuppression fields
by Paul Long 04 Sep '99

04 Sep '99

It doesn't really matter, but I was wondering, why are there two, apparently redundant silenceSuppression fields in the H.245 ASN.1 syntax, one in AudioCapability.g7231 and another in H2250LogicalChannelParameters? Paul Long Smith Micro Software, Inc.

1 0

None
by dhayanithi＠HSS.HNS.COM 03 Sep '99

03 Sep '99

=

1 0

"fastStart" in the Information message
by Paul E. Jones 02 Sep '99

02 Sep '99

Dear Experts, During the Santiago meeting, a request was made to include "fastStart" information in the Information message in H.225.0. That request was accepted and the field was approved as part of the Implementers Guide. Would the person (or people) advocating that change please contact me? Thanks, Paul

2 1

[Fwd: [Fwd: [Fwd: Re: H.323 mobility first darft]]]
by Edgar Martinez [1] 02 Sep '99

02 Sep '99

Dear All, Very good questions: I passing this email on because MR. Binar questions highlights some key issues. Ed FAQ's on IP wireless mobility. -------- Original Message -------- Subject: Re: H.323 mobility first darft Date: Wed, 01 Sep 1999 17:15:17 -0400 From: "Edgar Martinez [1]" <martinze(a)cig.mot.com> Organization: NSS-NAT To: "BINAR, Simon" <binar(a)isd-nec.co.uk> References: <199909011655.LAA02929(a)alba.cig.mot.com> Hi Simon, Thank you for your comments, Please read on... "BINAR, Simon" wrote: > Hi Ed, > > I looked at the document, and I would have a couple of > questions/comments about it. > > It seems to me that the draft provides the description of a complete > wireless access system. Yes, based on the SG16 Terms of reference. > However, I don't understand the point of > providing such a description, since wireless access systems suitable for > multimedia communications are being specified elsewhere (3GPP). Based on the Terms of reference and the Ad-hoc meetings we had in SG16. The assumptions where: 1. We will have H.323 wireless mobile handsets 2. We will provide IP mobility regardless of terminal type Fixed or Wireless 3. We will interwork with the legacy wireless (Networks and Terminals) which includes handovers.. 3GPP or 3GPP-2000 is based on GPRS and something called the layered approach to the IP network. Which ready means two separate networks one for IP and the other for mobility connected via a GW. The RAN interface (Iu-ps) to the GPRS network element is a lower layer ATM/AAL2 with IP on the upper layer connected to E-SGSN switch. I can not be convinced or believe that this is the pure IP solution for wireless. > > Shouldn't the wireless access system rather be completely transparent to > H.323 signalling? It is completely transparent, take alway the WAU and the HZR and you have your basic H.323 VoIP network. > > > Additionally, it seems to me that the proposed architecture does not > take into account mobility between fixed terminals. I can imagine > situations whereby a user could take his SIM card from one fixed H.323 > terminal to another. In such a case, mobility support at the H.323 > application layer would be required, however, no wireless access system > would be involved, and thus, components such as the WAU would not be > required either... Yes, you are right on the money, look at 8.2.1.5 "H.323 fixed terminal registration in a visited IP network" which implies exactly what you stated. The way it works from my research, is that the IMIS is programed in to the SIM card. The user ID is the IMIS once the user, that is, the IMIS is registered in the HZR. The user can plug the SIM card with the proper IMIS in a wireless terminal or fixed terminal. Please note that in the two fixed case call flows both 8.2.1.5 and 8.2.1.6 no WAU are used or shown. Only for the wireless cases. > > > ---------------------------------------------- > Simon Binar > NEC Europe Ltd. > Tel: +44 (0)1753 606933 > Fax: +44 (0)1753 606901 > EMail: binar(a)isd-nec.co.uk > ----------------------------------------------- > DISCLAIMER: Any views or opinions expressed in > this E-Mail message should be considered as the > personal views/opinions of the author. They do > not necessarily represent the views of the > author's employer. > > > -----Original Message----- > > From: Edgar Martinez [1] [mailto:martinze@CIG.MOT.COM] > > Sent: 23 August 1999 08:19 > > To: TIPHON(a)LIST.ETSI.FR > > Subject: H.323 mobility first darft > > > > > > Dear All > > > > I have uploaded the first H.323 draft, for user > > and service mobility. > > The focus of the document at the moment is to provide full > > mobility regards of terminal types, that is either fixed or wireless > > h.323 terminals. Only using H.323 messages with additional > > extensions to provide seamless wireless handover and > > terminal roaming. > > > > Anyone can pick-up a copy in following wed sites. > > > http://people.itu.int/~emartine/temp/ > or > ftp://standard.pictel.com/avc-site/Incoming/ > > The Filename is h323mob01.zip > > Comments are welcome. > > Best Regards, > -- > Edgar Martinez - Principal Staff Engineer > Email mailto:martinze@cig.mot.com > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > 1501 West Shure Drive, Arlington Hgts. IL 60004 > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ > > ------------------------------------------------------------------- > Mail archive for TIPHON can be browsed at the following url : > > http://www.etsi.org/tiphon/mailing.htm > ------------------------------------------------------------------- -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Re: MC/MCU related
by Lee Hyoung soo 02 Sep '99

02 Sep '99

Dear Sunil Chandra, For question 2,3, I don't have any idea. And for other questions, my opnion follows, Sunil Chandra wrote: > Hi Chris, > > I have following queries related to MC and MCU. > > 1. In H.323 section 6.2.8.4, there is a table which gives the terminal > types values for various terminal types. In this table there are certain > entries marked as NA. Does this mean that these terminal types are not > possible? for example, an MCU is not possible without an MC. I think some component which do not have MC is never be an MCU. > 4. Is it always necessary to have an MC in Gatekeeper? A Gatekeeper which do not have MC is not concerned with master-slave determination. So, in this table, a Gatekeeper which do not have MC was not considered. > 5. If a call signalling is routed through Gatekeeper, and there exists an > MCU which is not involved in this call. Is it possible for the Gatekeeper > to involve this MCU to create an ad-hoc conference from this call. If yes, > what is the procedure? If not, why? I think, H.323 terminal can involve other MCU's MC to make ad-hoc multipoint conference. And signalings between them is outside of standard. For example, someone can make MC as a stand-alone program like UNIX daemon, and use it for other terminal's ad-hoc conference expansion. Best wishes, soo.

1 0

MC/MCU related
by Sunil Chandra 01 Sep '99

01 Sep '99

Hi Chris, I have following queries related to MC and MCU. 1. In H.323 section 6.2.8.4, there is a table which gives the terminal types values for various terminal types. In this table there are certain entries marked as NA. Does this mean that these terminal types are not possible? for example, an MCU is not possible without an MC. 2. Why a terminal can not have a data MP? 3. Why there is no clause for an entity containing MC with audio MP only? 4. Is it always necessary to have an MC in Gatekeeper? 5. If a call signalling is routed through Gatekeeper, and there exists an MCU which is not involved in this call. Is it possible for the Gatekeeper to involve this MCU to create an ad-hoc conference from this call. If yes, what is the procedure? If not, why? WIth Regards, Sunil Chandra Hughes Software Systems

1 0

PEOPLE HELPING PEOPLE
by Warren 01 Sep '99

01 Sep '99

PEOPLE HELPING PEOPLE "GIVE AND YOU SHALL RECEIVE" READ THIS!!! THIS MAY BE THE MOST SIGNIFICANT LETTER YOU RECEIVE THIS YEAR!! Greetings, Hopefully my name is still on the list. When I first read the letter, I thought it was some off- the- wall idea to make money. A week later I met again with my client to discuss the issue. I told him that the letter originally brought to me was not 100% legal. I advised him to make a small change in the letter and it would be alright. I was curious about the letter, so he told me how it works. I thought it was a long shot, so I decided against participating. Before my client left I asked him to keep me updated as to his results. About two months later he called to tell me that he had received over $800,000 in cash!! I didn't believe him so he asked me to try the plan and see for myself. I thought about it for a few days and decided that there was not much to lose. I followed the instructions exactly and mailed out 200 letters. Sure enough the money started coming in!! It came slowly at first, but after three weeks I was getting more than I could open in a day. After about three months the money stopped coming. I kept a precise record of my earnings and at the end they totaled $868,439.00! I was earning a good living as a lawyer, but as anyone in the legal profession will tell you, there is a lot of stress that comes with the job. I told myself if things worked out I would retire from practice and play golf. I decided to try the letter again, but this time I sent out 500 letters. Well, three months after that I had a total of $2,344,178.00!! I just couldn't believe it. I met my old client for lunch to find out exactly how this program works. He told me that there were a few similar letters going around. What makes this one different is the fact that there are seven names on the letter, not five like most others. This fact, alone, resulted in more returns. The other factor was the advice I gave him in making the whole thing perfectly legal, since no one wants to risk doing anything illegal. I bet by now you are curious about what changes I told him to make. Well if you send a letter like this out, to be legal, you must sell something if you expect to receive payment. I told him that anyone sending money out must receive something in return. So when you send a dollar to each of the seven names on the list you must include a note saying "please put me on your mailing list" and include your name and mailing address. Follow these simple instructions exactly and within three months you will receive over $800,000.00. A) Mail a $1 bill (wrapped in a piece of blank paper) to each of the seven names below. Include a note (handwritten or typed) saying "Please add me to your mailing list" and include your name and mailing address.You Must include this note for this to be legal. 1. B & F Marketing 11 Circle Dr. Riverside, RI 02915 2. J. Russell 5201 Kingston Pk. #6-315 Knoxville, TN 37919 3. E-2000 Marketing PO Box 15185 East Providence, RI 02915 . Jerry Newland 220 Raven Dr. Clovis, New Mexico 88101 5. Kal Asi 16511 Whittier Blvd Whittier, CA 90603 6. J. R. Gann 3835 John Glenn Drive Granite City, IL 62040 7. Leonard McGhee PO Box 12727 Seattle, WA 98111-4727 B) Remove the name next to the #1 at the top of the list and move the rest of the names up one position. Then place your name in the #7 position. This is done by saving this to a file and then entering your information on line #7. Be very careful when you type the addresses and be sure to proof read them. C) When you have completed the above instructions you have the option of mailing your new letter in two ways. 1) Through US Postal Service or 2) through e-mail. This letter has been proven perfectly legal for both ways as long as you follow the above instructions, because you're purchasing membership in our exclusive mailing list. To mail this out over the internet, you could browse through areas and find people to send this to all the time. All you have to do is cut and paste e-mail addresses whenever you are on the internet. Or you can use a Bulk E-mail Network to mail your letter in large volumes for you. We highly recommend this method. Contact this Bulk E-mail company now. They have the lowest rates on the net and they are fast, provide effective results and give excellent service. They are running a special for $89.00 per 100,000 mailings and if you order now they are giving away an extra 50,000 mailings free. The number is 207-896-7915. Send this letter to thousands, even millions. This will bring big payoffs. ***Keep in mind that there is no limit to the amount of letters you can send out. The more you send, the more money you will make. We strongly encourage you to mail this letter to family and friends as well. THIS IS A SERVICE AND IS 100% LEGAL!!! (refer to title 18, section 1302 & 1342 of the U.S. Postal and Lottery Laws). This program is also, legal in Canada. Assume for example, that you get 7.5% return rate, which is very conservative. My first attempt was over 11%. 1) When you mail out 200 letters, 15 people will send you $1.00 2) Those 15 people mail out 200 letters and 225 people send you $1.00 3) Those 225 mail out 200 letters and 3,375 people send you $1.00 4) Those 3,375 people mail out 200 letters and 50,625 people send you $1.00 5) Those 50,625 people mail out 200 letters and 759,375 people send you$1.00 6) Those 759,375 people mail out 200 letters and 11,390,625 people send you $1.00 At this point your name drops of the list. Think about it. With only he first 6 levels, you have received over $813,615.00!! Amazing!!! THINK ABOUT IT Before you delete this program from your mailbox, as I almost did, take a moment to read it again and REALLY THINK ABOUT IT. Get a pencil and figure out what could happen when you participate. Figure out the worst possible response and no matter how you calculate it, you will still make alot of money! Any doubts you have will vanish when your first orders come in. IT WORKS! Now, smile all the way to the bank!! This is the power of PEOPLE HELPING PEOPLE. Stephen Corpas ///////////////////////////////////////////////////////////////////// // REMOVE AT mailto:kyydy@yahoo.com?subject=remove ///////////////////////////////////////////////////////////////////// //

1 0

Generate More Sales
by Pete 01 Sep '99

01 Sep '99

*** URGENT *** ACCEPT CREDIT CARDS FOR YOUR BUSINESS AND INCREASE YOUR PROFITS 30%-50% ! INTERNET STOREFRONT HOMEBASED OR MAIL ORDER BUSINESSES WE SPECIALIZE IN HELPING THE SMALL BUSINESS OWNER! IF YOU CALL IN THE NEXT FIVE DAYS YOU WILL RECEIVE: NO APPLICATION FEE NO PROGRAMMING FEE AND YOUR FIRST AND LAST MONTH LEASE PAYMENT IS FREE DON'T FORGET TO ASK ABOUT OUR WEB HOSTING AND DESIGN PACKAGE !!! CALL (888) 264-9272 OUR HOURS OF BUSINESS ARE 9AM - 6PM MST ///////////////////////////////////////////////////////////////////// / Please remove at mailto:kyydy@yahoo.com?subject=remove //////////////////////////////////////////////////////////////////////

1 0