- sg16-avd - lists.packetizer.com

Re: Alcatel Reaction on H.323m contributions
by Reddy, Paul K 15 Nov '99

15 Nov '99

Hi Laurent, Welcome to the Group. For your information, ITU-T SG16 Q13/A14 H.323 Mobility Annex-H group has formed a H.323 Mobility Ad Hoc working group in order to make progress in the development of H.323 Mobility Annex-H standard specifications. The H.323 Mobility Ad Hoc group agreed to have interim conference call meeting on Nov 17, 1999 8:00 am to 10:00 am (PST) in order to discuss contributions from different interested parties towards 6b. H.323 Mobility Functional Entities (HLF, VLF, AuF, IWF) 6c. H.323 Mobility Architecture of the agenda items. The following procedure was adopted by the Ad Hoc group: 1. Interested parties submitting contributions should request MTD-XX number from Conference Call chair and upload the document into the ftp site shown below. 2. Your MTD-08 document will be assigned to an agenda item and it will be discussed during the conference call accordingly. Your enclosed document showed the MTD-05 number,which is already assigned to Motorola. I am assigning the following MTD number for your document, please make changes and upload the document to the ftp://standard.pictel.com/avc-site/Incoming directory. MTD-08: Integrating 3GPP's option-1 architecture into the H.323 wireless IP mobility system and a full migration from GPRS to a Multimedia IP network proposal. Company: Alcatel Regards, -Paul Paul K. Reddy Intel Architecture Labs, Intel Corporation, 2111 NE 25th Avenue, Hillsboro, OR - 97124, USA, Office Phone# +1 (503)-264-9896 -----Original Message----- From: Laurent Thiebaut [mailto:LAURENT.THIEBAUT@ALCATEL.FR] Sent: Monday, November 15, 1999 9:40 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Alcatel Reaction on H.323m contributions Hello everybody, I have just subscribe to itu-sg16. I'm mostly interested in H.323 link with radio access, being involved in 3GPP standardization (3GPP S2 working group responsible of network architecture) Please find attached some comments on Contribution "Integrating 3GPP's option-1 architecture into the H.323 wireless IP mobility system and a full migration from GPRS to a Multimedia IP network proposal" (file MTD-05) - source Motorola - to be discussed on wednesday about H323 mobility. - comment on section "Alternate Proposal for an all IP option for 3GPP R'00. The purpose the all IP proposal is also to allow support of release 99 CS domain terminals. In addition it will also support the IP based services of option 1." The figure shown in the contribution does **NOT** correspond to the support of the CS terminals as described in 3GPP 23.922. This option 2 of the 3GPP standard corresponds to the option 1 architecture plus -- a MSC server mainly that comprises the call control and mobility control parts of a GSM/UMTS R99 MSC. MSC server controls the parts of the call state that pertain to connection control for media channels in a MGW. -- A GMSC server that mainly comprises the call control and mobility control parts of a GSM/UMTS R99 GMSC. The attached MTD05comment.zip contains extracts from 3GPP23.922 that explain the 3GPP position on network architecture. The following further discrepancies between contribution MTD05 and 3GPP specifications are: -- The network architecture defined by 3GPP does *NOT* imply to have the GK and the SGSN function mixed, -- nor has 3GPP accepted to merge the GGSN and the MG functions -- nor has 3GPP accepted to have a Gi interface between UTRAN (radio) and GGSN (Gateway to Packet Data networks such as Intranets / ISPs). Merging of functions is always possible at the implementation level but should not be dictated by standardization when not necessary. As H.323 networks may have to interact with other non 3GPP radio (and even mobile, non terrestrial radio) networks, it is better to have, as 3GPP has done, a clear separation between (radio) access bearer layer - UTRAN, ERAN, SGSN, GGSN for 3GPP networks, PDSN for CDMA2000 networks - and multimedia call control layer e.g. GK. Best regards Laurent T. --------------------------------------------------------------------------- V Laurent Thiebaut tel: +33 (0)1 3077 0645 A L C A T E L e.mail:laurent.thiebaut@alcatel.fr --------------------------------------------------------------------------- (Alcatel representant to 3GPP SA Working group 2 that is responsible of 3GPP system architecture)

1 0

Re: H.323 mobility:MTD number request
by Reddy, Paul K 15 Nov '99

15 Nov '99

Hi Anders, The following MTD number has been assigned to your document: MTD-07: "Definition of terms for H.323 Annex H". Company: Ericsson Regards, -Paul Paul K. Reddy Intel Architecture Labs, Intel Corporation, 2111 NE 25th Avenue, Hillsboro, OR - 97124, USA, Office Phone# +1 (503)-264-9896 -----Original Message----- From: Anders Svennevik (ERA) [mailto:Anders.Svennevik@era.ericsson.se] Sent: Monday, November 15, 1999 1:17 AM To: 'Mailing list for parties associated with ITU-T Study Group 16'; 'paul.k.reddy(a)INTEL.COM' Subject: RE: H.323 mobility:MTD number request Hi, Could I have an MTD number? The title of the document will most likely be something along the lines of "Defintion of terms for H.323 Annex H". Anders Svennevik Ericsson Radio

1 0

Re: Alcatel Reaction on H.323m contributions
by Edgar Martinez [1] 15 Nov '99

15 Nov '99

Dear MR. Thiebaut, The document you just send out has my name on the contact list. Which you edited without my consent. You should respect everyone's work and next time you change any contribution you put your name and use a different MTD. The original MTD-05 is in. ftp://standard.pictel.com/avc-site/Incoming Also the contribution source is "Mobility Ad-hoc group"??? I am part of the "Mobility AD-HOC group" and again neither myself or anyone representing Motorola or myself gave MR. Thiebaut permission or concur the use of the "Mobility Ad-hoc group" as the source. I hope you do not represent how things are done in 3GPP. MR. Thiebaut, on your blindness attempt to re-used my work to promote your own views. Let me warn you, the document was put in informational only. I send out email that we should restrain from comments until we went over all the contributions first in the conference call meeting. To ALL, The Edited MTD-05 in this email is not from Motorola please contact MR. Laurent Thiebaut <LAURENT.THIEBAUT(a)ALCATEL.FR> with your comments. I would not even bother to use the SG16 mailer to do so. see below for further comments: Laurent Thiebaut wrote: > Hello everybody, > I have just subscribe to itu-sg16. > I'm mostly interested in H.323 link with radio access, being involved in > 3GPP standardization (3GPP S2 working group responsible of network > architecture) > > Please find attached some comments on Contribution "Integrating > 3GPP's option-1 architecture into the H.323 wireless IP mobility > system and a full migration from GPRS to a Multimedia IP network > proposal" (file MTD-05) - source Motorola - to be discussed on > wednesday about H323 mobility. > > - comment on section "Alternate Proposal for an all IP option for 3GPP > R'00. The purpose the all IP proposal is also to allow support of release > 99 CS domain terminals. In addition it will also support the IP based > services of option 1." > > The figure shown in the contribution does **NOT** correspond to the > support of the CS terminals as described in 3GPP 23.922. This option 2 > of the 3GPP standard corresponds to the option 1 architecture plus > -- a MSC server mainly that comprises the call control and > mobility control parts of a GSM/UMTS R99 MSC. > MSC server controls the parts of the call state that pertain to > connection control for media channels in a MGW. > -- A GMSC server that mainly comprises the call control and > mobility control parts of a GSM/UMTS R99 GMSC. > The attached MTD05comment.zip contains extracts from 3GPP23.922 that > explain the 3GPP position on network architecture. The following is clearly stated in the document: For simplicity, only the 3GPP interfaces relevant to H.323 interfaces are shown for discussion. If one wants to compare, please See 3G TR 23.922 version 1.0.0[6] for full details of option 1. > > > The following further discrepancies between contribution MTD05 and > 3GPP specifications are: > -- The network architecture defined by 3GPP does *NOT* > imply to have the GK and the SGSN function mixed, > -- nor has 3GPP accepted to merge the GGSN and the MG > functions > -- nor has 3GPP accepted to have a Gi interface between > UTRAN (radio) and GGSN (Gateway to Packet Data networks such as > Intranets / ISPs). > Merging of functions is always possible at the implementation level > but should not be dictated by standardization when not necessary. > > As H.323 networks may have to interact with other non 3GPP radio (and > even mobile, non terrestrial radio) networks, it is better to have, > as 3GPP has done, a clear separation between (radio) access bearer > layer - UTRAN, ERAN, SGSN, GGSN for 3GPP networks, PDSN for CDMA2000 > networks - and multimedia call control layer e.g. GK. What I am talking about is "Full migration from GPRS to Multimedia IP network". Not a decompose MSC or GMSC the so-called Circuit Switched Trunk Gateway WGW (aka switch) and MSC server (aka SCP) your so-called all IP concepts. Finally in a full IP network the only separation that will exist is Circuit Switched networks (Old) and IP based networks (New). The bridge between the Old and New, will be the Signaling gateways and media gateways. Conclusion: ---------------- The H.323 mobility group should also consider the interworking of the GPRS network and provide a GPRS migration path to a full IP network solution. Such as the work in H.323 is providing an interworking and migration path for the PSTN to a full IP network solution. In addition the H.323 mobility group could include the two options "Alternate Proposal for an all IP option for 3GPP R'00" interim solution, and the Full migration from GPRS into H.323 Annex-H interworking sections. Further details can be discussed within the H.323 mobility group. > > > Best regards > Laurent T. > --------------------------------------------------------------------------- > V Laurent Thiebaut tel: +33 (0)1 3077 0645 > A L C A T E L e.mail:laurent.thiebaut@alcatel.fr > --------------------------------------------------------------------------- > (Alcatel representant to 3GPP SA Working group 2 that is responsible of 3GPP > system architecture) > > ------------------------------------------------------------------------ > Name: mtd-05~1.zip > mtd-05~1.zip Type: Winzip32 File (application/x-winzip) > Encoding: base64 -- 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

[Robustness] Conference call - final reminder and more agenda ite ms -- Tuesday, November 16 11AM EST USA
by Maureen Stillman 15 Nov '99

15 Nov '99

This is a final reminder that we will be having the first teleconference on robustness sponsored by Nokia on Tuesday, November 16 at 11AM EST USA. The phone number to call is: 613-688-2795 and the access code is 1097#. You must enter the pound key after the access code. The tentative agenda is: Definitions of Terms for robustness Items that can be settled in the short term Additional agenda items from the mailing list: They are topics we should discuss during the phone call or decide to defer. I took most of this text directly from your e-mail messages.... Summary of Agenda Items from the mailing list: 1) contribution D.225 - "Framework for Reliable H.323 Gatekeeper Architectures" How will this contribution be added and referenced in the "terms of reference" Red Bank document TD-028? 2) Further discussion of the proposal in Red Bank to strike the text in the current version that allows for the closure of the call signaling channel while a call is still in progress. 3) Recovery from GK crash 4) The more difficult problem is that upon TCP channel failure, the TPKT connection gets out of synch. It means that the application layer doesn't know automatically what part of information got lost. In this case, in order to synchronize H.323 Call state between the two sides, application level handshake must be introduced. This is also definitely a job for our Robustness group. 5) Another issue we have at hand is that of "what is a call signaling channel?" There used to be a one to one mapping between TCP connections and call signaling channels. This is not the case any longer-- one may have multiple calls over the same call signaling channel and one may not even use TCP. Making this distinction will be important for the robustness work being started, as the "logical" connection (the call signaling channel) and the "physical" connection (the TCP or UDP connection) must be referred to independently. (I'm quite open to new terms for here...). It is important to recognize whether an endpoint has closed the call signaling channel (as we understand it today) or if the physical connection has failed. Since we do not signal that we are going to close the call signaling channel today-- we just close the socket-- it makes this problem more difficult. 6) Actually, the SCTP transport protocol defined by Sigtran is specifically designed to address the path level robustness. It is designed to support multiple NIC cards (a.k.a. multi-homed nodes) and provide transparent interface and path failure detection and recovery. 7) think that Sigtran could be used to provide the GK "switch over" to a hot standby GK from the IP layer point of view. Conference Call Participants (so far): all are welcome to join in! Rich Bowen rkbowen(a)cisco.com Roy Radhika rrroy(a)att.com Orit Levin orit(a)radvision.com Dave Walker dave_walker(a)Mitel.com Terry Anderson tla(a)lucent.com Kumar, Vineet vineet.kumar(a)intel.com Asaf Steifeld AsafS(a)radware.co.il Michael Corrigan Michael_Corrigan(a)mw.3com.com Robert Callaghan Robert.Callaghan(a)siemenscom.com Glen Freundlich ggf(a)lucent.com Boaz Michaely Boaz_Michaely(a)vocaltec.com Jean-philippe Caradec caradec(a)piano.grenoble.hp.com Talk to you Tuesday.... -- maureen Maureen Stillman Member of Scientific Staff Voice: (607)273-0724 x62 Nokia IP Telephony Fax: (607)275-3610 127 W. State Street Mobile: (607)227-2933 Ithaca, NY 14850 e-mail: maureen.stillman(a)nokia.com www.nokia.com

1 0

AW: H.450.3 interrogation procedure
by Karl.Klaghofer＠ICN.SIEMENS.DE 15 Nov '99

15 Nov '99

Henri, By means of this field, the interrogation result may provide information to the served user, whether remote activation has been enabled (allowed). Karl Klaghofer > -----Ursprüngliche Nachricht----- > Von: Henri Mdenpdd [SMTP:henri.maenpaa@NOKIA.COM] > Gesendet am: Donnerstag, 11. November 1999 12:29 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: H.450.3 interrogation procedure > > All, > > I have a question concerning H.450.3 Call Diversion supplementary service, > and more specifically about the interrogation procedure. > > The response to an interrogation of current activations consists of a list > of IntResult IEs. > Each of these describe one diversion activation "description". Among the > information fields is this boolean value remoteEnabled. > What is the purpose of this? > > -Henri Mäenpää

1 0

Re: Alcatel Reaction on H.323m contributions
by Laurent Thiebaut 15 Nov '99

15 Nov '99

Hello everybody, I have just subscribe to itu-sg16. I'm mostly interested in H.323 link with radio access, being involved in 3GPP standardization (3GPP S2 working group responsible of network architecture) Please find attached some comments on Contribution "Integrating 3GPP's option-1 architecture into the H.323 wireless IP mobility system and a full migration from GPRS to a Multimedia IP network proposal" (file MTD-05) - source Motorola - to be discussed on wednesday about H323 mobility. - comment on section "Alternate Proposal for an all IP option for 3GPP R'00. The purpose the all IP proposal is also to allow support of release 99 CS domain terminals. In addition it will also support the IP based services of option 1." The figure shown in the contribution does **NOT** correspond to the support of the CS terminals as described in 3GPP 23.922. This option 2 of the 3GPP standard corresponds to the option 1 architecture plus -- a MSC server mainly that comprises the call control and mobility control parts of a GSM/UMTS R99 MSC. MSC server controls the parts of the call state that pertain to connection control for media channels in a MGW. -- A GMSC server that mainly comprises the call control and mobility control parts of a GSM/UMTS R99 GMSC. The attached MTD05comment.zip contains extracts from 3GPP23.922 that explain the 3GPP position on network architecture. The following further discrepancies between contribution MTD05 and 3GPP specifications are: -- The network architecture defined by 3GPP does *NOT* imply to have the GK and the SGSN function mixed, -- nor has 3GPP accepted to merge the GGSN and the MG functions -- nor has 3GPP accepted to have a Gi interface between UTRAN (radio) and GGSN (Gateway to Packet Data networks such as Intranets / ISPs). Merging of functions is always possible at the implementation level but should not be dictated by standardization when not necessary. As H.323 networks may have to interact with other non 3GPP radio (and even mobile, non terrestrial radio) networks, it is better to have, as 3GPP has done, a clear separation between (radio) access bearer layer - UTRAN, ERAN, SGSN, GGSN for 3GPP networks, PDSN for CDMA2000 networks - and multimedia call control layer e.g. GK. Best regards Laurent T. --------------------------------------------------------------------------- V Laurent Thiebaut tel: +33 (0)1 3077 0645 A L C A T E L e.mail:laurent.thiebaut@alcatel.fr --------------------------------------------------------------------------- (Alcatel representant to 3GPP SA Working group 2 that is responsible of 3GPP system architecture)

1 0

Re: H.323 mobility:MTD number request
by Anders Svennevik (ERA) 15 Nov '99

15 Nov '99

Hi, Could I have an MTD number? The title of the document will most likely be something along the lines of "Defintion of terms for H.323 Annex H". Anders Svennevik Ericsson Radio

1 0

Re: [Robustness] Telecon scheduled for Tuesday, 11/16 at 11AM EST USA
by Roy, Radhika R, ALARC 12 Nov '99

12 Nov '99

Hi, Maureen and All: In addition to TD-28, I am also adding a part of APC-1748b (Q.13 Rap.'s meeting report of Red bank meeting): "..It was noted that D.225 from Chile is relevant..." D.225 was not reflected in TD-28. Emails were also sent to clarify this. For completeness of this email, I am adding this as well. We will discuss this in the conference call when we discuss the terms of reference per TD-28. Thanks to Maureen for arranging the conf. call. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Maureen Stillman [SMTP:Maureen.Stillman@NOKIA.COM] > Sent: Friday, November 12, 1999 2:32 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [Robustness] Telecon scheduled for Tuesday, 11/16 at 11AM > EST USA > > This is a reminder that we will be having the first teleconference on > robustness sponsored by Nokia on Tuesday, November 16 at 11AM EST USA. > > The phone number to call is: > > 613-688-2795 and the access code is 1097#. You must enter the pound > key > after the access code. > > The tentative agenda is: > > Definitions of Terms for robustness > Items that can be settled in the short term > > Attached for your information are the terms of reference (TD-28) agreed > upon > at the last Study Group 16 meeting in Red Bank. > > Thanks and talk to you on Tuesday. I have 9 people so far saying they > will > attend listed on the cc list. Any additional should send me e-mail. > > <<TD-28.doc>> > -- maureen > > Maureen Stillman > Member of Scientific Staff Voice: (607)273-0724 x62 > Nokia IP Telephony Fax: (607)275-3610 > 127 W. State Street Mobile: (607)227-2933 > Ithaca, NY 14850 > e-mail: maureen.stillman(a)nokia.com > www.nokia.com > << File: TD-28.doc >>

1 0

[Robustness] Telecon scheduled for Tuesday, 11/16 at 11AM EST USA
by Maureen Stillman 12 Nov '99

12 Nov '99

This is a reminder that we will be having the first teleconference on robustness sponsored by Nokia on Tuesday, November 16 at 11AM EST USA. The phone number to call is: 613-688-2795 and the access code is 1097#. You must enter the pound key after the access code. The tentative agenda is: Definitions of Terms for robustness Items that can be settled in the short term Attached for your information are the terms of reference (TD-28) agreed upon at the last Study Group 16 meeting in Red Bank. Thanks and talk to you on Tuesday. I have 9 people so far saying they will attend listed on the cc list. Any additional should send me e-mail. <<TD-28.doc>> -- maureen Maureen Stillman Member of Scientific Staff Voice: (607)273-0724 x62 Nokia IP Telephony Fax: (607)275-3610 127 W. State Street Mobile: (607)227-2933 Ithaca, NY 14850 e-mail: maureen.stillman(a)nokia.com www.nokia.com

1 0

Re: H.323 mobility:MTD number request
by Reddy, Paul K 12 Nov '99

12 Nov '99

Hi Jaakko, I have assigned the following MTD number for your document: MTD-06: Title: H.323 Functional Architecture and Reference Points. Company: Nokia Regards, -Paul Paul K. Reddy Intel Architecture Labs, Intel Corporation, 2111 NE 25th Avenue, Hillsboro, OR - 97124, USA, Office Phone# +1 (503)-264-9896 -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] Sent: Friday, November 12, 1999 12:30 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: H.323 mobility:MTD number request Hi Paul, Could you reserve an MTD number for Nokia. The title of the document will be something along the lines: H.323 Functional Architecture and Reference Points. - Jaakko Sundquist ------------------------------------------------------- In a hole in the ground there lived a hobbit. Not a nasty, dirty, wet hole, filled with the ends of worms and an oozy smell, nor yet a dry, bare, sandy hole with nothing in it to sit down on or to eat: it was a hobbit-hole, and that means comfort. -------------------------------------------------------

1 0