- sg16-avd - lists.packetizer.com

Test
by Theresa Mackenhauer 04 Jan '00

04 Jan '00

Test

1 0

[Robustness] minutes and next Telecon -- January 6 at 11AM EST US A
by Maureen Stillman 03 Jan '00

03 Jan '00

The minutes from the last robustness telecon held on December 14, 1999 are attached. The next conference call for robustness, arranged by Nokia, is scheduled for Thursday, January 6th at 11:00 AM EST USA. Agenda for the teleconference: Discuss draft submission to SG-16 Geneva meeting written by Radvision incorporating discussions from the last several robustness teleconferences. The goal is to submit this input to the meeting by the deadline of January 27, 2000. Radvision will post this draft to the mailing list prior to the teleconference for our review. Conference call number: 613-688-2795 The access code 5767#. You must enter the pound sign after the access code. Please send e-mail to maureen.stillman(a)nokia.com if you plan to attend. Hope to talk with you on Thursday. Minutes of H.323 Robustness Teleconference - December 14, 1999 Prepared by Maureen Stillman, Nokia Next Teleconference: Will be held on Thursday, January 6 at 11AM EST USA. Nokia will host this again. Please send e-mail to maureen.stillman(a)nokia.com if you wish to join in. Agenda for the next teleconference: Discuss draft submission to SG-16 Geneva meeting written by Radvision incorporating discussions from the last several robustness teleconferences. The goal is to submit this input to the meeting by the deadline of January 27, 2000. Action items from this teleconference: 1. Post meeting minutes to mailing list 2. Radvision to post draft submission to the mailing list before the Jan. 6 teleconference. 3. Everyone needs read the draft submission so we can discuss it during the teleconference. Attending the 11/16 teleconference: Rich Bowen rkbowen(a)cisco.com Paul Jones Paul.jones(a)ties.itu.int Orit Levin orit(a)radvision.com Kumar, Vineet vineet.kumar(a)intel.com Robert Callaghan Robert.Callaghan(a)ICN.siemens.com Maureen Stillman maureen.stillman(a)nokia.com Jorg Ott jo(a)tzi.uni-bremen.de Michael Fortinsky Michael_Fortinsky(a)vocaltec.com Sasha Ruditsky at Radvision (please send me your e-mail address) Unable to attend, but submitted scenarios: Radhika Roy rrroy(a)att.com Submissions for the teleconference: Radvision AT&T Nokia, Security and Robustness Summary of Teleconference: Given that submissions for the SG-16 Geneva meeting are due on January 27, we decided to discuss short to medium term robustness solutions. At the Geneva meeting, we have the potential to add robustness solutions to the draft of H.323 version 4. Radvision agreed to draft a submission for comment and debate at our next teleconference scheduled for January 6. The intent is to submit a technical contribution on robustness by the January 27th deadline. Discussion: Scenario: We are focusing on the following scenario: Corporate Environment - 1 gatekeeper; all calls are gatekeeper routed; H.225 up and running; might be using fastconnect; two endpoints have a call in progress Gatekeeper goes down or fails - the two endpoints lose the call signaling channel We agree that such a call needs to be continued - how this should be done is a problem that needs to be solved. We have a redundant GK that we want to use. How can we recover the call from this scenario? If no component has any robustness mechanisms then the TCP connection should be terminated by the endpoint. Otherwise, if robustness mechanism is in place, we should base the solution on that fact that both endpoints as well as the gatekeeper are robust aware. The redundant gatekeeper starts the robustness procedure and will open new TCP ports. The endpoints will understand this based on the CALL ID value (see discussion on CALL ID below). On keeping the state of the call: We need to transmit the call state between the GK and endpoint. Should we keep all messages or some messages? Last transaction? H.450 is designed to be "fail safe" meaning that in the event of a problem, the service can fail but the call will not fail. We can't assume that we can restore the "exact state" of the call because unfortunately this is not deterministic. We should ignore the case in which someone is pushing keypad buttons, by assuming that they will just push the buttons again if they don't get the right response. We need a set of deterministic rules to determine what happens when there is a failure so we can reconstruct the call state. There will be a proposed procedure to do this. "Special protocols" such as H.450 must be "fail safe". H.225 has a status message. What happens with H.245 that doesn't have the equivalent of a status message? The standard currently states that if H.245 is lost then the call is terminated. We need to define extensions to H.245 to support ruggedness. Discussion of Call IDs: We need to determine what ID/IDs will be used for recovered calls. For example, will the conference ID or the call ID remain the same or will it be different for the recovered call? Will I get billed twice for the same call? There are potentially two different cases: 1. Maintain the same call by using the same Call ID 2. Clear resources and have a new call with a new Call ID Robert Callahan reported that there is currently an ad hoc group in Study Group 16, which is discussing additional IDs associated with a call for various purposes including billing. They are talking about adding IDs for billing supplementary services, for example. The conclusion was that we should wait for this group to propose their solution before deciding how CALL IDs for robustness should fit in. Pros and Cons of Application Layer Restart: Suppose we decide to design a restart mechanism that involves the endpoints. Application layer restart is OK for the endpoint that knows that there has been a failure, but what about an endpoint that doesn't know? How does it distinguish between a new call coming in and a call that is being restarted? What if both endpoints determine that there is a problem and both decide to restart the call? **** end of minutes **************** -- maureen Maureen Stillman Member of Scientific Staff Voice: (607)273-0724 x62 Nokia IP Telephony Fax: (607)275-3610 127 W. State Street Mobile: (607)227-2933 Ithaca, NY 14850 e-mail: maureen.stillman(a)nokia.com www.nokia.com

1 0

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

01 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 29 Dec '99

29 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

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

Geneva Meeting
by Bilalis Zacharias 22 Dec '99

22 Dec '99

Dear Mr. Okubo, concerning the contributions, it is not yet clear to me to who I have to mail them. Could you tell me? By the way do you know where I can find Annex A to TSB Circular 182 of 7 April 1999 (contributions submission)? Thanks in advance Best Regards / Mit freundlichen Grüssen Zacharias Bilalis SIEMENS ICN WN CS EC D12 > Schertlinstr. 8 > D-81359 Muenchen > Germany > Tel: + 49 89 722 28391 Fax: + 49 89 722 61243 Mail to: zacharias.bilalis(a)icn.siemens.de

2 1

New H.323 Implementors Mailing List
by Chris Wayman Purvis 22 Dec '99

22 Dec '99

All, I would like to invite all interested parties to join a new mailing list to discuss H.323 implementation issues. Jeff Pulver has kindly agreed to host the new list at pulver.com. To join, send a mail to <majordomo(a)pulver.com> with the subject blank and the text "subscribe h323implementors" in the body of the mail. You should then receive instructions on usage of the list. The new list exists purely to discuss H.323 implementation issues, much as the IMTC's H.323 implementors list has in the past, including implementation discussion on H.225.0, H.245, H.235, H.450.x and all other standards in the H.323 "raft". The reason for the existence of the new list is the IMTC's move to making their mailing lists "closed" (ie open only to members of the IMTC, excluding a number of people with a lot of H.323 knowledge). Note that the implementors list has distinct aims and objectives from this list. The implementors list offers help to people implementing current standards, while this list looks towards future development of the standards. Issues are sometimes raised on the implementors list, however, that lead eventually to improvements in the standards, normally via this list and the implementor's guide. I look forward to seeing you on the new 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

1 0

Hot Topic - Call for Paper
by Jorg Nonnenmacher 17 Dec '99

17 Dec '99

------- Blind-Carbon-Copy X-Mailer: exmh version 2.0.2 2/24/98 To: nonnen(a)research.bell-labs.com Subject: Hot Topic - Call for Paper Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Dec 1999 15:31:10 -0500 From: Jorg Nonnenmacher <nonnen(a)starling.research.bell-labs.com> CALL FOR PAPERS: Special Issue of Computer Communications on Integrating Multicast into the Internet --------------------------------------- CFP URL: http://www.cs.ucsb.edu/~almeroth/COMCOM:cfp.html Journal URL: http://www.elsevier.com/inca/publications/store/5/2/5/4/4/0/ TOPICS: The amount of bandwidth available in the Internet is increasing dramatically, both in the backbone networks, as well as in the last mile (broadband access). One consequence is that the delivery of high-quality multimedia data will become feasible, and multimedia data, including audio and video, will become the dominant traffic. As more users gain access to broadband services, new applications and services will become possible. The result will be a growing demand for large-scale multimedia applications and services. Multicasting as a pure networking solution to the transport of media is recognized as offering economies-of-scale for large-scale applications. Multicast is also believed to enable applications which provide service to thousands, even millions of customers. While there has been significant research work on multicast, efforts to successfully deploy a production service have lagged. Reasons range from frequently changing protocols, management and engineering problems, legacy hardware limitations, traffic conflicts with unicast, etc.. This special issue focuses on research issues dealing with the challenges of deploying multicast in the network. Specific topics include, but are not limited to: * Multicast Congestion Control * Multicast Overlay Networks * Next-Generation Multicast Routing Algorithms * Multicast Media Transport * Security for Multicast-Based Services * Multicast Traffic Engineering and Management * Multicast Pricing and Quality of Service GUEST EDITORS: Kevin Almeroth Jorg Nonnenmacher Department of Computer Science Network Research Dept, Lucent Technologies University of California 600-700 Mountain Avenue Santa Barbara, CA 93106-5110 Murray Hill, NJ 07974-0636 Phone: +1(805) 893-2777 Phone: +1(908) 582-1707 Fax: +1(805) 893-8553 Fax: +1(908) 582-6632 Email: almeroth(a)cs.ucsb.edu Email: nonnen(a)research.bell-labs.com IMPORTANT DATES: Paper Submission Deadline: February 1, 2000 Feedback to Authors: May 1, 2000 Final Manuscripts Due: June 1, 2000 Publication Date: Fall 2000 SUBMISSION INSTRUCTIONS: Authors are requested to send e-mail to one or both of the Guest Editors (almeroth(a)cs.ucsb.edu, nonnen(a)research.bell-labs.com) giving a URL from where a postscript or PDF file can be downloaded. Successfully received papers will be acknowledged. AUTHOR INFORMATION: Submissions made to the special issue should not have appeared in, or been submitted to other archival publications. All papers will be subjected to the journal's usual refereeing process. ------- End of Blind-Carbon-Copy

1 0

Re: H 323 on corporate intranets
by Paul Long 17 Dec '99

17 Dec '99

Richard, You're right, this _is_ the wrong place! :-) These kinds of queries should be directed to, for example, the USENET newsgroup, comp.dcom.videoconf. You would get better user response, fewer vendor responses, and irritate a lot fewer people. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Harkness, Richard C To: ITU-SG16(a)MAILBAG.INTEL.COM Sent: 12/16/99 2:21 PM Subject: H 323 on corporate intranets I am new to this site/list or whatever so please excuse me if I am in the wrong place for the following. Boeing wants to begin experimenting with VTC over IP. I want to talk with persons who have tried to implement H 323 video conferencing on their corporate intranet at rates of about 384 kbps. Anyone interested in sharing their experience please call Rich Harkness at (425) 865-4426. or repond by e-mail to: richard.c.harkness(a)boeing.com Leads to any other good sources (beside the VTC vendors) would be also appreciated. Thanks

1 0

Annex L Conference Call Minutes
by Dave Walker 17 Dec '99

17 Dec '99

Here are the minutes to the conference call that was held on Wednesday to discuss the H.323 Annex L stimulus protocol. My sincere thanks to all who participated! Attendees: Francois Audet, Orit Levin, Bob Gilman, Markku Korpi, Bob Callaghan, Vineet Kumar, Dave Walker 1. Positioning Annex L - H.450 should be described by what it can do, rather than what it can't do (as I did in the annotated agenda I sent out on Monday). It's main goal is networking interoperability, not providing all features required for PBX replacement. - H.323 provides some support for what are considered as supplementary services, such as identification services, call transfers, etc. It should be noted that use of Annex L may require that some "native" features, such as call id, may have undesirable interactions with the stimulus control and might have to be disabled. H.323 provides the basic call mechanism that is used by Annex L. - An extensive discussion of positioning with H.248 took place. It was suggested that the choice of H.248 or Annex L for features would be influenced by the implementation's point of departure. Gateway based implementations may have a preference for H.248, whereas Gatekeeper based implementations have a natural preference for Annex L. A prime goal is to keep H.248 line side packages and Annex L functionally similar. H.248 based endpoints tend to be unaware of call state. There was dissent among participants as to whether Annex L endpoints would be call state aware. H.323 currently allows a call to be established and used, as and when required, for multiple media connections. This permits an endpoint to initiate a call, signalling only, and to maintain it essentially forever; Annex L could be used to provide all other control. Analogies to existing systems can be made, however it was suggested that although H.323 may allow this, it is not necessarily desirable, especially from the point of interoperability. It was pointed out that endpoints which depend almost entirely on Annex L would need to be able to at least re-direct incoming Setup messages to their Gatekeeper in order to approach H.323 compliance. It was suggested that this issue be entirely removed from Annex L. While there was some concern that this would lead to implementation difficulty, the consensus seemed to support removal. - It was emphasized that we should strive for as much commonality with H.248 line side as possible. A highly desirable solution would be to simply reference the appropriate packages and specify the encoding mechanism to be used for H.323 stimulus. This would ensure future alignment. - It was agreed that H.323 Annex K is not intended to provide device control, its role is orthogonal to Annex L. WML transport can be provided by the generic tunnelling mechanism being developed for QSIG (H.323 Annex M). 2. Requirements - Everyone agreed that Unicode is needed. The issue is that both ends must realize that Unicode is being used. I suggested that support could be declared/configured using the management part of Annex L. An alternative is to use an escape code (0xff was suggested), which would indicate that the IE contains Unicode. This might require that we choose a flavour of Unicode - UTF-8 seems to be wildly popular. This discussion evolved into a discussion of the extensive use of "antique" ANSI escape sequences in the draft. - It was agreed that the level of complexity in the screen control section (3.1.1) of the draft was excessive. Endpoints which are capable of such sophistication should be capable of supporting some other protocol for display management. I suggested that only cursor positioning and erase capabilities were really required. This had some support until it was suggested that bandwidth is not at so much of a premium as in days of yore, so that a Gatekeeper requiring full control over a screen could simply re-write the entire display whenever it needed. This would require that Annex L point out that a Display IE always rewrites the entire screen. As Display IE is limited to 80 octets, which could be far fewer than 80 display characters depending on the flavour of Unicode, there may have to be some sort of continuation indicator. - The understandable preference for not being required to parse the entire Display IE was expressed. This led to a discussion of how other usages of Display in the current draft could be addressed. Specifically, how to control indicators. - Since the issue of adding support for (Q.932) Feature Activation and Feature Indication Information Elements was on the table, it was agreed that using FI to control indicators would be a cleaner solution that Display. However, a possible problem with this approach is that FA and FI are not supported in any version of H.225.0, so backwards compatibility would be compromised. There is a paragraph in H.225.0 which may allow earlier version EPs to use these IEs, but it is unclear. The paragraph, found in section 7.1, "Use of Q.931", states that "EPs may interpret and generate optional IEs defined below", but "also may interpret other IEs of ... other Q-series ... protocols". So interestingly, the word "generate" is missing from the second statement, so that EPs may not be permitted to generate FA and FI IEs, even if they are allowed to interpret them. On the other hand, the recommendation doesn't explicitly state that they may not be generated. Furthermore, it is unknown whether popular H.323 stacks support this. - The point was made that if we decide to pick up FA and FI, that it will not be sufficient to simply reference Q.932, rather Annex L will have to explicitly describe how and what these IEs are used for. In addition, the extent to which Annex L should explicitly list FA Feature Ids was uncertain, as was any view on re-using Ids already defined by other ITU recommendations. It was suggested that predefining a few could help ensure some degree of interoperability. This is the approach that has been followed for other encodings in Annex L, where a set of predefined elements is provided along with a mechanism for configuring nonstandard extensions. - FA/FI could be useful for replacing most, if not all, of the escape sequence mechanisms introduced into the Display and Keypad IEs. However, whether FI could be used to replace the currently suggested use of the Signal IE was not discussed. A Feature Id could be assigned to particular tone patterns, with the status value in the FI indicating whether the tone should be started or stopped. 3. Plans - We have to verify whether FA/FI are usable. This is certainly a way forward. I propose that minimal usage of Display and Keypad be maintained as an option, but significantly stripped down as described above. Allowing FA/FI has implications to the management part of the protocol. - The draft needs one or two usage examples illustrating how the procedures may be used. - Minimal requirements need to be defined. Optional functionality needs to be clearly described. There may be different levels of conformance: e.g. FA/FI, keypad/display, etc. Unless very carefully done, this will make it very difficult to ensure interoperability.

1 0

Re: [Robustness] Conference Call
by K. Jagannath Rao 17 Dec '99

17 Dec '99

very good! -----Original Message----- From: Kumar, Vineet [mailto:vineet.kumar@INTEL.COM] Sent: Friday, December 10, 1999 10:36 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [Robustness] Conference Call i plan to attend. vineet -----Original Message----- From: Steve.Edgar(a)NOKIA.COM [mailto:Steve.Edgar@NOKIA.COM] Sent: Thursday, December 09, 1999 12:57 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: [Robustness] Conference Call The conference call for robustness, arranged by Maureen Stillman, is scheduled for Tuesday, December 14th at 11:00 AM EST USA. Conf call number: 613-688-2795 Access code 9234# Please send e-mail to maureen.stillman(a)nokia.com if you plan to attend. Failure scenarios will be discussed. Please send failure scenarios to the Study Group 16 mailing list.

1 0

H.323 Mobility: Updated MTD-06 (Functional Architecture Diagram)
by Jaakko Sundquist 17 Dec '99

17 Dec '99

Hi Ed & all, As was agreed I updated the H.323 Mobility Functional Architecture Diagram. The diagram is included in the document I'm sending. The document itself is an updated version of MTD-06, with some of the text (as well as the diagram) updated and the example scenarios taken out (as they did not make as much sense after the changes in the diagram). Please note also that on the first page of the document I have listed the companies that agreed on the diagram being a part of the Annex H draft. I was not quite sure which companies were present in the telephony conference, so I listed only those that I felt were surely there. If there is a mistake in the list, please let me and the Annex H editor, Mr. Martinez, know about it (and I apologize already beforehand for my mistake) and we will correct it. We should also probably have a discussion about the diagram in the mailing list. It seems to me that, especially if the Hinter interface is accepted, there may be some quite unnecessary interfaces in the diagram now... I will also upload the diagram to: ftp://standard.pictel.com/avc-site/Incoming/H323_Mobility/ Have a nice weekend (studying the wonderful possibilities of H.323 Mobility :-) <<MTD-06a.zip>> - 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

H 323 on corporate intranets
by Harkness, Richard C 16 Dec '99

16 Dec '99

I am new to this site/list or whatever so please excuse me if I am in the wrong place for the following. Boeing wants to begin experimenting with VTC over IP. I want to talk with persons who have tried to implement H 323 video conferencing on their corporate intranet at rates of about 384 kbps. Anyone interested in sharing their experience please call Rich Harkness at (425) 865-4426. or repond by e-mail to: richard.c.harkness(a)boeing.com Leads to any other good sources (beside the VTC vendors) would be also appreciated. Thanks

1 0

Re: [Robustness] A couple comments on D.225
by Roy, Radhika R, ALARC 16 Dec '99

16 Dec '99

Hi, Offer and All: With respect to AT&T's proposal (D.225), 3Com's views can be summarized as follows: 1. Support distributed GK architecture (not the hierarchical model) 2. Treat the GK as a monolithic entity 3. Reduce the number of GK subcomponents into two categories: Registration/Pre-call (e.g., RAS) and Call Related issues (e.g., Q.931/932, H.245) If we are in agreement about those three items, we can start bringing follow-up contributions along those lines. With respect to hierarchical model, I'd like to point out that BEs that perform the "clearing house" functions work almost in a hierarchical fashion. If necessary, we can also examine whether the extension that will be made in H.323 protocol to enhance the reliability/robustness of the GK of the distributed model is also good for the hierarchical model. I also plan to attend the conf call on January 6. Happy Holidays and have a wonderful New Year!! Best regards, Radhika R. Roy, AT&T +1 732 420 1580 rrroy(a)att.com > -----Original Message----- > From: Offer Pazy [SMTP:Offer_Pazy@EUR.3COM.COM] > Sent: Wednesday, December 15, 1999 7:21 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [Robustness] A couple comments on D.225 > > Hello, > > I hope that this is the right forum, procedure and timing for commenting > on the > D.225 document. If not, please use moderate flames only.... > > In general, I like the models presented and I think they serve a useful > starting > point. I would like to offer two simplifications: > > 1. Distributed Vs hierarchical architectures: > > I don't see the value of having a special hierarchical case. As suggested > in > D.225, we must avoid single point of failures. The node at the top of the > diagram (figure 7) is such a point unless we introduce redundancy for it > as > well. When we do so, we go back to the general distributed case where each > node > has a primary GK of a zone plus zero or more backup GKs for other zones. > My view > is that describing the model in this way is simpler than having two > distinct > cases, > > 2. D.225 proposes that the three internal "components" of a GK should be > exposed > and that redundancy mechanisms should be defined for them. I wonder if we > should > not keep this as an implementation issue. After all, GKs are defined in > H.323 as > containing all these three components and there was no intention (I > believe) to > force end-points to distinguish between a failed GK and the failure of one > of > its subcomponents. To formalize such granularity would require us to > answer > questions such as: What happens if the Q.931 component of GK A fails but > its > H.245 component is running OK, and the backup of the Q.931 of GK A resides > with > GK B whose RAS component has failed? Or, what happens when an endpoint is > registered with GK A but uses GK B (GK-routed) as the originating GK when > the > Q.931 component of A has failed? etc. etc. Clearly this is a complex > problem to > solve. > > Instead I believe we should concentrate on treating the GK as a monolithic > entity which 1) has fail-stop semantics and 2) a backup entity is backing > up the > GK as a whole as opposed to having a backup for each subcomponent. From > the > standard and protocols stand-point this will suffice. Clearly, > implementors > will have to invest efforts in designing their GK architectures in the > most > fault tolerant manner (and may use some of the ideas presented in D.225), > but > this should really be out of scope for the standard as long as the > semantics of > a failed GK are clearly defined. > > A slightly different way to look at the proposal in D.225 is to reduce the > number of GK subcomponents from three (RAS, Q.931, H.245) to two: > Registration > issues and "a particular call"-related issues. As can be noticed, this > idea does > not just decrease the granularity (which by itself simplifies things), but > also > shifts the focus of the model from that of an implementation view to a > more > behavioral view. It can be argued that H.323 endpoints already have to > distinguish between the registration process and failures and the process > of > call establishment and control. > > Offer

1 0

[Robustness] telecon scheduled - January 6, 2000
by Maureen Stillman 16 Dec '99

16 Dec '99

The next Robustness telecon is scheduled for January 6 at 11AM EST USA. Details on the conference bridge will be sent after the turn of the millenium. We made significant progress during our last telecon. I will send out the minutes by Monday, December 20. The topic for the next telecon is to review the draft submission which is the result of our last several discussions. Radvision will write the text for the submission and circulate it prior to the January 6 telecon. Please send me e-mail if you wish to join the telecon. Thanks. -- maureen Maureen Stillman Member of Scientific Staff Voice: (607)273-0724 x62 Nokia IP Telephony Fax: (607)275-3610 127 W. State Street Mobile: (607)227-2933 Ithaca, NY 14850 e-mail: maureen.stillman(a)nokia.com www.nokia.com

1 0