- sg16-avd - lists.packetizer.com

Re: Comments on MTD-107a
by Laurent Thiebaut 14 Dec '99

14 Dec '99

Dear Mr Martinez and SG16 H323 mobile group The "message" of MTD-107 contribution is to decorrelate H323 mobility from radio mobility with the global aim to support the same H323 mobility for both fixed and radio terminals. That is why MTD-07 proposes: to suppress some radio mobile concepts from H323 mobility, taking into account that radio mobility tools/concepts such as paging, hand-over, location area, temporary radio mobile identity, .. are used by radio access networks in a way that is transparent to the H323 (mobile) layer. This does not mean that moves at radio level have no indirect impact on H323 mobility such as change of NPOA or change of Serving GK but these indirect impacts are decorrelated from the radio technology (GPRS, cdma2000, ...) to introduce the notion of double registration allowing to bring the independence between radio networks and H323 mobile network and hence independence between radio access technology (GPRS,, cdmaOne, ...) and H323 mobile network. Note that the solution proposed in MTD-107 allows various operational situations such as a separation between the administrative domain of the (possibly radio) access and the administrative domain of H323 mobility. This separation is rendered easy by the decoralation of the (possibly radio) access functions and the H323 mobility functions. On the other hand putting the GK in the SGSN or in any radio related function (as I understand is proposed in Motorola's MTD-305) does not bring the independence of H323 mobility from radio access (network and technology). Furthermore putting BTS or IP Radio Access Network in the scope of H323 mobility (as I understand is proposed in Motorola's MTD-305) implies very high ties between H323 mobile and radio technology. Mr Martinez, may be I have mis-understood MTD-305, in which case I would please ask you to give further explanations. 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 --------------------------------------------------------------------------- "Edgar Martinez [1]" <martinze(a)cig.mot.com> on 14/12/99 01:44:04 To: "H.323 Mobility" <ITU-SG16(a)mailbag.cps.intel.com> cc: "Roy, Radhika R, ALARC" <rrroy(a)att.com>, Laurent THIEBAUT/FR/ALCATEL@ALCATEL Subject: Re: Comments on MTD-107a Dear Radhika and Mr. Thiebaut, In reference to Alcatel's MTD-107a (v.s.) Motorola's MTD-305c. We (Motorola) would like to move 3GPP option 1 to a full IP solution within the H.323 mobility framework. Unlike MTD-107a, Motorola is working on one Universal IP solution that will support both fixed and mobile terminals and user and network services for voice, data and multi-media. Not just GPRS mobile data services. Right now 3GPP R'00 option 1 has two networks a GPRS and an IP network, which are shown side by side. 3GPP option 2 adds a third dimension a circuit switch side. Where 3GPP option 2 is composed of different three networks, GPRS, IP and Circuit switched. As matter of fact, UMTS R'99 has no IP, UMTS R'99 has the MSC and SSGN radio interfaces attached via an array of BSCs and RNCs and a mix of Iu-ps and Iu-cs connections. One can say that option 2 is just R'99 with access to some H.323 IP elements like a gateway and gatekeeper and that's all we get. See MTD-107a, MTD-08, 3GPP's TR23.922 and TR23.002 to see for yourself. The framework for MTD-305c is for the H.323 system to be able to interwork with the legacy network's both mobile and fixed systems, while also providing new technology and services to the IP network. "Roy, Radhika R, ALARC" wrote: > Hi, Laurent: > > Please see my reply provided below. > > My view point is: Let us keep doors open for all probable solutions. Let > people implement their solutions as they find optimal for their specific > environments. > > Best regards, > Radhika R. Roy > AT&T > > > -----Original Message----- > > From: Laurent.Thiebaut(a)alcatel.fr [SMTP:Laurent.Thiebaut@alcatel.fr] > > Sent: Monday, December 13, 1999 1:01 PM > > To: Roy, Radhika R, ALARC > > Cc: 'paul.k.reddy(a)intel.com'; 'vineet.kumar(a)intel.com'; > > 'jaakko.sundquist(a)nokia.com'; 'peeter.pruuden(a)nokia.com'; > > 'senthil.sengodan(a)nokia.com'; 'marc.roelands(a)siemens.atea.be'; > > 'martinze(a)cig.mot.com'; 'lpg019(a)email.mot.com'; 'orsic(a)lucent.com'; > > 'stephen.terrill(a)ericsson.com'; 'gosta.linder(a)lme.ericsson.se'; > > 'Anders.Svennevik(a)era.ericsson.se'; 'mike(a)synacom.com'; 'stu(a)synacom.com'; > > 'paul.jones(a)ties.itu.int'; 'baronson(a)acm.org'; > > Ameneh.Zahir-Emami(a)alcatel.fr; Nicolas.Tran(a)alcatel.fr > > Subject: RE: Comments on MTD-107a > > > > > > > > Hi Radhika, > > I do not understand what you mean by "take care-of some special needs > > in mobile environment" as a need for Temporary IDs. My understanding is > > that H.323 alias ("E.164, email, URL,and others" as you mention) are not > > modified when the user moves because > > it is these aliases that allow to reach the user even when the user > > moves (and its NPOA changes). Could you please clarify what you mean? > [Roy, Radhika R] What I envision that "Temporary ID" can also be > another " H.323 alias" considering the mobile environment. So, it is an > extension of the present H.323 alias addresses. > > > for paging: my understanding is that through a RRQ, the mobile gives > > the association between its alias(es) and its NPOA (IP) address to its > > Serving GK that stores the association in internal tables. When there is > > a mobile terminated call, thanks to > > HLF-VLF interactions (as described in Nokia's MTD104), the Serving GK @ > > is determined. Then the set-up message is sent to the Serving GK. Using > > the internal table populated at RRQ, the Serving GK sends the set-up > > message to the called mobile with the > > right NPOA (IP) address. This packet is received by the Access Network > > that may have to page the mobile, but this paging is transparent to H323. > > Could you please explain me what you see as wrong in the scenario I have > > given. > [Roy, Radhika R] This may be another alternative solution as you > have mentioned. At present, LRQ messages are sent between the GKs for > address resolution. Extending the same scenarios, paging of LRQs in mobile > environment may be needed. > > > 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 > > -------------------------------------------------------------------------- > > - > > > > > > > > > > "Roy, Radhika R, ALARC" <rrroy(a)att.com> on 08/12/99 19:12:32 > > > > > > > > To: Laurent THIEBAUT/FR/ALCATEL@ALCATEL > > > > cc: "'paul.k.reddy(a)intel.com'" > > <paul.k.reddy(a)intel.com>, > > "'vineet.kumar(a)intel.com'" > > <vineet.kumar(a)intel.com>, > > "'jaakko.sundquist(a)nokia.com'" > > <jaakko.sundquist(a)nokia.com>, > > "'peeter.pruuden(a)nokia.com'" > > <peeter.pruuden(a)nokia.com>, > > "'senthil.sengodan(a)nokia.com'" > > <senthil.sengodan(a)nokia.com>, > > "'marc.roelands(a)siemens.atea.be'" > > <marc.roelands(a)siemens.atea.be>, > > "'martinze(a)cig.mot.com'" <martinze(a)cig.mot.com>, > > "'lpg019(a)email.mot.com'" <lpg019(a)email.mot.com>, > > "'orsic(a)lucent.com'" <orsic(a)lucent.com>, > > "'stephen.terrill(a)ericsson.com'" > > <stephen.terrill(a)ericsson.com>, > > "'gosta.linder(a)lme.ericsson.se'" > > <gosta.linder(a)lme.ericsson.se>, > > "'Anders.Svennevik(a)era.ericsson.se'" > > <Anders.Svennevik(a)era.ericsson.se>, > > "'mike(a)synacom.com'" <mike(a)synacom.com>, > > "'stu(a)synacom.com'" <stu(a)synacom.com>, > > "'paul.jones(a)ties.itu.int'" > > <paul.jones(a)ties.itu.int>, "'baronson(a)acm.org'" > > <baronson(a)acm.org>, Ameneh > > ZAHIR-EMAMI/FR/ALCATEL@ALCATEL > > > > > > > > Subject: RE: Comments on MTD-107a > > > > > > > > > > > > > > Hi, Laurent: > > > > Paging: A simple answer will be to locate the mobile user for resolving > > the > > address needed in the LRQ message. > > > > Temporary ID: H.323 aliases are open enough to include E.164, email, URL, > > and others. In the same token, if mobile users also need to introduce > > other > > IDs similar such as Temporary IDs, Personal IDs, etc. to , we should be > > open to those suggestions. > > > > Best regards, > > Radhika R. Roy > > AT&T > > > > > -----Original Message----- > > > From: Laurent.Thiebaut(a)alcatel.fr [SMTP:Laurent.Thiebaut@alcatel.fr] > > > Sent: Wednesday, December 08, 1999 11:09 AM > > > To: Roy, Radhika R, ALARC > > > Cc: Roy, Radhika R, ALARC; 'paul.k.reddy(a)intel.com'; > > > 'vineet.kumar(a)intel.com'; 'jaakko.sundquist(a)nokia.com'; > > > 'peeter.pruuden(a)nokia.com'; 'senthil.sengodan(a)nokia.com'; > > > 'marc.roelands(a)siemens.atea.be'; 'martinze(a)cig.mot.com'; > > > 'lpg019(a)email.mot.com'; 'orsic(a)lucent.com'; > > > 'stephen.terrill(a)ericsson.com'; 'gosta.linder(a)lme.ericsson.se'; > > > 'Anders.Svennevik(a)era.ericsson.se'; 'mike(a)synacom.com'; > > 'stu(a)synacom.com'; > > > 'paul.jones(a)ties.itu.int'; 'baronson(a)acm.org'; > > > Ameneh.Zahir-Emami(a)alcatel.fr > > > Subject: Re: Comments on MTD-107a > > > > > > > > > > > > Hi, Everyone, this is just to answer to Roy's remark > > > Hi Radhika, > > > I agree with you when you say that "the lower layer mobility may > > cause > > > an impact on > > > the higher layer (e.g., H.323) as well. If it is so, the proper > > > abstraction > > > in the higher layer (e.g., H.323) should be there to take care of > > this > > > situation." > > > That's just the reason why we have deleted the notion of ?Location > > Area > > > Identity (set of Network of Attachments associated)? and ?Temporary > > > Identity?. but added the notions of "change of NPOA or of H323 Point of > > > Attachment may need to be dealt with > > > within H323 scope". > > > I'd better see alias @" in the list of concepts used by H323 mobility > > > instead of "Temporary Id" that looks (for me with too much of a mobile > > > culture I admit) like the temporary Identifier allocated on radio to > > hide > > > the permanent user identity > > > Could you explain the need of paging > > > Best regards > > > L. Thiebaut > > > > > > > > -------------------------------------------------------------------------- > > > -------------------------------------------------------------------- > > > > > > > > > Hi, Everyone: > > > > > > We are in receipt of the contribution from Alcatel (MTD-107a: Contact - > > > Laurent Thiebaut). For the interest of time, I take the liberty to offer > > > my > > > comments. > > > > > > I fully agree with the proposal of Laurent that H.323 Mobility should > > > focus > > > only on the H.323 mobility layer. In fact, the terms of reference of the > > > H.323 mobility group has also confirmed this. However, some specific > > texts > > > that Laurent have proposed may create some confusions. Let me expalin as > > > follows : > > > > > > If the lower layer mobility (e.g., radio link or network layer) is > > > transparent to the H.323 layer, nothing needs to done in the H.323 > > > application layer. However, the lower layer mobility may cause an impact > > > on > > > the higher layer (e.g., H.323) as well. If it is so, the proper > > > abstraction > > > in the higher layer (e.g., H.323) should be there to take care of this > > > situation. > > > > > > For example, switching of cells (e.g., cellular IP) may not cause any > > > impact > > > in the H.323 layer. In this situation, this mobility is transparent to > > the > > > H.323 layer. In some situation, the swiching of cells may also cause an > > > impact on the H.323 layer (e.g., H.323 point of attachment). In this > > case, > > > resources of the H.323 layer should also be taken care-of accordingly. > > > > > > Temporary IDs may also be needed in the H.323 layer. Contributions are > > > provided why these IDs are needed in the H.323 layer. These are the > > alias > > > addresses and can have an astraction in the H.323 layer. That does NOT > > > mean > > > in anyway that the solution of the H.323 is becoming specific to the > > radio > > > link layer. > > > > > > Similarly, LRQ message sets have the addresses that have been abstracted > > > in > > > the H.323 layer. Contributions have been provided why the paging of the > > > LRQ > > > message is needed in the H.323 layer. > > > > > > (However, I agree with him that location area may NOT be needed in H.323 > > > because the concepts of H.323 zones/domains will be sufficient. In same > > > token, we also do not need the concept of cells in H.323.) > > > > > > I find that texts proposed in the contribution are too restrictive. > > > > > > Finally, I propose that Laurent should keep an eye to the H.323 solution > > > that will be agreed upon should be transparent to the lower layer (e.g., > > > radio link or network layer) as we make more progress in this area. > > > > > > Best regards, > > > Radhika R. Roy > > > AT&T > > > + 1 732 420 1580 > > > rrroy(a)att.com > > > > > > > > > > > > > > > > -- 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: Comments on MTD-107a
by Edgar Martinez [1] 13 Dec '99

13 Dec '99

Dear Radhika and Mr. Thiebaut, In reference to Alcatel's MTD-107a (v.s.) Motorola's MTD-305c. We (Motorola) would like to move 3GPP option 1 to a full IP solution within the H.323 mobility framework. Unlike MTD-107a, Motorola is working on one Universal IP solution that will support both fixed and mobile terminals and user and network services for voice, data and multi-media. Not just GPRS mobile data services. Right now 3GPP R'00 option 1 has two networks a GPRS and an IP network, which are shown side by side. 3GPP option 2 adds a third dimension a circuit switch side. Where 3GPP option 2 is composed of different three networks, GPRS, IP and Circuit switched. As matter of fact, UMTS R'99 has no IP, UMTS R'99 has the MSC and SSGN radio interfaces attached via an array of BSCs and RNCs and a mix of Iu-ps and Iu-cs connections. One can say that option 2 is just R'99 with access to some H.323 IP elements like a gateway and gatekeeper and that's all we get. See MTD-107a, MTD-08, 3GPP's TR23.922 and TR23.002 to see for yourself. The framework for MTD-305c is for the H.323 system to be able to interwork with the legacy network's both mobile and fixed systems, while also providing new technology and services to the IP network. "Roy, Radhika R, ALARC" wrote: > Hi, Laurent: > > Please see my reply provided below. > > My view point is: Let us keep doors open for all probable solutions. Let > people implement their solutions as they find optimal for their specific > environments. > > Best regards, > Radhika R. Roy > AT&T > > > -----Original Message----- > > From: Laurent.Thiebaut(a)alcatel.fr [SMTP:Laurent.Thiebaut@alcatel.fr] > > Sent: Monday, December 13, 1999 1:01 PM > > To: Roy, Radhika R, ALARC > > Cc: 'paul.k.reddy(a)intel.com'; 'vineet.kumar(a)intel.com'; > > 'jaakko.sundquist(a)nokia.com'; 'peeter.pruuden(a)nokia.com'; > > 'senthil.sengodan(a)nokia.com'; 'marc.roelands(a)siemens.atea.be'; > > 'martinze(a)cig.mot.com'; 'lpg019(a)email.mot.com'; 'orsic(a)lucent.com'; > > 'stephen.terrill(a)ericsson.com'; 'gosta.linder(a)lme.ericsson.se'; > > 'Anders.Svennevik(a)era.ericsson.se'; 'mike(a)synacom.com'; 'stu(a)synacom.com'; > > 'paul.jones(a)ties.itu.int'; 'baronson(a)acm.org'; > > Ameneh.Zahir-Emami(a)alcatel.fr; Nicolas.Tran(a)alcatel.fr > > Subject: RE: Comments on MTD-107a > > > > > > > > Hi Radhika, > > I do not understand what you mean by "take care-of some special needs > > in mobile environment" as a need for Temporary IDs. My understanding is > > that H.323 alias ("E.164, email, URL,and others" as you mention) are not > > modified when the user moves because > > it is these aliases that allow to reach the user even when the user > > moves (and its NPOA changes). Could you please clarify what you mean? > [Roy, Radhika R] What I envision that "Temporary ID" can also be > another " H.323 alias" considering the mobile environment. So, it is an > extension of the present H.323 alias addresses. > > > for paging: my understanding is that through a RRQ, the mobile gives > > the association between its alias(es) and its NPOA (IP) address to its > > Serving GK that stores the association in internal tables. When there is > > a mobile terminated call, thanks to > > HLF-VLF interactions (as described in Nokia's MTD104), the Serving GK @ > > is determined. Then the set-up message is sent to the Serving GK. Using > > the internal table populated at RRQ, the Serving GK sends the set-up > > message to the called mobile with the > > right NPOA (IP) address. This packet is received by the Access Network > > that may have to page the mobile, but this paging is transparent to H323. > > Could you please explain me what you see as wrong in the scenario I have > > given. > [Roy, Radhika R] This may be another alternative solution as you > have mentioned. At present, LRQ messages are sent between the GKs for > address resolution. Extending the same scenarios, paging of LRQs in mobile > environment may be needed. > > > 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 > > -------------------------------------------------------------------------- > > - > > > > > > > > > > "Roy, Radhika R, ALARC" <rrroy(a)att.com> on 08/12/99 19:12:32 > > > > > > > > To: Laurent THIEBAUT/FR/ALCATEL@ALCATEL > > > > cc: "'paul.k.reddy(a)intel.com'" > > <paul.k.reddy(a)intel.com>, > > "'vineet.kumar(a)intel.com'" > > <vineet.kumar(a)intel.com>, > > "'jaakko.sundquist(a)nokia.com'" > > <jaakko.sundquist(a)nokia.com>, > > "'peeter.pruuden(a)nokia.com'" > > <peeter.pruuden(a)nokia.com>, > > "'senthil.sengodan(a)nokia.com'" > > <senthil.sengodan(a)nokia.com>, > > "'marc.roelands(a)siemens.atea.be'" > > <marc.roelands(a)siemens.atea.be>, > > "'martinze(a)cig.mot.com'" <martinze(a)cig.mot.com>, > > "'lpg019(a)email.mot.com'" <lpg019(a)email.mot.com>, > > "'orsic(a)lucent.com'" <orsic(a)lucent.com>, > > "'stephen.terrill(a)ericsson.com'" > > <stephen.terrill(a)ericsson.com>, > > "'gosta.linder(a)lme.ericsson.se'" > > <gosta.linder(a)lme.ericsson.se>, > > "'Anders.Svennevik(a)era.ericsson.se'" > > <Anders.Svennevik(a)era.ericsson.se>, > > "'mike(a)synacom.com'" <mike(a)synacom.com>, > > "'stu(a)synacom.com'" <stu(a)synacom.com>, > > "'paul.jones(a)ties.itu.int'" > > <paul.jones(a)ties.itu.int>, "'baronson(a)acm.org'" > > <baronson(a)acm.org>, Ameneh > > ZAHIR-EMAMI/FR/ALCATEL@ALCATEL > > > > > > > > Subject: RE: Comments on MTD-107a > > > > > > > > > > > > > > Hi, Laurent: > > > > Paging: A simple answer will be to locate the mobile user for resolving > > the > > address needed in the LRQ message. > > > > Temporary ID: H.323 aliases are open enough to include E.164, email, URL, > > and others. In the same token, if mobile users also need to introduce > > other > > IDs similar such as Temporary IDs, Personal IDs, etc. to , we should be > > open to those suggestions. > > > > Best regards, > > Radhika R. Roy > > AT&T > > > > > -----Original Message----- > > > From: Laurent.Thiebaut(a)alcatel.fr [SMTP:Laurent.Thiebaut@alcatel.fr] > > > Sent: Wednesday, December 08, 1999 11:09 AM > > > To: Roy, Radhika R, ALARC > > > Cc: Roy, Radhika R, ALARC; 'paul.k.reddy(a)intel.com'; > > > 'vineet.kumar(a)intel.com'; 'jaakko.sundquist(a)nokia.com'; > > > 'peeter.pruuden(a)nokia.com'; 'senthil.sengodan(a)nokia.com'; > > > 'marc.roelands(a)siemens.atea.be'; 'martinze(a)cig.mot.com'; > > > 'lpg019(a)email.mot.com'; 'orsic(a)lucent.com'; > > > 'stephen.terrill(a)ericsson.com'; 'gosta.linder(a)lme.ericsson.se'; > > > 'Anders.Svennevik(a)era.ericsson.se'; 'mike(a)synacom.com'; > > 'stu(a)synacom.com'; > > > 'paul.jones(a)ties.itu.int'; 'baronson(a)acm.org'; > > > Ameneh.Zahir-Emami(a)alcatel.fr > > > Subject: Re: Comments on MTD-107a > > > > > > > > > > > > Hi, Everyone, this is just to answer to Roy's remark > > > Hi Radhika, > > > I agree with you when you say that "the lower layer mobility may > > cause > > > an impact on > > > the higher layer (e.g., H.323) as well. If it is so, the proper > > > abstraction > > > in the higher layer (e.g., H.323) should be there to take care of > > this > > > situation." > > > That's just the reason why we have deleted the notion of ?Location > > Area > > > Identity (set of Network of Attachments associated)? and ?Temporary > > > Identity?. but added the notions of "change of NPOA or of H323 Point of > > > Attachment may need to be dealt with > > > within H323 scope". > > > I'd better see alias @" in the list of concepts used by H323 mobility > > > instead of "Temporary Id" that looks (for me with too much of a mobile > > > culture I admit) like the temporary Identifier allocated on radio to > > hide > > > the permanent user identity > > > Could you explain the need of paging > > > Best regards > > > L. Thiebaut > > > > > > > > -------------------------------------------------------------------------- > > > -------------------------------------------------------------------- > > > > > > > > > Hi, Everyone: > > > > > > We are in receipt of the contribution from Alcatel (MTD-107a: Contact - > > > Laurent Thiebaut). For the interest of time, I take the liberty to offer > > > my > > > comments. > > > > > > I fully agree with the proposal of Laurent that H.323 Mobility should > > > focus > > > only on the H.323 mobility layer. In fact, the terms of reference of the > > > H.323 mobility group has also confirmed this. However, some specific > > texts > > > that Laurent have proposed may create some confusions. Let me expalin as > > > follows : > > > > > > If the lower layer mobility (e.g., radio link or network layer) is > > > transparent to the H.323 layer, nothing needs to done in the H.323 > > > application layer. However, the lower layer mobility may cause an impact > > > on > > > the higher layer (e.g., H.323) as well. If it is so, the proper > > > abstraction > > > in the higher layer (e.g., H.323) should be there to take care of this > > > situation. > > > > > > For example, switching of cells (e.g., cellular IP) may not cause any > > > impact > > > in the H.323 layer. In this situation, this mobility is transparent to > > the > > > H.323 layer. In some situation, the swiching of cells may also cause an > > > impact on the H.323 layer (e.g., H.323 point of attachment). In this > > case, > > > resources of the H.323 layer should also be taken care-of accordingly. > > > > > > Temporary IDs may also be needed in the H.323 layer. Contributions are > > > provided why these IDs are needed in the H.323 layer. These are the > > alias > > > addresses and can have an astraction in the H.323 layer. That does NOT > > > mean > > > in anyway that the solution of the H.323 is becoming specific to the > > radio > > > link layer. > > > > > > Similarly, LRQ message sets have the addresses that have been abstracted > > > in > > > the H.323 layer. Contributions have been provided why the paging of the > > > LRQ > > > message is needed in the H.323 layer. > > > > > > (However, I agree with him that location area may NOT be needed in H.323 > > > because the concepts of H.323 zones/domains will be sufficient. In same > > > token, we also do not need the concept of cells in H.323.) > > > > > > I find that texts proposed in the contribution are too restrictive. > > > > > > Finally, I propose that Laurent should keep an eye to the H.323 solution > > > that will be agreed upon should be transparent to the lower layer (e.g., > > > radio link or network layer) as we make more progress in this area. > > > > > > Best regards, > > > Radhika R. Roy > > > AT&T > > > + 1 732 420 1580 > > > rrroy(a)att.com > > > > > > > > > > > > > > > > -- 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

H.323 Mobility Conference Call
by Roy, Radhika R, ALARC 13 Dec '99

13 Dec '99

Hi, Everyone: Here is the detail of tomorrow's H.323 mobility conference call: Conference Call Information and Agenda Date: December 14,1999 Time: 8:00 AM to 10:00 AM (Pacific Standard Time (PST)) Reservation # 13814047 Number port reserved: 30 Ports Conference Call Bridge call in number: +1 (212)-293-3602 Passcode: 1767395 We provide our sincere thanks to IMTC (Senthil Sengodan, Nokia, senthil.sengodan(a)nokia.com) for facilitating the conference call though providing ports. We also provide thanks to Paul K. Reddy of Intel for conducting the conference and taking notes. Note: All participating companies are welcome to submit Contributions (in addition to previous contributions), which Pertains to 6b, 6c and 7a. The contributions, which are not reviewed during last conference call will be automatically carried over to the December 14, 1999 conference call. Please send your requests for new MTD number for each new contribution you planned to submit for the December 14, 1999 conference to Mr. Paul K. Reddy at paul.k.reddy(a)intel.com. Once you are assigned with a MTD number, please forward the contribution to Mr. Paul K. Reddy to upload all your contributions as zipped files to the reflector at ftp://standard.pictel.com/avc-site/Incoming/H.323_Mobility/ConfCall12141999 directory. Agenda: 1. Call to Order & Opening Remarks 2. Attendance Registration 3. Introduction and Numbering of Contributions: 4. Agenda Review and Approval: MTD-301 4a. Review H.323 Mobility Ad Hoc Meeting report: MTD-302 5. Correspondence to other standards groups TIPHON, IMTC, IMT-2000 ITU-T SG-11, 3GPP for correspondence 6. Old Business MTD-110 (already reviewed) 6a. review Carry over contributions 6b. H.323 Mobility Functional Entities (HLF, VLF, AuF, IWF):MTD-104, MTD-105, MTD-107, MTD-111, MTD-112 6c. H.323 Mobility Architecture: MTD-103, MTD-106 6d. 7. New Business 7a. H.323 Interworking with PLMNs (H.246 Annex E scope, Goal and work plan):MTD-109, MTD-108 8. Meeting Schedule 8a. Discuss next conference call meetings 9. Review Assignments 10. Review Workplan 11. Open Discussion 12. Adjourn ----------------------------------------------------------------------- December 8, 1999 Conference Call Meeting Summary 1. Call to Order & Opening Remarks Conference call started at 8:05 am, Monday, December 8, 1999 hosted by IMTC (International Multimedia Teleconferencing Consortium). 2. Attendance Registration See roster below. Introduction and Numbering of Contributions: Contributions which were upload and are available for review at: http://standards.pictel.com/ftp/avc-site/Incoming/H323_Mobility/ConfCall1214 1999 and http://standards.pictel.com/ftp/avc-site/9910_Red 3. Agenda Review and Approval Contribution MTD-201 (Agenda, was introduced by conference call chair) reviewed and accepted as modified (Assigned the AT&T new contribution MTD-111 to agenda item 6b) 4. Review H.323 Mobility Ad Hoc Meeting report: MTD-202 Contribution MTD-202 - Conference call chair introduced the last conference call report and reviewed and approved with no modifications. 5. Correspondence to other standards groups none 6. Old Business : MTD-110 none 6a. review Carryover contributions 6b. H.323 Mobility Functional Entities (HLF, VLF, AuF, IWF):- MTD-104, MTD-105, MTD-107, MTD-111 Contribution MTD-104: Nokia continued the introduction of the H.323 Annex H functional architecture and reference points document. · After much discussion on the new the interfaces between HLF, VLF, AuF and existing H.323 network, the group agreed that H.323 Mobility architecture figure 1 from Nokia's contribution shall be accepted with the following two additions to the figure and then added into H.323 Annex H baseline document. 1. Add new interface from Visiting network VLF to Home network HLF 2. Also, add the Gateway and show the appropriate interface in the H.323 Mobility architecture figure · Nokia introduced the rest of the contribution with scenarios as FYI at this point. · Nokia was given the assignment to update the Architecture figure and send it to the H.323 Annex H editor to include in the H.323 Annex H baseline document. Contribution MTD-111: was introduced by AT&T, which is related to the Architecture document. Which was discussed and accepted as information only. Contributions MTD-105: was introduced by Ericsson, the group asked Ericsson to modify and resubmit the document after showing the exact text changes to H.323 Annex H definition document. Contribution MTD-106 and MTD-107: Alcatel introduced the MTD-106 and MTD-107 together. Due to the lack of time during December 8,1999 conference call, Alcatel contributions will be carried over to next conference call. 6c. H.323 Mobility Architecture: MTD-103, MTD-106 Contributions MTD-103 is carried over to next conference call, which is scheduled on December 14,1999. 6d. 7. New Business 7a. H.323 Interworking with PLMNs (H.246 Annex E scope, terms of reference and work plan): MTD-109, MTD-108 Contributions MTD-108 and MTD-109 are carried over to next conference call, which is scheduled on December 14,1999. 8. Meeting Schedule 8a. Discuss next conference call meetings: H.323 Mobility Ad Hoc group agreed to have next conference call on December 14, 1999 from 8:00 AM to 10:00 AM (Pacific Standard Time (PST)) and IMTC to make arrangement for the conference call bridge. 9. Review Assignments None 10. Review Workplan None 11. Open Discussion None 12. Adjourn Conference call Meeting adjourned Wednesday, December 08, 1999 at 10:10 AM (PST). Table 1: Contributions submitted and carried over from previous Conference Call for H.323 Mobility Conference Call on December 08, 1999 Previous MTD MTD Source Title MTDs in the Conf. Call, Dec., 08, 1999 201 Intel H.323 Mobility Ad Hoc Group Conference Call Agenda & Bridge information. 202 Intel H.323 Mobility Ad Hoc Group Nov., 29,1999 Conference call Report 5a 103 Motorola 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 6 104 Nokia H.323 Annex H Functional Architecture and Reference Points 7 105 Ericsson "Definition of terms for H.323 Annex H". 8 106 Alcatel Integrating 3GPP's architecture into the H.323 wireless IP mobility system 9 107 Alcatel Clear Split of functions between Call Control and (radio) Access networks /Annex-H (User, Terminal and Service Mobility in H.323) 10a 108 Motorola IMT-2000 Global Roaming and Interworking Scenarios 13 109 Intel H.246 Annex E Goal and Workplan 03b 110 Motorola Updated H.323 Annex H document 111 AT&T H.323 Annex H Functional Architecture and Reference Points 112 AT&T Extension of H.323 Protocol for Mobility Table 2: Attendance Registration for H.323 Mobility Conference Calls Name Company Phone FAX E-Mail Paul K. Reddy Intel Corporation 503-264-9896 503-264-3375 paul.k.reddy(a)intel.com Vineet Kumar Intel Corporation 503-264-3439 503-264-3375 vineet.kumar(a)intel.com Jaakko Sundquist Nokia jaakko.sundquist(a)nokia.com Peeter Pruuden Nokia peeter.pruuden(a)nokia.com Senthil Sengodan Nokia senthil.sengodan(a)nokia.com Pekka Rissanen Nokia pekka.ja.rissanen(a)nokia.com Radhika R. Roy AT&T rrroy(a)att.com Marc Roelands Siemens marc.roelands(a)siemens.atea.be Edgar Martinez Motorola martinze(a)cig.mot.com Paul Guram Motorola lpg019(a)email.mot.com Milo Orsic Lucent Technology orsic(a)lucent.com Stephen Terrill Ericsson stephen.terrill(a)ericsson.com Gösta Linder Ericsson gosta.linder(a)lme.ericsson.se Anders Svennevik Ericsson Anders.Svennevik(a)era.ericsson.se Paul E. Jones Cisco +1 919-392-6948 +1 919-392 -6801 paul.jones(a)ties.itu.int Manjari Asawa Cisco masawa(a)cisco.com Barry Aronson Toshiba Corp. baronson(a)acm.org Laurent Thiebaut Alcatel +33 (0)1 3077 0645 laurent.thiebaut(a)alcatel.fr Nicolas Tran Alcatel Nicolas.Tran(a)alcatel.fr Ameneh Zahir-Emami Alcatel Ameneh.Zahir-Emami(a)alcatel.fr Note: Please check your information and email it to paul.k.reddy(a)intel.com with your phone numbers and any corrections Best regards, Radhika R. Roy, AT&T H.323 Ad Hoc Mobility Group +1 732 420 1580 rroy(a)att.com

1 0

Re: [Robustess] D.225 from Chile
by Maureen Stillman 13 Dec '99

13 Dec '99

Enclosed is the document you requested. -- maureen -----Original Message----- From: EXT Orit Levin [mailto:orit@radvision.com] Sent: Monday, December 13, 1999 2:05 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: [Robustess] D.225 from Chile Hello Maureen and the others! Could you, please, send to me the full D.225 from Chile. Thanks a lot. Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com <http://www.radvision.com> orit(a)radvision.com <mailto:orit@radvision.com>

1 0

[Robustess] D.225 from Chile
by Orit Levin 13 Dec '99

13 Dec '99

Hello Maureen and the others! Could you, please, send to me the full D.225 from Chile. Thanks a lot. Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com

1 0

H.323 Annex L Conference Call Details
by Dave Walker 13 Dec '99

13 Dec '99

Here are the details and the agenda for this Wednesday's conference call on H.323 Annex L. I've provided some initial thoughts on the agenda items. ---------------------------------------------------------- Call Details ------------ date - 15 December 1999 (Wednesday) time - 11:00 EST phone - 1 800 267 6244 (North America only, sorry) 1 613 592 2122 (international) You'll reach the Mitel switchboard - ask them for Dave Walker's conference call! ---------------------------------------------------------- Agenda ------ 1. introduction of participants 2. positioning Annex L in relation to other flavours of H.323 2.1. H.450 H.450 describes peer-to-peer functional signalling for a well-defined set of supplementary services. Interoperability of non-standard services is limited. Definition of new services is a lengthy process. 2.2. H.323 H.323 supports both peer-peer and limited client-server models with limited support for supplementary services. 2.3. H.248 H.248 is purely client-server typically without any knowledge of call signalling. There is no explicit linkage to H.323 although H.323 may be used transparently to the MG. Given support for appropriate pre-defined packages, it should be possible to attain interoperability of non-standard features. Entities supporting H.248 do not necessarily interwork with H.323 entities. 2.4. H.323 Annex K Annex K offers flexibility of services for EPs which support HTML/WML. Limited control over media streams is available except via nonstandard APIs. Annex L offers extended control opportunities to Annex K based systems. 2.5. H.323 Annex L Annex L enables the interoperability of non-standard features that is offered by H.248, while ensuring compatibility with existing H.323 networks. Annex L is designed to enable full flexibility of non-standard supplementary services to H.323 version 1 and version 2 EPs. 3. requirements 3.1. level of backwards compatibility Explicit support for Annex L is via the presence of suitably encoded nonStandardControl in H323-UU-PDU (note that I still want to rename this field to alternateControl). I insist that v1 and v2 EPs be able to participate in the control aspect of the protocol if they support Keypad and Display and provide some means to inject desired escape sequences. 3.2. IA5/Unicode Display and Keypad require IA5. The requirement for Unicode is undeniable. IA5 is the same as U+0000 to U+00FF. Display and Keypad coding shall be IA5 unless the recieving entity has previously indicated support for Unicode. Use of Unicode could be negociated (or configured), or each usage could be tagged. 3.3. graphics support Sophisticated support can come from HTML. Do we need anything else? I think simple support for a bit-mapped display could be easily added, do we need it? and what protocol should be used? 3.4. HTML/WML based My belief is that Annex K addresses this entirely. While it would be easy to to add "HTML" or something as a type of capability, I don't think it reasonable to attempt to transport these pages/decks via H.323 signalling. So the option seems to be to add a mechanism for sending URLs in Annex L. The only advantage this would seem to present is the use of fields that exist in v1 and forward. 3.5. FA and FI Adding Feature Activation and Feature Indication. These are defined in Q.932 as Feature Key protocol. As defined there, two new information elements would be required. Alternatively, the information otherwise provided by these IEs could be text-encoded in the Keypad and Display IEs. 4. architectural models This is kind of addressed by item 2 in the agenda. We need some diagrams illustrating this and also some presenting locations of Feature Server with respect to controlled EPs and other H.323 entities. 5. document restructure - All of the ASN.1 encoding should be moved to its own section. - Description of all of the fields is required (taking H.225.0 as an example). 6. enhancements/changes to existing protocol (APC-1660) 6.1. text based One issue is the limiting size of Keypad and Display. The ability to handle larger sizes is a capability that could be negoctiated. Another issue is whether management aspects should be text based or ASN.1 based (as presented in APC-1660). 6.2. graphics? 6.3. HTML/WML beyond Annex K? 7. work plan Needs a section describing the procedures, as well as a few examples including full signalling MSCs. Volunteers? We need a section that describes minimal functionality (one or two flavours of).

1 0

[Robustness] conference call reminder -- Tuesday, Dec. 14 11AM ES T USA
by Maureen Stillman 13 Dec '99

13 Dec '99

The conference call for robustness, arranged by Nokia, is scheduled for Tuesday, December 14th at 11:00 AM EST USA. Conf call number: 613-688-2795 Access code 9234# Please send e-mail to maureen.stillman(a)nokia.com if you plan to attend. Failure scenarios will be discussed. Please send failure scenarios to the Study Group 16 mailing list. Hope to talk with you on 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

Re: H.323 meeting:?
by Roy, Radhika R, ALARC 12 Dec '99

12 Dec '99

Hi Ed: December 14: 11-1 PM EST USA. IMTC will provide the conf port. Paul is supposed to let me know in detail. I told Paul that I would request you to conduct the meeting in case he could not attend the meeting from Japan. Thanks, Radhika > -----Original Message----- > From: Edgar Martinez [1] [SMTP:martinze@cig.mot.com] > Sent: Sunday, December 12, 1999 2:56 PM > To: Roy, Radhika R, ALARC; H.323 Mobility > Subject: H.323 meeting:? > > Hi Radhika, > > I like to know when is the next conference call. > > -- > 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

H.323 meeting:?
by Edgar Martinez [1] 12 Dec '99

12 Dec '99

Hi Radhika, I like to know when is the next conference call. -- 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: [Robustness] Conference Call
by Kumar, Vineet 10 Dec '99

10 Dec '99

i plan to attend. vineet -----Original Message----- From: Steve.Edgar(a)NOKIA.COM [mailto:Steve.Edgar@NOKIA.COM] Sent: Thursday, December 09, 1999 12:57 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: [Robustness] Conference Call The conference call for robustness, arranged by Maureen Stillman, is scheduled for Tuesday, December 14th at 11:00 AM EST USA. Conf call number: 613-688-2795 Access code 9234# Please send e-mail to maureen.stillman(a)nokia.com if you plan to attend. Failure scenarios will be discussed. Please send failure scenarios to the Study Group 16 mailing list.

1 0