- sg16-avd - lists.packetizer.com

H.323 Mobility Conference Call
by Roy, Radhika R, ALARC 29 Dec '99

29 Dec '99

Hi, SG16 Members: Sub: H.323 Ad Hoc Mobility Group Conference Call Our next conference call will be held as follows: Date: January 10, 2000 Time: 8:00 AM to 10:00 AM (Pacific Standard Time (PST)) Reservation # 13928768 Number port reserved: 20 Ports Conference Call Bridge call in number: +1 (415)-904-8877 Passcode: 8813575 We appreciate IMTC for providing the ports for the conference call. We also appreciate Ed Martinez, Mototorla, for preparating the meeting agenda and edititing the H.323 Annex H document as per decision made in the conference call and discussion held in the SG16 email reflector. Agenda: 1. Call to Order & Opening Remarks 2. Attendance Registration 4. Agenda Review and Approval: MTD-01e 5. Review H.323 Mobility Ad Hoc Meeting report: MTD-02f 6. Review of contributions (Previously submitted + New contributions) 7. Discuss next conference call meetings 8. Review Assignments 9. Review Workplan 10. Open Discussion 11. Adjourn Best regards, Radhika R. Roy, AT&T H.323 Ad Hoc Mobility Group +1 732 420 1580 rrroy(a)att.com Note 1: Please provide your comments on H.323 Annex H (Editor's document MTD-3c) and Alcatel's contribution 107b via the SG16 email reflector, and the Editor will take care-of the document (H.323 Annex H) accordingly. It is expected that we'd not discuss these contributions during the conference call. Mote 2: Please review the detail of agenda provided in Table-1 of MTD-01e. Note 3: All participating companies are welcome to submit contributions in addition to previous contributions. Please send your each new contribution you planned to submit for the Jan. 10, 2000 conference to Ed Martinez at mailto:martinze@cig.mot.com Note 4: You can pick the documents in: ftp://standard.pictel.com/avc-site/Incoming/H323_Mobility/SG16_Mobility/ or http://people.itu.int/~emartine/temp/SG16-mobility/All_Confernce_Call_meetin gs/

1 0

H.323 Mobility: New MTD's
by Edgar Martinez [1] 28 Dec '99

28 Dec '99

Dear All, Two new contributions as been added for the January 10, 2000 conference meeting: MTD-15 "Changes to the Introduction Section of H.323 Annex-H" MTD-16 "Integrating Mobile IP within the H.323 Mobile System and the need for a Radio Access Interface" --- The agenda for the meeting is in MTD-01e and it will be updated as the new contributions come in. You may pick-up the documents in: ftp://standard.pictel.com/avc-site/Incoming/H323_Mobility/SG16_Mobility/ or http://people.itu.int/~emartine/temp/SG16-mobility/All_Confernce_Call_meeti… Regards, -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

H.323 Mobility: MTD-03 update
by Edgar Martinez [1] 27 Dec '99

27 Dec '99

Dear All, Nokia's MTD-06a "Functional architecture and reference points for H.323 Annex H" section has been added to MTD-03c. Mr. Radhikia Roy will send out the January 10, 2K conference call information. All participating companies are welcome to submit contributions in addition to previous contributions. Please send your each new contribution you planned to submit for the Jan. 10, 2000 conference to Ed Martinez at mailto:martinze@cig.mot.com You can pick the documents in: ftp://standard.pictel.com/avc-site/Incoming/H323_Mobility/SG16_Mobility/ or http://people.itu.int/~emartine/temp/SG16-mobility/All_Confernce_Call_meeti… Regards, -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Re: T.120
by Joerg Ott 26 Dec '99

26 Dec '99

I am searching my dim T.120 memory (it's been a while) as well as some of the documents and here's my recollection: In essence, you do not need the TSAP-ID parameters at all and can leave them empty (they are optional as far as I remember X.224/0). The TSAP-IDs constitute a way for addressing tranport layer entities and thus for multiplexing transport connections in the OSI model (similar to TCP port numbers). However, if you are using T.120, there is typically no such additional muxing required: either you use X.224/0/TPKT/TCP/IP in which cse you will make use of the well-defined T.120 port (1503, for stand-along applications) or you will negotiate a port number for data conferencing using e.g. H.245 OpenLogicalChannel procedures; in neither case you need an additional muxing point, so you can leave the TSAP-IDs empty. If don't have an IP-based network, you are likely to be running T.120 in the context of another H.32x system where, again, use may use H.242 or H.245 for assigning logical channels for T.120 data so that you do not need an additional muxing layer and can leave the TSAP-IDs empty. If you run a stand-alone T.120 system, the T.120 standards assume that you do not have other OSI applications running in parallel (which seems pretty likely :-) so that you don't need TSAP-IDs in this case, too. Leaving TSAP-IDs empty is allowed according to X.224 (11/93) para 6.5.4 (b) and encouraged following T.123 section 6 (second to last paragraph or so). Hope this helps, Joerg >Pl. help Vish - Radhika > >-----Original Message----- >From: vish(a)jlonline.com [SMTP:vish@jlonline.com] >Sent: Friday, December 24, 1999 4:50 AM >To: Roy, Radhika R, ALARC >Subject: about t120 > >Hi Mr Radhika, > In X.224 13.3.4,the TSAP-ID parameter in CR PDU header is not >defined,the x.224 does not specify which recommendation is used,where can I >find the encoding method of the TSAP-ID parameters? > Could you help me?thank you very much! > >Merry Christmas > >vish >

1 0

Comments on MTD-107a (H.323 Mobility)
by Roy, Radhika R, ALARC 24 Dec '99

24 Dec '99

Hi, Laurent and SG16 Members: In the last H.323 Ad Hoc Mobility conference call, I promised that I'd provide comments on Alcatel's MTD-107b via email. I see that Alcatel wants some modifications on the editor's document. I feel that it is the editorial comments and, it is better to address via emails. (The editor of Annex H could also deal with this directly while letting us know via email, and we can also provide our inputs if Alcatel send it to the editor.) My comments have been summarized in following categories: 1. To add/modify new texts, 2. To take out some architectural functional entities that have already been agreed upon (some of them may be only place holder for now because the actual solution decides how to deal with these entities) and 3. To add some new functional entities per Alcatel's proposal that has not been supported by the contribution providing solutions. For items like category 1, we can easily decide. First of all, we are not too concerned to add texts now because the actual solution will drive how to augment the texts better. It would be better NOT to spend too much time to augment the text. For items like category 2, let me add this: we made the decision in the last Red Bank meeting after a long discussion. These items have been put as place holders only. If we want to change now, it will put us back where we had been before the last Red Bank meeting. My question is: Can we not differ until such time we agree on a common solution? For items like category 3, I'd propose that let us see contributions in support of these functional entities before we decide why we need it unless it is obvious that we all agree that we need these entities. Let me go for each item of the contribution. We all agree, like Alcatel, that the H.323 mobility solution will be independent of the radio link layer. I also added that the solution will not only be independent of the radio link layer, but it should also be independent of layers that reside under the H.323 layer: Transport layer, Network layer, Link Layer, and MAC layer. If the proposed solution does not satisfy the above requirements, we will definitely not accept the solution. We have not proposed any solution yet. We have used some terminologies only and some of these terminologies may have "abstraction" of the lower layer. Please note that when I say an "abstraction," it only mean that an "event" may be initiated at the H.323 layer. That does not mean that the H.323 mobility layer will do the job of the lower layer if the lower layer is able to do perform this function. If the lower layer can perform this function, the H.323 layer will simply delicate that function to the lower layer generating an event. (A similar analogy is the multicasting: Application layer [T.125's MCS], Network Layer [IP multicast], and Link Layer [ATM multicast].) Section 5.1: Let editor decide whether the text proposed should be used at this stage. Even if the editor agrees, I'd request not to use "possible radio," because this is also true for all lower layers including the radio link. "Location Area Identity," "Temporary Identity," and "Paging Mechanism" cannot be taken out because of the reason explained in category 2. If we keep it as place holder, what is the harm? We can always re-visit it if we do not support these functions through the proposed solution. Regarding "Paging," I have explained that a GK may only use the LRQ message to resolve the address. However, the actual paging may be "implemented" by any functional entity in the radio link layer (pl. see a functional entity in the IMT-2000/3GPP architecture). In reality, the GK will rely on the radio link layer entity to do job for "paging." At best the GK will be a paging-aware entity to deal with the mobile wireless environment. I have no problem to agree with the text if other people agree. The text associated with the LRQ message that you have proposed as if we have decided how the LRQ message will be used by the GK. In fact, AT&T's contribution proposes a similar mechanism and I am waiting to see that people need to agree on the solution that has been proposed . In this respect, your text falls into category 3. Section 6: Why do you want to add such restrictive texts at this stage? It will create more controversy than solving the problem. I'd suggest the same is true for H.323 in general that the H.323 layer solution is independent of the lower layer. This global statement itself is good enough to take care of all text that you have proposed. More importantly, the texts suggest as if we know the solution. I feel that we have not come to this stage yet to make statements like this. For example, the call flows of the solution that we all agree will provide us all those steps that you are proposing from steps 1 through 6. I'd propose not to add the suggested text now. Architectural Model: I'd propose not to add this now because it is applicable when the interworking between the H.323 (mobile/non-mobile) and non-H.323 (mobile/non-mobile) system will be addressed. When the H.323 mobility solution will be applied in the context of IMT-2000/3GPP networking environment, we will definitely address this particular architecture. Rather, I'd propose to use the architectural reference diagram agreed upon by all members (Nokia has distributed that diagram to all SG16 members). Thanks to you for providing more insights how the H.323 mobility architecture should be independent of the lower layers. Best regards, Radhika R. Roy, AT&T +1 732 420 1580 rrroy(a)att.com

1 0

H.323 Mobility Works: SG16 Reflector vs. Conf Call
by Roy, Radhika R, ALARC 24 Dec '99

24 Dec '99

Hi, SG16 Members: I like to appeal to you all that we have only two conference calls left for the H.323 Ad Hoc Mobility group. The time is very precious to advance our work. The editor of H.323 Annex H needs to produce a meaning document so that the Q.13 Rapporteur can take this as a contribution to the SG16 meeting for determination in the upcoming Feb'00 SG16 meeting. Since a Rapporteur is from the US, the document needs to be submitted to US State Department on January 21st in the SG-D meeting. How can we expedite our progress? I have some thoughts that may allow us to make a quick progress. We like to use two media for communications: 1. SG16 email reflector and 2. Ad Hoc Mobility Group Conference call. How do we divide our works in these two media of communications? I propose that some items can better be addressed via emails. For example, we spent a lot of time in the last conference call whether we should take one document. If we do, how the document will be handled by the editor and/or Rapporteur. This sort of discussions can easily be addressed via the email. Moreover, we have done this in many cases. For example, H.225.0 Annex G, H.248, and many other meetings. An editor or Rapporteur knows how to deal with this situation. A editor will produce a document based on consensus made in the meetings on behalf of the Rapporteur, and a Rapporteur will decide whether the document can be taken as Rapporteur's contribution in the SG meeting. Of course, the document will contain two parts: 1. The part that has been agreed before the conference call and 2. The other will include as follows: A. What has been accepted to MODIFY from the original agreed version, if any and B. What has been added as NEW to the proposed documents. If necessary, the editor may also contact the Rapporteur to have clarifications further. In another example, suppose we have a document agreed upon in the last Red Bank SG16 meeting. Someone wants to have some comments to modify that document that is primarily from the editorial point of view. This work can be done via email as well. In this context, I will refer to Alcatel's contribution - MTD 107b. It wants some modifications and additions of the editor's document. We can handle this contribution via email as well (I also plan to send my comments via so that we do not need to spend time to address this during the conference call). The next question is: What do we want to discuss during the conference call? A simple answer is to address new areas that advance our understanding to provide solution related to the H.323 mobility. For example, one of the Nokia's contribution addresses the reference architecture of H.323 including mobility. This has been a new area towards solutions and, we have made progress in this area as well. My appeal to all members of the SG16 members is: Let us address contributions that advances the solution of the H.323 mobility problems in the upcoming conference calls. I have provided a contribution showing that there are three phases in this area: 1. Extension of H.323 for supporting mobility, 2. H.323 backend services related to mobility, and 3. Interworking between H.323 system (mobile/non-mobile) and Non-H.323 system (mobile/Non-mobile). Let us move on! Best regards, Radhika R. Roy, AT&T H.323 Ad Hoc Mobility Group +1 732 420 1580 rrroy(a)att.com

1 0

Re: H.323 Annex I/Clarifications
by Roy, Radhika R, ALARC 24 Dec '99

24 Dec '99

Hi, Chris: I may have misunderstood your questions. I have provided the reply assuming that it is related to the H.323 terminal, user, and service mobility. It is related to H.323 Annex H that deals with mobility in the H.323 layer. I think that your questions have been related to Annex I where the lower layers (below H.323 layer) are taken care of when mobile users move from place to place. If it is so, my reply does NOT answer your questions. If it is so, I am extremely sorry. With respect to Annex I, I have to refer to my original clarifications what needs to be done in the context of H.323 Annex I. I mailed my notes to the SG16 reflector sometime ago. Email discussions were held and more actions will follow on this item. In the light of Annex I, I do not have clear answer for your questions. We have not yet finalized what it will look like. I made some suggestions earlier. We like to get your inputs how we can shape H.323 Annex I. So far, Annex I have mentioned what needs to be done to improve the performance of the radio link layer. We need to go further how the H.323 mobility solution can be implemented over the lower layer including the IP layer. The IP layer may contain mobile IP, cellular IP, and/or any other services. My personal wish is that we would move to this area when finish the extension of H.323 for mobility. For example, I'd like to addess how H.323 mobile protocol can be used to satisfy the needs of the INM-2000/3GPP's wireless architecture in the context of the mobile H.323 terminal (MT), base station (BS), base station switching center (BSC), mobile switching center (MSC), and IP network. I believe that BSC can dela with link/MAC multiplexing layer while MSC will be an IP router with the knowledge of the IP layer. Wireless cells will be between the MT and BS. Now it depends where one puts the GK (and defines zones/domains) and how it communicates with the H.323 MT. It will then automatically bring all related issues: IP addresses, domains, and others. I am also thinking whether we will make this as a part of H.323 Annex I or not. I am fully confident that our H.323 mobility architecture (please also see AT&T's and Motorola's contributions) will be cosistent to complement the architecture defined by IMT-2000/3GPP. Now I may come to your questions: How do we related the zone (or GK) in the context of the lower layer? Is that relate to the IP addresses or IP domains only as you have mentioned? I will assume that the lower layer may contain the cell (pico, micro, macro) and/or wireless LANs (with or without cell concept) in wireless environments. In wire-line networks, the zone may consist of the usual network layer as H.323 system envisions. So, a zone may contain both wire-line and wireless networks as well. I guess that we are not in a position to answer your questions yet. Is it possible to suggest some framework how we can drive the work in H.323 Annex I if you do not find answers of your questions provided above? Best regards, Radhika > -----Original Message----- > From: Roy, Radhika R, ALARC > Sent: Friday, December 24, 1999 10:06 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Annex I > > Hi, Chris: > > We have an H.323 Ad Hoc Mobility Group to perform this work. We have been > discussing this for almost a year why we need H.323 mobility. All > wire-line > and wireless vendors and many service providers are also a part of it. All > of them brought contributions to extend the H.323 protocol for mobility. > > I am very much surprised to see your comments. I guess that all people who > are working to address this issue will also feel the same. > > I do not want to confuse anyone by making a simple statement that will > make > you feel why we need extensions in H.323 for mobility. So many papers have > been published by many researchers across the world for extension of H.323 > for mobility. One of the excellent papers had been published in INFOCOM'99 > referred in AT&T's contribution as well. I would suggest to kindly read > this > paper first before making any comments like "misconception" or others, > etc. > May be I have not been able to understand your points. I'd would also > suggest to attend the discussion of the Ad Hoc mobility conf. calls. > > Finally, I'd only suggest to examine how a GK will account the resources > when an H.323 mobile moves from one place to another. The resources of one > place have to be de-allocated in one place, while the resources in another > place are to be allocated. When people think about resources, these > resources are in terms of the H.323 layer. It does not matter how you > think > about the zone whether it is linked to physical locations, IP domain, or > something else. > > May be you might have a better solution to deal the mobility. May we > suggest > to bring contributions to solve the H.323 mobility problems that you might > think to be appropriate. > > Best regards, > Radhika > > > -----Original Message----- > > From: Chris Wayman Purvis [SMTP:cwp@isdn-comms.co.uk] > > Sent: Friday, December 24, 1999 8:27 AM > > To: Roy, Radhika R, ALARC; Mailing list for parties associated with > > ITU-T Study Group 16 > > Subject: Re: H.323 Annex I > > > > Radhika, All, > > > > I've finally managed to read that contribution, and it seems to me that > > the > > requirement for a mobile H.323 protocol arises entirely out of the > > misconception that gatekeeper zones are necessarily linked to physical > > locations or IP domains. Remove that assumption and I am still > completely > > baffled as to why any protocol above the network layer is required. > > > > I will look at the MTD contributions when I find time (which is > > depressingly > > short for this sort of activity at the moment), but would be glad of > > anybody's > > simple explanation of why H.323 mobility is required without the above > > assumptions on gatekeeper zones. > > > > Regards, > > Chris > > > > "Roy, Radhika R, ALARC" wrote: > > > > > > Hi, Chris: > > > > > > I guess that you have missed all discussions and contributions related > > H.323 > > > mobility (SG16 meeting in May'99, Berlin Aug'99, and Red Bank NJ > > Oct'99). > > > > > > H.323 is in application layer. > > > > > > IP/IPX is in the network layer. > > > > > > Radio/ATM is in the link layer. > > > > > > Mobility may have an impact in all layers. If the link layer mobility > is > > > transparent to the network layer, nothing should be done in the > network > > > layer. Similar is the case for others. > > > > > > When the mobility has an impact in the H.323 layer resources, we need > to > > > take into account in the H.323 layer. > > > > > > How does the H.323 mobility work? > > > > > > Please see AT&T contributions - APC-1651 provided in the Red Bank > > meeting. > > > The 70-page contribution has proposed a complete solution for H.323 > > > mobility. There are contributions as well. > > > > > > Hope this will clarify your questions. > > > > > > Best regards, > > > Radhika > > > > > > > -----Original Message----- > > > > From: Chris Wayman Purvis [SMTP:cwp@ISDN-COMMS.CO.UK] > > > > Sent: Wednesday, November 24, 1999 4:31 AM > > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > > Subject: Re: H.323 Annex I > > > > > > > > All, > > > > > > > > Might I be permitted to attempt to summarise Mr Roy's mail while > > asking my > > > > own > > > > question (my apologies to Mr Roy if I've misunderstood his point!)? > > > > I'm not an expert on Mobile IP. However, I don't understand why > there > > is > > > > anything at all involved in H.323 mobility beyond making the > statement > > "In > > > > IP > > > > networks, mobility issues are handled by using Mobile IP", and > > expecting > > > > users > > > > of other transports (IPX, native ATM etc) to make their own > > arrangements. > > > > So, the question: Why is the effort on mobility required? > > > > Obviously if this question is answered in contributions that I've > > missed, > > > > I'll > > > > be happy with a reference rather than a full explanation on the > list! > > > > > > > > Regards, > > > > Chris > > > > -- > > > > Dr Chris Purvis -- Development Manager > > > > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > > > > Winkfield Row, Berkshire. RG42 6LY ENGLAND > > > > Phone: +44 1344 899 007 > > > > Fax: +44 1344 899 001 > > > > -- > > Dr Chris Purvis -- Development Manager > > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > > Winkfield Row, Berkshire. RG42 6LY ENGLAND > > Phone: +44 1344 899 007 > > Fax: +44 1344 899 001

1 0

T.120
by Roy, Radhika R, ALARC 24 Dec '99

24 Dec '99

Pl. help Vish - Radhika -----Original Message----- From: vish(a)jlonline.com [SMTP:vish@jlonline.com] Sent: Friday, December 24, 1999 4:50 AM To: Roy, Radhika R, ALARC Subject: about t120 Hi Mr Radhika, In X.224 13.3.4,the TSAP-ID parameter in CR PDU header is not defined,the x.224 does not specify which recommendation is used,where can I find the encoding method of the TSAP-ID parameters? Could you help me?thank you very much! Merry Christmas vish

1 0

Re: H.323 Annex I
by Roy, Radhika R, ALARC 24 Dec '99

24 Dec '99

Hi, Chris: We have an H.323 Ad Hoc Mobility Group to perform this work. We have been discussing this for almost a year why we need H.323 mobility. All wire-line and wireless vendors and many service providers are also a part of it. All of them brought contributions to extend the H.323 protocol for mobility. I am very much surprised to see your comments. I guess that all people who are working to address this issue will also feel the same. I do not want to confuse anyone by making a simple statement that will make you feel why we need extensions in H.323 for mobility. So many papers have been published by many researchers across the world for extension of H.323 for mobility. One of the excellent papers had been published in INFOCOM'99 referred in AT&T's contribution as well. I would suggest to kindly read this paper first before making any comments like "misconception" or others, etc. May be I have not been able to understand your points. I'd would also suggest to attend the discussion of the Ad Hoc mobility conf. calls. Finally, I'd only suggest to examine how a GK will account the resources when an H.323 mobile moves from one place to another. The resources of one place have to be de-allocated in one place, while the resources in another place are to be allocated. When people think about resources, these resources are in terms of the H.323 layer. It does not matter how you think about the zone whether it is linked to physical locations, IP domain, or something else. May be you might have a better solution to deal the mobility. May we suggest to bring contributions to solve the H.323 mobility problems that you might think to be appropriate. Best regards, Radhika > -----Original Message----- > From: Chris Wayman Purvis [SMTP:cwp@isdn-comms.co.uk] > Sent: Friday, December 24, 1999 8:27 AM > To: Roy, Radhika R, ALARC; Mailing list for parties associated with > ITU-T Study Group 16 > Subject: Re: H.323 Annex I > > Radhika, All, > > I've finally managed to read that contribution, and it seems to me that > the > requirement for a mobile H.323 protocol arises entirely out of the > misconception that gatekeeper zones are necessarily linked to physical > locations or IP domains. Remove that assumption and I am still completely > baffled as to why any protocol above the network layer is required. > > I will look at the MTD contributions when I find time (which is > depressingly > short for this sort of activity at the moment), but would be glad of > anybody's > simple explanation of why H.323 mobility is required without the above > assumptions on gatekeeper zones. > > Regards, > Chris > > "Roy, Radhika R, ALARC" wrote: > > > > Hi, Chris: > > > > I guess that you have missed all discussions and contributions related > H.323 > > mobility (SG16 meeting in May'99, Berlin Aug'99, and Red Bank NJ > Oct'99). > > > > H.323 is in application layer. > > > > IP/IPX is in the network layer. > > > > Radio/ATM is in the link layer. > > > > Mobility may have an impact in all layers. If the link layer mobility is > > transparent to the network layer, nothing should be done in the network > > layer. Similar is the case for others. > > > > When the mobility has an impact in the H.323 layer resources, we need to > > take into account in the H.323 layer. > > > > How does the H.323 mobility work? > > > > Please see AT&T contributions - APC-1651 provided in the Red Bank > meeting. > > The 70-page contribution has proposed a complete solution for H.323 > > mobility. There are contributions as well. > > > > Hope this will clarify your questions. > > > > Best regards, > > Radhika > > > > > -----Original Message----- > > > From: Chris Wayman Purvis [SMTP:cwp@ISDN-COMMS.CO.UK] > > > Sent: Wednesday, November 24, 1999 4:31 AM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: H.323 Annex I > > > > > > All, > > > > > > Might I be permitted to attempt to summarise Mr Roy's mail while > asking my > > > own > > > question (my apologies to Mr Roy if I've misunderstood his point!)? > > > I'm not an expert on Mobile IP. However, I don't understand why there > is > > > anything at all involved in H.323 mobility beyond making the statement > "In > > > IP > > > networks, mobility issues are handled by using Mobile IP", and > expecting > > > users > > > of other transports (IPX, native ATM etc) to make their own > arrangements. > > > So, the question: Why is the effort on mobility required? > > > Obviously if this question is answered in contributions that I've > missed, > > > I'll > > > be happy with a reference rather than a full explanation on the list! > > > > > > Regards, > > > Chris > > > -- > > > Dr Chris Purvis -- Development Manager > > > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > > > Winkfield Row, Berkshire. RG42 6LY ENGLAND > > > Phone: +44 1344 899 007 > > > Fax: +44 1344 899 001 > > -- > Dr Chris Purvis -- Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > Winkfield Row, Berkshire. RG42 6LY ENGLAND > Phone: +44 1344 899 007 > Fax: +44 1344 899 001

1 0

Re: H.323 Annex I
by Roy, Radhika R, ALARC 24 Dec '99

24 Dec '99

Hi, Chris: I guess that you have missed all discussions and contributions related H.323 mobility (SG16 meeting in May'99, Berlin Aug'99, and Red Bank NJ Oct'99). H.323 is in application layer. IP/IPX is in the network layer. Radio/ATM is in the link layer. Mobility may have an impact in all layers. If the link layer mobility is transparent to the network layer, nothing should be done in the network layer. Similar is the case for others. When the mobility has an impact in the H.323 layer resources, we need to take into account in the H.323 layer. How does the H.323 mobility work? Please see AT&T contributions - APC-1651 provided in the Red Bank meeting. The 70-page contribution has proposed a complete solution for H.323 mobility. There are contributions as well. Hope this will clarify your questions. Best regards, Radhika > -----Original Message----- > From: Chris Wayman Purvis [SMTP:cwp@ISDN-COMMS.CO.UK] > Sent: Wednesday, November 24, 1999 4:31 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Annex I > > All, > > Might I be permitted to attempt to summarise Mr Roy's mail while asking my > own > question (my apologies to Mr Roy if I've misunderstood his point!)? > I'm not an expert on Mobile IP. However, I don't understand why there is > anything at all involved in H.323 mobility beyond making the statement "In > IP > networks, mobility issues are handled by using Mobile IP", and expecting > users > of other transports (IPX, native ATM etc) to make their own arrangements. > So, the question: Why is the effort on mobility required? > Obviously if this question is answered in contributions that I've missed, > I'll > be happy with a reference rather than a full explanation on the list! > > Regards, > Chris > -- > Dr Chris Purvis -- Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > Winkfield Row, Berkshire. RG42 6LY ENGLAND > Phone: +44 1344 899 007 > Fax: +44 1344 899 001

2 1