December 1999 - sg16-avd - lists.packetizer.com

Re: Closing Q.931 TCP connection..
by Boaz Michaely 04 Jan '00

04 Jan '00

Happy new Y2K ! Your consistent argueing against closing the Q.931 sig. channel, is appreciable, and I share your concern for many service scenarios. (I guess we'll talk more about this in February, which is why the ITU-SG16 list is copied) However, in the following scenario, it seems highly desireable to be able to close the sig. channel: (if this has been described before, please forgive my ignorance) Think of a scaleable IVR server farm which is implemented using multiple MG's, each capable of H.245, RTP/RTCP, and a very simple control protocol (H.248 ?). A single GRC GK, which is also an AnnexG Border Element is used as the single entry into this port-dense system. This GK may be addressed using LRQ from another domain (e.g. that of an ITSP). In addition, it publishes its own address using "SendSetup" type of addressing in the AnnexG templates that it publishes. Once a SETUP message comes in, the GK replies with an H.245 address of the applicable MG. Note that the GK has to be the point of call for SETUP, since it may use the information in the SETUP message for finding the applicable MG (i.e. using CLI and/or DNIS), as well as it performs load balancing on the MGs. Now the audio session is connected and the call takes place, while the MG handles the DTMFs and all the logic. Let's assume that there are no changes in the call routing from this point on (which is typically the case in, say, automatic banking systems etc.) GK intervention is not required any more until the call is done. It would be nice if the GK could get rid of the dangling Q.931 TCP connection, while the RTP call continues until it is disconnected by the human caller. If I understand correctly, this is a perfectly legitimate behaviour using the existing standard. (I trust this is true for all versions ?) Assuming this scenario is valid (have I overlooked anything ?) can we find a way to continue to support it while reducing the mess for other services ? Reinitiating the sig. channel in some way may not be a bad idea ? Finally, I must admit I do not understand Chris's comment about making sure the other party is not a GW. Why is that so? Boaz Michaely VocalTec Communications Ltd. +972 (9) 970-7869 email: boaz(a)vocaltec.com http://people.itu.int/~michaely "Paul E. Jones" <paul.jones(a)ties.itu.int> on 02/01/2000 12:04:50 AM Please respond to "Paul E. Jones" <paul.jones(a)ties.itu.int> To: "Chris Wayman Purvis" <cwp(a)isdn-comms.co.uk>, "Satya T" <satyat(a)MIEL.MOT.COM> cc: h323implementors(a)imtc.org (bcc: Boaz Michaely) Subject: Re: Closing Q.931 TCP connection.. Folks, I would like to second Chris' comments. It really is a very bad idea to close the call signaling channel. This might have been important prior to H.245 tunneling and Fast Connect, but in my opinion, this just isn't necessary any longer. My chief complaint is that once the channel is closed, there's no guarantee one can re-open it. This is especially true on the receiving end-- the called endpoint may not know the call signaling address to which to try to re-establish a socket connection, and it cannot assume 1720. Reverse call setup may not even be possible, given some network arrangements (including the usage of devices to traverse firewalls). There are several reasons to keep the channel open, too. This gives the endpoint the ability to perform supplementary services. If the channel is closed, the endpoints lose that functionality-- unless we can guarantee a way of re-establishing that channel. So, my advise to all implementers: never, never close the call signaling channel. Paul ----- Original Message ----- From: "Chris Wayman Purvis" <cwp(a)isdn-comms.co.uk> To: "Satya T" <satyat(a)MIEL.MOT.COM> Cc: <h323implementors(a)imtc.org> Sent: Tuesday, December 21, 1999 8:52 AM Subject: Re: Closing Q.931 TCP connection.. > Satya, > > This is the subject of much current discussion, but the group within ITU SG16 > discussing robustness. Currently: > ReleaseComplete closes the call. > Closing the Q.931 TCP connection without ReleaseComplete does not close the > call if there is a separate active H.245 connection. > However, consideration is being given to the possibility of changing this rule, > if no implementations can be found that deliberately close the Q.931 TCP > connection during a call. > > I strongly advise against deliberately closing the Q.931 TCP connection without > terminating the call, but as things currently stand > a) you are permitted do so as long as there is no gateway involved in the call > (which you may or may not be able to know!!!) > b) you should cope with other parties in the call doing this (unless you or > they are a gateway!!!!!). > > Regards, > Chris > > Satya T wrote: > > > > Hi all, > > There's a gatekeeper routed call, > > and if the GK closes down the Q931 TCP connection, > > does it mean the call is closed? Consider the following cases : > > > > 1. When GK sends RELEASE complete before breaking > > down the TCP > > 2. When GK does NOT send RELEASE complete before > > breaking down TCP > > > > H.245 connection is established & ON directly between the EPs in > > both cases when the Q931 TCP is broken down. > > > > Is it considered closed in both the scenarios? or only in the former? > > > > regards > > Satya T > > > > -------------------------------------------------------------------------- > > -- > 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 > -------------------------------------------------------------------------- --------------------------------------------------------------------------- ------------------------------ Please send E-mail to contact(a)imtc.org <mailto:contact@imtc.org> to subscribe or unsubscribe from this list ------------------------------ ---------------------------------------------------------------------------

3 2

Re: FW: Some H.225 Annex G questions (LONG)
by Michael Fortinsky 02 Jan '00

02 Jan '00

Hi Ellen, I am leading the Annex G implementation in VocalTec - working closely with Boaz Michaely who is the editor of H.225 Annex G. We think that your questions may be interesting to the mailing lists, so we are posting our answers. This will hopefully encourage further discussions - we need to decide whether we need a new version of AnnexG for the upcoming SG16 meeting in February. > ---------- > From: SRD Zhang Xiao > Sent: Tuesday, December 14, 1999 11:24 AM > To: 'Boaz_Michaely(a)vocaltec.com' > Subject: Some questions > > Hi Boaz, > > 1. Cache mechanism. 1.7.1.2 Receiving Descriptors says using > DescriptorUpdate message to update the descriptor. 1.7.1.3 Receiving > Response to Specific Queries says template can also be cached when using > AccessRequest. The problem is: AcessRequest only caches partial > descriptor, I mean some templates. When one template is updated, I can't > assign the template with its desciptor, I don't know who's its desciptor, > So I can't send DescriptorUpdate message to other BEs who cached this > template. What can I do for this case? > There are two kinds of templates that can be maintained as part of a descriptor: (a) those that contain sendAccessRequest (b) those that contain sendSetup Let's use Section 1.9.1 (Figures 9 and 10) as an example that illustrates how we understand the situation. (The same applies to the clearing house example in 1.9.2). In the example, BE(A) sends an accessRequest to BE(B) and receives a template in the accessConfirmation. Presumably, this will be a type-(b) template (one that contains sendSetup). There is no overlap between this template and the templates contained in the list of descriptors (if there was, BE(A) would not have sent the accessRequest in the first place). This response may be cached - in the example it is. It is correct that there is no mechanism to update this. It is the responsibility of the border element that issued the template to ensure that the template remains valid for the duration of the ttl. > 2. 1.7.1.3 Receiving Response to Specific Queries describe a BE coupled > with the firewall. When an AccessRequest arrives, it shall respond two > templates: one with a short lifetime owning Setup type, others with > AccessRequest type for other AliasAddress. Could you give me a bit more > detailed explanation about that? > This is a good question - maybe somebody (Glen?) can enlighten us? > 3. I found something conflict in 1.9.2.1 Exchange of Zone Information. In > Figure 14, why shall BED request BECH d1 and d2, BEE request BECH d3 > and d4 ? I consider BED's capability is d1 and d2, BEE 's capability > is d3 and d4, they're staticlly configured when initializing. Why need > they send DescripotrRequest? > You're right - there seem to be a few mistakes in the table and the flow diagram in section 1.9.2. We would recommend (to the editor :-) to introduce the following corrections: In the Table: - the template definition for Administrative Domain E should read "d3" and "d4" In Figure 14: - the DescriptorRequests from BE(D) should be for "d3" and "d4" - the DescriptorRequests from BE(E) should be for "d1" and "d2" In addition, the following editorial change should be made to Figures 8 and 14: - change "DescriptorIDReqConf" to "descriptorIDConfirmation" - change "DescriptorRequestConfirmation" to "descriptorConfirmation" > 4. I aslo found some conflicts in 1.9.2.2 Placing a Call.In Figure > 15,16,and 17, after initialization, BECH owns all Descriptors information, > when resolving a telephone number, an AccessRequest to BECH can finish > this procedure.Why need BECH send AccessRequest to BED,or BEE send > AccessRequest to BED? > According to descriptor "d1", an accessRequest must be sent to BE(D) - regardless of who knows about "d1". Actually, in this example we think there is a different mistake. In this case, BE(E) would send an accessRequest directly to BE(D) and bypass the clearing house. We think the intent of the example was to show how the clearing house can control call setup (e.g., for billing purposes). To correct this, the clearing house would need to publish its own set of descriptors (which indicate that sendAccessRequest should always go back to itself). ===> Unless anyone disagrees, we will recommend that the editor change this too. > 5. About AccessRequest definition. is AccessRequest->SourceInfo caller info > or access requester info? Could you give me some explanation? This is a good question. Annex G left this unspecified and clearly service providers will need to decide if they want to use this information and how. For example, the iNow! interdomain profile states that the SourceInfo should include the domainInfo and endpointType (presumably of the calling party). This works well in a distributed or full mesh configuration (section 1.5.2 of Annex G), but in the clearing house model, it is not specified what the clearing house should fill in for these fields in the accessRequest that it sends. The iNow! interdomain profile may be found at: ftp://ftp.imtc-files.org/imtc-site/inow-ag/iNOW_Interdomain_Profile_V2.1-AG -Approved.doc > 6. Why need Annex G? RAS is good, why introduce Annex G? RAS was not designed with interdomain communications in mind. For example, there is no discussion of how dialing plans or billing-related information can be transferred between domains. Annex G fills in many of these holes (for example, via AddressTemplates and UsageIndications). We hope this helps. Michael Fortinsky mike(a)vocaltec.com Boaz Michaely boaz(a)vocaltec.com

2 1

Information Required about H.246
by Deepak Wadhwa 30 Dec '99

30 Dec '99

Can somebody please point me to the latest recommendation or contribution related to H.323 - ISUP interworking. Thanks, -- +----------------------------------+-----------------------------------+ |Deepak Wadhwa | TRILLIUM DIGITAL SYSTEMS, INC. | |email: deepak(a)trillium.com | 12100 Wilshire Blvd.,Suite 1800,| |tel: +1(310)-584-0112(home) | LA, CA 90025-7118. | | +1(310)-442-9222(work) | | |fax: +1(310)-442-1162(work) | http://www.trillium.com | +----------------------------------+-----------------------------------+

2 1

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

30 Dec '99

Hi, SG16 Members: I like to add a minor correction of my earlier email (copy enclosed). Thanks to Boaz Michaely for pointing me this. Per my email, I mentioned about the US SG-D meeting. This meeting is internal to the US for review any contributions that might be going from the US to the Sg16 meeting. However, a Rapporteur represents the ITU position and their contributions are submitted to the ITU. However, any country can also review those contributions to formulate their own internal views if those documents are available. Please read my US SG-D meeting in this context. Best Regards, Radhika R. Roy > -----Original Message----- > From: Roy, Radhika R, ALARC > Sent: Friday, December 24, 1999 1:50 PM > To: 'Mailing list for parties associated with ITU-T Study Group 16' > Subject: H.323 Mobility Works: SG16 Reflector vs. Conf Call > > 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

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