- sg16-avd - lists.packetizer.com

H.323 Mobility Conference Call Meeting Minutes
by Roy, Radhika R, ALARC 15 Dec '99

15 Dec '99

Hi, Everyone: Next Meetings: Our next H.323 Mobility Conference Calls will held as follows: January 10 and 17: 11 AM - 1 PM, Eastern Standard Time (EST), USA. The detail of the conference bridge and meeting agenda will be sent later. Please send your contributions to Edgar Martinez, Motorola Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Meeting Minutes: The H.323 Ad Hoc Mobility Conference call was held on December 14, 1999. We provide our sincere thanks to IMTC for providing conference ports. Thanks to Ed Martinez of Motorola for conducting the meeting and taking notes. The companies represented in this meeting where: Motorola, Lucent, Intel, Alcatel, AT&T, Ericsson, Siemens On the status of the join MTD-3 contribution, Title "Annex-H (User, Terminal and Service Mobility in H.323)" at this time MTD-3 is up to version MTD-3b which was last reviewed in the conference call of Nov. 17, 1999. MTD-3 (final version) will be a joint contribution that will be presented in SG 16 and its Working Parties in Switzerland [Geneva] meeting from February 7 to 18. The status of this document is not the official H.323 Annex-H document but, a join H.323 mobile ad-hoc group contribution for H.323 Annex-H. It was recommended by Lucent that the cover page for MTD-3 mention the fact that MTD-3 is a join contribution from the mobile ad-hoc group, to be considered for input to the official H.323 Annex-H. MTD-03 will be updated on the receive of Nokia's agreed Ad-hoc architecture diagram on the Dec.8, conference call meeting. The diagram and contents will be posted to give the H.323 Ad-hoc group and other interested parties, time to do a final review before the next meeting in Jan. 10, 1999. For the next two meetings Ed marinez will be taking the contributions and will re-number the documents to the original numbering scheme and add the versions (e.g. MTD-00, MTD-00a...MTD-00z) and just carry the MTD's over to the next meeting. The reason is that the documents are being missed numbered from one meeting to another. Also, I find no good reason to change the number of the MTD, if the document has not changed, then why give it a new number. It is also confusing to other Ad-hoc members. Only two contributions where review MTD-106 and MTD-107b by Alcatel. MTD-106 gave a high level of 3GPP mobility and the presenter focus on section 3.9 Mobility Management procedures. To make a point that 3GPP that supports two registrations bearer and application level registrations . The proposal was that H.323 mobility support two registrations one called bearer level registration (e.g. GPRS attach) and, if so specified/allowed by the Mobile Set, MS subscription profile, an application level registration. MTD-107b AT&T and Alcatel started to review the contribution word by word to see what could be included in the join mobile ad-hoc contribution MTD-3 for February's full SG-16 meeting. Time ran out no resolution on what could be added or taken out of MTD-3. It is expected that a discussion will be held via email in the SG16 reflector related to Alcatel's contribution. The next two meetings are for January 10 and 17 the time, date and agenda will be posted. You may sent the contribution to Ed Martinez via email and he will download it for you and provide a MTD# if needed. Please advise Ed Martinez if your contribution which was put in the first conference call was not reviewed, so we can get to it before the last meeting on January 17. Best Regards, Radhika R. Roy, AT&T H.323 Ad Hoc Mobility Group +1 732 420 1580 rrroy(a)att.com

1 0

Re: I-D ACTION:draft-ietf-megaco-reqs-09.txt
by Nancy-M Greene 15 Dec '99

15 Dec '99

I've done my homework and filled in the references for the Megaco/H.248 requirements document (draft-ietf-megaco-reqs-09.txt) (thanks to those who helped me fill them in): > draft-ietf-megaco-reqs-09.txt references: > 13. References > > [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev- > els", RFC 2119, March 1997. > [2] Draft ITU-T Recommendation Q.2630.1, AAL type 2 Signalling Protocol > (Capability Set 1), ITU-T Meeting Report COM 11-R 149-E, July 1999 > [3] ITU-T Recommendation H.341, Line Transmission of Non-Telephone > Signals, May 1999. > [4] ATM Forum Technical Committee, af-vtoa-0083.001, Voice and Telephony > Over ATM to the Desktop Specification, March 1999. > [5] ITU-T Recommendatio H.323v2, Packet-based Multimedia Comunications > Systems (includes Annex C - H.323 on ATM), February 1998. > [6] ATM Forum Technical Committee, af-saa-0124.000, Gateway for H.323 > Media Transport Over ATM, May 1999. > [7] ITU-T Recommendation T.140, Protocol for Multimedia Application Text > Conversation, February 1998. > [8] ITU-T Recommendation V.18, Operational and Interworking Requirements > for DCEs Operating in Text Telephone Mode, February 1998. > [9] ITU-T Q.931, Digital Subscriber Signalling System No. 1 (DSS 1) - > ISDN User-Network Interface Layer 3 Specification fro Basic Call Control, > March 1993 > > Nancy > -------------------------------------------------------------------------- > Nancy M. Greene > Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > > > ---------- > From: Taylor, Tom-PT [CAR:B904-I:EXCH] > Sent: Friday, December 10, 1999 9:41 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: I-D ACTION:draft-ietf-megaco-reqs-09.txt > > I propose WG Last Call based on this document, with the expiry two weeks > hence (24 December). > > Changes from the previous version are as follows: > > - removed reqt 5.6 c) Support general test capabilities, for example > loopbacks through the MG to test DSP operation. > It was agreed that inward loopbacks are outside the scope of the protocol > - they are not part of call control, so would be handled by some other > maintenance protocol. Thus the above requirement is deleted. > > - reqt 5.7 a) - changed word call to connection > > - table in section 11 - removed wiretap > > - reqt 11.1.3.1 a) rewording of 2nd bullet on addressing - didn't mean > wildcarding, meant instead allowing the gateway to choose (part of) the > identifier > > > The references need to be completed still, and there may be an editor's > note or two that should still come out. > > -----Original Message----- > From: Internet-Drafts(a)IETF.ORG [SMTP:Internet-Drafts@IETF.ORG] > Sent: Friday, December 10, 1999 8:08 AM > To: MEGACO(a)STANDARDS.NORTELNETWORKS.COM > Subject: I-D ACTION:draft-ietf-megaco-reqs-09.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Media Gateway Control Working Group of > the IETF. > > Title : Media Gateway control protocol > architecture and > requirements > Author(s) : N. Greene, M. Ramalho, B. Rosen > Filename : draft-ietf-megaco-reqs-09.txt > Pages : 45 > Date : 09-Dec-99 > > TThis document describes protocol requirements for the Media Gateway > control protocol between a Media Gateway Controller and a Media Gateway. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-megaco-reqs-09.txt > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-megaco-reqs-09.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv(a)ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-megaco-reqs-09.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. << Message: >> > >

1 0

H.323 Mobility: docs
by Edgar Martinez [1] 15 Dec '99

15 Dec '99

Dear Adhoc-mobility, All the documents of the Adhoc-mobility group have been put in: ftp://standard.pictel.com/avc-site/Incoming/H323_Mobility/SG16_Mobility/ If you want to update your contribution for resubmission please do so. By adding an letter version, e.g. MTD-00.zip is version 1, MTD-00a is version 2 , MTD-00b is version 3 and so on. If you want to put a new contribution in, please sent it to me via email mailto:martinze@cig.mot.com I will down load and provide you a MTD number. Regards, -- Edgar Martinez - Principal Staff Engineer Email 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: Editor's comments
by Edgar Martinez [1] 15 Dec '99

15 Dec '99

Dear Mobile Ad-hoc group: Radhika Roy will send out the final meeting minutes, this is only input to the minutes. If anyone else wants to add to the minutes please post and copy Radhika Roy. Mobile ad-hoc group meeting Dec. 14, 1999 The companies represented in this meeting where: Motorola, Lucent, Intel, Alcatel, AT&T, Ericsson, Siemens On the status of the join MTD-3 contribution, Title "Annex-H (User, Terminal and Service Mobility in H.323)" at this time MTD-3 is up to version MTD-3b which was last reviewed in the conference call of Nov. 17, 1999. MTD-3 (final version) will be a join contribution that will be presented in SG 16 and its Working Parties in Switzerland [Geneva] meeting from February 7 to 18. The status of this document is not the official H.323 Annex-H document but, a join H.323 mobile ad-hoc group contribution for H.323 Annex-H. It was recommended by Lucent that the cover page for MTD-3 mention the fact that MTD-3 this is a join contribution from the mobile ad-hoc group, to be considered for input to the official H.323 Annex-H. MTD-03 will be updated on the receive of Nokia's agreed Ad-hoc architecture diagram on the Dec.8, conference call meeting. The diagram and contents will be posted to give the Ad-hoc group and other H.323 mobile and other interested parties, time to do a final review before the next meeting in Jan. 10, 1999. Note: I did not attend the Dec. 8 meeting. ---- For the next two meetings I will be taking the contributions and will re-number the documents to the original numbering scheme and add the versions (e.g. MTD-00, MTD-00a...MTD-00z) and just carry the MTD's over to the next meeting. The reason is that the documents are being missed numbered from one meeting to another. Also, I find no good reason to change the number of the MTD, if the document has not changed, then why give it a new number. It is also confusing to other Ad-hoc members. ---- Only two contributions where review MTD-106 and MTD-107b by Alcatel. MTD-106 gave a high level of 3GPP mobility and the presenter focus on section 3.9 Mobility Management procedures. To make a point that 3GPP that supports two registrations bearer and application level registrations . The proposal was that H.323 mobility support two registrations one called bearer level registration (e.g. GPRS attach) and, if so specified/allowed by the Mobile Set, MS subscription profile, an application level registration. MTD-107b AT&T and Alcatel started to review the contribution word by word to see what could be included in the join mobile ad-hoc contribution MTD-3 for February's full SG-16 meeting. Time ran out no resolution on what could be added or taken out of MTD-3. --- The next two meetings are for January 10 and 17 the time, date and agenda will be posted. You may sent the contribution to me at my email, I will download then for you and provide a MTD# if needed. Please advise me if your contribution which was put in the first conference call was not reviewed, so we can get to it before the last meeting on January 17. 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/

1 0

Re: [Robustness] A couple comments on D.225
by Ami Amir 15 Dec '99

15 Dec '99

I heartily agree with Offer's recommendations, and particularly think that the only distinction to be made is between the registration process and the call related functionality. Ami -----Original Message----- From: Offer Pazy [mailto:Offer_Pazy@EUR.3COM.COM] Sent: 15 December, 1999 14:21 To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: [Robustness] A couple comments on D.225 Hello, I hope that this is the right forum, procedure and timing for commenting on the D.225 document. If not, please use moderate flames only.... In general, I like the models presented and I think they serve a useful starting point. I would like to offer two simplifications: 1. Distributed Vs hierarchical architectures: I don't see the value of having a special hierarchical case. As suggested in D.225, we must avoid single point of failures. The node at the top of the diagram (figure 7) is such a point unless we introduce redundancy for it as well. When we do so, we go back to the general distributed case where each node has a primary GK of a zone plus zero or more backup GKs for other zones. My view is that describing the model in this way is simpler than having two distinct cases, 2. D.225 proposes that the three internal "components" of a GK should be exposed and that redundancy mechanisms should be defined for them. I wonder if we should not keep this as an implementation issue. After all, GKs are defined in H.323 as containing all these three components and there was no intention (I believe) to force end-points to distinguish between a failed GK and the failure of one of its subcomponents. To formalize such granularity would require us to answer questions such as: What happens if the Q.931 component of GK A fails but its H.245 component is running OK, and the backup of the Q.931 of GK A resides with GK B whose RAS component has failed? Or, what happens when an endpoint is registered with GK A but uses GK B (GK-routed) as the originating GK when the Q.931 component of A has failed? etc. etc. Clearly this is a complex problem to solve. Instead I believe we should concentrate on treating the GK as a monolithic entity which 1) has fail-stop semantics and 2) a backup entity is backing up the GK as a whole as opposed to having a backup for each subcomponent. From the standard and protocols stand-point this will suffice. Clearly, implementors will have to invest efforts in designing their GK architectures in the most fault tolerant manner (and may use some of the ideas presented in D.225), but this should really be out of scope for the standard as long as the semantics of a failed GK are clearly defined. A slightly different way to look at the proposal in D.225 is to reduce the number of GK subcomponents from three (RAS, Q.931, H.245) to two: Registration issues and "a particular call"-related issues. As can be noticed, this idea does not just decrease the granularity (which by itself simplifies things), but also shifts the focus of the model from that of an implementation view to a more behavioral view. It can be argued that H.323 endpoints already have to distinguish between the registration process and failures and the process of call establishment and control. Offer

1 0

[Robustness] A couple comments on D.225
by Offer Pazy 15 Dec '99

15 Dec '99

Hello, I hope that this is the right forum, procedure and timing for commenting on the D.225 document. If not, please use moderate flames only.... In general, I like the models presented and I think they serve a useful starting point. I would like to offer two simplifications: 1. Distributed Vs hierarchical architectures: I don't see the value of having a special hierarchical case. As suggested in D.225, we must avoid single point of failures. The node at the top of the diagram (figure 7) is such a point unless we introduce redundancy for it as well. When we do so, we go back to the general distributed case where each node has a primary GK of a zone plus zero or more backup GKs for other zones. My view is that describing the model in this way is simpler than having two distinct cases, 2. D.225 proposes that the three internal "components" of a GK should be exposed and that redundancy mechanisms should be defined for them. I wonder if we should not keep this as an implementation issue. After all, GKs are defined in H.323 as containing all these three components and there was no intention (I believe) to force end-points to distinguish between a failed GK and the failure of one of its subcomponents. To formalize such granularity would require us to answer questions such as: What happens if the Q.931 component of GK A fails but its H.245 component is running OK, and the backup of the Q.931 of GK A resides with GK B whose RAS component has failed? Or, what happens when an endpoint is registered with GK A but uses GK B (GK-routed) as the originating GK when the Q.931 component of A has failed? etc. etc. Clearly this is a complex problem to solve. Instead I believe we should concentrate on treating the GK as a monolithic entity which 1) has fail-stop semantics and 2) a backup entity is backing up the GK as a whole as opposed to having a backup for each subcomponent. From the standard and protocols stand-point this will suffice. Clearly, implementors will have to invest efforts in designing their GK architectures in the most fault tolerant manner (and may use some of the ideas presented in D.225), but this should really be out of scope for the standard as long as the semantics of a failed GK are clearly defined. A slightly different way to look at the proposal in D.225 is to reduce the number of GK subcomponents from three (RAS, Q.931, H.245) to two: Registration issues and "a particular call"-related issues. As can be noticed, this idea does not just decrease the granularity (which by itself simplifies things), but also shifts the focus of the model from that of an implementation view to a more behavioral view. It can be argued that H.323 endpoints already have to distinguish between the registration process and failures and the process of call establishment and control. Offer

1 0

[Robustness] Draft scenario for discussion -- malicious attacks
by Maureen Stillman 14 Dec '99

14 Dec '99

Enclosed is my draft contribution to robustness scenarios. <<Robustness scenario.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: [Robustness] conference call reminder -- Tuesday, Dec. 14 11A M ES T USA
by Roy, Radhika R, ALARC 14 Dec '99

14 Dec '99

Hi, Maureen: Due to conflict with the H.323 Mobility Conference call, I cannot attend this conference call. I am sorry for this. However, I am providing some quick inputs to the team as follows: Possible examples of H.323 Failures/Scenarios: 1. GK failures 2. GK/BE failures 3. H.323 terminal failures 4. H.323 GW failures 5. H.323 MCU failures 6. H.323 MC failures 7. TCP/UDP port failures for RAS, Q.931/932, and/or H.245 8. Network layer interface failures abstracted to the H.323 layer 9. Network link failures abstracted to the H.323 layer 10. RAS signaling messages' failures while TCP/UDP ports are up 11. Q.931 call signaling messages' failures while TCP/UDP ports are up 12. Call/conference related ID failures 13. H.245 logical channel failures 14. H.245 messages failures 15. RAS, Q.931/932, and/or H.245 signaling module failures Failure recovery: For each failure, how does the H.323 system recover? Hope that the team members may consider to discuss some failures scenarios around the above items. Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com > -----Original Message----- > From: Maureen Stillman [SMTP:Maureen.Stillman@NOKIA.COM] > Sent: Monday, December 13, 1999 10:32 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [Robustness] conference call reminder -- Tuesday, Dec. 14 > 11AM ES T USA > > 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

Alcatel MTD 107b
by Laurent Thiebaut 14 Dec '99

14 Dec '99

Please find attached a new version of MTD107. Could someone please put it on the "incoming" ftp server. Thank you for the help. Modification w.r.t. previous version are underlined by revision marks and are mainly editorial. (See attached file: MTD-107b.zip) 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 ---------------------------------------------------------------------------

1 0

Re: Comments on MTD-107a
by Roy, Radhika R, ALARC 14 Dec '99

14 Dec '99

Hi, Laurent: We would like to have the solution in H.323 layer that is independent of the lower layer in the context of Rec. H.323. It is not only for the radio layer (link), but also for the network and transport layer. Let us examine that there are certain situations where the abstraction of mobility in the radio layer (link) has an impact on the H.323 layer due to mobility. The resources in the H.323 layer should be taken care-of accordingly in mobile environments. Most the radio link layer mobile interactions will be transparent to the H.323 layer while certain situations of the radio link layer will have an impact due to mobility. The paging of the LRQ message is an example. With respect Motorola's contribution, we may have to discuss: To see whether the H.323 solution is independent of the radio link layer or not. I would also refer to see AT&T's contributions submitted in the last Red Bank meeting (PACs-1651/1652/1664/1665). I would be please to answer any questions in connection to the proposed solution in the light of the above. Best regards, Radhika R. Ro AT&T > -----Original Message----- > From: Laurent.Thiebaut(a)alcatel.fr [SMTP:Laurent.Thiebaut@alcatel.fr] > Sent: Tuesday, December 14, 1999 4:11 AM > To: Edgar Martinez [1] > Cc: H.323 Mobility; Roy, Radhika R, ALARC > Subject: Re:Re: Comments on MTD-107a > > > > 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