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

APC Document number
by Noriko Hosokawa 12 Sep '99

12 Sep '99

Dear Mr. Dan Gal In response to your request, APC-1650 has been allocated to your contribution. APC-1650 Source: Lucent Title : H.245 Generic Capabilities Definition and H.225 Packetization Specification for the Cellular/PCS CDMA EVRC Voice Codec. 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 *********************************************************** Documents for Q.12-14/16 Rapporteur meeting in Red Bank (18-22 October 1999) The documents can be retrieved as ftp://standard.pictel.com/avc-site/9910_Red/APC-1???.??? or http://standard.pictel.com/ftp/avc-site/9910_Red/APC-1???.??? ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1645 TIPHON Proposal for an H.323 "Security Profile" 1646 Motorola Annex-H(User and Service Mobility in H.323) 1647 Lucent Mobility Agents in H.323 Reference Architecture 1648 Lucent Registration Procedure for Wireless Mobile H.323 Terminals 1649 Lucent Mobility States for the Mobile H.323 Terminals 1650 Lucent H.245 Generic Capabilities Definition and H.225 Packetization Specification for the Cellular/PCS CDMA EVRC Voice Codec. 1651 AT&T H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1652 AT&T Viewgraph Presentation of H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1653 1654 1655 1656 ----------------------------------------------------------------------------

1 0

APC Document number
by Noriko Hosokawa 12 Sep '99

12 Sep '99

Dear Mr. Radhika R. Roy In response to your request, APC-1651 and 1652 have been allocated to your contributions. APC-1651 Source: AT&T Title : H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility APC-1652 Source: AT&T Title : Viewgraph Presentation of H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 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 *********************************************************** Documents for Q.12-14/16 Rapporteur meeting in Red Bank (18-22 October 1999) The documents can be retrieved as ftp://standard.pictel.com/avc-site/9910_Red/APC-1???.??? or http://standard.pictel.com/ftp/avc-site/9910_Red/APC-1???.??? ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1645 TIPHON Proposal for an H.323 "Security Profile" 1646 Motorola Annex-H(User and Service Mobility in H.323) 1647 Lucent Mobility Agents in H.323 Reference Architecture 1648 Lucent Registration Procedure for Wireless Mobile H.323 Terminals 1649 Lucent Mobility States for the Mobile H.323 Terminals 1650 Lucent H.245 Generic Capabilities Definition and H.225 Packetization Specification for the Cellular/PCS CDMA EVRC Voice Codec. 1651 AT&T H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1652 AT&T Viewgraph Presentation of H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1653 1654 1655 1656 ---------------------------------------------------------------------------- ----

1 0

Megaco/H.248 Contexts and Context Parameters
by Tom-PT Taylor 12 Sep '99

12 Sep '99

We have had a long discussion on the Megaco list about whether the sort of topology micro-management proposed in Berlin, with "Topology" as a context property, is really necessary. I would summarize the outcome of that discussion by saying that we can meet the known requirements for Legal Interception (if a vendor chooses to implement it in the MG) without the proposed Topology property. However, that property could allow for some value-added capability in a gateway (e.g. the difference between the subject of an operator intervention hearing only the operator and hearing the operator and also the other parties to the call in the background). I therefore propose this as the consensus resolution: the Topology property will be defined in the protocol, but support is optional both at the MG and the MGC. With this resolution in mind, I propose a change in the opening paragraph of section 6.1, "Contexts", of the current draft. It currently reads: "A Context is an association between a number of Terminations. The Context describes the topology (who hears/sees whom) and the media mixing and/or switching parameters if more than two Terminations are involved in the association." I propose instead this more expanded description: "A Context is an association ... Terminations. When more than two Terminations are present in a Context, the Context takes on the properties of a mixing bridge. The default assumption for audio streams is that the Context serves as an N-1 additive bridge, passing to each Termination the sum of inputs from all other Terminations in the context. When other media or other types of mixing are desired, the mixing behaviour for each stream must be stated explicitly as a context parameter. "By default, the Context is assumed to implement a star topology with the mixing bridge at the centre. The topology of the media flows through the context is controlled by controlling the flows into and out of the context at the individual Termination level. The flows between the Terminations and the mixing bridge are assumed to be continuations of the external flows in each direction. "As a value-added option, some MGs may support an alternate mesh topology through the mixing bridge. To control this, the protocol provides for a Topology property at the context level. Support of this property is optional at both the MG and the MGC." ------------- Following on from that, we need help from the specialists in Study Group 16, to create the appropriate syntax, first to describe the bridging properties and secondly to describe the topology. I will remind people proposing the syntax that the bridging behaviour will generally be different for each medium, and hence must be tied to the StreamID. Tom Taylor Advisor -- IPConnect Standards E-mail: taylor(a)nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961

2 1

Introducing: Dr As Cellulite Reducing & Weight Loss System
by Andy 12 Sep '99

12 Sep '99

Hello, We work with a weight loss physician (also American Board Certified in Family Medicine), who has formulated a topical gel product that has been very successful in the elimination of cellulite fat. This cellulite-reducing topical gel product is simply amazing! You literally have to measure yourself before and after using this product to believe it. Testimonials are flooding into this physician s office from people who have lost both inches and pounds, after just the first week of using the system. Here is just one of them: "I lost nine and half inches total, after my very first week of applying the gels. After my second and third weeks of application, I lost an additional 18 inches. My inches loss, as well as my weight loss, accelerated tremendously, when I started using the weight loss pills that came in my pak. In three months, I have lost a total of 42 inches and 22 pounds! Whats more, I have more energy than ever, I sleep better and I feel so much healthier. Presently, my friends, having seen the great results I have had with Dr As Cellulite Reducing & Weight Loss System, are now using the system as well. One of them lost an astounding 18 inches total after her very first week of applying the gels. Her self esteem is so much improved. Need we say more? If you will like to receive FREE info about Dr As Cellulite Reducing & Weight Loss System, fill the Info Request Form below, and fax it to: 208-246-1506 Info Request Form: Yes, please send me the FREE info on Dr As Cellulite Reducing & Weight Loss System. Please forward the said info to my LEGIBLY written or typed email address below. Thanks. Email Address : ________________________________________________ Note: Info is only sent by email. Thank you for your time. You will receive complete info within 72Hours on regular weekdays. ********************************************************************* To be removed reply to: mailto:citra157@usa.net?subject=remove *********************************************************************

1 0

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

10 Sep '99

Dear Jin, You asked following question: > If we are going to describe a complete wireless access system, what are the > problems/weakness of the being-defined 3G systems we are going to > address/attack. At the time I did not have the information to reply. But since then I gotten some contributions that are going into the next 3GPP-2000 meeting and with some proposals I can agree on. The main issue I saw from most of the contributions is that everything is centered on the SGSN. I send a comment to 3GPP-2000 suggesting the following. I mean if we can do IN on IP why not Mobility on the same IP network?? Regards, Ed "Edgar Martinez [1]" wrote: > -------- Original Message -------- > Subject: Re: Lucent contributions to R00 Ad hoc > Date: Fri, 10 Sep 1999 13:55:53 -0400 > From: "Edgar Martinez [1]" <martinze(a)cig.mot.com> > Organization: NSS-NAT > To: "Daniel, Elizabeth Mary (Liz)" <lizdaniel(a)LUCENT.COM> > CC: 3GPP_TSG_SA_WG2(a)LIST.ETSI.FR > References: <199909101704.MAA00109(a)alba.cig.mot.com> > > Dear Mary, > > I attend both TIPHON and ITU-SG16 and read with interest your > contribution on support R99 CS domain terminals. If standardizing > IP wireless is a big consideration. Has anyone looked at > decomposing the SGSN and applying those functional elements into >a existing IP standard, and an existing IP Architecture. > > Regards, > Ed > > "Daniel, Elizabeth Mary (Liz)" wrote: > > > Attached are two contributions to the R00 Ad Hoc. One on handover the other > > on support of R99 CS domain terminals. > > <<s2k_contribs>> > > > Liz Daniel > > > GSM/UMTS Standards > > > Lucent Technologies O > > > Sigma, Swindon, UK > > > Tel: +44 (0) 1793 88 3412 > > > Fax: +44 (0) 1793 88 3815 > > > E-Mail: lizdaniel(a)lucent.com > > > > > > > ------------------------------------------------------------------------ > > Name: s2k_contribs.zip > > s2k_contribs.zip Type: Winzip32 File (application/x-winzip) > > Encoding: base64 > > Description: s2k_contribs > > -- > 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/ -------- Original Message -------- Subject: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first darft]]] Date: Fri, 03 Sep 1999 16:27:25 -0400 From: "Edgar Martinez [1]" <martinze(a)cig.mot.com> Organization: NSS-NAT To: "Yang, Jin (Jin)" <jinyang(a)LUCENT.COM> CC: TIPHON_WG7(a)LIST.ETSI.FR References: <199909031416.JAA27858(a)alba.cig.mot.com> Dear Jin, The cat is out of the bag.. more to follow below... "Yang, Jin (Jin)" wrote: > Ed, > > more questions/comments follow. > > Thanks, > Jin > > ------------------------------ > Dr. Jin Yang > Principal Systems Engineer > GSM, Lucent Technologies > Sigma Building > Windmill Hill Business Park > Swindon SN5 6PP > UK > Email: jinyang(a)lucent.com > Tel: +44 1793 736070 > Fax: +44 1793 883815 > > > ---------- > > From: Edgar Martinez [1][SMTP:martinze@CIG.MOT.COM] > > Reply To: Edgar Martinez [1] > > Sent: 02 September 1999 12:56 > > To: TIPHON_WG7(a)LIST.ETSI.FR > > Subject: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first darft]]] > > > > 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. > If we are going to describe a complete wireless access system, what are the > problems/weakness of the being-defined 3G systems we are going to > address/attack. I can not attack something is being-defined, If it isn't defined. If it is defined to do something and it does it, that's fine. Lets defined wireless VoIP and address and attack those areas. Which is what TIPHON and SG16 is doing...all end-to-end IP issues. It is easier to be backward comparable them forward comparable. e.g., old Rotary phones can not outpluse DTMF and New DTMF phones can do both. Both types of phones are still supported but the old Analog systems are gone, and so are the Adjuncts (today it is called the overlay solutation). Lets focus on IP. If the Radio Access interface has the option to support a pure VoIP connection. The underline pure IP (pIP) Network will need to support what TIPHON is working on now, which is : charging/billing and security, call control procedures, naming and address translation issues, end to end quality of service aspects, verification, demonstration of legacy system interworking. All covered under the TIPHON systems. > > > > > 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.. > > > UMTS, for example, allows you to do 1 and 2. and 3GPP and 3GIP are working > on 3 (with lot of progresses already). If you imply that UMTS directly supports the H.323 Gateway, Gatekeeper MCU, SGW and MGW and both wireless/fixed H.323 PC terminals. Great I'll support it. Can you provide us reference to your claims. Also note that wireless mobility for a H.323 fixed terminals does not include handover, but for H.323 mobile terminal (MT) handover is included. Second point to your question, It would be nice to know what legacy NETWORK(s) is 3GPP-3GIP interworking with, since the voice and data is spit at the RAN where the voice traffic goes to the MSC and the data goes to the GPRS network. You call that alot of progresses? smells like adjuncts.. But you know all this I guess you wanted my confirmation? > > > > 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. > Iu-ps (transport) has GTP/IP/ATM. Do you have any concern here? I miss something, Why ATM? in a end-to-end IP network. > > > > I can not be convinced or believe that this is the pure > > IP solution for wireless. > what is a pure IP solution in your mind? An network that is all IP end-to-end as for your example (Applications/GTP/IP). Like TIPHON system with molitity is a pure IP solution. Thanks, Ed > > > Thanks, > Jin > > > > > > > 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/ > > > > ------------------------------------------------------------------- > > Mail archive for TIPHON_WG7 can be browsed at the following url : > > > > http://www.etsi.org/tiphon/mailing.htm > > ------------------------------------------------------------------- > > > > ------------------------------------------------------------------- > Mail archive for TIPHON_WG7 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

I'm out of the office (auto reply)
by Francois-Xavier Kowalski 10 Sep '99

10 Sep '99

Hello, I am not in the office right now to respond to your mail. I will reply to you (if necessary) upon my return. * For urgent cases, please contact Laurent VALLUY - Hewlett-Packard Telecom Infrastructure Division phone: +33 (0) 4 76 14 58 78 net: LAURENT_VALLUY(a)grenoble.hp.com, LAURENT_VALLUY(a)HP-France-om8.om.hp.com Thank you.

1 0

Implementers Guide; Changes to h.341 MIB
by Irina Suconick 10 Sep '99

10 Sep '99

Paul, Please include the following changes to H.341 MIB in the H.323 Implementers Guide. These changes were approved in the last SG16 meeting in Berlin. Thanks, Irina 1) Removed a double definition of rasAdmissionCallIdentifier from this table. rasAdmissionTable OBJECT-TYPE SYNTAX SEQUENCE OF RasAdmissionTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information about entities that have been admitted by the gatekeeper. It is a list of admitted endpoints. The number of entries equals to the number of admitted endpoints." ::= { rasAdmission 1 } rasAdmissionTableEntry OBJECT-TYPE SYNTAX RasAdmissionTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "It contains objects that describe endpoints that are admitted by the gatekeeper. " INDEX { ifIndex, rasAdmissionSrcCallSignallingAddress, rasAdmissionRasAddress, rasAdmissionCallIdentifier } ::= { rasAdmissionTable 1 } RasAdmissionTableEntry ::= SEQUENCE { rasAdmissionSrcCallSignallingAddressTag MmTAddressTag, rasAdmissionSrcCallSignallingAddress TAddress, rasAdmissionDestCallSignallingAddressTag MmTAddressTag, rasAdmissionDestCallSignallingAddress TAddress, rasAdmissionCallIdentifier MmGlobalIdentifier, rasAdmissionConferenceId MmGlobalIdentifier, rasAdmissionRasAddressTag MmTAddressTag, rasAdmissionRasAddress TAddress, rasAdmissionCRV MmH225Crv, rasAdmissionIsGatekeeper TruthValue, rasAdmissionSrcAliasAddressTag MmAliasTag, rasAdmissionSrcAliasAddress MmAliasAddress, rasAdmissionDestAliasAddressTag MmAliasTag, rasAdmissionDestAliasAddress MmAliasAddress, rasAdmissionAnswerCallIndicator INTEGER, rasAdmissionTime DateAndTime, rasAdmissionEndpointId MmEndpointID, rasAdmissionBandwidth Integer32, rasAdmissionIRRFrequency Integer32, rasAdmissionCallType MmCallType, rasAdmissionCallModel INTEGER, rasAdmissionSrcHandlesBandwidth TruthValue, rasAdmissionDestHandlesBandwidth TruthValue, rasAdmissionSecurity TruthValue, rasAdmissionSrcWillSupplyUUIE TruthValue, rasAdmissionDestWillSupplyUUIE TruthValue, rasAdmissionTableRowStatus RowStatus } 2) Combined the two counters for each variable into one. Each variable had a counter for the number of "In" messages (received) and the number of "Out" messages (sent). Now each variable represents the number of messages that were sent and received. CallSignalStatsEntry::= SEQUENCE { callSignalStatsCallConnections Counter32, callSignalStatsAlertingMsgs Counter32, callSignalStatsCallProceedings Counter32, callSignalStatsSetupMsgs Counter32, callSignalStatsSetupAckMsgs Counter32, callSignalStatsProgressMsgs Counter32, callSignalStatsReleaseCompleteMsgs Counter32, callSignalStatsStatusMsgs Counter32, callSignalStatsStatusInquiryMsgs Counter32, callSignalStatsFacilityMsgs Counter32, callSignalStatsInfoMsgs Counter32, callSignalStatsNotifyMsgs Counter32, callSignalStatsAverageCallDuration Integer32 } 3) rasRegistrationEndpointType is changed from Integer32 to MmH323EndpointType RasRegistrationTableEntry ::= SEQUENCE { rasRegistrationCallSignallingAddressTag MmTAddressTag, rasRegistrationCallSignallingAddress TAddress, rasRegistrationSrcRasAddressTag MmTAddressTag, rasRegistrationSrcRasAddress TAddress, rasRegistrationIsGatekeeper TruthValue, rasRegistrationGatekeeperId MmGatekeeperID, rasRegistrationEndpointId MmEndpointID, rasRegistrationEncryption TruthValue, rasRegistrationWillSupplyUUIE TruthValue, rasRegistrationIntegrityCheckValue TruthValue, rasRegistrationTableNumberOfAliases Integer32, rasRegistrationTableRowStatus RowStatus, rasRegistrationEndpointType MmH323EndpointType, rasRegistrationPregrantedARQ TruthValue, rasRegistrationIsregisteredByRRQ TruthValue }

1 0

Question about SET EndpointType
by henri.maenpaa＠NOKIA.COM 10 Sep '99

10 Sep '99

All, There seems to be redundant information in the endpointType IE concerning SETs. Hopefully this has just been left there accidentally from the earlier versions of H.225v3 drafts. Could someone clarify: First, endpointType can have set "bitmask" octet string along with terminal or gateway structures. OK. Then, if terminal was chosen for endpointType, terminalInfo specifies (again) being a SET with a boolean value. I think this should be removed. If there is some reason for including it there, then shouldn't it be included into gatewayInfo struct as well?!? -Henri Mäenpää, Nokia Wireless Business Communications

2 1

APC document number
by Noriko Hosokawa 10 Sep '99

10 Sep '99

Dear Mr. Orsic, Milo In response to your request, APC-1647,1648 and 1649 have been allocated to your contributions. APC-1647 Source: Lucent Title : Mobility Agents in H.323 Reference Architecture APC-1648 Source: Lucent Title : Registration Procedure for Wireless Mobile H.323 Terminals APC-1649 Source: Lucent Title : Mobility States for the Mobile H.323 Terminals 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 *********************************************************** Documents for Q.12-14/16 Rapporteur meeting in Red Bank (18-22 October 1999) The documents can be retrieved as ftp://standard.pictel.com/avc-site/9910_Red/APC-1???.??? or http://standard.pictel.com/ftp/avc-site/9910_Red/APC-1???.??? ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1645 TIPHON Proposal for an H.323 "Security Profile" 1646 Motorola Annex-H(User and Service Mobility in H.323) 1647 Lucent Mobility Agents in H.323 Reference Architecture 1648 Lucent Registration Procedure for Wireless Mobile H.323 Terminals 1649 Lucent Mobility States for the Mobile H.323 Terminals ---------------------------------------------------------------------------- From: "Orsic, Milo (Milo)" <orsic(a)lucent.com> To: "'okubo(a)GITI.OR.JP'" <okubo(a)GITI.OR.JP> Cc: "Orsic, Milo (Milo)" <orsic(a)lucent.com> Subject: APC Number Date: Thu, 9 Sep 1999 23:19:44 -0500 Dear Mr. Okubo, Will you please assign the APC numbers to the following Lucent contributions that will be presented at the forthcoming October 18-22, 1999 ITU-T SG16/Q 13-14 Rapporteur Meeting in Red Bank, NJ. 1. TITLE: Mobility Agents in H.323 Reference Architecture 2. TITLE: Registration Procedure for Wireless Mobile H.323 Terminals 3. TITLE: Mobility States for the Mobile H.323 Terminals All three contributions are discussing the mobility issues pertaining to the wireless mobile H.323 terminals. It is proposed that these contributions are discuss and adopted for inclusion into the H.323 Annex I document. Thank you very much for your kind attention to this matter. Regards, Milo Orsic Lucent Technologies orsic(a)lucent.com +1 630 713 5161 ----

1 0

Invitation to October Q.11-15 rapporteurs meeting in Red Bank
by Sakae OKUBO 09 Sep '99

09 Sep '99

Dear Q12-14/16 experts, Please find attached the invitation to the next Rapporteur meeting (Red Bank meeting) in October received from the host, AT&T and Lucent. Please note that there is an attachment file. The file has been placed at the PictureTel ftp site as: ftp://standard.pictel.com/avc-site/9910_Red/invitation.zip or http://standard.pictel.com/ftp/avc-site/9910_Red/invitation.zip The meeting notice will follow very soon. 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 *********************************************************** We are pleased to invite experts of Q.11, Q.12, Q.13, Q.14, and Q.15 to the joint rapporteurs' meeting to be held 18 - 22 October, 1999, in Red Bank, New Jersey. Please find attached information regarding the meeting location, meeting logistics, and lodging. Please also note that a block of rooms will be held by the hotel until 22 September, so delegates are encouraged to make arrangements very soon. The hotel had booked another function for Friday night before we made arrangements, so we will need to vacate the meeting rooms by 3:30 on Friday. We know this will disappoint many of us who have become accustomed to running until 7:00 or 8:00 in the evening on the last day. Because of this other function, the hotel is only able to hold a block of 70 rooms for Friday night. We hope this will not be a problem, as the early finish time should allow many delegates to catch a flight on Friday evening. Best Regards, Radhika Roy - AT&T Glen Freundlich - Lucent Technologies

1 0