- 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

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

Re: I-D ACTION:draft-ietf-megaco-reqs-09.txt
by Tom-PT Taylor 10 Dec '99

10 Dec '99

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

Question! MCU cascading
by Jun-young Heo 10 Dec '99

10 Dec '99

Hi everyone! I have a question about MCU cascading. I know MC cascading from reading H.323v2 recommendation. But, i'm not sure how to control media distribution. I think MasterMC knows only capset of local terminals connected directly. so, MasterMC can't make a SCM(selected communication mode) about all terminals. How MasterMC knows it? Eventually, I want to know about MP cascading excatly. One more question. Is SessionID in message related to logical channel and CommunicationModeCommand, distributed by MC? H.245 recommendation says, "Only the master can create the session identification." at p.81. But, Netmeeting and ViewStation which I tested create session ID itselft by convention(Audio:1, Video:2). Is it right? I wish experts advise to me. thanks for reading. bye.

1 0

[Robustness] RADVision's input for the conference call
by Orit Levin 09 Dec '99

09 Dec '99

Hello Maureen and all the others! Please count on two RADVision's legs for the conference: one for myself and the other for RADVision Ltd. in Israel. I am attaching our input to the conference call. The paper discusses problems and possible solutions for GK failure in the middle of managing routed calls. Best Regards, 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

[Robustness] Conference Call
by Steve.Edgar＠NOKIA.COM 09 Dec '99

09 Dec '99

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

H.323 Annex L Conference Call Announcement
by Dave Walker 09 Dec '99

09 Dec '99

There will be a conference call next week to discuss the evolution of the H.323 stimulus protocol (Annex L), the most recent draft being APC-1660. The call will be on Wednesday, December 15 at 11:00 AM EST. I will be publishing call coordinates and an agenda on Monday. I would appreciate if everyone interested in participating would send me mail so that I can reserve a sufficient number of ports. Regards, Dave Walker Mitel Corporation Ontario, CANADA

2 1