- sg16-avd - lists.packetizer.com

ITU Red Bank Minutes - COMMENTS
by <Morgan Potter> 03 Nov '99

03 Nov '99

With reference to the minutes detailed in APC 1748: In view of the contributions on extensibility (APC -1683A, TD43, APC-1694, and APC-1737) put forward at the Red Bank meeting, we intend to continue the dialogue with Nortel with the aim of extending their contribution APC-1656 to include a more generic long term solution (as detailed in TD-43). We believe that APC -1656 is a good starting point, but needs further work to include extensibility concepts, from APC-1683A, before 'determination' of H.225 version 4. It is our understanding that the dialogue is an ongoing process, and this should be reflected in the meeting minutes. Morgan Potter.

1 0

AW: presentationIndicator and Calling Party Number
by Horvath Ernst 03 Nov '99

03 Nov '99

Paul, from H.225.0 subclause 7.2.2 it is clear that the general encoding rules of Q.931 apply. Setting bit 8 of octet 3 to 1 was correct as long as octet 3a was forbidden in H.225.0. Now, since octet 3a is allowed, bit 8 must follow the rules for an extension bit. I recognize your backwards compatibility issue, but a proper implementation of Q.931 encoding and error rules should allow an old implementation to cope with this situation gracefully. Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: Paul Long [mailto:plong@SMITHMICRO.COM] > Gesendet am: Mittwoch, 3. November 1999 17:33 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: Re: presentationIndicator and Calling Party Number > > H.225.0 has always required that the octet-3 extension bit in > calling party > number be set to 1. Regardless of the reason for it being > this way, setting > it to 0 renders an EP non-compliant and risks > interoperability problems. In > addition, H.225.0 cannot be changed in this regard in a future version > without risking interoperability problems. > > Paul Long > Smith Micro Software, Inc. > > -----Original Message----- > From: Horvath Ernst [mailto:ernst.horvath@SIEMENS.AT] > Sent: Wednesday, November 03, 1999 10:06 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: AW: presentationIndicator and Calling Party Number > > > Hi, > > see inserted answers below. > > Ernst Horvath > Siemens AG > > > -----Ursprüngliche Nachricht----- > > Von: henri.maenpaa(a)NOKIA.COM [mailto:henri.maenpaa@NOKIA.COM] > > Gesendet am: Mittwoch, 3. November 1999 15:55 > > An: ITU-SG16(a)mailbag.cps.intel.com > > Betreff: presentationIndicator and Calling Party Number > > > > All, > > > > First, there seems to be some inconsistency about the use of > > 3a octet of > > Q931 CallingPartyNumber field in H.225.0. Hopefully this is just an > > editorial mistake. > > > > Q931 (05/98) states the following (chapter 4.5.1 Coding Rules): > > c) An octet group is formed by using some extension > > mechanism. The > > preferred extension mechanism is to extend an octet (N) > > through the next > > octet(s) (Na, Nb, etc.) by using bit 8 in each octet as an > > extension bit. > > The bit value "0" indicates that the octet continues through > > the next octet. > > The bit value "1" indicates that this octet is the last > > octet. If one octet > > (Nb) is present, also the preceding octets (N and Na) must > be present. > > > > Whereas H.225.0v3 (09/99) seems to do the opposite in Calling > > Party Number > > field by telling to set the octet 3 extension bit to 1, and > > use octet 3a as > > "encoded following the values and rules of table 4-9/Q931." > > > > [EH:] This can only be an oversight. The correct text must be > for bit 8 > of > octet 3: Set to '1' if octet 3a is not present, set to '0' otherwise. > > > > > Second, I am also wondering why H.225.0 currently allows two > > methods for > > CLIP/CLIR indication: > > Octet 3a and the ASN.1 side presentationIndicator IE. OK, > the standard > > states strictly that octet 3a overrides the other, and > therefore there > > should not be insolvable conflicts at the receiving entity, > > but still why > > they were both included? > > > > [EH:] H.225.0 allows two places to include calling party information > (both > optional): the Calling party number information element and the > sourceAddress field in User-user. The presentationIndicator field is > intended for the latter one. > > > > -Henri Mäenpää, Nokia > > >

2 1

AW: presentationIndicator and Calling Party Number
by Horvath Ernst 03 Nov '99

03 Nov '99

Hi, see inserted answers below. Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: henri.maenpaa(a)NOKIA.COM [mailto:henri.maenpaa@NOKIA.COM] > Gesendet am: Mittwoch, 3. November 1999 15:55 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: presentationIndicator and Calling Party Number > > All, > > First, there seems to be some inconsistency about the use of > 3a octet of > Q931 CallingPartyNumber field in H.225.0. Hopefully this is just an > editorial mistake. > > Q931 (05/98) states the following (chapter 4.5.1 Coding Rules): > c) An octet group is formed by using some extension > mechanism. The > preferred extension mechanism is to extend an octet (N) > through the next > octet(s) (Na, Nb, etc.) by using bit 8 in each octet as an > extension bit. > The bit value "0" indicates that the octet continues through > the next octet. > The bit value "1" indicates that this octet is the last > octet. If one octet > (Nb) is present, also the preceding octets (N and Na) must be present. > > Whereas H.225.0v3 (09/99) seems to do the opposite in Calling > Party Number > field by telling to set the octet 3 extension bit to 1, and > use octet 3a as > "encoded following the values and rules of table 4-9/Q931." > [EH:] This can only be an oversight. The correct text must be for bit 8 of octet 3: Set to '1' if octet 3a is not present, set to '0' otherwise. > > Second, I am also wondering why H.225.0 currently allows two > methods for > CLIP/CLIR indication: > Octet 3a and the ASN.1 side presentationIndicator IE. OK, the standard > states strictly that octet 3a overrides the other, and therefore there > should not be insolvable conflicts at the receiving entity, > but still why > they were both included? > [EH:] H.225.0 allows two places to include calling party information (both optional): the Calling party number information element and the sourceAddress field in User-user. The presentationIndicator field is intended for the latter one. > -Henri Mäenpää, Nokia >

2 1

presentationIndicator and Calling Party Number
by henri.maenpaa＠NOKIA.COM 03 Nov '99

03 Nov '99

All, First, there seems to be some inconsistency about the use of 3a octet of Q931 CallingPartyNumber field in H.225.0. Hopefully this is just an editorial mistake. Q931 (05/98) states the following (chapter 4.5.1 Coding Rules): c) An octet group is formed by using some extension mechanism. The preferred extension mechanism is to extend an octet (N) through the next octet(s) (Na, Nb, etc.) by using bit 8 in each octet as an extension bit. The bit value "0" indicates that the octet continues through the next octet. The bit value "1" indicates that this octet is the last octet. If one octet (Nb) is present, also the preceding octets (N and Na) must be present. Whereas H.225.0v3 (09/99) seems to do the opposite in Calling Party Number field by telling to set the octet 3 extension bit to 1, and use octet 3a as "encoded following the values and rules of table 4-9/Q931." Second, I am also wondering why H.225.0 currently allows two methods for CLIP/CLIR indication: Octet 3a and the ASN.1 side presentationIndicator IE. OK, the standard states strictly that octet 3a overrides the other, and therefore there should not be insolvable conflicts at the receiving entity, but still why they were both included? -Henri Mäenpää, Nokia

2 1

Re: Intra Domain/Inter zone communication
by Roy, Radhika R, ALARC 03 Nov '99

03 Nov '99

Hi, Haim and All: I am glad that you took the pain to go through AT&T's contribution (APC-1434) submitted a long time ago. You are right. There are some fundamental issues that need to be addressed for scalability especially for the large-scale network(s). Let me summarize my personal view point what progress we have made so far: * Inter-Domain Communications: 1. We have finalized the H.225.0 Annex G protocol. HopCount and other aspects (e.g., distributed and centralized domain concepts, caching mechanisms [but not how to manage the cache]) of AT&T's contribution were accepted. 2. More work needs to be done. For example, seamless communications (e.g., signaling messages) between the intra-domain and the inter-domain. How do we send signaling messages (RAS/Annex G, Call Signaling) among the BEs when domains are fully distributive (not fully connected)? How do we implement the application layer H.323 QOS on end-to-end basis using the same QOS services format from end users' point of view when pre-call or call signaling messages will go via none (direct), all, or some BEs between the source-destination domains considering the domains are distributive and each domain may implement different network layer QOS services? All these issues are subject to further standardization. 3. More contributions will allow us to proceed in this area in the future. * Inter-Zone/Intra-Domain Communications: 1. No modification or improvement has been made in H.323. 2. AT&T contributions have been made to allow the more powerful Annex G messages for inter-zone communications as well. I request that all companies examine this proposal. 3. For two-GK model, I see that the existing signaling messages may work (even then we have some problems). However, we have, as you have also pointed out, serious problems in the case of multiple-GK (3, 10, ... ) environment. 4. We also need to provide more contributions solving these problems. * Going-Forward: 1. We have opened a new work group know as "H.323 Robustness." 2. This group will have to deal with GK reliability as well. In this situation, we have to consider multiple GKs even in a given domain. We definitely need an new inter-GK protocol. 3. My suggestion would be: Let us consider the GK architecture and test the inter-GK protocol. Many of the suggestions made in AT&T contributions may still be applicable to develop the inter-GK protocol. 4. We may have a valuable experience while we develop the new inter-GK protocol to improve the robustness. 5. We may then apply the same experience how we can further improve the existing signaling messages for inter-GK communications as well. For now, this is what I have to offer to you. Hope that others will also provide their comments. Best Regards, Radhika R. Roy AT&T + 1 732 420 1580 rrroy(a)att.com > -----Original Message----- > From: Haim Rochberger [SMTP:Haim_Rochberger@EUR.3COM.COM] > Sent: Wednesday, November 03, 1999 4:36 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Q: Intra Domain/Inter zone communication > > I apologize for the wide distribution - I am a "new kid in town". > I know that Annex G refers to inter-Domain connectivity... but my current > interest is Inter-Zone/Intra-Domain. > It is clear that GKs can broadcast LRQ msg to resolve non-local addresses > (and > cache them) , but this does not sound like a scaleable > solution. > I found a contribution APC-1434 from AT&T that gives some static and > dynamic > solution/guidelines. > My questions are: > 1) What is the status of the contribution ? anyone knows if this is > accepted ? > 2) Can someone point me to other places in any standard/contribution that > address this issue (if such exist). > If no special mechanism exist, and yet people agree that this is an issue > (scaleability and redundancy) for Inter-Zone > then let me know, and I can build a contribution that will offer those > requirements. > > Yours, > Haim. > e-mail: Haim_Rochberger(a)3com.com

1 0

Q: Intra Domain/Inter zone communication
by Haim Rochberger 03 Nov '99

03 Nov '99

I apologize for the wide distribution - I am a "new kid in town". I know that Annex G refers to inter-Domain connectivity... but my current interest is Inter-Zone/Intra-Domain. It is clear that GKs can broadcast LRQ msg to resolve non-local addresses (and cache them) , but this does not sound like a scaleable solution. I found a contribution APC-1434 from AT&T that gives some static and dynamic solution/guidelines. My questions are: 1) What is the status of the contribution ? anyone knows if this is accepted ? 2) Can someone point me to other places in any standard/contribution that address this issue (if such exist). If no special mechanism exist, and yet people agree that this is an issue (scaleability and redundancy) for Inter-Zone then let me know, and I can build a contribution that will offer those requirements. Yours, Haim. e-mail: Haim_Rochberger(a)3com.com

1 0

Re: The meaning of the reception of a "new" capability set
by Pete Cordell 03 Nov '99

03 Nov '99

Paul, Um, the more e-mail I see on this the more painfully 'obvious' it seems to me that the shortened form was probably not the right way to go!!! I'm not sure what to do about that. Maybe as you say we just have to put it down to experience. On the acknowledgement front, we wait for the CLCs to come in. If they don't appear in time we assume it's not going to work. We also planned to keep a list of endpoints that we knew don't work (keying off Vendor ID or whatever field it is). We don't do that at the moment though as we don't have enough information about which EPs support it. Pete ============================================= Pete Cordell pete(a)tech-know-ware.com ============================================= -----Original Message----- From: Paul Long <plong(a)SMITHMICRO.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: 02 November 1999 16:56 Subject: Re: The meaning of the reception of a "new" capability set >Pete, > >This is how the delta concept is described: > >B.2.2.1/H.245v5: "At the start, no table entries are defined. When a >CapabilityTableEntry is received, it replaces the previously received >CapabilityTableEntry with the same CapabilityTableEntryNumber. A >CapabilityTableEntry without a Capability may be used to remove the >previously received CapabilityTableEntry with the same >CapabilityTableEntryNumber." > >I think this passage makes it clear that TCS is a "delta" mechanism, >although it does not use this or a similar term. > >By the way, due to the apparently inadvertent use of "should" rather than >"shall" in the normative text of v2 and v3, the crucial step of closing >channels upon receipt of an empty cap set is not mandatory. 8.4.6/H.323v3: >"If media stream or data logical channels were previously opened by the >endpoint, they should be closed." Is v4 our earliest possible opportunity to >make this mandatory? At that point, there will be three meanings of an empty >cap set. > >I agree with your team that the initiating EP should have been required to >explicitly remove all receive caps in the remote EP. Having the meaning of >an empty cap set change from one version to another is asking for trouble, >trouble that we are already seeing. Also, having a special rule for the >empty cap set is bad design. This is analogous to having a special, or >reserved, value for a field, e.g., "9/9/99". :-} Pick up any book on >software or database design, and it will mention this issue. > >Regarding the use of RequestMode, since we were adding a fair amount of >normative text for pause anyway, we could have just as easily said that a >RequestMode containing a null mode _shall_ be accepted, regardless of >whether the EP is in receipt of a multipointModeCommand. This would have >used the existing mechanism in H.245 for doing this, required less normative >text, and been clearer, IMO, than to introduce the new concept of "empty cap >set." > >Also, if we had used RequestMode, we would know whether the remote EP was >actually going to close all the channels. Many (all?) v2 EPs on the market >now do not support pause, but they all accept an empty TCS. This effectively >makes pause useless because it is not dependably supported--the initiating >EP does not have positive feedback as to whether the remote EP is actually >going to pause--even though it is required. > >BTW, I'm not blaming you or anyone else for this. I just hope that we learn >from our mistakes. > >Paul Long >Smith Micro Software, Inc. > >-----Original Message----- >From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] >Sent: Tuesday, November 02, 1999 5:44 AM >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: The meaning of the reception of a "new" capability set > > >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 >> >

2 1

Call Clearing related
by Sunil Chandra 03 Nov '99

03 Nov '99

Dear Paul, Question 1: This is specifically in regards to call clearing in which both endpoints have pregranted ARQs and the call is GK routed. If the GK closes the call signalling channel, how would the GK know of the call clearing? possibilities : a) both endpoints send a DRQ (even if they have pregranted ARQ). b) GK peeps into the H.245 channel and treats the EndSessionCommand as the request for call clearing. c) (Assuming that GK has requested for IRRs.) On detection of 'n' missed IRRs, the GK decides to poll the endpoint and gets no answer or negative answer, Gk assumes that the call has been released. (But it may have serious implications on billing.) Question 2: If the possibility (a) is TRUE, is the DRQ mandatory for a registered endpoint whether it has sent ARQ or not and whether it sends a subsequent RELEASE COMPLETE or not. Question 3: If the possibilty (c) is TRUE, should it not be mandatory to specify irrFrequencyInCall in either ACF or RCF, if the GK does not want to retain the call signaling channel? With regards, Sunil Chandra Hughes Software System

3 4

Mentor Program
by Oscar 03 Nov '99

03 Nov '99

*Earn $2000 - $5000 weekly-starting within 1-4 weeks *78% Profit Paid Daily *No Selling *No Risk Guarantee *Work from home, No overhead, or employees. *High Tech Training & Support *Not MLM, 100x more profitable *Multibillion Dollar Travel Industry The most incredible part of our business is that ALL MY CLIENTS CALL ME! DO YOU QUALIFY FOR OUR MENTOR PROGRAM? ACCEPTING ONLY 12 NEW ASSOCIATES This is not a hobby! Serious Inquires Only!! Please reply with the following information NAME: EMAIL ADDRESS: PHONE: BEST TIME TO CALL: TO: mailto:rudy93@enotify.com?subject=more_info FOR MORE INFORMATION If your an entrepreneur or have always wanted to be your own BOSS, read on. We supply state-of-the-art training and a support system that allows you to work your business from your home with just a phone-without cold calling. DO NOT REPLY IF YOU ARE LOOKING FOR A "GET RICH QUICK" SCHEME or some extra cash or if you're lazy. We are only looking for FOCUSED serious entrepreneurs. (Pt/FT) with the DESIRE to improve their lifestyle immediately. /////////////////////////////////////////////////////////// Please remove at mailto:fedt87@yahoo.com?subject=remove ///////////////////////////////////////////////////////////

1 0

Re: H.323 Mobility Ad Hoc Group Conference Call information
by Edgar Martinez [1] 02 Nov '99

02 Nov '99

1 0

Re: H.323 Mobility Ad Hoc Group Conference Call information
by Reddy, Paul K 02 Nov '99

02 Nov '99

Dear Ed, The Item 7a in the agenda is H.323 Interworking with PLMNs. I included the H.246 Annex E scope, terms of reference and work plan within parenthesis is to remind us that contributions on H.246 Annex E will be discussed under agenda item 7a for final consensus. I do not mind using the URL you proposed, but please give us the FTP site where we can upload the contributions for the conference call. The site you proposed below does not work for ftp. thanks, Paul Paul K. Reddy Intel Architecture Labs, Intel Corporation, 2111 NE 25th Avenue, Hillsboro, OR - 97124, USA, Office Phone# +1 (503)-264-9896 -----Original Message----- From: Edgar Martinez [1] [mailto:martinze@CIG.MOT.COM] Sent: Tuesday, November 02, 1999 10:58 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 Mobility Ad Hoc Group Conference Call information Dear Paul, >7a. H.323 Interworking with PLMNs (H.246 Annex E scope, terms of >reference and work plan) Isn't this H.323 interworking within PLMNs -- Last comments: Old Business: [Include TD65 agreedment] "To focus topics are Chapter 4 and Chapter 5 of the outline and the completion of the outline." I assume the completion of the outline, means for the full document, as I stated in the closing of the meeting not to forget the Interworking sections. --- On contributions and documents, due to fact that the standard.pictel.com/avc-site/Incoming, directory is temporary and documents there have a short lifespan. I have set-up a folder in the ITU wed-stie we can use for our Ad-hoc documents. So if anyone agrees you can place to document there or if you have and problems sent then to me by email. http://people.itu.int/~emartine/temp/SG16-mobility/ConfCall_Nov17-99/ Ed "Reddy, Paul K" wrote: > Hi Everyone: > > The following are the H.323 Mobility Ad Hoc group conference call > Information: > > 1. Conference Call Bridge Information > Date: November 17, 1999 > Time: 8:00 AM to 10:00 AM (Pacific Standard Time (PST)) > > Conference Call Bridge Number: +1 (916)-356-9200 > Reservation Number: 3-327470 > Passcode: 5421571 > > Note: There are 20 ports available for the conference call, please use one > or two ports per company. > > Procedure to join the conference call: > · Please call +1 (916)-356-9200 and > · wait for voice prompt to enter the first digit of reservation number, and > enter "3" as the first digit of reservation number, > · and then wait for the voice prompt to enter the passcode, and enter > 5421571 as passcode, then you will be bridged to conference call. > > 2. Agenda for the H.323 Mobility Ad Hoc group conference call: > > 1. Call to Order & Opening Remarks > 2. Attendance Registration > 3. Introduction and Numbering of Contributions > 4. Agenda Review and Approval > 4a. Review H.323 Mobility Ad Hoc Meeting report > 5. Correspondence to other standards groups > 6. Old Business > 6a. review TD-16, TD-42b > 6b. H.323 Mobility Functional Entities (HLF, VLF, AuF, IWF) > 6c. H.323 Mobility Architecture > 6d. > 7. New Business > 7a. H.323 Interworking with PLMNs (H.246 Annex E scope, terms of > reference and work plan) > 8. Meeting Schedule > 8a. Discuss next conference call meetings > 9. Review Assignments > 10. Review Workplan > 11. Open Discussion > 12. Adjourn > > Note: All participating companies are welcome to submit > contributions (in addition to previous contributions), which > pertains to 6b, 6c and 7a. > > Please upload all your contributions as zipped files to the reflector at > ftp://standard.pictel.com/avc-site/Incoming/H.323_Mobility directory. > > Currently, the following documents are uploaded to the above ftp directory: > TD-01 : H.323 Mobility Ad Hoc Group Interim meeting via Conference Call > Agenda > TD-02 : H.323 Mobility Ad Hoc Group Activity Report > > Please send me email with your document number as TD-XX and title, if you > upload any documents so that I can keep track and assign to the agenda item > to be discussed during our conference call. > > Please send email at paul.k.reddy(a)intel.com, if you have any questions. > > thanks, > Paul > > Paul K. Reddy > Intel Architecture Labs, > Intel Corporation, > 2111 NE 25th Avenue, > Hillsboro, OR - 97124, USA, > Office Phone# +1 (503)-264-9896 > > -----Original Message----- > From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] > Sent: Tuesday, November 02, 1999 9:19 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.323 Mobility Ad Hoc Group Activity Report > > Hi Everyone: > > I am summarizing the activity of the last SG16 Q.11-15 Red Bank meeting held > on October 18-22, 1999, as follows: > > 1. The titles of H.323 Annex H and I have been modified as stated below: > > * H.323 Annex H: User, Terminal, and Service Mobility in H.323 - > Editor: E. Martinez, Motorola > * H.323 Annex I: Packet-based Multimedia Telephony over Error Prone > Channels - Editor: B. Aronson, Toshiba > > 2. 15 APCs (AT&T, Ericsson, Intel, Lucent, Motorola, Nokia, and Siemens) > related to Annex H and 1 APC (Toshiba) related to Annex I were submitted. In > addtion, 3 TDs (16, 42b, and 65) were produced by the Ad Hoc Mobility Group. > > 3. TD 65 reflects the outline (on-going work) of H.323 Annex H. > > 4. A separate work item has been proposed as an H.248 Annex E: "Interworking > PLMNs with H.323 Networks." The scope and title are yet to be decided. > Moreover, an editor also needs to be assigned for this work. > > 5. Not all detail of each contribution was discussed in the meeting. Only > terminologies and some functional aspects of each contribution were > discussed. It was also agreed that the mobility solution would focus on the > H.323 application layer. By definition, any H.323 solutions can be used by > any packet-based network. (That is, a network layer is free to choose any > implementation scheme as it is deemed to be necessary.) > > 6. The first conference call on H.323 mobility will be held on November 17, > 1999, Time: 8:00 AM - 10:00 AM (Pacific Standard Time (PST), USA. Paul Reddy > of Intel will send the detail meeting notice including the conference bridge > number and meeting agenda. Contributions are also solicited for the on-going > discussions and conference calls. > > If you have any questions, please let me know. > > Best regards, > Radhika R. Roy > AT&T > +1 732 420 1580 > rrroy(a)att.com -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

White paper on MGCP vs MEGACO
by vbajaj＠HSS.HNS.COM 02 Nov '99

02 Nov '99

Hi all, Our sincere apologies for the wide cross-posting and inconvenience that it may have caused. We thought the information compiled in this white paper may be of interest to participants of all these mailing lists. Hence, the wide crossposting. Attached with this mail is a White paper that highlights the differences between MEGACO, the proposed protocol for control of Media Gateways by the Media Gateway Controllers in the desomposed Gateway architecture, and its predecessor MGCP protocol. Comments are most welcome and may be sent to vbajaj(a)hss.hns.com. Regards, Vikas Bajaj Gateway Development Team Hughes Software Systems Ltd. (See attached file: MEGACOvsMGCP_v3.doc)

2 2

Re: H.323 Mobility Ad Hoc Group Conference Call information
by Edgar Martinez [1] 02 Nov '99

02 Nov '99

Dear Paul, >7a. H.323 Interworking with PLMNs (H.246 Annex E scope, terms of >reference and work plan) Isn't this H.323 interworking within PLMNs -- Last comments: Old Business: [Include TD65 agreedment] "To focus topics are Chapter 4 and Chapter 5 of the outline and the completion of the outline." I assume the completion of the outline, means for the full document, as I stated in the closing of the meeting not to forget the Interworking sections. --- On contributions and documents, due to fact that the standard.pictel.com/avc-site/Incoming, directory is temporary and documents there have a short lifespan. I have set-up a folder in the ITU wed-stie we can use for our Ad-hoc documents. So if anyone agrees you can place to document there or if you have and problems sent then to me by email. http://people.itu.int/~emartine/temp/SG16-mobility/ConfCall_Nov17-99/ Ed "Reddy, Paul K" wrote: > Hi Everyone: > > The following are the H.323 Mobility Ad Hoc group conference call > Information: > > 1. Conference Call Bridge Information > Date: November 17, 1999 > Time: 8:00 AM to 10:00 AM (Pacific Standard Time (PST)) > > Conference Call Bridge Number: +1 (916)-356-9200 > Reservation Number: 3-327470 > Passcode: 5421571 > > Note: There are 20 ports available for the conference call, please use one > or two ports per company. > > Procedure to join the conference call: > · Please call +1 (916)-356-9200 and > · wait for voice prompt to enter the first digit of reservation number, and > enter "3" as the first digit of reservation number, > · and then wait for the voice prompt to enter the passcode, and enter > 5421571 as passcode, then you will be bridged to conference call. > > 2. Agenda for the H.323 Mobility Ad Hoc group conference call: > > 1. Call to Order & Opening Remarks > 2. Attendance Registration > 3. Introduction and Numbering of Contributions > 4. Agenda Review and Approval > 4a. Review H.323 Mobility Ad Hoc Meeting report > 5. Correspondence to other standards groups > 6. Old Business > 6a. review TD-16, TD-42b > 6b. H.323 Mobility Functional Entities (HLF, VLF, AuF, IWF) > 6c. H.323 Mobility Architecture > 6d. > 7. New Business > 7a. H.323 Interworking with PLMNs (H.246 Annex E scope, terms of > reference and work plan) > 8. Meeting Schedule > 8a. Discuss next conference call meetings > 9. Review Assignments > 10. Review Workplan > 11. Open Discussion > 12. Adjourn > > Note: All participating companies are welcome to submit > contributions (in addition to previous contributions), which > pertains to 6b, 6c and 7a. > > Please upload all your contributions as zipped files to the reflector at > ftp://standard.pictel.com/avc-site/Incoming/H.323_Mobility directory. > > Currently, the following documents are uploaded to the above ftp directory: > TD-01 : H.323 Mobility Ad Hoc Group Interim meeting via Conference Call > Agenda > TD-02 : H.323 Mobility Ad Hoc Group Activity Report > > Please send me email with your document number as TD-XX and title, if you > upload any documents so that I can keep track and assign to the agenda item > to be discussed during our conference call. > > Please send email at paul.k.reddy(a)intel.com, if you have any questions. > > thanks, > Paul > > Paul K. Reddy > Intel Architecture Labs, > Intel Corporation, > 2111 NE 25th Avenue, > Hillsboro, OR - 97124, USA, > Office Phone# +1 (503)-264-9896 > > -----Original Message----- > From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] > Sent: Tuesday, November 02, 1999 9:19 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.323 Mobility Ad Hoc Group Activity Report > > Hi Everyone: > > I am summarizing the activity of the last SG16 Q.11-15 Red Bank meeting held > on October 18-22, 1999, as follows: > > 1. The titles of H.323 Annex H and I have been modified as stated below: > > * H.323 Annex H: User, Terminal, and Service Mobility in H.323 - > Editor: E. Martinez, Motorola > * H.323 Annex I: Packet-based Multimedia Telephony over Error Prone > Channels - Editor: B. Aronson, Toshiba > > 2. 15 APCs (AT&T, Ericsson, Intel, Lucent, Motorola, Nokia, and Siemens) > related to Annex H and 1 APC (Toshiba) related to Annex I were submitted. In > addtion, 3 TDs (16, 42b, and 65) were produced by the Ad Hoc Mobility Group. > > 3. TD 65 reflects the outline (on-going work) of H.323 Annex H. > > 4. A separate work item has been proposed as an H.248 Annex E: "Interworking > PLMNs with H.323 Networks." The scope and title are yet to be decided. > Moreover, an editor also needs to be assigned for this work. > > 5. Not all detail of each contribution was discussed in the meeting. Only > terminologies and some functional aspects of each contribution were > discussed. It was also agreed that the mobility solution would focus on the > H.323 application layer. By definition, any H.323 solutions can be used by > any packet-based network. (That is, a network layer is free to choose any > implementation scheme as it is deemed to be necessary.) > > 6. The first conference call on H.323 mobility will be held on November 17, > 1999, Time: 8:00 AM - 10:00 AM (Pacific Standard Time (PST), USA. Paul Reddy > of Intel will send the detail meeting notice including the conference bridge > number and meeting agenda. Contributions are also solicited for the on-going > discussions and conference calls. > > If you have any questions, please let me know. > > Best regards, > Radhika R. Roy > AT&T > +1 732 420 1580 > rrroy(a)att.com -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

H.323 Mobility Ad Hoc Group Conference Call information
by Reddy, Paul K 02 Nov '99

02 Nov '99

Hi Everyone: The following are the H.323 Mobility Ad Hoc group conference call Information: 1. Conference Call Bridge Information Date: November 17, 1999 Time: 8:00 AM to 10:00 AM (Pacific Standard Time (PST)) Conference Call Bridge Number: +1 (916)-356-9200 Reservation Number: 3-327470 Passcode: 5421571 Note: There are 20 ports available for the conference call, please use one or two ports per company. Procedure to join the conference call: · Please call +1 (916)-356-9200 and · wait for voice prompt to enter the first digit of reservation number, and enter "3" as the first digit of reservation number, · and then wait for the voice prompt to enter the passcode, and enter 5421571 as passcode, then you will be bridged to conference call. 2. Agenda for the H.323 Mobility Ad Hoc group conference call: 1. Call to Order & Opening Remarks 2. Attendance Registration 3. Introduction and Numbering of Contributions 4. Agenda Review and Approval 4a. Review H.323 Mobility Ad Hoc Meeting report 5. Correspondence to other standards groups 6. Old Business 6a. review TD-16, TD-42b 6b. H.323 Mobility Functional Entities (HLF, VLF, AuF, IWF) 6c. H.323 Mobility Architecture 6d. 7. New Business 7a. H.323 Interworking with PLMNs (H.246 Annex E scope, terms of reference and work plan) 8. Meeting Schedule 8a. Discuss next conference call meetings 9. Review Assignments 10. Review Workplan 11. Open Discussion 12. Adjourn Note: All participating companies are welcome to submit contributions (in addition to previous contributions), which pertains to 6b, 6c and 7a. Please upload all your contributions as zipped files to the reflector at ftp://standard.pictel.com/avc-site/Incoming/H.323_Mobility directory. Currently, the following documents are uploaded to the above ftp directory: TD-01 : H.323 Mobility Ad Hoc Group Interim meeting via Conference Call Agenda TD-02 : H.323 Mobility Ad Hoc Group Activity Report Please send me email with your document number as TD-XX and title, if you upload any documents so that I can keep track and assign to the agenda item to be discussed during our conference call. Please send email at paul.k.reddy(a)intel.com, if you have any questions. thanks, Paul Paul K. Reddy Intel Architecture Labs, Intel Corporation, 2111 NE 25th Avenue, Hillsboro, OR - 97124, USA, Office Phone# +1 (503)-264-9896 -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] Sent: Tuesday, November 02, 1999 9:19 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: H.323 Mobility Ad Hoc Group Activity Report Hi Everyone: I am summarizing the activity of the last SG16 Q.11-15 Red Bank meeting held on October 18-22, 1999, as follows: 1. The titles of H.323 Annex H and I have been modified as stated below: * H.323 Annex H: User, Terminal, and Service Mobility in H.323 - Editor: E. Martinez, Motorola * H.323 Annex I: Packet-based Multimedia Telephony over Error Prone Channels - Editor: B. Aronson, Toshiba 2. 15 APCs (AT&T, Ericsson, Intel, Lucent, Motorola, Nokia, and Siemens) related to Annex H and 1 APC (Toshiba) related to Annex I were submitted. In addtion, 3 TDs (16, 42b, and 65) were produced by the Ad Hoc Mobility Group. 3. TD 65 reflects the outline (on-going work) of H.323 Annex H. 4. A separate work item has been proposed as an H.248 Annex E: "Interworking PLMNs with H.323 Networks." The scope and title are yet to be decided. Moreover, an editor also needs to be assigned for this work. 5. Not all detail of each contribution was discussed in the meeting. Only terminologies and some functional aspects of each contribution were discussed. It was also agreed that the mobility solution would focus on the H.323 application layer. By definition, any H.323 solutions can be used by any packet-based network. (That is, a network layer is free to choose any implementation scheme as it is deemed to be necessary.) 6. The first conference call on H.323 mobility will be held on November 17, 1999, Time: 8:00 AM - 10:00 AM (Pacific Standard Time (PST), USA. Paul Reddy of Intel will send the detail meeting notice including the conference bridge number and meeting agenda. Contributions are also solicited for the on-going discussions and conference calls. If you have any questions, please let me know. Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com

1 0

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

02 Nov '99

Hi, Jaakko: Pl. see my reply provided below. Best regards, Radhika > -----Original Message----- > From: jaakko.sundquist(a)NOKIA.COM [SMTP:jaakko.sundquist@NOKIA.COM] > Sent: Tuesday, November 02, 1999 11:13 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H323mobility: meeting > > Once again, hi, Radhika, Ed + all > > See my comments below... > > Hi, Jaakko, Ed, and All: > > I hope that Jaakko will get this mail while he is in his > office (Thanks > Jaakko - you have reminded us the time difference)! > > [Jaakko:] You caught me just in time. > > > Please note the following: > > 1. Zone and domain are well defined in H.323. > [Jaakko:] Yes, they are defined. > > 2. We have to work for mobility solution in a way that > fits > very well that > already exists in H.323. > > [Jaakko:] Agreed. > > 3. We can invent many things if we need to solve mobility > problems only when > we think that those functions are NOT covered in existing > H.323 standard. > > [Jaakko:] Yes. > > 4. If mobility problems can be solved using the concept of > "zones" and > "domains," I would assume that it would be a big mile > stone > so far the > continuity of H.323 is concerned. That is, as Ed pointed > out, H.323 mobility > problem is NOT a rocket science. We have to remember that > we > are working in > the framework of already existing H.323 standard > architecture. We have to > relate our solution in the context of existing H.323 > standard. In other > words, we CANNOT change the fundamental concept of > existing > H.323 standards > just because we are addressing mobility. > > [Jaakko:] Yes, of course. I'm not arguing against that. I > guess you are referring to the Location Area discussion here. The LA > concept > is really merely a scaling issue, you could of course handle paging (I'm > assuming that we will need the paging procedure) based on zones, i.e. page > every NPoA in a zone when a call arrives, but this might be quite limiting > in some cases (the zone may be needlessly big or very small). I do not > think > that we need to change any fundamental concepts of H.323, if we introduce > the LA concept. [Roy, Radhika R] May be we can include LA when we see that we need to optimize a zone further. We may revisit this in the second step. > 5. I do not understand what benefits we are gaining adding > more > "terminologies" like "AREA {home, foreign, etc}" while the > "zone" and > "domain" are already well defined in H.323. My personal > view > is that we > should FIRST try to solve H.323 mobility problems within > the > context of > "zone" and "domain" as far as practicable. I would argue > that zone and > domain are good enough to serve this purpose for now. (Pl. > also see AT&T's > and Motorola's contributions.) > > [Jaakko:] As I already said, I did not intent to define > the > terms: home area and visited area. I was just trying to illustrate the > point > I was making about not having the Home/visited zone terms defined yet. [Roy, Radhika R] It is good point. Let us define these. AT&T contributions have the detail definition for each term. > 6. With respect to your comments that it appears that > every > GK will have HLF > and VLF function, I would say that every GK will have the > access to the HLF > and VLF function. This capability for each GK has to be > provided because of > the fact that H.323 architecture is GK-centric. We do not > have any choice > because we are restricted by the H.323 architecture. > > [Jaakko:] I did not argue against this. The point is that > if > we identify a concept called the Home Zone, this already implies that each > User has only one zone, in which he/she/it is not a "visiting user". I > think > this would be really restricting. [Roy, Radhika R] As I mentioned that H.323 is the GK-centric. A user may change his/her network point of point attachment, but it is still the same (Home) GK. So, a given (home) GK, there has to be another level of granularity to address mobility in terms of network point of attachment. Please see AT&T contribution how home and foreign network concept have solved the problem. Similar is the case with Motorola's contribution. The bottom line is that home/foreign GK concept does NOT imply any restriction to solve H.323 mobility. > 6.1 With respect to your question whether HLF/VLF can be > distributive or > centralized, having said (in item 5) that every GK should > have access to HLF > and VLF function, it is up to implementation whether HLF > and > VLF function > can be centralized or distributive. Please see AT&T > contributions submitted > in Red Bank how we can implement these functions in both > distributive and > centralized environment. > > [Jaakko:] This is actually quite much the point I was > making. By defining the Home Zone we would in my mind actually be pointing > to the centralized model. [Roy, Radhika R] By definition, there can as many GKs as one wish have in an H.323 system. So, by definition, the GK-centric H.323 architecture is distributive. By defining home/foreign GK, H.323 mobility also becomes distributive up to the point that a basic H.323 system allows us. So, we do not see any limitations. > 6.2 In an analogy of this HLF/VLF function, I can bring > another function - > Directory services. For example, H.323 assumes that all > the > address (e.g., > alias, transport, network) are kept by each GK. H.323 does > not answer how > the address information is maintained by each GK. People > are > using LDAP > directory server. The question is: whether that directory > service is > distributive or centralized? I guess that it can be done > in > both ways > depending on implementation. > > [Jaakko:] My point exactly. I would like that all GKs > inside > the same Administrative Domain would be able to access the same HLF/VLF > functionality. [Roy, Radhika R] As I pointed out, this an implementation issue. I would argue that we should allow both options and let an implementor choose as it is necessary. Please also see AT&T contributions how both options can be addressed. > 6.3 In AT&T contribution, it is shown that it better to > make > VLF > distributive (per GK) although HLF function can be made > both > distributive > and centralized. Again, this is a matter of > implementation. > As mentioned in > AT&T contribution, we also need to define a kind of > backend > protocol for VLF > and HLF (something like similar to Siemens, Nokia and > Intel's contribution - > TD-39: Security Services for Backend Services and Mobility > in H.323). > > [Jaakko:] I would assume that you can distribute the > HLF/VLF > functionalities inside the Administrative Domain as you like, but > distributing them between the Domains would be difficult. Actually I think > that the concept of Administrative Domain was introduced in H.323 for this > kind of reasons. [Roy, Radhika R] Again, H.323 system is GK-centric in a given domain. For inter-domain, it is BE-centric. In a given domain, H.323 architecture has to be GK-centric. Once we solve intra-zone and inter-zone (intra-domain) mobility, we can extend our experience for inter-domain problem as well. Please also see AT&T contribution how these problems have been addressed. My replies to 6.1 and 6.2 are also good for this case. > 7. Again, I, personally, do not rule our to re-examine the > benfit of "AREA" > (e.g. location area [LA]) vs. "ZONE/DOMAIN" concept. May > be > it is in the > second step. > > [Jaakko:] I am just a bit afraid that if we leave this > kind > of a major mobility related concept out of the first phase thinking > process, > we will find it much more difficult to include the concept in the second > phase (where I think we will need it). Furthermore, I'm not convinced that > the LA concept would not be useful in the pure H.323 approach either. [Roy, Radhika R] I think that it can be place holder for now. I would request to bring more detail contributions proposing solutions like AT&T and Motorola to prove the case better. Then, we can compare both solutions. In AT&T contribution, I feel that the LA can be accommodated to optimize the zone further. So, I do not see that it is a problem to accommodate the LA concept if needed. I personally prefer that we can better address this in the second phase once we solve the problem for the basic architecture. > Hope that this email will clarify the things better. > > [Jaakko:] I think the main thing is that we got the > discussion going on again. I'm kind of tired already, and I hope that I > didn't mess things up too much in this mail. [Roy, Radhika R] Definitely, I also like that discussions must go on. We must be convinced that we have the best solution because it has the severe implications for all on-going mobility standard works throughout the world once we standardize H.323 mobility in SG16. > Best regards, > Radhika > > Same to you, > Jaakko

1 0

H.323 Mobility Ad Hoc Group Activity Report
by Roy, Radhika R, ALARC 02 Nov '99

02 Nov '99

Hi Everyone: I am summarizing the activity of the last SG16 Q.11-15 Red Bank meeting held on October 18-22, 1999, as follows: 1. The titles of H.323 Annex H and I have been modified as stated below: * H.323 Annex H: User, Terminal, and Service Mobility in H.323 - Editor: E. Martinez, Motorola * H.323 Annex I: Packet-based Multimedia Telephony over Error Prone Channels - Editor: B. Aronson, Toshiba 2. 15 APCs (AT&T, Ericsson, Intel, Lucent, Motorola, Nokia, and Siemens) related to Annex H and 1 APC (Toshiba) related to Annex I were submitted. In addtion, 3 TDs (16, 42b, and 65) were produced by the Ad Hoc Mobility Group. 3. TD 65 reflects the outline (on-going work) of H.323 Annex H. 4. A separate work item has been proposed as an H.248 Annex E: "Interworking PLMNs with H.323 Networks." The scope and title are yet to be decided. Moreover, an editor also needs to be assigned for this work. 5. Not all detail of each contribution was discussed in the meeting. Only terminologies and some functional aspects of each contribution were discussed. It was also agreed that the mobility solution would focus on the H.323 application layer. By definition, any H.323 solutions can be used by any packet-based network. (That is, a network layer is free to choose any implementation scheme as it is deemed to be necessary.) 6. The first conference call on H.323 mobility will be held on November 17, 1999, Time: 8:00 AM - 10:00 AM (Pacific Standard Time (PST), USA. Paul Reddy of Intel will send the detail meeting notice including the conference bridge number and meeting agenda. Contributions are also solicited for the on-going discussions and conference calls. If you have any questions, please let me know. Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com

1 0

Re: The meaning of the reception of a "new" capability set
by Pete Cordell 02 Nov '99

02 Nov '99

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 >

2 1

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

02 Nov '99

Once again, hi, Radhika, Ed + all See my comments below... Hi, Jaakko, Ed, and All: I hope that Jaakko will get this mail while he is in his office (Thanks Jaakko - you have reminded us the time difference)! [Jaakko:] You caught me just in time. Please note the following: 1. Zone and domain are well defined in H.323. [Jaakko:] Yes, they are defined. 2. We have to work for mobility solution in a way that fits very well that already exists in H.323. [Jaakko:] Agreed. 3. We can invent many things if we need to solve mobility problems only when we think that those functions are NOT covered in existing H.323 standard. [Jaakko:] Yes. 4. If mobility problems can be solved using the concept of "zones" and "domains," I would assume that it would be a big mile stone so far the continuity of H.323 is concerned. That is, as Ed pointed out, H.323 mobility problem is NOT a rocket science. We have to remember that we are working in the framework of already existing H.323 standard architecture. We have to relate our solution in the context of existing H.323 standard. In other words, we CANNOT change the fundamental concept of existing H.323 standards just because we are addressing mobility. [Jaakko:] Yes, of course. I'm not arguing against that. I guess you are referring to the Location Area discussion here. The LA concept is really merely a scaling issue, you could of course handle paging (I'm assuming that we will need the paging procedure) based on zones, i.e. page every NPoA in a zone when a call arrives, but this might be quite limiting in some cases (the zone may be needlessly big or very small). I do not think that we need to change any fundamental concepts of H.323, if we introduce the LA concept. 5. I do not understand what benefits we are gaining adding more "terminologies" like "AREA {home, foreign, etc}" while the "zone" and "domain" are already well defined in H.323. My personal view is that we should FIRST try to solve H.323 mobility problems within the context of "zone" and "domain" as far as practicable. I would argue that zone and domain are good enough to serve this purpose for now. (Pl. also see AT&T's and Motorola's contributions.) [Jaakko:] As I already said, I did not intent to define the terms: home area and visited area. I was just trying to illustrate the point I was making about not having the Home/visited zone terms defined yet. 6. With respect to your comments that it appears that every GK will have HLF and VLF function, I would say that every GK will have the access to the HLF and VLF function. This capability for each GK has to be provided because of the fact that H.323 architecture is GK-centric. We do not have any choice because we are restricted by the H.323 architecture. [Jaakko:] I did not argue against this. The point is that if we identify a concept called the Home Zone, this already implies that each User has only one zone, in which he/she/it is not a "visiting user". I think this would be really restricting. 6.1 With respect to your question whether HLF/VLF can be distributive or centralized, having said (in item 5) that every GK should have access to HLF and VLF function, it is up to implementation whether HLF and VLF function can be centralized or distributive. Please see AT&T contributions submitted in Red Bank how we can implement these functions in both distributive and centralized environment. [Jaakko:] This is actually quite much the point I was making. By defining the Home Zone we would in my mind actually be pointing to the centralized model. 6.2 In an analogy of this HLF/VLF function, I can bring another function - Directory services. For example, H.323 assumes that all the address (e.g., alias, transport, network) are kept by each GK. H.323 does not answer how the address information is maintained by each GK. People are using LDAP directory server. The question is: whether that directory service is distributive or centralized? I guess that it can be done in both ways depending on implementation. [Jaakko:] My point exactly. I would like that all GKs inside the same Administrative Domain would be able to access the same HLF/VLF functionality. 6.3 In AT&T contribution, it is shown that it better to make VLF distributive (per GK) although HLF function can be made both distributive and centralized. Again, this is a matter of implementation. As mentioned in AT&T contribution, we also need to define a kind of backend protocol for VLF and HLF (something like similar to Siemens, Nokia and Intel's contribution - TD-39: Security Services for Backend Services and Mobility in H.323). [Jaakko:] I would assume that you can distribute the HLF/VLF functionalities inside the Administrative Domain as you like, but distributing them between the Domains would be difficult. Actually I think that the concept of Administrative Domain was introduced in H.323 for this kind of reasons. 7. Again, I, personally, do not rule our to re-examine the benfit of "AREA" (e.g. location area [LA]) vs. "ZONE/DOMAIN" concept. May be it is in the second step. [Jaakko:] I am just a bit afraid that if we leave this kind of a major mobility related concept out of the first phase thinking process, we will find it much more difficult to include the concept in the second phase (where I think we will need it). Furthermore, I'm not convinced that the LA concept would not be useful in the pure H.323 approach either. Hope that this email will clarify the things better. [Jaakko:] I think the main thing is that we got the discussion going on again. I'm kind of tired already, and I hope that I didn't mess things up too much in this mail. Best regards, Radhika Same to you, Jaakko

1 0

Re: RAS terminal and gateway discovery/registration messages
by Gene Schroeder 02 Nov '99

02 Nov '99

Rex, I think we are talking about two meanings of registering multiple times. I believe the proposals you mention relate to a single, (logical) endpoint registering multiple times to augment alias lists, etc. The key is that for each registration, the gatekeeper is aware that the same logical endpoint is involved, and it is simply augmenting/editing registration information for an already-registered endpoint. What I was trying to say was that if a physical device registers as if it were multiple logical endpoints, then in practice the registrations can't or shouldn't use the same transport address. In this case, the gatekeeper is not (in principle) aware that the same physical device is acting as multiple endpoints. Rather, it sees N independent RRQs. If the RRQs share transport addresses, things will probably not work as expected. Now, per the proposals you mention, each of these logical endpoints could themselves register multiple times, but that is the other meaning of multiple.... Gene Schroeder elemedia -----Original Message----- From: Rex Coldren <coldrenr(a)agcs.com> To: ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com> Date: Tuesday, November 02, 1999 10:23 AM Subject: Re: RAS terminal and gateway discovery/registration messages Gene, It is not true that a device that registers multiple times must use different transport addresses. At least not in H.225 v4. Have a look at Berlin APC 1581 and TD 27. These proposals cover additive registration capabilities for an endpoint. ftp://standard.pictel.com/avc-site/9908_Ber/ Rex Coldren +1 623 582 7883 Gene Schroeder wrote: Regarding your first question, I believe that H.225 is simply saying that a physicaldevice can register as multiple logical endpoints, and this might be most commonfor a GW or MCU. It certainly doesn't mean that a PSTN GW would register oncefor each line. However, a GW could partition its lines in some way, and registeronce for each grouping. By the way, while it is not stated explicitly, I believe thatin practice a device that registers multiple times must use different transportaddresses (IP-port combination) in each registration, to allow each logicalendpoint to be individually addressed. Regarding your second question, a GW might register an alias for administrativeor management purposes. Gene Schroederelemedia -----Original Message----- From: Mohamed Mustafa <M.Mustafa(a)SDXPLC.COM> To: ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com> Date: Tuesday, November 02, 1999 6:50 AM Subject: RAS terminal and gateway discovery/registration messages 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: H323mobility:meeting
by Roy, Radhika R, ALARC 02 Nov '99

02 Nov '99

Hi, Ed and All: Milo Orsic has pointed out a fundamental point. Let us use the established procedure that nothing should be added until we jointly discussed and accepted. In this regard, please also see my earlier reply. Best regards, Radhika R. Roy AT&T + 1 732 420 1580 rrroy(a)att.com > -----Original Message----- > From: Orsic, Milo (Milo) [SMTP:orsic@LUCENT.COM] > Sent: Tuesday, November 02, 1999 10:28 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H323mobility:meeting > > Hi Ed, > Please do not include anything in the H.323 Annex H > until a given concept has been discussed and jointly accepted. > I commend you for your enthusiasm to get it done, but > let us follow the established procedures. > Thanks, > My best regards, > Milo Orsic > Lucent Technologies > > > > ---------- > > From: Edgar Martinez [1][SMTP:martinze@CIG.MOT.COM] > > Reply To: Mailing list for parties associated with ITU-T Study Group > > 16 > > Sent: Monday, November 01, 1999 9:23 PM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: H323mobility:meeting > > > > Hi Radhika, > > > > I am glad to see that we all agreed mobility on H.323 is not > > rocket science. > > > > On the call scenarios I did not see any conflicts with > > h.225 call control. Once the mobility/location issue is resolve, that is > > once > > the application knows where to route the calls. In other words, when the > > RAS > > procedures and the location updates are done, we know where to route > the > > call, > > using basic h.225 call control. And it was covered in Motorola's APC > 1646. > > By > > the way, > > I like to include the Call scenarios you identified in the H.323 annex-H > > document. > > To test out "OUR" H.323 combined contributions for the architecture. > > > > Also see last comments below. > > > > "Roy, Radhika R, ALARC" wrote: > > > > > Hi, Ed: > > > > > > I guess that we talking about the same thing. > > > > > > Who told that mobility functions are different in H.323 (IP) or other > > > networks? The basic functionality is the same from end users' point of > > view. > > > > > > In H.323, the H.323 (e.g., H.225.0, Q.931/932) signaling messages are > > used. > > > The cellular-PSTN networks use their signaling messages. The call > > scenarios > > > can be as follows: > > > > > > 1. Mobile H.323 Terminal to Mobile H.323 Terminal > > > 2. Mobile H.323 Terminal to Fixed H.323 Terminal and vice versa > > > 3. Cellular-PSTN Terminal to Mobile H.323 Terminal (3a) and vice versa > > (3b) > > > 4. Cellular-PSTN Terminal to Fixed H.323 terminal (4a) and vice versa > > (4b) > > > > > > For cases 1 and 2, mobility solutions can be provided using the H.323 > > > mobility only (pl. see AT&T's and Nokia's contributions that deal in > > terms > > > of H.323 only). > > > > > > For scenarios 3 and 4, the question of interworking between H.323 (IP) > > and > > > cellular-PSTN comes. > > > > > > Because of H.323, we have certain constraints imposed by its > > architecture. > > > For example, H.323 mobility solution may look as follows: > > > > > > * H.323 mobility is applicable for both wireless and wire-line > > > mobility. > > > * H.323 mobility is addressed in the application layer and can > be > > > implemented to any packet-switched networks (e.g., IP, etc.). > > > * H.323 mobility management is done using the RAS (extended to > > > incorporate mobility) signaling scheme. RAS is usually used for the > > pre-call > > > control signaling and, is completely separated from the call control > > > (Q.931/932) signaling. However, in H.323, it is mandatory that RAS > > signal > > > has to go through the gatekeeper (GK). RAS signaling can be used > anytime > > > independent of the call control scheme. In this respect, H.323 > mobility > > can > > > be managed anytime (before the call, during the call, and/or after the > > call) > > > as it is necessary. > > > * In H.323, Q.931/932 is used for the call control. H.245 is > used > > > primarily to control media (audio, video, and/or data) within a call. > > > * The wireless or wire-line network layer (e.g., IP) can use any > > > scheme as appropriate for implementation of the application layer > H.323 > > > mobility. > > > > > > (How will a complete end-to-end solution look like that satisfy > > scenarios 1, > > > 2, 3, and 4? As an HYPOTHETICAL end-to-end solution, I would request > > combine > > > the solution provided in AT&T's contribution [APC-1651] in H.323 > domain > > and > > > Motorola's contribution [APC-1646] in cellular/PSTN-H.323 excluding > some > > > redundant functions. > > > > > I guess that Motorola's solution does NOT address > > > scenarios 1 and 2 adequately. > > > > Once the RAS procedures are done, we know where to route the call using > > basic > > h.225 call control. > > > > Motorola is not forcing any solution if one looks at the References > > section > > of APC-1646 you will see we try to us the best solutions, and sections > 4.1 > > to > > 4.1.2 is > > based on AT&T's Document - TD-9 August 2-6 1999 Berlin contribution. As > > the > > Editor of Annex-H and the lack of contributions at that time, the > > reference > > below > > was all I had to work with. > > > > [1] ITU-T Recommendation H.245 (1998), Control protocol for multimedia > > communication. > > [2] ITU-T Recommendation H.323 (1999), "Packet-Based Multimedia > > Communications > > Systems." > > [3] Internet Draft <draft-teoyli-mobileip-mvpn-02.txt> February 1999, > > Mobile IP > > extension > > for Private Internets Support (MPN), W. T. Teo National University of > > Singapore > > and Y. > > Li Nortel Networks, Inc. > > [4] W. Liao, "Mobility Internet telephony: Mobile Extensions to H.323," > > INFOCOM'99, > > New York, NY, USA, 2-6 August, 1999. > > [5] RECOMMENDATION ITU-R M.1073-1 DIGITAL CELLULAR LAND > > MOBILE TELECOMMUNICATION SYSTEMS (Question ITU-R 107/8) (1994-1997) > > [6] HANDOVER PROCEDURES ITU-T Recommendation Q.1005 (Extract from the > > Blue > > Book) > > © ITU 1988, 1993 > > [7] E. Martinez, Motorola, "Annex - H (User and Service Mobility in > H.323) > > Proposed Architecture, > > " APC-1560, ITU-T SG16 Q.11-15 Rapporteur Meeting, Berlin, Germany, 2-6 > > August, > > 1999. > > [8] H.323 Mobility Ad Hoc Group, "Terms of Reference for H.323 > Mobility", > > Temporary Document > > No. 34 (Berlin) 5 August 1999 > > > > Best Regards, > > > > Ed > > > > > > > The bottom line is that a solution will look > > > like this: Add some new messages in H.323 and extend the existing > H.323 > > > messages. I guess that AT&T's APC-1651 can satisfy almost all > > requirements > > > specified in Motorola's APC-1646. I hope that APC-1641 will also be > able > > > interwork with GSM/GPRS, ANSI-41, etc. The requirements for TIPHON > > matrix > > > will also be satisfied. If needed, one can also use mobile IP or other > > > schemes for implementation in the IP network layer. I am personally > also > > > interested about the location area concept as proposed by Nokia. Of > > course, > > > I am waiting to see other contributions and on-going discussions.) > > > > > > Hope this will clarify further. > > > > > > Thanks, > > > Radhika > > > > > > > -----Original Message----- > > > > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > > > > Sent: Monday, November 01, 1999 3:14 PM > > > > To: ITU-SG16(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: The meaning of the reception of a "new" capability set
by Pete Cordell 02 Nov '99

02 Nov '99

Frank, To answer your questions specifically: >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. This is what an "empty TCS" is now defined as... at least for today! >- The effect of receiving such a message does not effect the stored caps of the sending EP at the receiving EP Yes it does: The receiving EP now believes that the sending has no receive capabilities. >- You (and the team you're working with) would have liked the effect to have been that all caps are removed. > The result of the two methods is the same, but we would have preferred an "empty TCS" to mean one that indicated that all remaining caps were removed. E.g., if you had: Current capability set: 0: {{H.261qcif&cif},{G.723.1,G.711)} 2: {{H.263sqcif&qcif&cif},{G.723,G.711}} Then empty TCS would be: 0: {} 2: {} plus removing the individual caps such as H.261qcif etc. >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? By re-capping I mean the ability to receive a new capability set and act on it accordingly. For example, if you had: Current capability set: 0: {{H.261qcif},{G.711}} 1: {{H.261cif},{G.711}} and were transmitting H.261cif and you received Incoming termCapSet 2 as: 1: {} resulting in: Current capability set: 0: {{H.261qcif},{G.711}} You would have to close your H.261cif channel (and hopefully open a H.261qcif channel). By 90% I mean, if you act as above, you get most of the behaviour required for third party pause. What you don't get is the MSD happening again when you receive a non-empty cap set. ============================================= Pete Cordell pete(a)tech-know-ware.com =============================================

1 0

Re: H323mobility:meeting
by Orsic, Milo (Milo) 02 Nov '99

02 Nov '99

Hi Ed, Please do not include anything in the H.323 Annex H until a given concept has been discussed and jointly accepted. I commend you for your enthusiasm to get it done, but let us follow the established procedures. Thanks, My best regards, Milo Orsic Lucent Technologies > ---------- > From: Edgar Martinez [1][SMTP:martinze@CIG.MOT.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Monday, November 01, 1999 9:23 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: H323mobility:meeting > > Hi Radhika, > > I am glad to see that we all agreed mobility on H.323 is not > rocket science. > > On the call scenarios I did not see any conflicts with > h.225 call control. Once the mobility/location issue is resolve, that is > once > the application knows where to route the calls. In other words, when the > RAS > procedures and the location updates are done, we know where to route the > call, > using basic h.225 call control. And it was covered in Motorola's APC 1646. > By > the way, > I like to include the Call scenarios you identified in the H.323 annex-H > document. > To test out "OUR" H.323 combined contributions for the architecture. > > Also see last comments below. > > "Roy, Radhika R, ALARC" wrote: > > > Hi, Ed: > > > > I guess that we talking about the same thing. > > > > Who told that mobility functions are different in H.323 (IP) or other > > networks? The basic functionality is the same from end users' point of > view. > > > > In H.323, the H.323 (e.g., H.225.0, Q.931/932) signaling messages are > used. > > The cellular-PSTN networks use their signaling messages. The call > scenarios > > can be as follows: > > > > 1. Mobile H.323 Terminal to Mobile H.323 Terminal > > 2. Mobile H.323 Terminal to Fixed H.323 Terminal and vice versa > > 3. Cellular-PSTN Terminal to Mobile H.323 Terminal (3a) and vice versa > (3b) > > 4. Cellular-PSTN Terminal to Fixed H.323 terminal (4a) and vice versa > (4b) > > > > For cases 1 and 2, mobility solutions can be provided using the H.323 > > mobility only (pl. see AT&T's and Nokia's contributions that deal in > terms > > of H.323 only). > > > > For scenarios 3 and 4, the question of interworking between H.323 (IP) > and > > cellular-PSTN comes. > > > > Because of H.323, we have certain constraints imposed by its > architecture. > > For example, H.323 mobility solution may look as follows: > > > > * H.323 mobility is applicable for both wireless and wire-line > > mobility. > > * H.323 mobility is addressed in the application layer and can be > > implemented to any packet-switched networks (e.g., IP, etc.). > > * H.323 mobility management is done using the RAS (extended to > > incorporate mobility) signaling scheme. RAS is usually used for the > pre-call > > control signaling and, is completely separated from the call control > > (Q.931/932) signaling. However, in H.323, it is mandatory that RAS > signal > > has to go through the gatekeeper (GK). RAS signaling can be used anytime > > independent of the call control scheme. In this respect, H.323 mobility > can > > be managed anytime (before the call, during the call, and/or after the > call) > > as it is necessary. > > * In H.323, Q.931/932 is used for the call control. H.245 is used > > primarily to control media (audio, video, and/or data) within a call. > > * The wireless or wire-line network layer (e.g., IP) can use any > > scheme as appropriate for implementation of the application layer H.323 > > mobility. > > > > (How will a complete end-to-end solution look like that satisfy > scenarios 1, > > 2, 3, and 4? As an HYPOTHETICAL end-to-end solution, I would request > combine > > the solution provided in AT&T's contribution [APC-1651] in H.323 domain > and > > Motorola's contribution [APC-1646] in cellular/PSTN-H.323 excluding some > > redundant functions. > > > I guess that Motorola's solution does NOT address > > scenarios 1 and 2 adequately. > > Once the RAS procedures are done, we know where to route the call using > basic > h.225 call control. > > Motorola is not forcing any solution if one looks at the References > section > of APC-1646 you will see we try to us the best solutions, and sections 4.1 > to > 4.1.2 is > based on AT&T's Document - TD-9 August 2-6 1999 Berlin contribution. As > the > Editor of Annex-H and the lack of contributions at that time, the > reference > below > was all I had to work with. > > [1] ITU-T Recommendation H.245 (1998), Control protocol for multimedia > communication. > [2] ITU-T Recommendation H.323 (1999), "Packet-Based Multimedia > Communications > Systems." > [3] Internet Draft <draft-teoyli-mobileip-mvpn-02.txt> February 1999, > Mobile IP > extension > for Private Internets Support (MPN), W. T. Teo National University of > Singapore > and Y. > Li Nortel Networks, Inc. > [4] W. Liao, "Mobility Internet telephony: Mobile Extensions to H.323," > INFOCOM'99, > New York, NY, USA, 2-6 August, 1999. > [5] RECOMMENDATION ITU-R M.1073-1 DIGITAL CELLULAR LAND > MOBILE TELECOMMUNICATION SYSTEMS (Question ITU-R 107/8) (1994-1997) > [6] HANDOVER PROCEDURES ITU-T Recommendation Q.1005 (Extract from the > Blue > Book) > © ITU 1988, 1993 > [7] E. Martinez, Motorola, "Annex - H (User and Service Mobility in H.323) > Proposed Architecture, > " APC-1560, ITU-T SG16 Q.11-15 Rapporteur Meeting, Berlin, Germany, 2-6 > August, > 1999. > [8] H.323 Mobility Ad Hoc Group, "Terms of Reference for H.323 Mobility", > Temporary Document > No. 34 (Berlin) 5 August 1999 > > Best Regards, > > Ed > > > > The bottom line is that a solution will look > > like this: Add some new messages in H.323 and extend the existing H.323 > > messages. I guess that AT&T's APC-1651 can satisfy almost all > requirements > > specified in Motorola's APC-1646. I hope that APC-1641 will also be able > > interwork with GSM/GPRS, ANSI-41, etc. The requirements for TIPHON > matrix > > will also be satisfied. If needed, one can also use mobile IP or other > > schemes for implementation in the IP network layer. I am personally also > > interested about the location area concept as proposed by Nokia. Of > course, > > I am waiting to see other contributions and on-going discussions.) > > > > Hope this will clarify further. > > > > Thanks, > > Radhika > > > > > -----Original Message----- > > > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > > > Sent: Monday, November 01, 1999 3:14 PM > > > To: ITU-SG16(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: H323mobility: meeting
by Roy, Radhika R, ALARC 02 Nov '99

02 Nov '99

Hi, Ed and All: Thanks for your reply. To answer your question: "To test H.323 Mobility architecture combining both AT&T's and Motorola's contributions," let me suggest the following: 1. Let us discuss off-line via a conf call because contributions are really lengthy. 2. We can then send our individual comments in the SG16 reflector: What you have found in common and what we have not agreed. In this way, we might be able to focus to the appropriate points more clearly. After that SG16 members can also provide their comments. In addition, we will also be discussing in the upcoming conf calls on-going basis. Hope this will be acceptable to you. Best regards, Radhika > -----Original Message----- > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > Sent: Monday, November 01, 1999 10:24 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H323mobility:meeting > > Hi Radhika, > > I am glad to see that we all agreed mobility on H.323 is not > rocket science. > > On the call scenarios I did not see any conflicts with > h.225 call control. Once the mobility/location issue is resolve, that is > once > the application knows where to route the calls. In other words, when the > RAS > procedures and the location updates are done, we know where to route the > call, > using basic h.225 call control. And it was covered in Motorola's APC 1646. > By > the way, > I like to include the Call scenarios you identified in the H.323 annex-H > document. > To test out "OUR" H.323 combined contributions for the architecture. > > Also see last comments below. > > "Roy, Radhika R, ALARC" wrote: > > > Hi, Ed: > > > > I guess that we talking about the same thing. > > > > Who told that mobility functions are different in H.323 (IP) or other > > networks? The basic functionality is the same from end users' point of > view. > > > > In H.323, the H.323 (e.g., H.225.0, Q.931/932) signaling messages are > used. > > The cellular-PSTN networks use their signaling messages. The call > scenarios > > can be as follows: > > > > 1. Mobile H.323 Terminal to Mobile H.323 Terminal > > 2. Mobile H.323 Terminal to Fixed H.323 Terminal and vice versa > > 3. Cellular-PSTN Terminal to Mobile H.323 Terminal (3a) and vice versa > (3b) > > 4. Cellular-PSTN Terminal to Fixed H.323 terminal (4a) and vice versa > (4b) > > > > For cases 1 and 2, mobility solutions can be provided using the H.323 > > mobility only (pl. see AT&T's and Nokia's contributions that deal in > terms > > of H.323 only). > > > > For scenarios 3 and 4, the question of interworking between H.323 (IP) > and > > cellular-PSTN comes. > > > > Because of H.323, we have certain constraints imposed by its > architecture. > > For example, H.323 mobility solution may look as follows: > > > > * H.323 mobility is applicable for both wireless and wire-line > > mobility. > > * H.323 mobility is addressed in the application layer and can be > > implemented to any packet-switched networks (e.g., IP, etc.). > > * H.323 mobility management is done using the RAS (extended to > > incorporate mobility) signaling scheme. RAS is usually used for the > pre-call > > control signaling and, is completely separated from the call control > > (Q.931/932) signaling. However, in H.323, it is mandatory that RAS > signal > > has to go through the gatekeeper (GK). RAS signaling can be used anytime > > independent of the call control scheme. In this respect, H.323 mobility > can > > be managed anytime (before the call, during the call, and/or after the > call) > > as it is necessary. > > * In H.323, Q.931/932 is used for the call control. H.245 is used > > primarily to control media (audio, video, and/or data) within a call. > > * The wireless or wire-line network layer (e.g., IP) can use any > > scheme as appropriate for implementation of the application layer H.323 > > mobility. > > > > (How will a complete end-to-end solution look like that satisfy > scenarios 1, > > 2, 3, and 4? As an HYPOTHETICAL end-to-end solution, I would request > combine > > the solution provided in AT&T's contribution [APC-1651] in H.323 domain > and > > Motorola's contribution [APC-1646] in cellular/PSTN-H.323 excluding some > > redundant functions. > > > I guess that Motorola's solution does NOT address > > scenarios 1 and 2 adequately. > > Once the RAS procedures are done, we know where to route the call using > basic > h.225 call control. > > Motorola is not forcing any solution if one looks at the References > section > of APC-1646 you will see we try to us the best solutions, and sections 4.1 > to > 4.1.2 is > based on AT&T's Document - TD-9 August 2-6 1999 Berlin contribution. As > the > Editor of Annex-H and the lack of contributions at that time, the > reference > below > was all I had to work with. > > [1] ITU-T Recommendation H.245 (1998), Control protocol for multimedia > communication. > [2] ITU-T Recommendation H.323 (1999), "Packet-Based Multimedia > Communications > Systems." > [3] Internet Draft <draft-teoyli-mobileip-mvpn-02.txt> February 1999, > Mobile IP > extension > for Private Internets Support (MPN), W. T. Teo National University of > Singapore > and Y. > Li Nortel Networks, Inc. > [4] W. Liao, "Mobility Internet telephony: Mobile Extensions to H.323," > INFOCOM'99, > New York, NY, USA, 2-6 August, 1999. > [5] RECOMMENDATION ITU-R M.1073-1 DIGITAL CELLULAR LAND > MOBILE TELECOMMUNICATION SYSTEMS (Question ITU-R 107/8) (1994-1997) > [6] HANDOVER PROCEDURES ITU-T Recommendation Q.1005 (Extract from the > Blue > Book) > © ITU 1988, 1993 > [7] E. Martinez, Motorola, "Annex - H (User and Service Mobility in H.323) > Proposed Architecture, > " APC-1560, ITU-T SG16 Q.11-15 Rapporteur Meeting, Berlin, Germany, 2-6 > August, > 1999. > [8] H.323 Mobility Ad Hoc Group, "Terms of Reference for H.323 Mobility", > Temporary Document > No. 34 (Berlin) 5 August 1999 > > Best Regards, > > Ed > > > > The bottom line is that a solution will look > > like this: Add some new messages in H.323 and extend the existing H.323 > > messages. I guess that AT&T's APC-1651 can satisfy almost all > requirements > > specified in Motorola's APC-1646. I hope that APC-1641 will also be able > > interwork with GSM/GPRS, ANSI-41, etc. The requirements for TIPHON > matrix > > will also be satisfied. If needed, one can also use mobile IP or other > > schemes for implementation in the IP network layer. I am personally also > > interested about the location area concept as proposed by Nokia. Of > course, > > I am waiting to see other contributions and on-going discussions.) > > > > Hope this will clarify further. > > > > Thanks, > > Radhika > > > > > -----Original Message----- > > > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > > > Sent: Monday, November 01, 1999 3:14 PM > > > To: ITU-SG16(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: RAS terminal and gateway discovery/registration messages
by Gene Schroeder 02 Nov '99

02 Nov '99

Regarding your first question, I believe that H.225 is simply saying that a physical device can register as multiple logical endpoints, and this might be most common for a GW or MCU. It certainly doesn't mean that a PSTN GW would register once for each line. However, a GW could partition its lines in some way, and register once for each grouping. By the way, while it is not stated explicitly, I believe that in practice a device that registers multiple times must use different transport addresses (IP-port combination) in each registration, to allow each logical endpoint to be individually addressed. Regarding your second question, a GW might register an alias for administrative or management purposes. Gene Schroeder elemedia -----Original Message----- From: Mohamed Mustafa <M.Mustafa(a)SDXPLC.COM> To: ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com> Date: Tuesday, November 02, 1999 6:50 AM Subject: RAS terminal and gateway discovery/registration messages 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

2 1

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

02 Nov '99

Hi, Jaakko, Ed, and All: I hope that Jaakko will get this mail while he is in his office (Thanks Jaakko - you have reminded us the time difference)! Please note the following: 1. Zone and domain are well defined in H.323. 2. We have to work for mobility solution in a way that fits very well that already exists in H.323. 3. We can invent many things if we need to solve mobility problems only when we think that those functions are NOT covered in existing H.323 standard. 4. If mobility problems can be solved using the concept of "zones" and "domains," I would assume that it would be a big mile stone so far the continuity of H.323 is concerned. That is, as Ed pointed out, H.323 mobility problem is NOT a rocket science. We have to remember that we are working in the framework of already existing H.323 standard architecture. We have to relate our solution in the context of existing H.323 standard. In other words, we CANNOT change the fundamental concept of existing H.323 standards just because we are addressing mobility. 5. I do not understand what benefits we are gaining adding more "terminologies" like "AREA {home, foreign, etc}" while the "zone" and "domain" are already well defined in H.323. My personal view is that we should FIRST try to solve H.323 mobility problems within the context of "zone" and "domain" as far as practicable. I would argue that zone and domain are good enough to serve this purpose for now. (Pl. also see AT&T's and Motorola's contributions.) 6. With respect to your comments that it appears that every GK will have HLF and VLF function, I would say that every GK will have the access to the HLF and VLF function. This capability for each GK has to be provided because of the fact that H.323 architecture is GK-centric. We do not have any choice because we are restricted by the H.323 architecture. 6.1 With respect to your question whether HLF/VLF can be distributive or centralized, having said (in item 5) that every GK should have access to HLF and VLF function, it is up to implementation whether HLF and VLF function can be centralized or distributive. Please see AT&T contributions submitted in Red Bank how we can implement these functions in both distributive and centralized environment. 6.2 In an analogy of this HLF/VLF function, I can bring another function - Directory services. For example, H.323 assumes that all the address (e.g., alias, transport, network) are kept by each GK. H.323 does not answer how the address information is maintained by each GK. People are using LDAP directory server. The question is: whether that directory service is distributive or centralized? I guess that it can be done in both ways depending on implementation. 6.3 In AT&T contribution, it is shown that it better to make VLF distributive (per GK) although HLF function can be made both distributive and centralized. Again, this is a matter of implementation. As mentioned in AT&T contribution, we also need to define a kind of backend protocol for VLF and HLF (something like similar to Siemens, Nokia and Intel's contribution - TD-39: Security Services for Backend Services and Mobility in H.323). 7. Again, I, personally, do not rule our to re-examine the benfit of "AREA" (e.g. location area [LA]) vs. "ZONE/DOMAIN" concept. May be it is in the second step. Hope that this email will clarify the things better. Best regards, Radhika > -----Original Message----- > From: jaakko.sundquist(a)NOKIA.COM [SMTP:jaakko.sundquist@NOKIA.COM] > Sent: Tuesday, November 02, 1999 3:41 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H323mobility:meeting > > 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