2 Nov
1999
2 Nov
'99
10:27 a.m.
Hi Ed, Please do not include anything in the H.323 Annex H until a given concept has been discussed and jointly accepted. I commend you for your enthusiasm to get it done, but let us follow the established procedures. Thanks, My best regards, Milo Orsic Lucent Technologies > ---------- > From: Edgar Martinez [1][SMTP:martinze@CIG.MOT.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Monday, November 01, 1999 9:23 PM > To: ITU-SG16@mailbag.cps.intel.com > Subject: Re: H323mobility:meeting > > Hi Radhika, > > I am glad to see that we all agreed mobility on H.323 is not > rocket science. > > On the call scenarios I did not see any conflicts with > h.225 call control. Once the mobility/location issue is resolve, that is > once > the application knows where to route the calls. In other words, when the > RAS > procedures and the location updates are done, we know where to route the > call, > using basic h.225 call control. And it was covered in Motorola's APC 1646. > By > the way, > I like to include the Call scenarios you identified in the H.323 annex-H > document. > To test out "OUR" H.323 combined contributions for the architecture. > > Also see last comments below. > > "Roy, Radhika R, ALARC" wrote: > > > Hi, Ed: > > > > I guess that we talking about the same thing. > > > > Who told that mobility functions are different in H.323 (IP) or other > > networks? The basic functionality is the same from end users' point of > view. > > > > In H.323, the H.323 (e.g., H.225.0, Q.931/932) signaling messages are > used. > > The cellular-PSTN networks use their signaling messages. The call > scenarios > > can be as follows: > > > > 1. Mobile H.323 Terminal to Mobile H.323 Terminal > > 2. Mobile H.323 Terminal to Fixed H.323 Terminal and vice versa > > 3. Cellular-PSTN Terminal to Mobile H.323 Terminal (3a) and vice versa > (3b) > > 4. Cellular-PSTN Terminal to Fixed H.323 terminal (4a) and vice versa > (4b) > > > > For cases 1 and 2, mobility solutions can be provided using the H.323 > > mobility only (pl. see AT&T's and Nokia's contributions that deal in > terms > > of H.323 only). > > > > For scenarios 3 and 4, the question of interworking between H.323 (IP) > and > > cellular-PSTN comes. > > > > Because of H.323, we have certain constraints imposed by its > architecture. > > For example, H.323 mobility solution may look as follows: > > > > * H.323 mobility is applicable for both wireless and wire-line > > mobility. > > * H.323 mobility is addressed in the application layer and can be > > implemented to any packet-switched networks (e.g., IP, etc.). > > * H.323 mobility management is done using the RAS (extended to > > incorporate mobility) signaling scheme. RAS is usually used for the > pre-call > > control signaling and, is completely separated from the call control > > (Q.931/932) signaling. However, in H.323, it is mandatory that RAS > signal > > has to go through the gatekeeper (GK). RAS signaling can be used anytime > > independent of the call control scheme. In this respect, H.323 mobility > can > > be managed anytime (before the call, during the call, and/or after the > call) > > as it is necessary. > > * In H.323, Q.931/932 is used for the call control. H.245 is used > > primarily to control media (audio, video, and/or data) within a call. > > * The wireless or wire-line network layer (e.g., IP) can use any > > scheme as appropriate for implementation of the application layer H.323 > > mobility. > > > > (How will a complete end-to-end solution look like that satisfy > scenarios 1, > > 2, 3, and 4? As an HYPOTHETICAL end-to-end solution, I would request > combine > > the solution provided in AT&T's contribution [APC-1651] in H.323 domain > and > > Motorola's contribution [APC-1646] in cellular/PSTN-H.323 excluding some > > redundant functions. > > > I guess that Motorola's solution does NOT address > > scenarios 1 and 2 adequately. > > Once the RAS procedures are done, we know where to route the call using > basic > h.225 call control. > > Motorola is not forcing any solution if one looks at the References > section > of APC-1646 you will see we try to us the best solutions, and sections 4.1 > to > 4.1.2 is > based on AT&T's Document - TD-9 August 2-6 1999 Berlin contribution. As > the > Editor of Annex-H and the lack of contributions at that time, the > reference > below > was all I had to work with. > > [1] ITU-T Recommendation H.245 (1998), Control protocol for multimedia > communication. > [2] ITU-T Recommendation H.323 (1999), "Packet-Based Multimedia > Communications > Systems." > [3] Internet Draft <draft-teoyli-mobileip-mvpn-02.txt> February 1999, > Mobile IP > extension > for Private Internets Support (MPN), W. T. Teo National University of > Singapore > and Y. > Li Nortel Networks, Inc. > [4] W. Liao, "Mobility Internet telephony: Mobile Extensions to H.323," > INFOCOM'99, > New York, NY, USA, 2-6 August, 1999. > [5] RECOMMENDATION ITU-R M.1073-1 DIGITAL CELLULAR LAND > MOBILE TELECOMMUNICATION SYSTEMS (Question ITU-R 107/8) (1994-1997) > [6] HANDOVER PROCEDURES ITU-T Recommendation Q.1005 (Extract from the > Blue > Book) > © ITU 1988, 1993 > [7] E. Martinez, Motorola, "Annex - H (User and Service Mobility in H.323) > Proposed Architecture, > " APC-1560, ITU-T SG16 Q.11-15 Rapporteur Meeting, Berlin, Germany, 2-6 > August, > 1999. > [8] H.323 Mobility Ad Hoc Group, "Terms of Reference for H.323 Mobility", > Temporary Document > No. 34 (Berlin) 5 August 1999 > > Best Regards, > > Ed > > > > The bottom line is that a solution will look > > like this: Add some new messages in H.323 and extend the existing H.323 > > messages. I guess that AT&T's APC-1651 can satisfy almost all > requirements > > specified in Motorola's APC-1646. I hope that APC-1641 will also be able > > interwork with GSM/GPRS, ANSI-41, etc. The requirements for TIPHON > matrix > > will also be satisfied. If needed, one can also use mobile IP or other > > schemes for implementation in the IP network layer. I am personally also > > interested about the location area concept as proposed by Nokia. Of > course, > > I am waiting to see other contributions and on-going discussions.) > > > > Hope this will clarify further. > > > > Thanks, > > Radhika > > > > > -----Original Message----- > > > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > > > Sent: Monday, November 01, 1999 3:14 PM > > > To: ITU-SG16@MAILBAG.INTEL.COM > > > Subject: Re: H323mobility:meeting > > > > > > Hi Radhika, > > > > > > The Annex-h document was push back to 2001. > > > > > > The mobility H.323 additions is not allot of work. > > > The mobility applications and concepts been around > > > for long time. > > > > > > I would hope the following to re-use 100% of the IP > > > network already defined in Standards. And borrowing and applying > > > mobile applications already defined to H.323 . Which can > > > coexist with other mobile "SERVICES" from IETF, GSM/GPRS > > > and even 3GPP. All on the same IP network using one access protocol > > > preferably the H.323 access protocols. Once we have a solid IP network > > > infrastructure which includes other "SERVICES" like: reliable IP > > > transport, > > > QoS, charging/billing, security, IN interworking and naming and > > > address translations. Adding mobility and Interworking services > > > to H.323 seems like a drop in the bucket. Now do we need to defined > > > everything, I argue that only the parts needed to be address are > > > common to all mobile systems. > > > > > > In TIPHON document 7001 we provide a matrix of existing mobile > > > Services on networks. Which compares the mobility aspects > > > for terminal, user and service mobility. > > > > > > In the same token if one looks at H.323 interworking > > > IN on IP, ISDN, ISUP and HTTP services, they're focus > > > is on re-using common elements. And one access protocol > > > H.323, why is mobility any different? > > > > > > Ed > > > > > > "Roy, Radhika R, ALARC" wrote: > > > > > > > Hi, Ed and All, > > > > > > > > I fully agree with you that we need to address both together to have > an > > > > end-to-end solution. In fact, this is also AT&T's goal because we > want > > > to > > > > provide services on end-to-end basis consisting both > cellular-PSTN/ISDN > > > and > > > > H.323 (IP). > > > > > > > > In fact, you have covered some functions: "HomeZone ID, VisitedZone > ID, > > > Home > > > > Aera and Visited Area." That is, we are NOT considering any > generalized > > > > solution that excludes the fundamental concept of "Zone" and > "Domain" of > > > > H.323. > > > > > > > > The point is that we can consider more functions as much as we want, > but > > > we > > > > still needs to work within the framework of H.323. > > > > > > > > When I say that we need to provide solution in the context of H.323, > I > > > mean > > > > that we need to find solution in the framework of H.323 as much as > we > > > can > > > > (that might include all abstractions of cellular-PSTN network, if > > > possible, > > > > in H.323 as well). It provides a systematic way to solve the problem > > > > step-by-step. > > > > > > > > Once we complete this first step, we then apply this solution in the > > > conext > > > > of cellular-PSN/ISDN-H.323 (IP). We will able to test and examine > how > > > far we > > > > have been able to satisfy the requirements in the first step. If we > do > > > not > > > > satisfy all requirements, then we need to extend the functionalities > of > > > the > > > > first step. > > > > > > > > Let us examine the case of location area (LA). As I mentioned in my > > > earlier > > > > email, LA can be considered in H.323 as a subset of zone without > > > relating to > > > > the LA of the cellular-PSTN network. In this situation, LA defined > is > > > H.323 > > > > may not be useful to provide interoperability between cellular-PSTN > and > > > > H.323 (IP). Should we not abstract the LA in H.323 in such a way > that > > > also > > > > provides interoperability in the context of both cellular-PSTN and > H.323 > > > > (IP)? Does not the two-step process provide better granularity to > have > > > the > > > > complete solution? > > > > > > > > H.323 Annex H has two primary sections: H.323 Mobility and > > > Interoperability > > > > (H.323-Cellular-PSTN). > > > > > > > > When I say two-step process, I mean two-step working mode of Annex > H. > > > > However, we will standardize the H.323 Annex H after completing both > > > H.323 > > > > Mobility and Interoperability (H.323-Cellular-PSTN). > > > > > > > > Did we not agree that we may not be able to visualize all functions > to > > > start > > > > with and we may have to come back to add more functions as we go > more > > > deep > > > > into the solution? Kindly see AT&T contributions > APC-1651/1652/164/1665 > > > how > > > > many MORE functions that we need to define even in H.323. Do I start > > > arguing > > > > right now why you are not including all function right away? > > > > > > > > I have not even written a contribution considering > cellular-PSTN-H.323 > > > (IP) > > > > interworking yet. > > > > > > > > Hope this will clarify further. > > > > > > > > Best regards, > > > > Radhika > > > > > > > > > -----Original Message----- > > > > > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > > > > > Sent: Monday, November 01, 1999 12:34 PM > > > > > To: ITU-SG16@MAILBAG.INTEL.COM > > > > > Subject: Re: H323mobility:meeting > > > > > Importance: High > > > > > > > > > > Dear Roy and Jaakko, > > > > > > > > > > The information in Annex-H Draft all came from both TD16 and > > > > > TD42b. The HomeZone ID and VisitedZone ID are new concepts > > > > > used for H.323 mobility which is related to the functions we > > > > > all agreed was needed to provide mobility for the application > point of > > > > > view. > > > > > The new definition should not clash with the meaning of ZONE or > > > > > Domain in H.323. In any event, we need to defined the properties > > > > > of the HomeZone ID, VisitedZone ID, Home Aera and Visited > > > > > Area. In the context of H.323 mobility and Interworking with PSTN. > > > > > > > > > > --- > > > > > New subject: > > > > > > > > > > >Our first goal is to define a mobility architecture in the > context of > > > > > H.323. > > > > > >Our second goal is to interworking between the packet-based H.323 > > > > > mobility > > > > > >architecture and circuit-switched based cellular-PSN/ISDN > mobility > > > > > >architecture. > > > > > > > > > > Motorola is looking at a full end-to-end fixed, wireless > > > > > and mobile full IP solution. Which includes interworking > > > > > as a major basic requirement. > > > > > > > > > > We are not defining or designing a new IP system. Our > > > > > job is simply to add to the existing IP infrastructure wireless > > > access > > > > > and the mobility applications. And support interworking with the > > > legacy > > > > > mobile systems. We and others are looking at providing the full > > > package. > > > > > > > > > > If we do not address the full solution now, I feel we leave the > door > > > > > open for Hybrid systems, so-called network overlay or work > arounds. > > > > > > > > > > I will oppose that Annex-H is complete. If we do not address the > > > > > interworking > > > > > sections (as proposed in the TOR) within the same timeframe that > we > > > are > > > > > defining > > > > > > > > > > how to add the mobility functions to H.323. > > > > > > > > > > Regards, > > > > > Ed > > > > > > > > > > "Roy, Radhika R, ALARC" wrote: > > > > > > > > > > > Hi, Ed, Jaakko, and All, > > > > > > > > > > > > In H.323, zone and domain are well defined. > > > > > > > > > > > > If we can solve mobility problems within the framework of H.323 > as > > > far > > > > > as > > > > > > practicable, we do not need to create new terminology in the > context > > > of > > > > > > H.323 for now. Contributions (APC-1651/1652) have also been > > > presented > > > > > also > > > > > > how H.323 mobility problems can be solved with the context of > zones > > > and > > > > > > domains. > > > > > > > > > > > > I understand that location area (LA) is also used in the > cellular > > > > > wireless > > > > > > network. > > > > > > > > > > > > If the new terminologis like location area (LA) are created for > > > > > interworking > > > > > > between cellular-PSTN and IP networking environments, we > definitely > > > need > > > > > to > > > > > > look into how "LA" is fitted in the context of zone or domain. > > > However, > > > > > zone > > > > > > and domain are the fundamental concept of H.323 that always > needs to > > > be > > > > > > related. > > > > > > > > > > > > Our first goal is to define a mobility architecture in the > context > > > of > > > > > H.323. > > > > > > Our second goal is to interworking between the packet-based > H.323 > > > > > mobility > > > > > > architecture and circuit-switched based cellular-PSN/ISDN > mobility > > > > > > architecture. > > > > > > > > > > > > In H.323, a zone may consist of many networks (e.g., many IP > > > > > subnetworks). > > > > > > Do we need to create LAs within a zone? Will the LA be a good > fit > > > with > > > > > that > > > > > > of cellular network for interworking at this point of time > because > > > we > > > > > have > > > > > > not yet solved the basic problem in the context of H.323? > > > > > > > > > > > > I had some initial discussion with Jaako in the last Red Bank > > > meeting, > > > > > but > > > > > > we could not complete our discussion. My personal view has been > that > > > we > > > > > may > > > > > > need something like LA to further optimize the mobility problem > > > within a > > > > > > zone. For example, paging may be one of the reasons. However, I > have > > > > > > realized that this LA concept may be more important in the > context > > > of > > > > > H.323 > > > > > > (IP) and cellular-PSTN interworking. So, my feeling has been > that we > > > may > > > > > > need more functions similar to LA when interworking is concerned > > > > > (Motorola's > > > > > > contribution APC1646 is an example). The idea has been that we > > > should > > > > > > consider all those extensions in H.323 mobility architecture > when we > > > > > deal > > > > > > with interworking (second phase). > > > > > > > > > > > > Definitely, LA concept has some merits and we need to discuss > it. > > > > > > > > > > > > Best regards, > > > > > > Radhika R. Roy > > > > > > AT&T > > > > > > + 1 732 420 1580 > > > > > > rrroy@att.com > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: jaakko.sundquist@NOKIA.COM > [SMTP:jaakko.sundquist@NOKIA.COM] > > > > > > > Sent: Monday, November 01, 1999 7:23 AM > > > > > > > To: ITU-SG16@MAILBAG.INTEL.COM > > > > > > > Subject: Re: H323mobility:meeting > > > > > > > > > > > > > > Hi Ed, > > > > > > > > > > > > > > I haven't read your draft yet, but I just want to make a short > > > comment > > > > > on > > > > > > > the definitions that you proposed. > > > > > > > You mention the concepts of HomeZone ID and VisitedZone ID. > This > > > > > implies > > > > > > > already to a certain architecture, namely one where the "home > > > area" > > > > > and > > > > > > > "visited area" of a User are defined to be identified with the > > > > > accuracy of > > > > > > > one zone. In my contribution to the Red Bank meeting (APC > 1659) I > > > > > proposed > > > > > > > similar "home area" and "visited area" concepts based on > > > > > Administrative > > > > > > > Domains, which in my mind makes more sense as the Domains have > so > > > far > > > > > in > > > > > > > H.323 been the entities that are responsible for maintaining > any > > > > > > > information > > > > > > > of their users. > > > > > > > So I propose that we think about the architecture first before > > > > > defining > > > > > > > these terms. > > > > > > > > > > > > > > - Jaakko Sundquist > > > > > > > ------------------------------------------------------- > > > > > > > In a hole in the ground there lived a hobbit. > > > > > > > Not a nasty, dirty, wet hole, filled with the ends of > > > > > > > worms and an oozy smell, nor yet a dry, bare, > > > > > > > sandy hole with nothing in it to sit down on or to eat: > > > > > > > it was a hobbit-hole, and that means comfort. > > > > > > > ------------------------------------------------------- > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: EXT Edgar Martinez [1] > > > > > > > [mailto:martinze@cig.mot.com] > > > > > > > Sent: Monday, November 01, 1999 3:33 AM > > > > > > > To: ITU-SG16@mailbag.cps.intel.com > > > > > > > Subject: H323mobility:meeting > > > > > > > > > > > > > > Dear All, > > > > > > > > > > > > > > I have put together the first proposed draft > and > > > > > outline > > > > > > > for > > > > > > > H.323 Annex-H. You can pick-up a copy in: > > > > > > > http://people.itu.int/~emartine/temp/ > > > > > > > > > > > > > > Editor's Special Note: The interworking > referred > > > in > > > > > this > > > > > > > annex is > > > > > > > the interwork of legacy systems to H.323 > systems. > > > Not > > > > > to > > > > > > > be > > > > > > > confused > > > > > > > with interworking H.323 systems to circuit > > > switched > > > > > hybrid > > > > > > > systems > > > > > > > or circuit switched adjuncts. The work > proposed > > > > > therewith, > > > > > > > does not > > > > > > > impact > > > > > > > the legacy systems or impose new requirements > to > > > the > > > > > > > Legacy > > > > > > > systems > > > > > > > to support H.323 terminals or H.323 systems. > > > > > > > > > > > > > > Need to add more sections to the Annex-H to > > > comply > > > > > with > > > > > > > TOR > > > > > > > e.g., > > > > > > > Interworking: > > > > > > > > > > > > > > Network interworking > > > > > > > connections between H.323 systems and mobile > > > networks > > > > > > > (e.g., > > > > > > > GSM, ANSI > > > > > > > 41, ...) > > > > > > > connections between mobile H.323 systems and > PSTN > > > or > > > > > other > > > > > > > networks. > > > > > > > > > > > > > > Terminal interworking > > > > > > > Use of non-H.323 mobile terminals (e.g., GSM > > > handset, > > > > > > > H.324 > > > > > > > terminal, > > > > > > > H.320 terminal, etc.) to communicate with > H.323 > > > > > systems. > > > > > > > > > > > > > > Tandeming minimisation > > > > > > > Non-transcoding of media streams > > > > > > > > > > > > > > Also, it would be nice if we can add to the > > > > > > > the defiention section: > > > > > > > > > > > > > > Home Location Funtion (HFL) > > > > > > > Vistor Location Funtion (VFL) > > > > > > > Authentication user Funtion (AuF) > > > > > > > HomeZone ID (HZid) > > > > > > > VisitedZone ID (VZid) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Edgar Martinez - Principal Staff Engineer > > > > > > > Email mailto:martinze@cig.mot.com > > > > > > > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > > > > > > > 1501 West Shure Drive, Arlington Hgts. IL > 60004 > > > > > > > Public: TIPHON & Other Stds - > > > > > > > http://people.itu.int/~emartine/ > > > > > > > Private:TIPHON & Other Stds - > > > > > > > http://www.cig.mot.com/~martinze/ > > > > > > > > > > -- > > > > > Edgar Martinez - Principal Staff Engineer > > > > > Email mailto:martinze@cig.mot.com > > > > > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > > > > > 1501 West Shure Drive, Arlington Hgts. IL 60004 > > > > > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > > > > > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ > > > > > > -- > > > Edgar Martinez - Principal Staff Engineer > > > Email mailto:martinze@cig.mot.com > > > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > > > 1501 West Shure Drive, Arlington Hgts. IL 60004 > > > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > > > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ > > -- > Edgar Martinez - Principal Staff Engineer > Email mailto:martinze@cig.mot.com > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > 1501 West Shure Drive, Arlington Hgts. IL 60004 > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ >