- sg16-avd - lists.packetizer.com

Re: The meaning of the reception of a "new" capability set
by frank.derks＠PHILIPS.COM 02 Nov '99

02 Nov '99

Pete, I am having difficulty with what it is that you are trying to convey. Let me try to summarise: - An empty CS is transmitted "as a TCS message" containing only a sequence number and a protocol identifier. - The effect of receiving such a message does not effect the stored caps of the sending EP at the receiving EP - You (and the team you're working with) would have liked the effect to have been that all caps are removed. I do not think that I understand your statement on "Re-cap" providing 90% of the functionality in the case that you do not understand empty CSs, could you elaborate on that? Frank Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)MAILBAG.INTEL.COM> on 02/11/99 13:05:18 Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)MAILBAG.INTEL.COM> @ SMTP To: ITU-SG16 <ITU-SG16(a)MAILBAG.INTEL.COM> @ SMTP cc: Subject: Re: The meaning of the reception of a "new" capability set Classification: Restricted I think H.245 covers the delta aspects, although it goes on more about how to add caps and how to delete caps rather than explicitly saying that the caps are a delta. The definition of an empty cap set is defined in the revised text in the "Third party pause..." section. Basically its only seqNum and protocolIdentifier. I think the team I'm working with would have preferred to have an empty cap set as one that explicitly removed all the existing caps. Even if you don't know about empty cap sets, as long as you can re-cap, you get 90% of the functionality this way. That was the originally intended method when the text said something like "a cap set that indicates that there are no more receive caps". (It seemed obvious to me what it was!!!) However, it became clear that this wasn't clear to everybody and hence consensus from the list moved to the revised text which adopts the other definition. The 'initial' method is also much more complex to explain, which I felt could also lead to interoperability issues. (Even if you don't like the method chosen, you will probably prefer it to the other solution we came up with which was for an endpoint to accept both methods!!!) And another note, you only have to comply with RequestMode when under control of an MC. Without an MC it's optional. We assumed that that would be a big enough excuse for implementors not to implement anything to do with RequestMode! Pete ============================================= Pete Cordell pete(a)tech-know-ware.com ============================================= -----Original Message----- From: frank.derks(a)PHILIPS.COM <frank.derks(a)PHILIPS.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: 02 November 1999 09:16 Subject: Re: The meaning of the reception of a "new" capability set >Hi Paul, > >thanks for the reply. Is there any work going on to more clearly describe that "delta" is the desired behaviour? The next question that this brings is: "what is an "empty CS", because I can see several ways of achieving this. Again I do not see a clear >specification on what an empty CS looks like. > >I fully agree with your statement about the third-party initiated pause and re-routing, but at the moment it is the only "lightweight" method of achieving certain behaviours that would otherwise require H.450. > >Frank > > > > > >Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)MAILBAG.INTEL.COM> on 01/11/99 17:29:54 >Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)MAILBAG.INTEL.COM> @ SMTP >To: ITU-SG16 <ITU-SG16(a)MAILBAG.INTEL.COM> @ SMTP >cc: >Subject: Re: The meaning of the reception of a "new" capability set >Classification: Restricted >Ilya, > >No, no, no!!! :-) Each TCS message is a _delta_ to be applied to the remote >EP's current capability set stored in the EP. This issue was discussed a few >months ago on the reflector. My reply follows my signature. > >BTW, the pause feature added to H.323v2 redefines the meaning of an empty >TCS. In H.323v1, an empty TCS causes no change to the current cap set--a >NO-OP, so to speak. As of v2, however, an empty TCS means close all outgoing >channels, assume that the remote EP has no receive or transmit caps (flush >the current capapbility set for the remote EP), and upon receipt of the next >presumably non-empty TCS, re-open outgoing channels based on the possibly >new set of receive caps. From what I've heard, though, many if not all v2 >EPs still exhibit v1 behavior in this regard. I doubt whether "pause" will >ever be a dependable feature. IMO, overloading a message like this is just >asking for trouble. The same thing could have been better accomplished with >RequestMode. > >Paul Long >Smith Micro Software, Inc. > > >>>>>>>>>> My reply from July 1, 1999 >Ramana, Chris, et al.: > >An incoming terminalCapabilitySet message _modifies_ the current capability >set in the receiving EP. The entire set is not necessarily transmitted >within every message. This has been true since H.245v1. In fact, H.245 says >that one should not transmit unchanged capabilities. One starts out with an >empty set of descriptors. Incoming descriptors replace any extant ones with >the same descriptor number. If one does not already exist with the same >number, this adds a new descriptor; if one does exist, the new one replaces >the old one; if the new descriptor does not contain >simultaneousCapabilities, this removes any existing descriptor for the given >number. (This is the same scheme used to modify the capability table.) Here >is an illustrative chronological scenario: > > Current capability set: > <empty> > >Incoming termCapSet 1 >0: {{H.261qcif},{G.711}} >1: {{H.261cif},{G.711}} > > Current capability set: > 0: {{H.261qcif},{G.711}} > 1: {{H.261cif},{G.711}} > >Incoming termCapSet 2 >1: {} > > Current capability set: > 0: {{H.261qcif},{G.711}} > >Incoming termCapSet 3 >1: {{H.261cif},{G.711}} >2: {{H.263sqcif&qcif&cif},{G.723,G.711}} > > Current capability set: > 0: {{H.261qcif},{G.711}} > 1: {{H.261cif},{G.711}} > 2: {{H.263sqcif&qcif&cif},{G.723,G.711}} > >Incoming termCapSet 4 >1: {} >0: {{H.261qcif&cif},{G.723.1,G.711)} > > Current capability set: > 0: {{H.261qcif&cif},{G.723.1,G.711)} > 2: {{H.263sqcif&qcif&cif},{G.723,G.711}} > >Paul Long >Smith Micro Software, Inc. ><<<<<<<<< > >-----Original Message----- >From: Ilya Freytsis [mailto:IFREYTSIS@VIDEOSERVER.COM] >Sent: Monday, November 01, 1999 8:57 AM >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: The meaning of the reception of a "new" capability set > > >I believe every new capability set should be treated as a complete >replacement for the previously received one. Otherwise conferencing >servers >(MCS) and Gateways will not be able exercise enough control over the >media >modes of the multipoint conferences and gateway sessions. > >Ilya Freytsis > > > -----Original Message----- > From: frank.derks(a)PHILIPS.COM >[mailto:frank.derks@PHILIPS.COM] > Sent: Monday, November 01, 1999 8:31 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: The meaning of the reception of a "new" >capability set > > Neither H.323 nor H.245 are too clear about what it >means >when an endpoint receives another set of capabilities after having >already >received one. In previous E-mail messages on this list, I have read that >capability sets are cumulative, i.e. anything > "new" received in a TCS message adds to the capabilities >transmitted in a previous TCS message. I have, however, found nothing in >the >recommendations that backs this up. > > So what is the intended procedure? Does a newly received >set >of capabilities replace the previously received set? Do capabilities >received in a TCS message add to the already received capabilities? How >are >capabilities removed? What constitutes an "empty > capability set" etc. > > I would appreciate it if somebody could point me in the >right direction. > > Regards, > > Frank >

1 0

Re: H323 Robustness
by Boaz Michaely 02 Nov '99

02 Nov '99

Network layer support for robustness is great where available, and hopefully it works transparently, as Qiaobing states. Agreed, we may want to assure that the interfaces to lower layer robustness mechanisms are well defined, however our focus here is enhancing the application level, which grants a network independent solution. Boaz http://people.itu.int/~michaely Qiaobing Xie <xieqb(a)CIG.MOT.COM> on 02/11/99 01:11:38 AM Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> To: ITU-SG16(a)mailbag.cps.intel.com cc: (bcc: Boaz Michaely) Subject: Re: H323 Robustness Actually, the SCTP transport protocol defined by Sigtran is specifically designed to address the path level robustness. It is designed to support multiple NIC cards (a.k.a. multi-homed nodes) and provide transparent interface and path failure detection and recovery. -Qiaobing On Nov 1, 1:22pm, Edgar Martinez [1] wrote: > Subject: Re: H323 Robustness > Dear All, > > I would think that Sigtran could be used to provide > the GK "switch over" to a hot standby GK > from the IP layer point of view. > > Ed > > "Roy, Radhika R, ALARC" wrote: > > > Hi, Gaurav and All: > > > > Further my earlier email, I am enclosing D.225. > > > > In the last Red Bank meeting report (APC-1748 Version 2, October 29, 1999), > > it has been noted that D.225 from Chile is relevant in addition to other > > documents. > > > > D.225 primarily focuses on reliable GK architectures because H.323 considers > > that it is the most important entity whose robustness needs to be considered > > first. The existing H.323 signaling scheme already provides a mechanism for > > one or more alternative GKs to increase reliability. Of course, the > > reliability of other H.323 entities should also be considered. > > > > The alternate gatekeeper that has been used in H.323 should be the starting > > point for building the H.323 robustness model. > > > > What do we mean robustness? D.225 provides a definition considering > > reliability, availability, serviceability, recoverability, scalability, > > context, and security. > > > > What do we mean by failures? Failures have to be considered in the context > > of H.323. Failure detection and handling should include all scenarios (e.g., > > connection-oriented transport protocol [TCP], connectionless oriented > > transport protocol [UDP], etc.) for signaling. Failures of media streams and > > their recovery should also be addressed. > > > > The system scope can be as follows: 1. intra-zone, 2. inter-zone > > (intra-domain), and 3. inter-domain. As shown in D.225, for case 1, an > > alternate GK can be located in the same zone; for case 2, an alternate GK > > can be located in the same zone of the primary GK or in a different zone > > other than the zone of the primary GK; similarly, case 3 may also have > > different options like case 2. The situation can be more complicated if > > there is more than one alternate GK as envisioned in H.323. > > > > We will start with a simple scenario. > > > > We may well discover that we need a sort of inter-GK protocol. Can we look > > into something that exists today similar to this problem? > > > > I find that routers are doing something very similar to this for the last > > two decades. Failure detection and handling, database synchronization and > > re-synchronization, and many more. Can we use many those for our inter-GK > > protocol to take care-of H.323 robustness? > > > > However, there are dissimilarities as well. GK is an application layer > > entity. If we can devise an intelligent scheme not to maintain all the > > databases (e.g., databases consisting with H.323 call states) of all GKs > > synchronized other than the respective primary and the alternate GK, we may > > simplify some of the problems. Moreover, GK needs not to be involved with > > the network level link states. Assuming that the GK will be able to abstract > > the GK-level connectivity with the help of the network layer entities like > > routers, we can simplify our problems further. > > > > This is the initial input for our upcoming discussion. > > > > As we go forward, we will learn more how to address the complex problem. > > > > Best regards, > > Radhika R. Roy > > AT&T > > +1 732 420 1580 > > rrroy(a)att.com > > > > <<D-225.doc>> > > > -----Original Message----- > > > From: gmakkar(a)hss.hns.com [SMTP:gmakkar@hss.hns.com] > > > Sent: Monday, November 01, 1999 9:42 AM > > > To: Roy, Radhika R, ALARC > > > Subject: Re: H323mobility:meeting > > > > > > > > > > > > > > > Radhika, > > > Could you share the D.225 doc being referred to in this mail. TD-28 > > > refers to this too. > > > > > > Thanks and Regards, > > > Gaurav Makkar > > > > > > > ------------------------------------------------------------------------ > > Name: D-225.doc > > D-225.doc Type: Winword File (application/msword) > > Encoding: base64 > > -- > Edgar Martinez - Principal Staff Engineer > Email mailto:martinze@cig.mot.com > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > 1501 West Shure Drive, Arlington Hgts. IL 60004 > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ >-- End of excerpt from Edgar Martinez [1]

1 0

RAS terminal and gateway discovery/registration messages
by Mohamed Mustafa 02 Nov '99

02 Nov '99

Hi All, H.225.0 states that "one GRQ is sent per logical endpoint; thus an MCU or a Gateway might send many". Do I take it therefore, that a H.323-to-ISDN gateway with a maximum capacity of n lines must send n GRQ and RRQ messages; i.e., one for each line? If this is the case, can anyone shed any light on the reasoning behind it? Also, can anyone explain the relevance of the endpointAlias field in the GRQ message and the terminalAlias fields in the RRQ and RCF messages to a H.323 gateway application? After all, a gateway is supposed to be transparent to normal endpoints and does not need to be directly addressed by them. Thanks, Mohamed

1 0

Re: The meaning of the reception of a "new" capability set
by frank.derks＠PHILIPS.COM 02 Nov '99

02 Nov '99

Hi Paul, thanks for the reply. Is there any work going on to more clearly describe that "delta" is the desired behaviour? The next question that this brings is: "what is an "empty CS", because I can see several ways of achieving this. Again I do not see a clear specification on what an empty CS looks like. I fully agree with your statement about the third-party initiated pause and re-routing, but at the moment it is the only "lightweight" method of achieving certain behaviours that would otherwise require H.450. Frank Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)MAILBAG.INTEL.COM> on 01/11/99 17:29:54 Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)MAILBAG.INTEL.COM> @ SMTP To: ITU-SG16 <ITU-SG16(a)MAILBAG.INTEL.COM> @ SMTP cc: Subject: Re: The meaning of the reception of a "new" capability set Classification: Restricted Ilya, No, no, no!!! :-) Each TCS message is a _delta_ to be applied to the remote EP's current capability set stored in the EP. This issue was discussed a few months ago on the reflector. My reply follows my signature. BTW, the pause feature added to H.323v2 redefines the meaning of an empty TCS. In H.323v1, an empty TCS causes no change to the current cap set--a NO-OP, so to speak. As of v2, however, an empty TCS means close all outgoing channels, assume that the remote EP has no receive or transmit caps (flush the current capapbility set for the remote EP), and upon receipt of the next presumably non-empty TCS, re-open outgoing channels based on the possibly new set of receive caps. From what I've heard, though, many if not all v2 EPs still exhibit v1 behavior in this regard. I doubt whether "pause" will ever be a dependable feature. IMO, overloading a message like this is just asking for trouble. The same thing could have been better accomplished with RequestMode. Paul Long Smith Micro Software, Inc. >>>>>>>>> My reply from July 1, 1999 Ramana, Chris, et al.: An incoming terminalCapabilitySet message _modifies_ the current capability set in the receiving EP. The entire set is not necessarily transmitted within every message. This has been true since H.245v1. In fact, H.245 says that one should not transmit unchanged capabilities. One starts out with an empty set of descriptors. Incoming descriptors replace any extant ones with the same descriptor number. If one does not already exist with the same number, this adds a new descriptor; if one does exist, the new one replaces the old one; if the new descriptor does not contain simultaneousCapabilities, this removes any existing descriptor for the given number. (This is the same scheme used to modify the capability table.) Here is an illustrative chronological scenario: Current capability set: <empty> Incoming termCapSet 1 0: {{H.261qcif},{G.711}} 1: {{H.261cif},{G.711}} Current capability set: 0: {{H.261qcif},{G.711}} 1: {{H.261cif},{G.711}} Incoming termCapSet 2 1: {} Current capability set: 0: {{H.261qcif},{G.711}} Incoming termCapSet 3 1: {{H.261cif},{G.711}} 2: {{H.263sqcif&qcif&cif},{G.723,G.711}} Current capability set: 0: {{H.261qcif},{G.711}} 1: {{H.261cif},{G.711}} 2: {{H.263sqcif&qcif&cif},{G.723,G.711}} Incoming termCapSet 4 1: {} 0: {{H.261qcif&cif},{G.723.1,G.711)} Current capability set: 0: {{H.261qcif&cif},{G.723.1,G.711)} 2: {{H.263sqcif&qcif&cif},{G.723,G.711}} Paul Long Smith Micro Software, Inc. <<<<<<<<< -----Original Message----- From: Ilya Freytsis [mailto:IFREYTSIS@VIDEOSERVER.COM] Sent: Monday, November 01, 1999 8:57 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: The meaning of the reception of a "new" capability set I believe every new capability set should be treated as a complete replacement for the previously received one. Otherwise conferencing servers (MCS) and Gateways will not be able exercise enough control over the media modes of the multipoint conferences and gateway sessions. Ilya Freytsis -----Original Message----- From: frank.derks(a)PHILIPS.COM [mailto:frank.derks@PHILIPS.COM] Sent: Monday, November 01, 1999 8:31 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: The meaning of the reception of a "new" capability set Neither H.323 nor H.245 are too clear about what it means when an endpoint receives another set of capabilities after having already received one. In previous E-mail messages on this list, I have read that capability sets are cumulative, i.e. anything "new" received in a TCS message adds to the capabilities transmitted in a previous TCS message. I have, however, found nothing in the recommendations that backs this up. So what is the intended procedure? Does a newly received set of capabilities replace the previously received set? Do capabilities received in a TCS message add to the already received capabilities? How are capabilities removed? What constitutes an "empty capability set" etc. I would appreciate it if somebody could point me in the right direction. Regards, Frank

1 0

Re: H323mobility:meeting
by jaakko.sundquist＠NOKIA.COM 02 Nov '99

02 Nov '99

Hi again Ed, Radhika et al As you had quite a bit of conversation during my out-of-office hours, I'll try to include all my comments on the discussion in this one mail. First of all, I do not understand Ed's comment about the HomeZone ID & VisitedZone ID not clashing with the meaning of zone. Surely these are meant to be some identifiers for certain zones. I did not, btw. propose the concepts Home Area and Visited Area, these terms are in my opinion not good terms and I just tried to illustrate my point with using them in the earlier mail. Thus I propose that we do not use them. What I was trying to say in the earlier mail is this: we have not agreed where the HLF and VLF (or AuF for that matter) should be placed in the architecture. The concept of HomeZone implies that each User has one zone which is his/her/its home, thus also implying that the HLF must be associated with the GK of that zone and no other GK (of course other GKs could have their own HLFs). Similarly each GK would have their own VLFs. When I introduced the concepts of Home Domain and Visited Domain, I was thinking about the HLF and VLF being functionalities that are used by all the GKs in the Domain, thus I would rather associate them with e.g. the BE than the GK. The point is that we have not defined or even really discussed the architecture yet, so let's not define terms that already point to a certain direction in the architectural decision. As for the Location Area (LA) concept, my contribution (APC-1659) did not actually present it as a subset of a zone. I tried to define it in such a way that I would not restrict the possible Network Points of Attachment that can belong to a LA. The result in the end was, I agree, quite complicated, allowing the LA to be either a subset, a superset (one LA includes NPoAs in many zones) or equal to a zone (LA = zone). I think we have to discuss further how the LA should be defined (complexity vs. scalability), but I do think that the concept is a valuable one and should be adopted. I also think that the two-step approach of first defining the functionalities for "pure" H.323 Mobility and only after that the functions needed for PLMN interworking may not be the best approach. I think that we need to consider the interworking case also when defining the pure H.323 case. This way we can take both cases into account, thus reducing unnecessary work in the second phase, i.e. the interworking phase. I'm not saying that we should define the interworking as a whole simultaneously with the pure H.323 mobility, but I would like to always consider the effects of our decisions to the interworking issue, when we are defining the pure H.323 case. Lastly, I read Ed's draft for Annex H and I just have one small comment. In the scope it says something about the fact that the NPoA can change. I think we agreed that it should have stated that the NPoA can change also during a call, thus allowing handovers. I would like to see this in there just to avoid having the same discussions again. I'm sorry that I didn't catch this one already in Red Bank. - Jaakko Sundquist ------------------------------------------------------- In a hole in the ground there lived a hobbit. Not a nasty, dirty, wet hole, filled with the ends of worms and an oozy smell, nor yet a dry, bare, sandy hole with nothing in it to sit down on or to eat: it was a hobbit-hole, and that means comfort. -------------------------------------------------------

1 0

Re: H323mobility:meeting
by Edgar Martinez [1] 02 Nov '99

02 Nov '99

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, INFOCOM99, 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(a)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(a)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(a)att.com > > > > > > > > > > > -----Original Message----- > > > > > > From: jaakko.sundquist(a)NOKIA.COM [SMTP:jaakko.sundquist@NOKIA.COM] > > > > > > Sent: Monday, November 01, 1999 7:23 AM > > > > > > To: ITU-SG16(a)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(a)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/

1 0

Re: H323 Robustness
by Qiaobing Xie 01 Nov '99

01 Nov '99

Actually, the SCTP transport protocol defined by Sigtran is specifically designed to address the path level robustness. It is designed to support multiple NIC cards (a.k.a. multi-homed nodes) and provide transparent interface and path failure detection and recovery. -Qiaobing On Nov 1, 1:22pm, Edgar Martinez [1] wrote: > Subject: Re: H323 Robustness > Dear All, > > I would think that Sigtran could be used to provide > the GK "switch over" to a hot standby GK > from the IP layer point of view. > > Ed > > "Roy, Radhika R, ALARC" wrote: > > > Hi, Gaurav and All: > > > > Further my earlier email, I am enclosing D.225. > > > > In the last Red Bank meeting report (APC-1748 Version 2, October 29, 1999), > > it has been noted that D.225 from Chile is relevant in addition to other > > documents. > > > > D.225 primarily focuses on reliable GK architectures because H.323 considers > > that it is the most important entity whose robustness needs to be considered > > first. The existing H.323 signaling scheme already provides a mechanism for > > one or more alternative GKs to increase reliability. Of course, the > > reliability of other H.323 entities should also be considered. > > > > The alternate gatekeeper that has been used in H.323 should be the starting > > point for building the H.323 robustness model. > > > > What do we mean robustness? D.225 provides a definition considering > > reliability, availability, serviceability, recoverability, scalability, > > context, and security. > > > > What do we mean by failures? Failures have to be considered in the context > > of H.323. Failure detection and handling should include all scenarios (e.g., > > connection-oriented transport protocol [TCP], connectionless oriented > > transport protocol [UDP], etc.) for signaling. Failures of media streams and > > their recovery should also be addressed. > > > > The system scope can be as follows: 1. intra-zone, 2. inter-zone > > (intra-domain), and 3. inter-domain. As shown in D.225, for case 1, an > > alternate GK can be located in the same zone; for case 2, an alternate GK > > can be located in the same zone of the primary GK or in a different zone > > other than the zone of the primary GK; similarly, case 3 may also have > > different options like case 2. The situation can be more complicated if > > there is more than one alternate GK as envisioned in H.323. > > > > We will start with a simple scenario. > > > > We may well discover that we need a sort of inter-GK protocol. Can we look > > into something that exists today similar to this problem? > > > > I find that routers are doing something very similar to this for the last > > two decades. Failure detection and handling, database synchronization and > > re-synchronization, and many more. Can we use many those for our inter-GK > > protocol to take care-of H.323 robustness? > > > > However, there are dissimilarities as well. GK is an application layer > > entity. If we can devise an intelligent scheme not to maintain all the > > databases (e.g., databases consisting with H.323 call states) of all GKs > > synchronized other than the respective primary and the alternate GK, we may > > simplify some of the problems. Moreover, GK needs not to be involved with > > the network level link states. Assuming that the GK will be able to abstract > > the GK-level connectivity with the help of the network layer entities like > > routers, we can simplify our problems further. > > > > This is the initial input for our upcoming discussion. > > > > As we go forward, we will learn more how to address the complex problem. > > > > Best regards, > > Radhika R. Roy > > AT&T > > +1 732 420 1580 > > rrroy(a)att.com > > > > <<D-225.doc>> > > > -----Original Message----- > > > From: gmakkar(a)hss.hns.com [SMTP:gmakkar@hss.hns.com] > > > Sent: Monday, November 01, 1999 9:42 AM > > > To: Roy, Radhika R, ALARC > > > Subject: Re: H323mobility:meeting > > > > > > > > > > > > > > > Radhika, > > > Could you share the D.225 doc being referred to in this mail. TD-28 > > > refers to this too. > > > > > > Thanks and Regards, > > > Gaurav Makkar > > > > > > > ------------------------------------------------------------------------ > > Name: D-225.doc > > D-225.doc Type: Winword File (application/msword) > > Encoding: base64 > > -- > Edgar Martinez - Principal Staff Engineer > Email mailto:martinze@cig.mot.com > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > 1501 West Shure Drive, Arlington Hgts. IL 60004 > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ >-- End of excerpt from Edgar Martinez [1]

1 0

Re: H323mobility:meeting
by Roy, Radhika R, ALARC 01 Nov '99

01 Nov '99

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. 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(a)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(a)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(a)att.com > > > > > > > > > -----Original Message----- > > > > > From: jaakko.sundquist(a)NOKIA.COM [SMTP:jaakko.sundquist@NOKIA.COM] > > > > > Sent: Monday, November 01, 1999 7:23 AM > > > > > To: ITU-SG16(a)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(a)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/

1 0

Re: [Robustness] group formed
by Joerg Ott 01 Nov '99

01 Nov '99

At 12:44 01.11.99 -0800, Callaghan, Robert wrote: >I propose Tuesday, November 16 as the first conference call to be held from >11-12 EST. >Please send e-mail to me at: maureen.stillman(a)nokia.com if you wish to >participate or if the time is not good, but you wish to participate. > >[RWC] I would prefer to have the week before or after the proposed date. > If we need to change the date then please avoid any overlap with the IETF which is held in Washington DC 7 - 12 November. Thanks, Joerg

1 0

Re: [Robustness] group formed
by Callaghan, Robert 01 Nov '99

01 Nov '99

I propose Tuesday, November 16 as the first conference call to be held from 11-12 EST. Please send e-mail to me at: maureen.stillman(a)nokia.com if you wish to participate or if the time is not good, but you wish to participate. [RWC] I would prefer to have the week before or after the proposed date. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Information and Communication Networks Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------

1 0

Re: [Robustness] group formed
by Callaghan, Robert 01 Nov '99

01 Nov '99

Maureen, I am sorry that I did not get this information to you sooner. I just returned to the office from a second trip. TD-28 was accepted as the term of reference for the work. However Dale tried to say that the work should be completed by February in Geneva. I accepted this as a goal for the easy part; but some work may take longer. Dale then noted that this work should be added to the question for the next work period. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Information and Communication Networks Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Maureen.Stillman(a)NOKIA.COM [mailto:Maureen.Stillman@NOKIA.COM] Sent: Wednesday, October 27, 1999 6:07 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: [Robustness] group formed A new group has formed to study the area of providing robustness mechanisms for H.323. This group has agreed to work on items together. Attached is TD-28 written in Red Bank which outlines terms of reference for work to be undertaken towards providing robustness mechanisms in H.323 and identifies a number of potential future work areas. The group decided to initially work on defining a set of terms for robustness via the mailing list. Please send contributions of relevant terms (and optionally their definitions). Please put [Robustness] in the subject line for those who want to filter e-mail. The group will schedule occasional conference calls open to any interested parties. Nokia will host the first conference call. Conference Call Agenda: A. terms submitted on the mailing list B. next steps for the group I propose Tuesday, November 16 as the first conference call to be held from 11-12 EST. Please send e-mail to me at: maureen.stillman(a)nokia.com if you wish to participate or if the time is not good, but you wish to participate. The TD-28 document is attached and the Web site is: ftp://standard.pictel.com/avc-site/9910_Red/TD-28.zip <<TD-28 robust.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: H323mobility:meeting
by Edgar Martinez [1] 01 Nov '99

01 Nov '99

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(a)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(a)att.com > > > > > > > -----Original Message----- > > > > From: jaakko.sundquist(a)NOKIA.COM [SMTP:jaakko.sundquist@NOKIA.COM] > > > > Sent: Monday, November 01, 1999 7:23 AM > > > > To: ITU-SG16(a)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(a)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/

1 0

Re: H323mobility:meeting
by Roy, Radhika R, ALARC 01 Nov '99

01 Nov '99

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(a)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(a)att.com > > > > > -----Original Message----- > > > From: jaakko.sundquist(a)NOKIA.COM [SMTP:jaakko.sundquist@NOKIA.COM] > > > Sent: Monday, November 01, 1999 7:23 AM > > > To: ITU-SG16(a)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(a)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/

1 0

Re: H323 Robustness
by Edgar Martinez [1] 01 Nov '99

01 Nov '99

Dear All, I would think that Sigtran could be used to provide the GK "switch over" to a hot standby GK from the IP layer point of view. Ed "Roy, Radhika R, ALARC" wrote: > Hi, Gaurav and All: > > Further my earlier email, I am enclosing D.225. > > In the last Red Bank meeting report (APC-1748 Version 2, October 29, 1999), > it has been noted that D.225 from Chile is relevant in addition to other > documents. > > D.225 primarily focuses on reliable GK architectures because H.323 considers > that it is the most important entity whose robustness needs to be considered > first. The existing H.323 signaling scheme already provides a mechanism for > one or more alternative GKs to increase reliability. Of course, the > reliability of other H.323 entities should also be considered. > > The alternate gatekeeper that has been used in H.323 should be the starting > point for building the H.323 robustness model. > > What do we mean robustness? D.225 provides a definition considering > reliability, availability, serviceability, recoverability, scalability, > context, and security. > > What do we mean by failures? Failures have to be considered in the context > of H.323. Failure detection and handling should include all scenarios (e.g., > connection-oriented transport protocol [TCP], connectionless oriented > transport protocol [UDP], etc.) for signaling. Failures of media streams and > their recovery should also be addressed. > > The system scope can be as follows: 1. intra-zone, 2. inter-zone > (intra-domain), and 3. inter-domain. As shown in D.225, for case 1, an > alternate GK can be located in the same zone; for case 2, an alternate GK > can be located in the same zone of the primary GK or in a different zone > other than the zone of the primary GK; similarly, case 3 may also have > different options like case 2. The situation can be more complicated if > there is more than one alternate GK as envisioned in H.323. > > We will start with a simple scenario. > > We may well discover that we need a sort of inter-GK protocol. Can we look > into something that exists today similar to this problem? > > I find that routers are doing something very similar to this for the last > two decades. Failure detection and handling, database synchronization and > re-synchronization, and many more. Can we use many those for our inter-GK > protocol to take care-of H.323 robustness? > > However, there are dissimilarities as well. GK is an application layer > entity. If we can devise an intelligent scheme not to maintain all the > databases (e.g., databases consisting with H.323 call states) of all GKs > synchronized other than the respective primary and the alternate GK, we may > simplify some of the problems. Moreover, GK needs not to be involved with > the network level link states. Assuming that the GK will be able to abstract > the GK-level connectivity with the help of the network layer entities like > routers, we can simplify our problems further. > > This is the initial input for our upcoming discussion. > > As we go forward, we will learn more how to address the complex problem. > > Best regards, > Radhika R. Roy > AT&T > +1 732 420 1580 > rrroy(a)att.com > > <<D-225.doc>> > > -----Original Message----- > > From: gmakkar(a)hss.hns.com [SMTP:gmakkar@hss.hns.com] > > Sent: Monday, November 01, 1999 9:42 AM > > To: Roy, Radhika R, ALARC > > Subject: Re: H323mobility:meeting > > > > > > > > > > Radhika, > > Could you share the D.225 doc being referred to in this mail. TD-28 > > refers to this too. > > > > Thanks and Regards, > > Gaurav Makkar > > > > ------------------------------------------------------------------------ > Name: D-225.doc > D-225.doc Type: Winword File (application/msword) > Encoding: base64 -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

H.323mobility:Interim Work
by Edgar Martinez [1] 01 Nov '99

01 Nov '99

Dear SG16 and TIPHON Mobility Advocates, I will like to include in the agenda some discussions in adding level-1 headings for the interworking sections, to annex-h and what functions are needed besides the UIM, based on the TOR. --- Interim Work:(ref. td65) "The H.323 Mobility Ad Hoc Working Group agreed on having a conference call on November 17, 1999 from 8:00 am to 10:00 am (Pacific Standard Time (PST)). Intel agreed to host the Conference Bridge for this H.323 Mobility Ad Hoc work on H.323 Mobility. Details of the call will be posted on the H.323 reflector shortly and all interested parties are invited. All companies participating in the conference call are requested to submit their input a week in advance on the H.323 reflector to ensure that call is productive. For the first call focus topics are Chapter 4 and Chapter 5 of the outline above and the completion of the outline." 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: H323mobility:meeting
by Edgar Martinez [1] 01 Nov '99

01 Nov '99

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(a)att.com > > > -----Original Message----- > > From: jaakko.sundquist(a)NOKIA.COM [SMTP:jaakko.sundquist@NOKIA.COM] > > Sent: Monday, November 01, 1999 7:23 AM > > To: ITU-SG16(a)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(a)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/

1 0

Re: H323 Robustness
by Roy, Radhika R, ALARC 01 Nov '99

01 Nov '99

Hi, Gaurav and All: Further my earlier email, I am enclosing D.225. In the last Red Bank meeting report (APC-1748 Version 2, October 29, 1999), it has been noted that D.225 from Chile is relevant in addition to other documents. D.225 primarily focuses on reliable GK architectures because H.323 considers that it is the most important entity whose robustness needs to be considered first. The existing H.323 signaling scheme already provides a mechanism for one or more alternative GKs to increase reliability. Of course, the reliability of other H.323 entities should also be considered. The alternate gatekeeper that has been used in H.323 should be the starting point for building the H.323 robustness model. What do we mean robustness? D.225 provides a definition considering reliability, availability, serviceability, recoverability, scalability, context, and security. What do we mean by failures? Failures have to be considered in the context of H.323. Failure detection and handling should include all scenarios (e.g., connection-oriented transport protocol [TCP], connectionless oriented transport protocol [UDP], etc.) for signaling. Failures of media streams and their recovery should also be addressed. The system scope can be as follows: 1. intra-zone, 2. inter-zone (intra-domain), and 3. inter-domain. As shown in D.225, for case 1, an alternate GK can be located in the same zone; for case 2, an alternate GK can be located in the same zone of the primary GK or in a different zone other than the zone of the primary GK; similarly, case 3 may also have different options like case 2. The situation can be more complicated if there is more than one alternate GK as envisioned in H.323. We will start with a simple scenario. We may well discover that we need a sort of inter-GK protocol. Can we look into something that exists today similar to this problem? I find that routers are doing something very similar to this for the last two decades. Failure detection and handling, database synchronization and re-synchronization, and many more. Can we use many those for our inter-GK protocol to take care-of H.323 robustness? However, there are dissimilarities as well. GK is an application layer entity. If we can devise an intelligent scheme not to maintain all the databases (e.g., databases consisting with H.323 call states) of all GKs synchronized other than the respective primary and the alternate GK, we may simplify some of the problems. Moreover, GK needs not to be involved with the network level link states. Assuming that the GK will be able to abstract the GK-level connectivity with the help of the network layer entities like routers, we can simplify our problems further. This is the initial input for our upcoming discussion. As we go forward, we will learn more how to address the complex problem. Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com <<D-225.doc>> > -----Original Message----- > From: gmakkar(a)hss.hns.com [SMTP:gmakkar@hss.hns.com] > Sent: Monday, November 01, 1999 9:42 AM > To: Roy, Radhika R, ALARC > Subject: Re: H323mobility:meeting > > > > > Radhika, > Could you share the D.225 doc being referred to in this mail. TD-28 > refers to this too. > > Thanks and Regards, > Gaurav Makkar >

1 0

LRJ reason, notRegistered
by Paul Long 01 Nov '99

01 Nov '99

Dale, Unless there is some objection, could you add the comment, "-- requesting entity not registered," to the notRegistered reject reason for LocationReject in H.225.0? There was some question as to which entity this referred. Paul Long Smith Micro Software, Inc.

1 0

Re: The meaning of the reception of a "new" capability set
by Ilya Freytsis 01 Nov '99

01 Nov '99

I believe every new capability set should be treated as a complete replacement for the previously received one. Otherwise conferencing servers (MCS) and Gateways will not be able exercise enough control over the media modes of the multipoint conferences and gateway sessions. Ilya Freytsis -----Original Message----- From: frank.derks(a)PHILIPS.COM [mailto:frank.derks@PHILIPS.COM] Sent: Monday, November 01, 1999 8:31 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: The meaning of the reception of a "new" capability set Neither H.323 nor H.245 are too clear about what it means when an endpoint receives another set of capabilities after having already received one. In previous E-mail messages on this list, I have read that capability sets are cumulative, i.e. anything "new" received in a TCS message adds to the capabilities transmitted in a previous TCS message. I have, however, found nothing in the recommendations that backs this up. So what is the intended procedure? Does a newly received set of capabilities replace the previously received set? Do capabilities received in a TCS message add to the already received capabilities? How are capabilities removed? What constitutes an "empty capability set" etc. I would appreciate it if somebody could point me in the right direction. Regards, Frank

2 1

Re: H323mobility:meeting
by Roy, Radhika R, ALARC 01 Nov '99

01 Nov '99

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(a)att.com > -----Original Message----- > From: jaakko.sundquist(a)NOKIA.COM [SMTP:jaakko.sundquist@NOKIA.COM] > Sent: Monday, November 01, 1999 7:23 AM > To: ITU-SG16(a)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(a)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/

1 0

The meaning of the reception of a "new" capability set
by frank.derks＠PHILIPS.COM 01 Nov '99

01 Nov '99

Neither H.323 nor H.245 are too clear about what it means when an endpoint receives another set of capabilities after having already received one. In previous E-mail messages on this list, I have read that capability sets are cumulative, i.e. anything "new" received in a TCS message adds to the capabilities transmitted in a previous TCS message. I have, however, found nothing in the recommendations that backs this up. So what is the intended procedure? Does a newly received set of capabilities replace the previously received set? Do capabilities received in a TCS message add to the already received capabilities? How are capabilities removed? What constitutes an "empty capability set" etc. I would appreciate it if somebody could point me in the right direction. Regards, Frank

1 0

Re: H323mobility:meeting
by jaakko.sundquist＠NOKIA.COM 01 Nov '99

01 Nov '99

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(a)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/

1 0

Revised(Fwd: H323mobility:meeting)
by Edgar Martinez [1] 01 Nov '99

01 Nov '99

Oh well... -------- Original Message -------- Subject: H323mobility:meeting Date: Sun, 31 Oct 1999 20:33:25 -0500 From: "Edgar Martinez [1]" <martinze(a)cig.mot.com> Organization: NSS-NAT To: Entirely SG16 <ITU-SG16(a)mailbag.cps.intel.com> CC: "TIPHON_WG7(a)LIST.ETSI.FR" <TIPHON_WG7(a)LIST.ETSI.FR> 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 Function (HFL) Visitor Location Function (VFL) Authentication user Function (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/

1 0

H323mobility:meeting
by Edgar Martinez [1] 01 Nov '99

01 Nov '99

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/

1 0

White contributions for decision in Feb. 2000
by Sakae OKUBO 31 Oct '99

31 Oct '99

Dear Q12-14/16 experts, JS> The H.248 white draft has been uploaded to the PictureTel ftp archive JS> (ftp://standard.pictel.com/avc-site/Incoming/h248-whitedraft.zip) CG> The H246annexC whitepaper is now stored on the pictel website. CG> The file is whitepaper_H246annexC_clean.zip GH> In the Incoming directory of standard.pictel.com/avc-site , GH> I have uploaded a white document for decision GH> in the meeting in Geneva of SG16 in february. GH> It is H.323 Annex G, Text Conversation and Text SET. All of these files have been moved to /0002_Gen directory. Please see the following index: http://standard.pictel.com/ftp/avc-site/0002_Gen/0002_Gen.html Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0