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

Re: Question on Intels new annex-j h.246 proposal..
by Reddy, Paul K 26 Oct '99

26 Oct '99

Dear Edgar, The new annex is H.246 Annex-E not h.246 Annex-J, which is essentially a mapping of MAP (mobile application part) of GSM or ANSI-41 or PDC networks to H.225.0. Please refer to Intel's proposals (APC-1671, APC-1672)at ITU-SG16 reflector (Red Bank Meeting) for more details. Edgar Martinez's Question: Does Intel foresee the same concepts, that is using an adjunct (switched/IP) Gateway used with the legacy Class-5 switches PSTN? to support H.323 terminals on Class 5 switches? Paul Reddy's Answer: Intel's focus is on interworking PLMNs with H.323 networks at MAP level. Other groups already working on the PSTN interworking with H.323 networks, which may provide the support of H.323 terminals on Class 5 Switches. -Paul Paul K. Reddy Intel Architecture Labs, Intel Corporations, 2111 NE 25th Avenue, Hillsboro, OR - 97124, USA. Phone# +1 (503)-264-9896 -----Original Message----- From: Edgar Martinez [mailto:martinze@cig.mot.com] Sent: Sunday, October 24, 1999 1:35 PM To: paul.k.reddy(a)intel.com; ITU-SG16(a)mailbag.cps.intel.com Subject: Question on Intels new annex-j h.246 proposal.. Importance: High Dear Paul, An offical new annex-j for h.246 has been opened, proposed by Intel. Which is Interworking H.323 terminals with the legacy GSM and ANSI wireless networks. What this is proposing is a (MSC+VLR) Gateway that provides H.323 access to the Public Land Mobile Network (PLMN). All the voice and supplementary services will still be provided by the Legacy MSCs. And the data services only by H.323. APC 1671 "H.323 with USIM and PLMN Interworking" and APC 1672 "User Mobility and Service Mobility Services for Wireless Subscribers with H.323 terminals accessing MM over IP and PLMN Networks" Question: Does Intel foresee the same concepts, that is using an adjunct (swithed/IP) Gateway used with the legacy Class-5 switches PSTN? to support H.323 terminals on Class 5 switches? Thanks, Edgar Martinez

2 1

new h.246 annex-e proposal..
by Edgar Martinez [1] 26 Oct '99

26 Oct '99

Dear Paul, Thank you for your reply, and your correction on the new h.246 annex-e. I expect to see some interesting contributions coming your way. You also, pointed out a every informative item. >Other groups already working on the PSTN interworking >with H.323 networks, which may provide the support >of H.323 terminals on Class 5 Switches. Maybe the suggestion on expanding our H.323 interworking to provide PSTN services and H.323 terminal support on a Class-5 switch has merit. But replacing a ISDN terminal or PC with a modem connection to Internet, with a H.323 IP/Class-5 gateway is deja vu. If you have more information could you please share that information with us. Which are the groups working on providing H.323 terminals on Class 5 Switches. Regards, Ed "Reddy, Paul K" wrote: > Dear Edgar, > > The new annex is H.246 Annex-E not h.246 Annex-J, which is essentially a > mapping of MAP (mobile application part) of GSM or ANSI-41 or PDC networks > to H.225.0. So far new parameters in H.225.0 RAS messages, we may also need to to add parameters to H.225.0 (q.931) call control. > > . > Please refer to Intel's proposals (APC-1671, APC-1672)at ITU-SG16 reflector > (Red Bank Meeting) for more details. > > > Edgar Martinez's Question: > Does Intel foresee the same concepts, that is using an adjunct (switched/IP) > Gateway used with the legacy Class-5 switches PSTN? to support H.323 > terminals on Class 5 switches? > > Paul Reddy's Answer: > Intel's focus is on interworking PLMNs with H.323 networks at MAP level. > Other groups already working on the PSTN interworking with H.323 networks, > which may provide the support of H.323 terminals on Class 5 Switches. > > -Paul > > Paul K. Reddy > Intel Architecture Labs, > Intel Corporations, > 2111 NE 25th Avenue, > Hillsboro, OR - 97124, USA. > Phone# +1 (503)-264-9896 > > -----Original Message----- > From: Edgar Martinez [mailto:martinze@cig.mot.com] > Sent: Sunday, October 24, 1999 1:35 PM > To: paul.k.reddy(a)intel.com; ITU-SG16(a)mailbag.cps.intel.com > Subject: Question on Intels new annex-j h.246 proposal.. > Importance: High > > Dear Paul, > > An offical new annex-j for h.246 has been > opened, > proposed by Intel. Which is Interworking > H.323 terminals with the legacy GSM and ANSI > wireless > networks. What this is proposing is a > (MSC+VLR) > Gateway that provides H.323 access to the > Public Land > Mobile Network (PLMN). All the voice and > supplementary services will still be provided > by the Legacy > MSCs. And the data services only by H.323. > APC > 1671 "H.323 with USIM and PLMN Interworking" > and > APC 1672 "User Mobility and Service Mobility > Services for > Wireless Subscribers with H.323 terminals > accessing > MM over IP and PLMN Networks" > > Question: > > Does Intel foresee the same concepts, that is > using an adjunct (swithed/IP) Gateway used > with the legacy Class-5 switches PSTN? to > support > H.323 terminals on Class 5 switches? > > Thanks, > Edgar Martinez -- 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: IN-IPT interworking issue
by Boaz Michaely 25 Oct '99

25 Oct '99

Dear Mr. Mi , Thank you for following up ! I took the liberty of replying to you over the reflectors, since many people are interested: >.What's the conclusion for your contribution? TD-97 (Proposal to simplify the functional architecture for IN support of IP Networks) was the basis for discussion in Manchester and was followed by an editing session of SG11 baseline. A liasion including the result of the updated baseline doc. was sent to SG16 in APC-1602 (attached zip file) (See attached file: APC-1602.zip) >.What kind of service does the interface "H.323 service control" between > MGC and GK refer to? Is it related to MGC originated IPT IN-call >(i.e.the call is coming from PSTN side)? The diagram you refer to is attached for everyone's convenience (IPT-IN.gif) (See attached file: IPT-IN.gif) - In some ways this interface resembles the TCAP interface between the SSF to the SCP: it allows for the IPT service controller (the GK) to instruct the GW on what to do with an incoming call (which may originate in IP or in PSTN). As the diagram depicts, the basic support already exists in RAS, however SG16, as well as some other organizations, have contemplated on expanding it. This proposed interface has not yet materialized. >.To my current understanding, IPT IN-call, for example 800 or 300 >(calling card) calls, is of value only for H.323 terminal originated >call. There is no scenario for MGC originated IPT IN-call. Is that the >case? The typical scenario for a terminal originated call is a PC user, while a GW originated call is for a calling card service. There is no difference between the two for this purpose: The originating endpoint (whether a terminal or a GW), requests the GK to provide the routing information (address, security token, etc) for a destination GW that supports the requested E.164 number. The problem that "IF1" (see diagram) needs to solve, is to allow the GK to consult the IN database for making such decisions. At the same time, it may prove beneficial for the SCP to consult with the GK in a mirrored scenario (assuming the GK based network has a meaningful service knowledge). The trivial example, is off course, the GK's knowledge of the registered endpoints (=logged in users). Finally, please note that in parallel to SG11 work, which aims to define IP interworking for CS-4, SG16 is aiming to define IPT interworking with CS-1, with zero changes to CS-1, and minimal changes to H.323. Please take a look at my editor's web page, which contains links to the relevant documents: http://people.itu.int/~michaely/ Contributions are solicited ! Sincerely, Boaz Michaely. mizk <mizk(a)em.njupt.edu.cn> on 23/10/99 10:24:29 PM To: Michaely Boaz <boaz(a)vocaltec.com> cc: (bcc: Boaz Michaely) Subject: IN-IPT interworking issue Dear Mr.Boaz: I read your contribution TD97 on IN-IPT interworking at SG11/Q4,5&22 Manchester meeting. It interests me a lot because I have been actively involved in IN/Internet interworking issue at SG11/Q5 from the very beginning. My two contributions were the main sources of TD-GEN11/123 and its addendum. Since I didn't attend to Manchester meeting, I would like you to give some information on the following points: .What's the conclusion for your contribution? .What kind of service does the interface "H.323 service control" between MGC and GK refer to? Is it related to MGC originated IPT IN-call (i.e.the call is coming from PSTN side)? .To my current understanding, IPT IN-call, for example 800 or 300 (calling card) calls, is of value only for H.323 terminal originated call. There is no scenario for MGC originated IPT IN-call. Is that the case? Thank you in advance for your information. Best regards, Zhengkun Mi delegate to SG11 MII(formerly MPT), China

2 1

Text Conversation standards report
by Gunnar Hellstrom 25 Oct '99

25 Oct '99

Gunnar Hellström October 23, 1999 This is a report from accessibility related activities in ITU-T Q11-15/16 meeting in Red Bank, New Jersey 1999-10-18—22. in the Multimedia Systems and Services ITU-T Q11-15/16 meeting in Red Bank, NJ, I have participated with a set of accessibility related contributions from LM Ericsson. The contributions can be downloaded from standard.pictel.com/avc-site/9910_red The meeting was successful and the results point towards major achievements in approved accessibility related standards in February 2000. 1 Total Conversation and Text Telephone Services ---------------------------------------------------- A definition of the Total Conversation Service concept is made in a draft multimedia service description F.MCVS, as an extension of the video phone and video conferencing concept, by adding real time text conversation to it. The F.MCVS draft is numbered APC-1690a. It was reviewed briefly. Q1/16 is supposed to bring it to the next SG16 meeting for determination. The Text Telephone Service is also defined here. 2 Text Conversation in IP Multimedia Conversation and IP Text Telephony ---------------------------------------------------------------------------- Telecommunication is moving into the IP networks. Standardised text conversation must be established there as well as it was in the PSTN as text telephony. One main architecture for IP Multimedia and IP Telephony is ITU-T H.323. Text conversation is added by H.323 Annex G, Text Conversation and Text SET. It also defines a simple IP text telephone with text and voice features. A revised version of the document was reviewed in the meeting, and approved. It was submitted as a white contribution to ITU-T in Geneva for decision in the February 2000 SG16 meeting. The submitted document is found as TD-60. The main change from last version was that RTP transport of text is now default and TCP is a preferred option. Also the H.245 message syntax is more precise. For IP transmission of text conversation, an IETF document “RTP-Text” is in the process of being approved. It was reviewed as APC-1689. After checking that it matched the H.323 Annex G progress, it was slightly modified and entered as a contribution for next IETF meeting in Washington DC on November 10. It can be found in Internet-Drafts as ietf-draft-avt-rtp-text-02.txt For the purpose of defining the text conversation presentation protocol T.140 as the contents of RTP-Text, T140 is applied for MIME registration as a media stream of the text type, both with and without the enclosing RTP payload description. When the MIME registration is complete, it is possible to make IP text telephones and IP Total Conversation devices also according to the IETF SIP architecture without any need for further standardisation. 3 Interworking with text conversation in different networks --------------------------------------------------------------- H.248 is an important gateway architecture in creation. It will enable calls to efficiently cross the border between IP networks and other environments, like PSTN and mobile networks. It is important to define how that is to be done for text conversation and text telephony. H.248 is structured in a core document and packages that add specific application information. The creation of H.248 is a joint project between ITU and IETF and the core document will be published also as an IETF document. Text Conversation and Text Telephone packages are proposed in H.248 Annex I. It was entered as APC-1691 to the meeting, and refined into TD-55a. Time did not allow for a thorough review of it. The Core H.248 was approved to go for decision in February. The general format for package definition has been varying and was still varying in the meeting. It was not regarded stable, and therefore only a few very central packages were approved for decision. The other packages, including Annex I, were recommended for determination in February. The text conversation packages will be entered together with other basic packages in one document to the Megaco working group of IETF for the meeting in Washington DC in November. Mike Kallas of Nortel Networks is the editor of the combined document. 4 Text Conversation in ISDN ------------------------------- The approved modification to H.320 multimedia in ISDN to carry text conversation in a H.224 transport channel was again discussed in Q11/16. The required full new text of H.224 and the modification instructions were submitted to ITU for decision via Tom Geary, rapporteur of Q11/16. 5 Text included in the video stream --------------------------------------- The advanced video coding activity H.26L works on a definition of how small amounts of real time text can be transferred in the video stream. They were adviced to use ISO 10646 UTF-8 coding and some kind of usage indicator, that can indicate the application: text description of video, video subtitling, text conversation, copyright info etc. 6 New question definitions ------------------------------ The proposed new question definitions for 2001-2004 were briefly reviewed. Question H is a broadened Accessibility question. The proposed project Mediacom 2004 also includes Accessibility studies. It is important to find out if the ITU members are prepared to put resources into the proposed work items of the Accessibility activities. The definitions are found in APC-1680, TD-11, and TD-12. 7 Conclusion ---------------- If everything goes smoothly, the Total Conversation concept can be complete by February 18, 2000. That will allow any interested organisation to create standardised interworking telecommunication services including text conversation. If properly exploited, it will be a major achievement for anyone, but especially for deaf, hearing impaired, speech impaired and deafblind people. The gateway definition will only be Determined in February and are expected to be Decided later during 2000 together with other H.248 gateway additions. The standards are backwards compatible with earlier telecom services and enable: · Text telephony in PSTN, IP and mobile networks, including concurrent use of voice and text. · Total conversation in PSTN, ISDN, IP, data conferencing and mobile networks allowing simultaneous real time conversation in video, text and voice.______________________________________ Gunnar Hellström LM Ericsson Sweden Mob +46 708 204 288 Tel +46 8 556 002 03 Fax +46 8 556 002 06 Video +468 556 002 05 Txt (All kinds) +46 8 556 002 05 E-mail gunnar.hellstrom(a)omnitor.se

1 0

Changes made in Red Bank
by Brian Rosen 25 Oct '99

25 Oct '99

Red Bank was quite a tiring experience. I hope the work we did at 7:00 am after starting at 8:30 am the previous morning is reasonable (I'll look it over!). Here are the changes we made to Megaco/H.248: 1. The compilation from ASN.1 to ABNF is gone. Annex A will have an ASN.1 which will be encoded with, at least as of now, BER. Annex B will have the ABNF we have been working with, which encodes to text. 2. The wording of the document was changed so that SDP SHALL be used when text encoding and Tag/Value (Appendix D) SHALL be used when binary encoding. This removes one option. 3. Some updates were made to references. An ASN.1 reference was added, RFC2234 was made normative. 4. Some terms in the Definitions and References sections were deleted, as they were no longer used in the text. 5. Clarifications were made in 6.1 to state that a Termination SHALL exists in only one Context at a time. 6. In 6.1.1, context properties were renamed to Attributes. Two new attributes were defined: a "Priority" that is applied per context and is used by the MG when it has conflicts with resource assignment, queuing, etc, and "Emergency", as in 911, which is used for preferential handling in the MG. 7. Text was added in 6.2.1 to state that an MGC can only affect terminations and the resources associated with them (when, for example, multiple virtual MGs are implemented). 8. Properties are now defined with read only or read/write capability. 9. The Descriptor Table in 6.4.2 received minor editing updates. 10. The text that described the hierarchy of Media/Stream/Local-Remote... was moved to 7.1.5 11. Text in 6.2.5 was edited to allow packages to be defined on root. 12. Text in section 7 was added to allow the MGC to instruct the MG to take terminations in or out of service. 13. Text in 7.1.2 was clarified to specify that unspecified optional parameters take defined default values. 14. H.225.0 was removed from the list of MUX types. 15. Text was added to section 7 to make EventsDescriptors and SignalsDescriptors be stream specific, and appear inside Stream. 15. Text in 7.1.5 was clarified to make Local/Remote/LocalControl/Signals/Events appearing at the command level imply stream=1, whatever stream=1 was. Although stream=1 defaults to "audio", it can be assigned to whatever the MGC wants to set it to. 16. TerminationBuffered was moved to LocalControl (although there is, at this writing, still some issues around events that affect this change). 17. Wording on what "send only" mode means was clarified. A stream set to mode=sendonly does not pass received media into the context. 18. Signals were defined NOT to be affected by mode. 19. Section 7.1.9 was edited to specify that when using SDP, "s=", "t=" and "o=" lines are optional, and 'v=' is only required between session descriptors. 20. in 7.1.11, wording was changed so that Signals are defined as proceeding from the termination towards the exterior of the Context. When the same Signal is applied to multiple Terminations within one Transaction, the MG should consider using the same resource for these Signals. Signals now have two default parameters - they need not be defined. One is "SignalType" (Brief, Timeout, On/Off). The other is "Duration". Default values must be specified for these parameters when defining a signal. This means that you can define a signal as normally (defaulting to) Brief, with a specific length, but override it in an EventsDescriptor. The Duration is the length of the signal if it is Brief, the length of the timer if it is TimeOut. Duration is not used with On/Off signals. 21. The table in 7.1.12 was edited to fix errors. Text was added to state that Audit with an empty list causes no descriptors to be returned, and is useful in Subtract to inhibit automatic sending of Statistics. 22. The "Port" parameter of ServiceChange was renamed "ServiceChangeAddress" to account for non IP usage. 23. Digit map wording was edited. The Start timer is started at the beginning of every digit map use, but can be overridden. 23. Text in 7.1.17 was edited to show that the ObservedEvents Descriptor is what Notify returns. 24. Changes were made to the text in 7.1 about topology: - A oneway connection must implemented in such a way that the other Terminations in the Context are not aware of the change in topology. - The Topology Descriptor occurs before any command in an action. - TerminationA or TerminationB may be specified as Choose which takes the value the MG assigns to the first underspecified TerminationID in a command within the same Action as the Topology Descriptor. 25. The "media type" wording in 7.2.1 was removed. 26. Text in 7.25 was edited to clarify various kinds of audits. - Specifying an empty Audit Descriptor results in only the TerminationID being returned. This may be useful to get a list of TerminationIDs when used with wildcard - The table was changed. All the audits with wildcard produce audits of terminations (not lists) - an audit of All contexts with the TerminationID set to root produces a list of all active contextIDs. 27. Changes in AuditCapabilities clarify that events and signals return a possible values of all parameters. 28. Text in 7.2.8 was updated to change Port to ServiceChangeAddress and to permit MGC to MG in service/out of service commands. 29. Additional reasons were added to ServiceChangeReason: 910 Media Capability Failure 911 Modem Capability Failure 912 Mux Capability Failure 913 Signal Capability Failure 914 Event Capability Failure 915 State Loss 30. A line was added to 7.3, command error codes which states: Implementations are encouraged to append diagnostic information to the end of the string. 31. Additional error messages were added (see the list) 32. Text was clarified in Section 9 to state that when the protocol is transported over IP, MGCs shall implement both TCP and UDP/ALF, an MG shall implement TCP or UDP/ALF or both. 33. Wording in 11.1 (Virtual MGs) was edited for clarity. I don't think we changed any behavior. 34. The Packages section was largely rewritten. The changes are numerous, but are not radically different from what was there. Here are some highlights: - Packages have versions. Backwards compatibility is REQUIRED for a new version. A non-backwards compatible change is a new package definition (different packageId) - Packages can "Extend" an existing package. The version of the package being extended must be specified. Extensions only ADD properties, events, signals, statistics and/or new values for parameters . No overloading of names is permitted. - Properties and parameters have a declared type - Properties must specify whether they are defined in TerminationState or LocalControl - Properties have read only or read/write characteristics - Events are described with two sections on parameters, one used with EventsDescriptor, one used with Notify. Names can overlap in these two sections - Default values for SignalType and Duration must be specified - All identifiers are defined with a string name and a binary identifier. 35. Annex A was supplied, with a complete ASN.1 description of the protocol 36. Changes were made in Annex B to realize the changes documented above 37. Annex C, which used to be the "compiler" that complied ASN.1 to ABNF was eliminated. In it's place will be the base package definition. 38. Annex D received heavy editing, primarily adding specific values for various fields. 39. Annex E used to be UDP/ALF. It will have both TCP and UDP/ALF (what used to be Annex E and F). The ABNF for TransactionAck is in this Annex. 40. Annex F will now be transport on ATM. Three protocols will be defined: AAL5/ALF, AAL5/SSCOP and AAL5/MTP3b. All are optional. 41. Annex G will become Appendix G, as the examples are informative. Examples will be updated. 42. A new Annex, H, will have transport on SCTP. Transport on SCTP is optional at both MG and MGC (and MGCs must still implement both TCP and UDP/ALF, and MGs must support one or both of these). Brian Rosen John Segers Editors

1 0

List of participants of the Red Bank Meeting - correction
by Sakae OKUBO 25 Oct '99

25 Oct '99

/// Apologies, I have indicated wrong file in the previous message. /// Dear Q11, Q12-14, Q15 experts, I have placed a provisional list of participants of the Red Bank meeting at the following place: ftp://standard.pictel.com/avc-site/Incoming/TD-00a.zip or http://standard.pictel.com/ftp/avc-site/Incoming/TD-00a.zip This is based on your indication whether you would attend the working dinner last Wednesday. The mark is your major interest as I guess. Seemingly there are several who had registered but are not marked here, and several who had not registered but attended the meeting. Please advise me (okubo(a)giti.or.jp) whatever additions/corrections/deletions you may have. (To Mr. Geary and Mr. Sullivan: if you have definitive lists of Q11 and Q15 participants, please send me your files.) Best regards, Sakae OKUBO (Mr.) *********************************************************** 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 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

List of participants of the Red Bank Meeting
by Sakae OKUBO 25 Oct '99

25 Oct '99

Dear Q11, Q12-14, Q15 experts, I have placed a provisional list of participants of the Red Bank meeting at the following place: ftp://standard.pictel.com/avc-site/Incoming/APC-1748.zip or http://standard.pictel.com/ftp/avc-site/Incoming/APC-1748.zip This is based on your indication whether you would attend the working dinner last Wednesday. The mark is your major interest as I guess. Seemingly there are several who had registered but are not marked here, and several who had not registered but attended the meeting. Please advise me (okubo(a)giti.or.jp) whatever additions/corrections/deletions you may have. (To Mr. Geary and Mr. Sullivan: if you have definitive lists of Q11 and Q15 participants, please send me your files.) Best regards, Sakae OKUBO (Mr.) *********************************************************** 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 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Provisional report of the Red Bank meeting
by Sakae OKUBO 25 Oct '99

25 Oct '99

Dear Q12-14/16 experts, Please be advised that a provisional report of the Red Bank meeting is available at the following place: ftp://standard.pictel.com/avc-site/Incoming/APC-1748.zip or http://standard.pictel.com/ftp/avc-site/Incoming/APC-1748.zip This is an integration of TD-53a (general, Q12), TD-54a (Q13) and TD-47c (Q14) with minimum editing. I will later refine it with all Annexes and the list of participants. I hope this will be useful for your debriefing. Please also be advised that all TDs and missing APC documents have been uploaded to /9910_Red directory. Best regards, Sakae OKUBO (Mr.) *********************************************************** 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 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Question on Intels new annex-j h.246 proposal..
by Edgar Martinez 24 Oct '99

24 Oct '99

Dear Paul, An offical new annex-j for h.246 has been opened, proposed by Intel. Which is Interworking H.323 terminals with the legacy GSM and ANSI wireless networks. What this is proposing is a (MSC+VLR) Gateway that provides H.323 access to the Public Land Mobile Network (PLMN). All the voice and supplementary services will still be provided by the Legacy MSCs. And the data services only by H.323. APC 1671 "H.323 with USIM and PLMN Interworking" and APC 1672 "User Mobility and Service Mobility Services for Wireless Subscribers with H.323 terminals accessing MM over IP and PLMN Networks" Question: Does Intel foresee the same concepts, that is using an adjunct (swithed/IP) Gateway used with the legacy Class-5 switches PSTN? to support H.323 terminals on Class 5 switches? Thanks, Edgar Martinez

1 0

All in One
by Harris 24 Oct '99

24 Oct '99

Start your own 1-900 business or Adult Web Site Business! People are making $$$ week, after week in the 1-900 business. We'll teach you all of our incredible secrets that will take your new exciting business to a whole new level! It's The Simplest and Most Exciting Business You Could Ever Start! *You'll use our "state" of the art equipment! *You'll use our "Live 1 on 1 Psychics" & "Chat Line" girls! *You'll use our incredible Date Line program(s)! No chargebacks! Quick payouts! No expertise needed! Complete programs start at only $99 (no additional charges) The only thing you'll have to do is advertise! This is an excellent turnkey business. We also have excellent turnkey programs if you want to own your own "top" of the line adult web site. ACT NOW!!! For a free color brochure: reply to: mailto:santl9@enotify.com?subject=brochure With the following information: Name:_________________ Address:_________________ City/State/Zip:_________________ email address:_________________ Telephone:_________________ (optional) ///////////////////////////////////////////// To be removed permanantly from this list reply to: mailto:p.deen@angelfire.com?subject=remove /////////////////////////////////////////////

1 0