- sg16-avd - lists.packetizer.com

Re: [Fwd: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first darft]]] ]
by Yang, Jin (Jin) 13 Sep '99

13 Sep '99

Dear Edgar, The document you attached is a contribution from Lucent, comparing two alternatives (proposed by Ericsson and Alcatel) for CS terminal support in an "all IP" architecture. I did not quite catch the commonality between this discussion and what's happening in TIPHON. (I may miss something, in that case can you kelp?) Also this document was not about IN and IP. (what it said is that IP based MSC can re-use IN platform easily). Would you shed some light on your proposed IN for IP mobility? Thanks, Jin ------------------------------ Dr. Jin Yang 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] > Sent: 10 September 1999 19:39 > To: Yang, Jin (Jin) > Cc: TIPHON_WG7(a)LIST.ETSI.FR; Entirely SG16; TIPHON : Entirely > Subject: [Fwd: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first > darft]]]] > > <<File: R99 support.doc>> > 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

APC Document number
by Noriko Hosokawa 13 Sep '99

13 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 13 Sep '99

13 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 13 Sep '99

13 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 10 Sep '99

10 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

LogicalChannelRateRelease
by Srinivasa Beereddy 10 Sep '99

10 Sep '99

Hi All, H.245V5 introduces new logical channel bit rate change messages. One of the message is LogicalChannelRateRelease. The section B.1.2.4 says the following. B.1.2.4 Logical Channel Rate Release This is sent in the case of a timeout. My question is which timer should be used for the above indicated purpose? There are no new timers added to H.245V5. thanks, Srini Trillium Digital Systems ~ ~

2 1

H.323v4 draft
by Paul E. Jones 09 Sep '99

09 Sep '99

Dear Experts, I have posted a preliminary draft of H.323v4 in the Incoming directory of the AVC site. This draft should contain all of the text approved for v4 during the Berlin meeting. As was mentioned Berlin, we would like to work out issues with the gateway decomposition and application sections as much as possible BEFORE the October meeting. Please, make comments. Also, there was some text that was accepted in Berlin for the Implementers Guide (relating to v2 and v3) and other text that was intended to be introduced as a rapporteur's TD during the September meeting to correct errors in the H.323v3 white contribution. All of that text should be in this v4 draft document. Please bring my attention to anything that is missing. I'll have to speak with Mr. Skran to find out exactly what he would like to introduce via a Rapporteur's TD for H.323v3. However, below is a list of things I would personally like to see introduced during the September meeting. o All changes made to Annex C, which were made to preserve backward compatibility. o Changes made to section 8.1.7 (fast connect procedure) o Changes to 8.4.6 (third party pause) Please voice your opinion on additions to or deletions from this list. Best Regards, Paul

3 3

Questions on H.235
by Aseem Agarwal 08 Sep '99

08 Sep '99

Hi i have the following questions about H.235 procedures: The Diffie Hellman exchange as depicted in Fig 1/H.235 is as follows: EP GK ClrTkn(Dh_a, Time_a) CryptoTkn[(genId_a, time_a,Dh_a)Sign_a] ----------------------------------------------------------------------> ClrTkn(Dh_b, Random_b, Time_a) CryptoTkn[{genId_a,Time_b,Dh_b}Sign_b] ------- <----------------------------------------------------------------------- _____________________________________________________________________________ ClrTkn[{(genId_b XOR Random_b XOR (x)}EHD-secret)] ------- ----------------------------------------------------------------------> ClrTkn[ (genId_a, Random_b) ] <----------------------------------------------------------------------- 1.In the phase II procedure above, how does the EP know about genId_b ? I feel that the genId in cryptoToken in phase I message from GK to EP (second line in the diagram) should have genId_b and not genId_a. Is my understanding correct ? 2.As applied to RAS protocol in H.323 context, for a non subscription based authentication case: Dh_a and Dh_b have public keys for EP and Gk respectively. (x) is requestSeqNum. genId_b has gkId in GCF. What does genId_a have in GRQ ? The above exchange is NOT immune to man-in-the-middle attacks. A third party can easily snoop in and find out Dh_a, Dh_b, GkId and IntegrityMechanism algorithms as these are passed un-ecrypted in GRQ-GCF exchange. How is this authentication procedure any different from just passing a GK assigned dynamic identifier (e.g. EndPointId) in all messages to the GK ?? How is this procedure affected if the EP knows Gk's id apriori (through provisioning or out of band methods as in manual discovery)? 3. H.235 also mentions that this procedures may be used on the call signalling channel as well. The scope of the Key generated as a result of this procedure is not clearly specified. Is this key used for encryption on the call control channel or is it valid only for call signalling channel ? Any pointers would be appreciated. thanks, aseem(a)trillium.com

1 0

Issues with H.235
by Pete Cordell 08 Sep '99

08 Sep '99

Dear All, I'm implementing some of the H.235 stuff and have a few concerns. RandomVal is defined as INTEGER only. This is not a particularly helpful definition as in theory this could be a million bit + integer if needed. Not many computers support such types! In fact, a well known ASN.1 compiler maps this to an int which is a signed 32-bit value on our platform. Is this sufficient? Without further discussion about the range of this value I feel there is a potential for interoperability problems. Perhaps we can say that RandomVal will never be more than 32 bits long, and then add a type like RandomSeq as an OCTET STRING for cases when we need a longer random value. There are also a few other issues, for example: nonStandardParameter in H.235 is defined differently to that in H.225. Why is that? Similarly tokenID only takes an OID. Again, why such a limited format? Regards, Pete ============================================= Pete Cordell pete(a)tech-know-ware.com =============================================

3 2

Re: Pathological bearer cap changes in H.225.0v3
by Callaghan, Robert 07 Sep '99

07 Sep '99

Paul, Your logic is correct. I only attempted to provide you with a summary of the discussion in Santiago. There were a number of IEs that forbidden that were to be added in Berlin. This, in part, came about from one possible solution for transporting QSIG over H.323. Because there was no resolution to the primary question, the IE change was not accepted. This question is scheduled to return at Red Bank. That would be a good chance for your opinion to be heard. The worst case is that everything forbidden will be possible. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Business Communication Systems Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Paul Long [mailto:plong@SMITHMICRO.COM] Sent: Tuesday, September 07, 1999 3:13 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Pathological bearer cap changes in H.225.0v3 Bob, 1. But there has never been a requirement that components of IEs be treated like actual IEs. Where did this come from? This is a gross rationalization. The Recommendation clearly states that this octet shall not be encoded. Therefore, it is perfectly reasonable for an entity to assume that it will never encounter this octet. Geez, what are standards for? What other "shalls" will be relaxed in the future? 2. Even if IE components were to be treated like IEs--which they cannot--this would still not justify the removal of this requirement. H.225.0 says only that "unrecognized," e.g., new, IEs shall be ignored, not that well-known but otherwise clearly prohibited ones shall be ignored, which is what you are proposing. But please prove me wrong. Show me in the H.225.0 Recommendation where it says that 1. IE components, such as Octet 3a of bearer caps, shall be treated like IEs and 2. that well-known but otherwise prohibited IEs shall be ignored. BTW, our products in particular are okay in this regard--they will ignore optional IE fields, even the ones that are prohibited--so I'm not simply trying rationalize something to keep our products from becoming non-interoperable due to a bad design decision. It's just that I don't like the precedent this sets that it's okay to "change the rules once the game has started." I won't go on about this, though. I'm done. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Tuesday, September 07, 1999 12:58 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Pathological bearer cap changes in H.225.0v3 Paul, The question you present was covered in Santiago. The conclusion is that v1 and v2 devices should conform to the procedures for information elements that have content that is not understood. For information elements that are not defined as "must understand" (Calling party number is in this class) if the contents are not understood, then the information element shall be discarded and the connection is completed without this element. For the calling party number information element, if octet 3a is added in order to indicate "presentation restricted" and this in not understood; the calling party number ie is discarded and the connection is completed without this element. If the element is not present, then its contents may not be presented (No problem). Bob ------------------------------------------------------------------ Robert Callaghan Siemens Business Communication Systems Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Paul Long [mailto:plong@SMITHMICRO.COM] Sent: Tuesday, September 07, 1999 1:08 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Pathological bearer cap changes in H.225.0v3 I just took a look at the changes made to H.225.0v3 in Santiago. I noticed that whereas octet 3a of Calling Party Number in Bearer caps "Shall not be present" in H.225.0v1 and v2, it is allowed in v3! And this apparent oversight was not rectified in Berlin after discussion on this reflector. How will we now guarantee interoperability between v1, v2, and v3+ entities? What if some v1 or v2 entities were implemented according to the Recommendation and do not expect this octet to be present and indeed will fail through no fault of their own? Several alternatives were presented back in May. Why was the least interoperable solution kept? Paul Long Smith Micro Software, Inc.

1 0

Re: Pathological bearer cap changes in H.225.0v3
by Pete Cordell 07 Sep '99

07 Sep '99

For the record, I agree with Paul. The rational given for allowing octet 3a is not sufficient to allow backward compatibility with an endpoint conforming to v1, v2. Perhaps it was wrong to not allow octet 3a. It is wrong to allow something that was previously not allowed. Two wrongs don't make a right!!! Just for the record, I think in my implementation, it will be happy to have as many octet 3a, 3b as you care to give it, but will just ignore them. As the standard says there WILL BE NO octet 3as etc, IMO that's quite a legitimate implementation (just a case of being tolerant of what you get). However, as it doesn't know about octet 3as, it will present the information anyway. Thus a valid set of decisions (made without hindsight) doesn't give the results that are desired. How can that be backward compatible??? 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 <ITU-SG16(a)MAILBAG.INTEL.COM> Date: 07 September 1999 20:20 Subject: Re: Pathological bearer cap changes in H.225.0v3 >Bob, > >1. But there has never been a requirement that components of IEs be treated >like actual IEs. Where did this come from? This is a gross rationalization. >The Recommendation clearly states that this octet shall not be encoded. >Therefore, it is perfectly reasonable for an entity to assume that it will >never encounter this octet. Geez, what are standards for? What other >"shalls" will be relaxed in the future? > >2. Even if IE components were to be treated like IEs--which they >cannot--this would still not justify the removal of this requirement. >H.225.0 says only that "unrecognized," e.g., new, IEs shall be ignored, not >that well-known but otherwise clearly prohibited ones shall be ignored, >which is what you are proposing. > >But please prove me wrong. Show me in the H.225.0 Recommendation where it >says that 1. IE components, such as Octet 3a of bearer caps, shall be >treated like IEs and 2. that well-known but otherwise prohibited IEs shall >be ignored. > >BTW, our products in particular are okay in this regard--they will ignore >optional IE fields, even the ones that are prohibited--so I'm not simply >trying rationalize something to keep our products from becoming >non-interoperable due to a bad design decision. It's just that I don't like >the precedent this sets that it's okay to "change the rules once the game >has started." I won't go on about this, though. I'm done. > >Paul Long >Smith Micro Software, Inc. > >-----Original Message----- >From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] >Sent: Tuesday, September 07, 1999 12:58 PM >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: Pathological bearer cap changes in H.225.0v3 > > >Paul, > >The question you present was covered in Santiago. > >The conclusion is that v1 and v2 devices should conform to the >procedures >for information elements that have content that is not understood. For >information elements that are not defined as "must understand" (Calling >party number is in this class) if the contents are not understood, then >the >information element shall be discarded and the connection is completed >without this element. For the calling party number information element, >if >octet 3a is added in order to indicate "presentation restricted" and >this in >not understood; the calling party number ie is discarded and the >connection >is completed without this element. If the element is not present, then >its >contents may not be presented (No problem). > >Bob > >------------------------------------------------------------------ >Robert Callaghan >Siemens Business Communication Systems >Tel: +1.561.997.3756 Fax: +1.561.997.3403 >Email: Robert.Callaghan(a)ICN.Siemens.com >------------------------------------------------------------------ > > >-----Original Message----- >From: Paul Long [mailto:plong@SMITHMICRO.COM] >Sent: Tuesday, September 07, 1999 1:08 PM >To: ITU-SG16(a)mailbag.cps.intel.com >Subject: Pathological bearer cap changes in H.225.0v3 > > >I just took a look at the changes made to H.225.0v3 in Santiago. I >noticed >that whereas octet 3a of Calling Party Number in Bearer caps "Shall not >be >present" in H.225.0v1 and v2, it is allowed in v3! And this apparent >oversight was not rectified in Berlin after discussion on this >reflector. >How will we now guarantee interoperability between v1, v2, and v3+ >entities? >What if some v1 or v2 entities were implemented according to the >Recommendation and do not expect this octet to be present and indeed >will >fail through no fault of their own? Several alternatives were presented >back >in May. Why was the least interoperable solution kept? > >Paul Long >Smith Micro Software, Inc. >

1 0

Most current H.225.0v3 draft?
by Paul Long 07 Sep '99

07 Sep '99

What is the most current draft of H.225.0v3 up for Decision this month? My guess is <ftp://standard.pictel.com/avc-site/9909_Gen/h225v3bcm.doc>. I need to know so that I can be sure I'm using the correct ASN.1 at SuperOp! next week. Thanks, Paul Long Smith Micro Software, Inc.

2 1

Re: Pathological bearer cap changes in H.225.0v3
by Callaghan, Robert 07 Sep '99

07 Sep '99

Paul, The question you present was covered in Santiago. The conclusion is that v1 and v2 devices should conform to the procedures for information elements that have content that is not understood. For information elements that are not defined as "must understand" (Calling party number is in this class) if the contents are not understood, then the information element shall be discarded and the connection is completed without this element. For the calling party number information element, if octet 3a is added in order to indicate "presentation restricted" and this in not understood; the calling party number ie is discarded and the connection is completed without this element. If the element is not present, then its contents may not be presented (No problem). Bob ------------------------------------------------------------------ Robert Callaghan Siemens Business Communication Systems Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Paul Long [mailto:plong@SMITHMICRO.COM] Sent: Tuesday, September 07, 1999 1:08 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Pathological bearer cap changes in H.225.0v3 I just took a look at the changes made to H.225.0v3 in Santiago. I noticed that whereas octet 3a of Calling Party Number in Bearer caps "Shall not be present" in H.225.0v1 and v2, it is allowed in v3! And this apparent oversight was not rectified in Berlin after discussion on this reflector. How will we now guarantee interoperability between v1, v2, and v3+ entities? What if some v1 or v2 entities were implemented according to the Recommendation and do not expect this octet to be present and indeed will fail through no fault of their own? Several alternatives were presented back in May. Why was the least interoperable solution kept? Paul Long Smith Micro Software, Inc.

2 1

Pathological bearer cap changes in H.225.0v3
by Paul Long 07 Sep '99

07 Sep '99

I just took a look at the changes made to H.225.0v3 in Santiago. I noticed that whereas octet 3a of Calling Party Number in Bearer caps "Shall not be present" in H.225.0v1 and v2, it is allowed in v3! And this apparent oversight was not rectified in Berlin after discussion on this reflector. How will we now guarantee interoperability between v1, v2, and v3+ entities? What if some v1 or v2 entities were implemented according to the Recommendation and do not expect this octet to be present and indeed will fail through no fault of their own? Several alternatives were presented back in May. Why was the least interoperable solution kept? Paul Long Smith Micro Software, Inc.

1 0

Re: H.323 mobility draft
by Edgar Martinez [1] 07 Sep '99

07 Sep '99

Roberto, Tell me more... Roberto Winkler wrote: > Edgar, all > > thanks for the reply, but I have some more.... > > Again, with reference to the WAU, whose capabilities and role I still don't > quite understand, I don't see how can it 'intercept' messages belonging to > the RAS channel (i.e. addressed to or coming from the Gatekeeper), without > a true redefinition of the whole system. I disagreed with your last statement " without a true redefinition of the whole system". If we designed a system that needs to be redefined everytime we provide a new service then we did something wrong. It may be true for some other systems you are looking at, like G _ _ _ or 3_ _ _. The Radio sub-system WAU is just a (GW) which provides the Radio Control Function (RCF) and bearer connection. It maintains the state of the radio links connections, for a given call, between the a user agent/terminal agent and the network as perceived by the RCF. It establishes, maintains, modifies and releases a radio and fixed line bearer connection between a mobile and the network. The MT to WAU relationship we hope to re-use the Radio technology defined by UMTS/3GPP. The MT to H.323 IP relationship we plan to re-use the H.323 elements and the TIPHON system. > > But, most important, I think that Mr. Martinez's contribution cannot be > appreciated in its entirety without a clear and precise description of the > functionalities and capabilities of the blocks in the proposed reference > architecture, which I feel is missing from the picture as it is now. As a > matter of example, with reference to the WAU, the following items should be > clarified: > - capabilities and functions > - protocol stack > - differences to other Gateways > - differences to Gatekeepers All of the above is already available in one form or another, it has been presented in other contributions I had provided to ITU and WG7. The contributions can modified specificity for the new H.323 Annex H 'user and services mobility" once the framework is agreed on. Plus Annex H it is open for contributions and you or anyone are welcome to provide some. > > > To my humble opinion, this should be the first task to be accomplished, > before aiming at message flows. We need both and will have both, but this is the same old problem that network architects face and everyone has their own opinion. I rather first know from a high level, what we are trying to provide before jumping in to details. Have you ever been asked to "show me a call flow or block diagarm" what you are trying to do? Call flows without the intended protocols message to be used, in a specific system makes little sense to me. Regards, Ed > > > Thanks very much and best regards everybody > > Roberto Winkler > > Roberto Winkler > Senior Researcher > Fondazione Ugo Bordoni > Via B. Castiglione, 59 > 00142 Rome Italy > > tel +39 0654803411 > fax. +39 0654804404 > e-mail wnk(a)fub.it > > ------------------------------------------------------------------- > Mail archive for TIPHON_WG7 can be browsed at the following url : > > http://www.etsi.org/tiphon/mailing.htm > ------------------------------------------------------------------- -- Forwarded -- Subject: Re: H.323 mobility draft Date: Mon, 06 Sep 1999 10:54:19 -0400 From: "Edgar Martinez [1]" <martinze(a)cig.mot.com> Organization: NSS-NAT To: Roberto Winkler <wnk(a)FUB.IT> CC: TIPHON_WG7(a)LIST.ETSI.FR References: 1 Dear Roberto, Thank you for your comments. Responses follow: Roberto Winkler wrote: > hello > I have the following basic questions about the document in subject: > > - what does IMIS mean ? ASN.1 data type IMIS in section 8.5 and the call flows is a typo it will be correct. IMSI ::= TBCD-STRING (SIZE (3..8)) imsi IMIS OPTIONAL (typo in document) should be imsi IMSI OPTIONAL (correction) > > - I have the impression that many message flows in section 8 break the > usual RAS channel definition, because messages that in the 'original' H.323 > are exchanged between endpoint and gatekeeper are now intercepted by WAU, > whose role (and mapping to UMTS architecture) is really unclear to me. > As > an example, there is the GRQ/GCF exchange in 8.2.1.2 > and ARQ/ACF exchanged between WAU and GK in 8.3.1.1. The WAU is not that much different that a MCU or Gateway which may register a single Transport Address or multiple Transport Addresses. To the GateKeeper the WAU will look like (GW) end-point. Of course of we want to support wireless mobility some tweets will have to be done in the H.323 procedures to handle H.323 (MT) wireless or Fixed Terminal mobility. But, it should not beak the under lining core set procedures for basic H.323. > Text from H.323v3 section 7.2.2 http://standard.pictel.com/ftp/avc-site/Incoming/ 7.2.2 Endpoint registration: Registration is the process by which an endpoint joins a Zone, and informs the Gatekeeper of its Transport Address and alias addresses. As part of their configuration process, all endpoints shall register with the Gatekeeper identified through the discovery process. Registration shall occur before any calls are attempted and may occur periodically as necessary (for example, at endpoint power-up). A Gateway or MCU may register a single Transport Address or multiple Transport Addresses. The use of multiple Transport Addresses may simplify the routing of calls to specific ports. An endpoint shall send a Registration Request (RRQ) to a Gatekeeper. This is sent to the Gatekeeper's RAS Channel Transport Address. The endpoint has the Network Address of the Gatekeeper from the Gatekeeper discovery process and uses the well-known RAS Channel TSAP Identifier. The Gatekeeper shall respond with either a Registration Confirmation (RCF) or a Registration Reject (RRJ). See Figure 8. An endpoint shall only register with a single Gatekeeper. The RRQ may be repeated periodically (i.e. at terminal power-up), so the Gatekeeper shall be able to handle multiple requests from the same endpoint. If a Gatekeeper receives an RRQ having the same alias address and the same Transport Address as an active registration previous RRQ, it shall respond with RCF. Snip... Regards, Ed > > > Clarifications are appreciated > > best regards > > Roberto Winkler > > Roberto Winkler > Senior Researcher > Fondazione Ugo Bordoni > Via B. Castiglione, 59 > 00142 Rome Italy > > tel +39 0654803411 > fax. +39 0654804404 > e-mail wnk(a)fub.it > > ------------------------------------------------------------------- > 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

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