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

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

H.323 Mobility Conference Call Meeting Minutes
by Roy, Radhika R, ALARC 15 Dec '99

15 Dec '99

Hi, Everyone: Next Meetings: Our next H.323 Mobility Conference Calls will held as follows: January 10 and 17: 11 AM - 1 PM, Eastern Standard Time (EST), USA. The detail of the conference bridge and meeting agenda will be sent later. Please send your contributions to Edgar Martinez, Motorola Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Meeting Minutes: The H.323 Ad Hoc Mobility Conference call was held on December 14, 1999. We provide our sincere thanks to IMTC for providing conference ports. Thanks to Ed Martinez of Motorola for conducting the meeting and taking notes. The companies represented in this meeting where: Motorola, Lucent, Intel, Alcatel, AT&T, Ericsson, Siemens On the status of the join MTD-3 contribution, Title "Annex-H (User, Terminal and Service Mobility in H.323)" at this time MTD-3 is up to version MTD-3b which was last reviewed in the conference call of Nov. 17, 1999. MTD-3 (final version) will be a joint contribution that will be presented in SG 16 and its Working Parties in Switzerland [Geneva] meeting from February 7 to 18. The status of this document is not the official H.323 Annex-H document but, a join H.323 mobile ad-hoc group contribution for H.323 Annex-H. It was recommended by Lucent that the cover page for MTD-3 mention the fact that MTD-3 is a join contribution from the mobile ad-hoc group, to be considered for input to the official H.323 Annex-H. MTD-03 will be updated on the receive of Nokia's agreed Ad-hoc architecture diagram on the Dec.8, conference call meeting. The diagram and contents will be posted to give the H.323 Ad-hoc group and other interested parties, time to do a final review before the next meeting in Jan. 10, 1999. For the next two meetings Ed marinez will be taking the contributions and will re-number the documents to the original numbering scheme and add the versions (e.g. MTD-00, MTD-00a...MTD-00z) and just carry the MTD's over to the next meeting. The reason is that the documents are being missed numbered from one meeting to another. Also, I find no good reason to change the number of the MTD, if the document has not changed, then why give it a new number. It is also confusing to other Ad-hoc members. Only two contributions where review MTD-106 and MTD-107b by Alcatel. MTD-106 gave a high level of 3GPP mobility and the presenter focus on section 3.9 Mobility Management procedures. To make a point that 3GPP that supports two registrations bearer and application level registrations . The proposal was that H.323 mobility support two registrations one called bearer level registration (e.g. GPRS attach) and, if so specified/allowed by the Mobile Set, MS subscription profile, an application level registration. MTD-107b AT&T and Alcatel started to review the contribution word by word to see what could be included in the join mobile ad-hoc contribution MTD-3 for February's full SG-16 meeting. Time ran out no resolution on what could be added or taken out of MTD-3. It is expected that a discussion will be held via email in the SG16 reflector related to Alcatel's contribution. The next two meetings are for January 10 and 17 the time, date and agenda will be posted. You may sent the contribution to Ed Martinez via email and he will download it for you and provide a MTD# if needed. Please advise Ed Martinez if your contribution which was put in the first conference call was not reviewed, so we can get to it before the last meeting on January 17. Best Regards, Radhika R. Roy, AT&T H.323 Ad Hoc Mobility Group +1 732 420 1580 rrroy(a)att.com

1 0

Re: I-D ACTION:draft-ietf-megaco-reqs-09.txt
by Nancy-M Greene 15 Dec '99

15 Dec '99

I've done my homework and filled in the references for the Megaco/H.248 requirements document (draft-ietf-megaco-reqs-09.txt) (thanks to those who helped me fill them in): > draft-ietf-megaco-reqs-09.txt references: > 13. References > > [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev- > els", RFC 2119, March 1997. > [2] Draft ITU-T Recommendation Q.2630.1, AAL type 2 Signalling Protocol > (Capability Set 1), ITU-T Meeting Report COM 11-R 149-E, July 1999 > [3] ITU-T Recommendation H.341, Line Transmission of Non-Telephone > Signals, May 1999. > [4] ATM Forum Technical Committee, af-vtoa-0083.001, Voice and Telephony > Over ATM to the Desktop Specification, March 1999. > [5] ITU-T Recommendatio H.323v2, Packet-based Multimedia Comunications > Systems (includes Annex C - H.323 on ATM), February 1998. > [6] ATM Forum Technical Committee, af-saa-0124.000, Gateway for H.323 > Media Transport Over ATM, May 1999. > [7] ITU-T Recommendation T.140, Protocol for Multimedia Application Text > Conversation, February 1998. > [8] ITU-T Recommendation V.18, Operational and Interworking Requirements > for DCEs Operating in Text Telephone Mode, February 1998. > [9] ITU-T Q.931, Digital Subscriber Signalling System No. 1 (DSS 1) - > ISDN User-Network Interface Layer 3 Specification fro Basic Call Control, > March 1993 > > Nancy > -------------------------------------------------------------------------- > Nancy M. Greene > Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > > > ---------- > From: Taylor, Tom-PT [CAR:B904-I:EXCH] > Sent: Friday, December 10, 1999 9:41 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: I-D ACTION:draft-ietf-megaco-reqs-09.txt > > I propose WG Last Call based on this document, with the expiry two weeks > hence (24 December). > > Changes from the previous version are as follows: > > - removed reqt 5.6 c) Support general test capabilities, for example > loopbacks through the MG to test DSP operation. > It was agreed that inward loopbacks are outside the scope of the protocol > - they are not part of call control, so would be handled by some other > maintenance protocol. Thus the above requirement is deleted. > > - reqt 5.7 a) - changed word call to connection > > - table in section 11 - removed wiretap > > - reqt 11.1.3.1 a) rewording of 2nd bullet on addressing - didn't mean > wildcarding, meant instead allowing the gateway to choose (part of) the > identifier > > > The references need to be completed still, and there may be an editor's > note or two that should still come out. > > -----Original Message----- > From: Internet-Drafts(a)IETF.ORG [SMTP:Internet-Drafts@IETF.ORG] > Sent: Friday, December 10, 1999 8:08 AM > To: MEGACO(a)STANDARDS.NORTELNETWORKS.COM > Subject: I-D ACTION:draft-ietf-megaco-reqs-09.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Media Gateway Control Working Group of > the IETF. > > Title : Media Gateway control protocol > architecture and > requirements > Author(s) : N. Greene, M. Ramalho, B. Rosen > Filename : draft-ietf-megaco-reqs-09.txt > Pages : 45 > Date : 09-Dec-99 > > TThis document describes protocol requirements for the Media Gateway > control protocol between a Media Gateway Controller and a Media Gateway. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-megaco-reqs-09.txt > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-megaco-reqs-09.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv(a)ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-megaco-reqs-09.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. << Message: >> > >

1 0

H.323 Mobility: docs
by Edgar Martinez [1] 15 Dec '99

15 Dec '99

Dear Adhoc-mobility, All the documents of the Adhoc-mobility group have been put in: ftp://standard.pictel.com/avc-site/Incoming/H323_Mobility/SG16_Mobility/ If you want to update your contribution for resubmission please do so. By adding an letter version, e.g. MTD-00.zip is version 1, MTD-00a is version 2 , MTD-00b is version 3 and so on. If you want to put a new contribution in, please sent it to me via email mailto:martinze@cig.mot.com I will down load and provide you a MTD number. Regards, -- Edgar Martinez - Principal Staff Engineer Email 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: Editor's comments
by Edgar Martinez [1] 15 Dec '99

15 Dec '99

Dear Mobile Ad-hoc group: Radhika Roy will send out the final meeting minutes, this is only input to the minutes. If anyone else wants to add to the minutes please post and copy Radhika Roy. Mobile ad-hoc group meeting Dec. 14, 1999 The companies represented in this meeting where: Motorola, Lucent, Intel, Alcatel, AT&T, Ericsson, Siemens On the status of the join MTD-3 contribution, Title "Annex-H (User, Terminal and Service Mobility in H.323)" at this time MTD-3 is up to version MTD-3b which was last reviewed in the conference call of Nov. 17, 1999. MTD-3 (final version) will be a join contribution that will be presented in SG 16 and its Working Parties in Switzerland [Geneva] meeting from February 7 to 18. The status of this document is not the official H.323 Annex-H document but, a join H.323 mobile ad-hoc group contribution for H.323 Annex-H. It was recommended by Lucent that the cover page for MTD-3 mention the fact that MTD-3 this is a join contribution from the mobile ad-hoc group, to be considered for input to the official H.323 Annex-H. MTD-03 will be updated on the receive of Nokia's agreed Ad-hoc architecture diagram on the Dec.8, conference call meeting. The diagram and contents will be posted to give the Ad-hoc group and other H.323 mobile and other interested parties, time to do a final review before the next meeting in Jan. 10, 1999. Note: I did not attend the Dec. 8 meeting. ---- For the next two meetings I will be taking the contributions and will re-number the documents to the original numbering scheme and add the versions (e.g. MTD-00, MTD-00a...MTD-00z) and just carry the MTD's over to the next meeting. The reason is that the documents are being missed numbered from one meeting to another. Also, I find no good reason to change the number of the MTD, if the document has not changed, then why give it a new number. It is also confusing to other Ad-hoc members. ---- Only two contributions where review MTD-106 and MTD-107b by Alcatel. MTD-106 gave a high level of 3GPP mobility and the presenter focus on section 3.9 Mobility Management procedures. To make a point that 3GPP that supports two registrations bearer and application level registrations . The proposal was that H.323 mobility support two registrations one called bearer level registration (e.g. GPRS attach) and, if so specified/allowed by the Mobile Set, MS subscription profile, an application level registration. MTD-107b AT&T and Alcatel started to review the contribution word by word to see what could be included in the join mobile ad-hoc contribution MTD-3 for February's full SG-16 meeting. Time ran out no resolution on what could be added or taken out of MTD-3. --- The next two meetings are for January 10 and 17 the time, date and agenda will be posted. You may sent the contribution to me at my email, I will download then for you and provide a MTD# if needed. Please advise me if your contribution which was put in the first conference call was not reviewed, so we can get to it before the last meeting on January 17. Best Regards, -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Re: [Robustness] A couple comments on D.225
by Ami Amir 15 Dec '99

15 Dec '99

I heartily agree with Offer's recommendations, and particularly think that the only distinction to be made is between the registration process and the call related functionality. Ami -----Original Message----- From: Offer Pazy [mailto:Offer_Pazy@EUR.3COM.COM] Sent: 15 December, 1999 14:21 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] A couple comments on D.225
by Offer Pazy 15 Dec '99

15 Dec '99

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] Draft scenario for discussion -- malicious attacks
by Maureen Stillman 14 Dec '99

14 Dec '99

Enclosed is my draft contribution to robustness scenarios. <<Robustness scenario.doc>> -- maureen Maureen Stillman Member of Scientific Staff Voice: (607)273-0724 x62 Nokia IP Telephony Fax: (607)275-3610 127 W. State Street Mobile: (607)227-2933 Ithaca, NY 14850 e-mail: maureen.stillman(a)nokia.com www.nokia.com

1 0

Re: [Robustness] conference call reminder -- Tuesday, Dec. 14 11A M ES T USA
by Roy, Radhika R, ALARC 14 Dec '99

14 Dec '99

Hi, Maureen: Due to conflict with the H.323 Mobility Conference call, I cannot attend this conference call. I am sorry for this. However, I am providing some quick inputs to the team as follows: Possible examples of H.323 Failures/Scenarios: 1. GK failures 2. GK/BE failures 3. H.323 terminal failures 4. H.323 GW failures 5. H.323 MCU failures 6. H.323 MC failures 7. TCP/UDP port failures for RAS, Q.931/932, and/or H.245 8. Network layer interface failures abstracted to the H.323 layer 9. Network link failures abstracted to the H.323 layer 10. RAS signaling messages' failures while TCP/UDP ports are up 11. Q.931 call signaling messages' failures while TCP/UDP ports are up 12. Call/conference related ID failures 13. H.245 logical channel failures 14. H.245 messages failures 15. RAS, Q.931/932, and/or H.245 signaling module failures Failure recovery: For each failure, how does the H.323 system recover? Hope that the team members may consider to discuss some failures scenarios around the above items. Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com > -----Original Message----- > From: Maureen Stillman [SMTP:Maureen.Stillman@NOKIA.COM] > Sent: Monday, December 13, 1999 10:32 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [Robustness] conference call reminder -- Tuesday, Dec. 14 > 11AM ES T USA > > The conference call for robustness, arranged by Nokia, 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. Hope to talk with you on Tuesday. > > > -- 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

Alcatel MTD 107b
by Laurent Thiebaut 14 Dec '99

14 Dec '99

Please find attached a new version of MTD107. Could someone please put it on the "incoming" ftp server. Thank you for the help. Modification w.r.t. previous version are underlined by revision marks and are mainly editorial. (See attached file: MTD-107b.zip) Best regards Laurent T. --------------------------------------------------------------------------- V Laurent Thiebaut tel: +33 (0)1 3077 0645 A L C A T E L e.mail:laurent.thiebaut@alcatel.fr ---------------------------------------------------------------------------

1 0

Re: Comments on MTD-107a
by Roy, Radhika R, ALARC 14 Dec '99

14 Dec '99

Hi, Laurent: We would like to have the solution in H.323 layer that is independent of the lower layer in the context of Rec. H.323. It is not only for the radio layer (link), but also for the network and transport layer. Let us examine that there are certain situations where the abstraction of mobility in the radio layer (link) has an impact on the H.323 layer due to mobility. The resources in the H.323 layer should be taken care-of accordingly in mobile environments. Most the radio link layer mobile interactions will be transparent to the H.323 layer while certain situations of the radio link layer will have an impact due to mobility. The paging of the LRQ message is an example. With respect Motorola's contribution, we may have to discuss: To see whether the H.323 solution is independent of the radio link layer or not. I would also refer to see AT&T's contributions submitted in the last Red Bank meeting (PACs-1651/1652/1664/1665). I would be please to answer any questions in connection to the proposed solution in the light of the above. Best regards, Radhika R. Ro AT&T > -----Original Message----- > From: Laurent.Thiebaut(a)alcatel.fr [SMTP:Laurent.Thiebaut@alcatel.fr] > Sent: Tuesday, December 14, 1999 4:11 AM > To: Edgar Martinez [1] > Cc: H.323 Mobility; Roy, Radhika R, ALARC > Subject: Re:Re: Comments on MTD-107a > > > > Dear Mr Martinez and SG16 H323 mobile group > The "message" of MTD-107 contribution is to decorrelate H323 mobility from > radio mobility with the global aim to support the same H323 mobility for > both fixed and radio terminals. That is why MTD-07 proposes: > to suppress some radio mobile concepts from H323 mobility, taking into > account that radio mobility tools/concepts such as paging, hand-over, > location area, temporary radio mobile identity, .. are used by radio > access networks in a way that is > transparent to the H323 (mobile) layer. This does not mean that moves > at radio level have no indirect impact on H323 mobility such as change of > NPOA or change of Serving GK but these indirect impacts are decorrelated > from the radio technology (GPRS, > cdma2000, ...) > to introduce the notion of double registration allowing to bring the > independence between radio networks and H323 mobile network and hence > independence between radio access technology (GPRS,, cdmaOne, ...) and > H323 mobile network. > > Note that the solution proposed in MTD-107 allows various operational > situations such as a separation between the administrative domain of the > (possibly radio) access and the administrative domain of H323 mobility. > This separation is rendered easy by the > decoralation of the (possibly radio) access functions and the H323 > mobility functions. > > On the other hand putting the GK in the SGSN or in any radio related > function (as I understand is proposed in Motorola's MTD-305) does not > bring the independence of H323 mobility from radio access (network and > technology). Furthermore putting BTS or IP > Radio Access Network in the scope of H323 mobility (as I understand is > proposed in Motorola's MTD-305) implies very high ties between H323 mobile > and radio technology. > > Mr Martinez, may be I have mis-understood MTD-305, in which case I would > please ask you to give further explanations. > Best regards > Laurent T. > -------------------------------------------------------------------------- > - > V Laurent Thiebaut tel: +33 (0)1 3077 0645 > A L C A T E L e.mail:laurent.thiebaut@alcatel.fr > -------------------------------------------------------------------------- > - > > > > > > "Edgar Martinez [1]" <martinze(a)cig.mot.com> on 14/12/99 01:44:04 > > > > To: "H.323 Mobility" <ITU-SG16(a)mailbag.cps.intel.com> > > cc: "Roy, Radhika R, ALARC" <rrroy(a)att.com>, Laurent > THIEBAUT/FR/ALCATEL@ALCATEL > > > > Subject: Re: Comments on MTD-107a > > > > > > > Dear Radhika and Mr. Thiebaut, > > In reference to Alcatel's MTD-107a (v.s.) Motorola's MTD-305c. > > We (Motorola) would like to move 3GPP option 1 to a full IP solution > within the H.323 mobility framework. Unlike MTD-107a, Motorola is working > on one Universal IP solution that will support both fixed and mobile > terminals > and user and network services for voice, data and multi-media. > Not just GPRS mobile data services. > > Right now 3GPP R'00 option 1 has two networks a GPRS and an IP network, > which are shown side by side. 3GPP option 2 adds a third dimension a > circuit > switch side. > Where 3GPP option 2 is composed of different three networks, GPRS, IP > and Circuit switched. > > As matter of fact, UMTS R'99 has no IP, UMTS R'99 has the MSC and > SSGN radio interfaces attached via an array of BSCs and RNCs and a > mix of Iu-ps and Iu-cs connections. One can say that option 2 is just > R'99 with > > access to some H.323 IP elements like a gateway and gatekeeper > and that's all we get. See MTD-107a, MTD-08, 3GPP's TR23.922 > and TR23.002 to see for yourself. > > The framework for MTD-305c is for the H.323 system to be able to > interwork with the legacy network's both mobile and fixed systems, > while also providing new technology and services to the IP network. > > "Roy, Radhika R, ALARC" wrote: > > > Hi, Laurent: > > > > Please see my reply provided below. > > > > My view point is: Let us keep doors open for all probable solutions. Let > > people implement their solutions as they find optimal for their specific > > environments. > > > > Best regards, > > Radhika R. Roy > > AT&T > > > > > -----Original Message----- > > > From: Laurent.Thiebaut(a)alcatel.fr [SMTP:Laurent.Thiebaut@alcatel.fr] > > > Sent: Monday, December 13, 1999 1:01 PM > > > To: Roy, Radhika R, ALARC > > > Cc: 'paul.k.reddy(a)intel.com'; 'vineet.kumar(a)intel.com'; > > > 'jaakko.sundquist(a)nokia.com'; 'peeter.pruuden(a)nokia.com'; > > > 'senthil.sengodan(a)nokia.com'; 'marc.roelands(a)siemens.atea.be'; > > > 'martinze(a)cig.mot.com'; 'lpg019(a)email.mot.com'; 'orsic(a)lucent.com'; > > > 'stephen.terrill(a)ericsson.com'; 'gosta.linder(a)lme.ericsson.se'; > > > 'Anders.Svennevik(a)era.ericsson.se'; 'mike(a)synacom.com'; > 'stu(a)synacom.com'; > > > 'paul.jones(a)ties.itu.int'; 'baronson(a)acm.org'; > > > Ameneh.Zahir-Emami(a)alcatel.fr; Nicolas.Tran(a)alcatel.fr > > > Subject: RE: Comments on MTD-107a > > > > > > > > > > > > Hi Radhika, > > > I do not understand what you mean by "take care-of some special > needs > > > in mobile environment" as a need for Temporary IDs. My understanding > is > > > that H.323 alias ("E.164, email, URL,and others" as you mention) are > not > > > modified when the user moves because > > > it is these aliases that allow to reach the user even when the > user > > > moves (and its NPOA changes). Could you please clarify what you mean? > > [Roy, Radhika R] What I envision that "Temporary ID" can also > be > > another " H.323 alias" considering the mobile environment. So, it is an > > extension of the present H.323 alias addresses. > > > > > for paging: my understanding is that through a RRQ, the mobile > gives > > > the association between its alias(es) and its NPOA (IP) address to its > > > Serving GK that stores the association in internal tables. When there > is > > > a mobile terminated call, thanks to > > > HLF-VLF interactions (as described in Nokia's MTD104), the Serving > GK @ > > > is determined. Then the set-up message is sent to the Serving GK. > Using > > > the internal table populated at RRQ, the Serving GK sends the set-up > > > message to the called mobile with the > > > right NPOA (IP) address. This packet is received by the Access > Network > > > that may have to page the mobile, but this paging is transparent to > H323. > > > Could you please explain me what you see as wrong in the scenario I > have > > > given. > > [Roy, Radhika R] This may be another alternative solution as > you > > have mentioned. At present, LRQ messages are sent between the GKs for > > address resolution. Extending the same scenarios, paging of LRQs in > mobile > > environment may be needed. > > > > > Best regards > > > Laurent T. > > > > -------------------------------------------------------------------------- > > > - > > > V Laurent Thiebaut tel: +33 (0)1 3077 0645 > > > A L C A T E L e.mail:laurent.thiebaut@alcatel.fr > > > > -------------------------------------------------------------------------- > > > - > > > > > > > > > > > > > > > "Roy, Radhika R, ALARC" <rrroy(a)att.com> on 08/12/99 19:12:32 > > > > > > > > > > > > To: Laurent THIEBAUT/FR/ALCATEL@ALCATEL > > > > > > cc: "'paul.k.reddy(a)intel.com'" > > > <paul.k.reddy(a)intel.com>, > > > "'vineet.kumar(a)intel.com'" > > > <vineet.kumar(a)intel.com>, > > > "'jaakko.sundquist(a)nokia.com'" > > > <jaakko.sundquist(a)nokia.com>, > > > "'peeter.pruuden(a)nokia.com'" > > > <peeter.pruuden(a)nokia.com>, > > > "'senthil.sengodan(a)nokia.com'" > > > <senthil.sengodan(a)nokia.com>, > > > "'marc.roelands(a)siemens.atea.be'" > > > <marc.roelands(a)siemens.atea.be>, > > > "'martinze(a)cig.mot.com'" <martinze(a)cig.mot.com>, > > > "'lpg019(a)email.mot.com'" <lpg019(a)email.mot.com>, > > > "'orsic(a)lucent.com'" <orsic(a)lucent.com>, > > > "'stephen.terrill(a)ericsson.com'" > > > <stephen.terrill(a)ericsson.com>, > > > "'gosta.linder(a)lme.ericsson.se'" > > > <gosta.linder(a)lme.ericsson.se>, > > > "'Anders.Svennevik(a)era.ericsson.se'" > > > <Anders.Svennevik(a)era.ericsson.se>, > > > "'mike(a)synacom.com'" <mike(a)synacom.com>, > > > "'stu(a)synacom.com'" <stu(a)synacom.com>, > > > "'paul.jones(a)ties.itu.int'" > > > <paul.jones(a)ties.itu.int>, "'baronson(a)acm.org'" > > > <baronson(a)acm.org>, Ameneh > > > ZAHIR-EMAMI/FR/ALCATEL@ALCATEL > > > > > > > > > > > > Subject: RE: Comments on MTD-107a > > > > > > > > > > > > > > > > > > > > > Hi, Laurent: > > > > > > Paging: A simple answer will be to locate the mobile user for > resolving > > > the > > > address needed in the LRQ message. > > > > > > Temporary ID: H.323 aliases are open enough to include E.164, email, > URL, > > > and others. In the same token, if mobile users also need to introduce > > > other > > > IDs similar such as Temporary IDs, Personal IDs, etc. to , we should > be > > > open to those suggestions. > > > > > > Best regards, > > > Radhika R. Roy > > > AT&T > > > > > > > -----Original Message----- > > > > From: Laurent.Thiebaut(a)alcatel.fr > [SMTP:Laurent.Thiebaut@alcatel.fr] > > > > Sent: Wednesday, December 08, 1999 11:09 AM > > > > To: Roy, Radhika R, ALARC > > > > Cc: Roy, Radhika R, ALARC; 'paul.k.reddy(a)intel.com'; > > > > 'vineet.kumar(a)intel.com'; 'jaakko.sundquist(a)nokia.com'; > > > > 'peeter.pruuden(a)nokia.com'; 'senthil.sengodan(a)nokia.com'; > > > > 'marc.roelands(a)siemens.atea.be'; 'martinze(a)cig.mot.com'; > > > > 'lpg019(a)email.mot.com'; 'orsic(a)lucent.com'; > > > > 'stephen.terrill(a)ericsson.com'; 'gosta.linder(a)lme.ericsson.se'; > > > > 'Anders.Svennevik(a)era.ericsson.se'; 'mike(a)synacom.com'; > > > 'stu(a)synacom.com'; > > > > 'paul.jones(a)ties.itu.int'; 'baronson(a)acm.org'; > > > > Ameneh.Zahir-Emami(a)alcatel.fr > > > > Subject: Re: Comments on MTD-107a > > > > > > > > > > > > > > > > Hi, Everyone, this is just to answer to Roy's remark > > > > Hi Radhika, > > > > I agree with you when you say that "the lower layer mobility may > > > cause > > > > an impact on > > > > the higher layer (e.g., H.323) as well. If it is so, the proper > > > > abstraction > > > > in the higher layer (e.g., H.323) should be there to take care of > > > this > > > > situation." > > > > That's just the reason why we have deleted the notion of > ?Location > > > Area > > > > Identity (set of Network of Attachments associated)? and ?Temporary > > > > Identity?. but added the notions of "change of NPOA or of H323 > Point of > > > > Attachment may need to be dealt with > > > > within H323 scope". > > > > I'd better see alias @" in the list of concepts used by H323 > mobility > > > > instead of "Temporary Id" that looks (for me with too much of a > mobile > > > > culture I admit) like the temporary Identifier allocated on radio to > > > hide > > > > the permanent user identity > > > > Could you explain the need of paging > > > > Best regards > > > > L. Thiebaut > > > > > > > > > > > > -------------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > > > > > > > > > > > > Hi, Everyone: > > > > > > > > We are in receipt of the contribution from Alcatel (MTD-107a: > Contact - > > > > Laurent Thiebaut). For the interest of time, I take the liberty to > offer > > > > my > > > > comments. > > > > > > > > I fully agree with the proposal of Laurent that H.323 Mobility > should > > > > focus > > > > only on the H.323 mobility layer. In fact, the terms of reference of > the > > > > H.323 mobility group has also confirmed this. However, some specific > > > texts > > > > that Laurent have proposed may create some confusions. Let me > expalin as > > > > follows : > > > > > > > > If the lower layer mobility (e.g., radio link or network layer) is > > > > transparent to the H.323 layer, nothing needs to done in the H.323 > > > > application layer. However, the lower layer mobility may cause an > impact > > > > on > > > > the higher layer (e.g., H.323) as well. If it is so, the proper > > > > abstraction > > > > in the higher layer (e.g., H.323) should be there to take care of > this > > > > situation. > > > > > > > > For example, switching of cells (e.g., cellular IP) may not cause > any > > > > impact > > > > in the H.323 layer. In this situation, this mobility is transparent > to > > > the > > > > H.323 layer. In some situation, the swiching of cells may also cause > an > > > > impact on the H.323 layer (e.g., H.323 point of attachment). In this > > > case, > > > > resources of the H.323 layer should also be taken care-of > accordingly. > > > > > > > > Temporary IDs may also be needed in the H.323 layer. Contributions > are > > > > provided why these IDs are needed in the H.323 layer. These are the > > > alias > > > > addresses and can have an astraction in the H.323 layer. That does > NOT > > > > mean > > > > in anyway that the solution of the H.323 is becoming specific to the > > > radio > > > > link layer. > > > > > > > > Similarly, LRQ message sets have the addresses that have been > abstracted > > > > in > > > > the H.323 layer. Contributions have been provided why the paging of > the > > > > LRQ > > > > message is needed in the H.323 layer. > > > > > > > > (However, I agree with him that location area may NOT be needed in > H.323 > > > > because the concepts of H.323 zones/domains will be sufficient. In > same > > > > token, we also do not need the concept of cells in H.323.) > > > > > > > > I find that texts proposed in the contribution are too restrictive. > > > > > > > > Finally, I propose that Laurent should keep an eye to the H.323 > solution > > > > that will be agreed upon should be transparent to the lower layer > (e.g., > > > > radio link or network layer) as we make more progress in this area. > > > > > > > > Best regards, > > > > Radhika R. Roy > > > > AT&T > > > > + 1 732 420 1580 > > > > rrroy(a)att.com > > > > > > > > > > > > > > > > > > > > > > > > -- > Edgar Martinez - Principal Staff Engineer > Email mailto:martinze@cig.mot.com > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > 1501 West Shure Drive, Arlington Hgts. IL 60004 > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ > > > >

1 0

Re: Comments on MTD-107a
by Laurent Thiebaut 14 Dec '99

14 Dec '99

Dear Mr Martinez and SG16 H323 mobile group The "message" of MTD-107 contribution is to decorrelate H323 mobility from radio mobility with the global aim to support the same H323 mobility for both fixed and radio terminals. That is why MTD-07 proposes: to suppress some radio mobile concepts from H323 mobility, taking into account that radio mobility tools/concepts such as paging, hand-over, location area, temporary radio mobile identity, .. are used by radio access networks in a way that is transparent to the H323 (mobile) layer. This does not mean that moves at radio level have no indirect impact on H323 mobility such as change of NPOA or change of Serving GK but these indirect impacts are decorrelated from the radio technology (GPRS, cdma2000, ...) to introduce the notion of double registration allowing to bring the independence between radio networks and H323 mobile network and hence independence between radio access technology (GPRS,, cdmaOne, ...) and H323 mobile network. Note that the solution proposed in MTD-107 allows various operational situations such as a separation between the administrative domain of the (possibly radio) access and the administrative domain of H323 mobility. This separation is rendered easy by the decoralation of the (possibly radio) access functions and the H323 mobility functions. On the other hand putting the GK in the SGSN or in any radio related function (as I understand is proposed in Motorola's MTD-305) does not bring the independence of H323 mobility from radio access (network and technology). Furthermore putting BTS or IP Radio Access Network in the scope of H323 mobility (as I understand is proposed in Motorola's MTD-305) implies very high ties between H323 mobile and radio technology. Mr Martinez, may be I have mis-understood MTD-305, in which case I would please ask you to give further explanations. Best regards Laurent T. --------------------------------------------------------------------------- V Laurent Thiebaut tel: +33 (0)1 3077 0645 A L C A T E L e.mail:laurent.thiebaut@alcatel.fr --------------------------------------------------------------------------- "Edgar Martinez [1]" <martinze(a)cig.mot.com> on 14/12/99 01:44:04 To: "H.323 Mobility" <ITU-SG16(a)mailbag.cps.intel.com> cc: "Roy, Radhika R, ALARC" <rrroy(a)att.com>, Laurent THIEBAUT/FR/ALCATEL@ALCATEL Subject: Re: Comments on MTD-107a Dear Radhika and Mr. Thiebaut, In reference to Alcatel's MTD-107a (v.s.) Motorola's MTD-305c. We (Motorola) would like to move 3GPP option 1 to a full IP solution within the H.323 mobility framework. Unlike MTD-107a, Motorola is working on one Universal IP solution that will support both fixed and mobile terminals and user and network services for voice, data and multi-media. Not just GPRS mobile data services. Right now 3GPP R'00 option 1 has two networks a GPRS and an IP network, which are shown side by side. 3GPP option 2 adds a third dimension a circuit switch side. Where 3GPP option 2 is composed of different three networks, GPRS, IP and Circuit switched. As matter of fact, UMTS R'99 has no IP, UMTS R'99 has the MSC and SSGN radio interfaces attached via an array of BSCs and RNCs and a mix of Iu-ps and Iu-cs connections. One can say that option 2 is just R'99 with access to some H.323 IP elements like a gateway and gatekeeper and that's all we get. See MTD-107a, MTD-08, 3GPP's TR23.922 and TR23.002 to see for yourself. The framework for MTD-305c is for the H.323 system to be able to interwork with the legacy network's both mobile and fixed systems, while also providing new technology and services to the IP network. "Roy, Radhika R, ALARC" wrote: > Hi, Laurent: > > Please see my reply provided below. > > My view point is: Let us keep doors open for all probable solutions. Let > people implement their solutions as they find optimal for their specific > environments. > > Best regards, > Radhika R. Roy > AT&T > > > -----Original Message----- > > From: Laurent.Thiebaut(a)alcatel.fr [SMTP:Laurent.Thiebaut@alcatel.fr] > > Sent: Monday, December 13, 1999 1:01 PM > > To: Roy, Radhika R, ALARC > > Cc: 'paul.k.reddy(a)intel.com'; 'vineet.kumar(a)intel.com'; > > 'jaakko.sundquist(a)nokia.com'; 'peeter.pruuden(a)nokia.com'; > > 'senthil.sengodan(a)nokia.com'; 'marc.roelands(a)siemens.atea.be'; > > 'martinze(a)cig.mot.com'; 'lpg019(a)email.mot.com'; 'orsic(a)lucent.com'; > > 'stephen.terrill(a)ericsson.com'; 'gosta.linder(a)lme.ericsson.se'; > > 'Anders.Svennevik(a)era.ericsson.se'; 'mike(a)synacom.com'; 'stu(a)synacom.com'; > > 'paul.jones(a)ties.itu.int'; 'baronson(a)acm.org'; > > Ameneh.Zahir-Emami(a)alcatel.fr; Nicolas.Tran(a)alcatel.fr > > Subject: RE: Comments on MTD-107a > > > > > > > > Hi Radhika, > > I do not understand what you mean by "take care-of some special needs > > in mobile environment" as a need for Temporary IDs. My understanding is > > that H.323 alias ("E.164, email, URL,and others" as you mention) are not > > modified when the user moves because > > it is these aliases that allow to reach the user even when the user > > moves (and its NPOA changes). Could you please clarify what you mean? > [Roy, Radhika R] What I envision that "Temporary ID" can also be > another " H.323 alias" considering the mobile environment. So, it is an > extension of the present H.323 alias addresses. > > > for paging: my understanding is that through a RRQ, the mobile gives > > the association between its alias(es) and its NPOA (IP) address to its > > Serving GK that stores the association in internal tables. When there is > > a mobile terminated call, thanks to > > HLF-VLF interactions (as described in Nokia's MTD104), the Serving GK @ > > is determined. Then the set-up message is sent to the Serving GK. Using > > the internal table populated at RRQ, the Serving GK sends the set-up > > message to the called mobile with the > > right NPOA (IP) address. This packet is received by the Access Network > > that may have to page the mobile, but this paging is transparent to H323. > > Could you please explain me what you see as wrong in the scenario I have > > given. > [Roy, Radhika R] This may be another alternative solution as you > have mentioned. At present, LRQ messages are sent between the GKs for > address resolution. Extending the same scenarios, paging of LRQs in mobile > environment may be needed. > > > Best regards > > Laurent T. > > -------------------------------------------------------------------------- > > - > > V Laurent Thiebaut tel: +33 (0)1 3077 0645 > > A L C A T E L e.mail:laurent.thiebaut@alcatel.fr > > -------------------------------------------------------------------------- > > - > > > > > > > > > > "Roy, Radhika R, ALARC" <rrroy(a)att.com> on 08/12/99 19:12:32 > > > > > > > > To: Laurent THIEBAUT/FR/ALCATEL@ALCATEL > > > > cc: "'paul.k.reddy(a)intel.com'" > > <paul.k.reddy(a)intel.com>, > > "'vineet.kumar(a)intel.com'" > > <vineet.kumar(a)intel.com>, > > "'jaakko.sundquist(a)nokia.com'" > > <jaakko.sundquist(a)nokia.com>, > > "'peeter.pruuden(a)nokia.com'" > > <peeter.pruuden(a)nokia.com>, > > "'senthil.sengodan(a)nokia.com'" > > <senthil.sengodan(a)nokia.com>, > > "'marc.roelands(a)siemens.atea.be'" > > <marc.roelands(a)siemens.atea.be>, > > "'martinze(a)cig.mot.com'" <martinze(a)cig.mot.com>, > > "'lpg019(a)email.mot.com'" <lpg019(a)email.mot.com>, > > "'orsic(a)lucent.com'" <orsic(a)lucent.com>, > > "'stephen.terrill(a)ericsson.com'" > > <stephen.terrill(a)ericsson.com>, > > "'gosta.linder(a)lme.ericsson.se'" > > <gosta.linder(a)lme.ericsson.se>, > > "'Anders.Svennevik(a)era.ericsson.se'" > > <Anders.Svennevik(a)era.ericsson.se>, > > "'mike(a)synacom.com'" <mike(a)synacom.com>, > > "'stu(a)synacom.com'" <stu(a)synacom.com>, > > "'paul.jones(a)ties.itu.int'" > > <paul.jones(a)ties.itu.int>, "'baronson(a)acm.org'" > > <baronson(a)acm.org>, Ameneh > > ZAHIR-EMAMI/FR/ALCATEL@ALCATEL > > > > > > > > Subject: RE: Comments on MTD-107a > > > > > > > > > > > > > > Hi, Laurent: > > > > Paging: A simple answer will be to locate the mobile user for resolving > > the > > address needed in the LRQ message. > > > > Temporary ID: H.323 aliases are open enough to include E.164, email, URL, > > and others. In the same token, if mobile users also need to introduce > > other > > IDs similar such as Temporary IDs, Personal IDs, etc. to , we should be > > open to those suggestions. > > > > Best regards, > > Radhika R. Roy > > AT&T > > > > > -----Original Message----- > > > From: Laurent.Thiebaut(a)alcatel.fr [SMTP:Laurent.Thiebaut@alcatel.fr] > > > Sent: Wednesday, December 08, 1999 11:09 AM > > > To: Roy, Radhika R, ALARC > > > Cc: Roy, Radhika R, ALARC; 'paul.k.reddy(a)intel.com'; > > > 'vineet.kumar(a)intel.com'; 'jaakko.sundquist(a)nokia.com'; > > > 'peeter.pruuden(a)nokia.com'; 'senthil.sengodan(a)nokia.com'; > > > 'marc.roelands(a)siemens.atea.be'; 'martinze(a)cig.mot.com'; > > > 'lpg019(a)email.mot.com'; 'orsic(a)lucent.com'; > > > 'stephen.terrill(a)ericsson.com'; 'gosta.linder(a)lme.ericsson.se'; > > > 'Anders.Svennevik(a)era.ericsson.se'; 'mike(a)synacom.com'; > > 'stu(a)synacom.com'; > > > 'paul.jones(a)ties.itu.int'; 'baronson(a)acm.org'; > > > Ameneh.Zahir-Emami(a)alcatel.fr > > > Subject: Re: Comments on MTD-107a > > > > > > > > > > > > Hi, Everyone, this is just to answer to Roy's remark > > > Hi Radhika, > > > I agree with you when you say that "the lower layer mobility may > > cause > > > an impact on > > > the higher layer (e.g., H.323) as well. If it is so, the proper > > > abstraction > > > in the higher layer (e.g., H.323) should be there to take care of > > this > > > situation." > > > That's just the reason why we have deleted the notion of ?Location > > Area > > > Identity (set of Network of Attachments associated)? and ?Temporary > > > Identity?. but added the notions of "change of NPOA or of H323 Point of > > > Attachment may need to be dealt with > > > within H323 scope". > > > I'd better see alias @" in the list of concepts used by H323 mobility > > > instead of "Temporary Id" that looks (for me with too much of a mobile > > > culture I admit) like the temporary Identifier allocated on radio to > > hide > > > the permanent user identity > > > Could you explain the need of paging > > > Best regards > > > L. Thiebaut > > > > > > > > -------------------------------------------------------------------------- > > > -------------------------------------------------------------------- > > > > > > > > > Hi, Everyone: > > > > > > We are in receipt of the contribution from Alcatel (MTD-107a: Contact - > > > Laurent Thiebaut). For the interest of time, I take the liberty to offer > > > my > > > comments. > > > > > > I fully agree with the proposal of Laurent that H.323 Mobility should > > > focus > > > only on the H.323 mobility layer. In fact, the terms of reference of the > > > H.323 mobility group has also confirmed this. However, some specific > > texts > > > that Laurent have proposed may create some confusions. Let me expalin as > > > follows : > > > > > > If the lower layer mobility (e.g., radio link or network layer) is > > > transparent to the H.323 layer, nothing needs to done in the H.323 > > > application layer. However, the lower layer mobility may cause an impact > > > on > > > the higher layer (e.g., H.323) as well. If it is so, the proper > > > abstraction > > > in the higher layer (e.g., H.323) should be there to take care of this > > > situation. > > > > > > For example, switching of cells (e.g., cellular IP) may not cause any > > > impact > > > in the H.323 layer. In this situation, this mobility is transparent to > > the > > > H.323 layer. In some situation, the swiching of cells may also cause an > > > impact on the H.323 layer (e.g., H.323 point of attachment). In this > > case, > > > resources of the H.323 layer should also be taken care-of accordingly. > > > > > > Temporary IDs may also be needed in the H.323 layer. Contributions are > > > provided why these IDs are needed in the H.323 layer. These are the > > alias > > > addresses and can have an astraction in the H.323 layer. That does NOT > > > mean > > > in anyway that the solution of the H.323 is becoming specific to the > > radio > > > link layer. > > > > > > Similarly, LRQ message sets have the addresses that have been abstracted > > > in > > > the H.323 layer. Contributions have been provided why the paging of the > > > LRQ > > > message is needed in the H.323 layer. > > > > > > (However, I agree with him that location area may NOT be needed in H.323 > > > because the concepts of H.323 zones/domains will be sufficient. In same > > > token, we also do not need the concept of cells in H.323.) > > > > > > I find that texts proposed in the contribution are too restrictive. > > > > > > Finally, I propose that Laurent should keep an eye to the H.323 solution > > > that will be agreed upon should be transparent to the lower layer (e.g., > > > radio link or network layer) as we make more progress in this area. > > > > > > Best regards, > > > Radhika R. Roy > > > AT&T > > > + 1 732 420 1580 > > > rrroy(a)att.com > > > > > > > > > > > > > > > > -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Re: Comments on MTD-107a
by Edgar Martinez [1] 14 Dec '99

14 Dec '99

Dear Radhika and Mr. Thiebaut, In reference to Alcatel's MTD-107a (v.s.) Motorola's MTD-305c. We (Motorola) would like to move 3GPP option 1 to a full IP solution within the H.323 mobility framework. Unlike MTD-107a, Motorola is working on one Universal IP solution that will support both fixed and mobile terminals and user and network services for voice, data and multi-media. Not just GPRS mobile data services. Right now 3GPP R'00 option 1 has two networks a GPRS and an IP network, which are shown side by side. 3GPP option 2 adds a third dimension a circuit switch side. Where 3GPP option 2 is composed of different three networks, GPRS, IP and Circuit switched. As matter of fact, UMTS R'99 has no IP, UMTS R'99 has the MSC and SSGN radio interfaces attached via an array of BSCs and RNCs and a mix of Iu-ps and Iu-cs connections. One can say that option 2 is just R'99 with access to some H.323 IP elements like a gateway and gatekeeper and that's all we get. See MTD-107a, MTD-08, 3GPP's TR23.922 and TR23.002 to see for yourself. The framework for MTD-305c is for the H.323 system to be able to interwork with the legacy network's both mobile and fixed systems, while also providing new technology and services to the IP network. "Roy, Radhika R, ALARC" wrote: > Hi, Laurent: > > Please see my reply provided below. > > My view point is: Let us keep doors open for all probable solutions. Let > people implement their solutions as they find optimal for their specific > environments. > > Best regards, > Radhika R. Roy > AT&T > > > -----Original Message----- > > From: Laurent.Thiebaut(a)alcatel.fr [SMTP:Laurent.Thiebaut@alcatel.fr] > > Sent: Monday, December 13, 1999 1:01 PM > > To: Roy, Radhika R, ALARC > > Cc: 'paul.k.reddy(a)intel.com'; 'vineet.kumar(a)intel.com'; > > 'jaakko.sundquist(a)nokia.com'; 'peeter.pruuden(a)nokia.com'; > > 'senthil.sengodan(a)nokia.com'; 'marc.roelands(a)siemens.atea.be'; > > 'martinze(a)cig.mot.com'; 'lpg019(a)email.mot.com'; 'orsic(a)lucent.com'; > > 'stephen.terrill(a)ericsson.com'; 'gosta.linder(a)lme.ericsson.se'; > > 'Anders.Svennevik(a)era.ericsson.se'; 'mike(a)synacom.com'; 'stu(a)synacom.com'; > > 'paul.jones(a)ties.itu.int'; 'baronson(a)acm.org'; > > Ameneh.Zahir-Emami(a)alcatel.fr; Nicolas.Tran(a)alcatel.fr > > Subject: RE: Comments on MTD-107a > > > > > > > > Hi Radhika, > > I do not understand what you mean by "take care-of some special needs > > in mobile environment" as a need for Temporary IDs. My understanding is > > that H.323 alias ("E.164, email, URL,and others" as you mention) are not > > modified when the user moves because > > it is these aliases that allow to reach the user even when the user > > moves (and its NPOA changes). Could you please clarify what you mean? > [Roy, Radhika R] What I envision that "Temporary ID" can also be > another " H.323 alias" considering the mobile environment. So, it is an > extension of the present H.323 alias addresses. > > > for paging: my understanding is that through a RRQ, the mobile gives > > the association between its alias(es) and its NPOA (IP) address to its > > Serving GK that stores the association in internal tables. When there is > > a mobile terminated call, thanks to > > HLF-VLF interactions (as described in Nokia's MTD104), the Serving GK @ > > is determined. Then the set-up message is sent to the Serving GK. Using > > the internal table populated at RRQ, the Serving GK sends the set-up > > message to the called mobile with the > > right NPOA (IP) address. This packet is received by the Access Network > > that may have to page the mobile, but this paging is transparent to H323. > > Could you please explain me what you see as wrong in the scenario I have > > given. > [Roy, Radhika R] This may be another alternative solution as you > have mentioned. At present, LRQ messages are sent between the GKs for > address resolution. Extending the same scenarios, paging of LRQs in mobile > environment may be needed. > > > Best regards > > Laurent T. > > -------------------------------------------------------------------------- > > - > > V Laurent Thiebaut tel: +33 (0)1 3077 0645 > > A L C A T E L e.mail:laurent.thiebaut@alcatel.fr > > -------------------------------------------------------------------------- > > - > > > > > > > > > > "Roy, Radhika R, ALARC" <rrroy(a)att.com> on 08/12/99 19:12:32 > > > > > > > > To: Laurent THIEBAUT/FR/ALCATEL@ALCATEL > > > > cc: "'paul.k.reddy(a)intel.com'" > > <paul.k.reddy(a)intel.com>, > > "'vineet.kumar(a)intel.com'" > > <vineet.kumar(a)intel.com>, > > "'jaakko.sundquist(a)nokia.com'" > > <jaakko.sundquist(a)nokia.com>, > > "'peeter.pruuden(a)nokia.com'" > > <peeter.pruuden(a)nokia.com>, > > "'senthil.sengodan(a)nokia.com'" > > <senthil.sengodan(a)nokia.com>, > > "'marc.roelands(a)siemens.atea.be'" > > <marc.roelands(a)siemens.atea.be>, > > "'martinze(a)cig.mot.com'" <martinze(a)cig.mot.com>, > > "'lpg019(a)email.mot.com'" <lpg019(a)email.mot.com>, > > "'orsic(a)lucent.com'" <orsic(a)lucent.com>, > > "'stephen.terrill(a)ericsson.com'" > > <stephen.terrill(a)ericsson.com>, > > "'gosta.linder(a)lme.ericsson.se'" > > <gosta.linder(a)lme.ericsson.se>, > > "'Anders.Svennevik(a)era.ericsson.se'" > > <Anders.Svennevik(a)era.ericsson.se>, > > "'mike(a)synacom.com'" <mike(a)synacom.com>, > > "'stu(a)synacom.com'" <stu(a)synacom.com>, > > "'paul.jones(a)ties.itu.int'" > > <paul.jones(a)ties.itu.int>, "'baronson(a)acm.org'" > > <baronson(a)acm.org>, Ameneh > > ZAHIR-EMAMI/FR/ALCATEL@ALCATEL > > > > > > > > Subject: RE: Comments on MTD-107a > > > > > > > > > > > > > > Hi, Laurent: > > > > Paging: A simple answer will be to locate the mobile user for resolving > > the > > address needed in the LRQ message. > > > > Temporary ID: H.323 aliases are open enough to include E.164, email, URL, > > and others. In the same token, if mobile users also need to introduce > > other > > IDs similar such as Temporary IDs, Personal IDs, etc. to , we should be > > open to those suggestions. > > > > Best regards, > > Radhika R. Roy > > AT&T > > > > > -----Original Message----- > > > From: Laurent.Thiebaut(a)alcatel.fr [SMTP:Laurent.Thiebaut@alcatel.fr] > > > Sent: Wednesday, December 08, 1999 11:09 AM > > > To: Roy, Radhika R, ALARC > > > Cc: Roy, Radhika R, ALARC; 'paul.k.reddy(a)intel.com'; > > > 'vineet.kumar(a)intel.com'; 'jaakko.sundquist(a)nokia.com'; > > > 'peeter.pruuden(a)nokia.com'; 'senthil.sengodan(a)nokia.com'; > > > 'marc.roelands(a)siemens.atea.be'; 'martinze(a)cig.mot.com'; > > > 'lpg019(a)email.mot.com'; 'orsic(a)lucent.com'; > > > 'stephen.terrill(a)ericsson.com'; 'gosta.linder(a)lme.ericsson.se'; > > > 'Anders.Svennevik(a)era.ericsson.se'; 'mike(a)synacom.com'; > > 'stu(a)synacom.com'; > > > 'paul.jones(a)ties.itu.int'; 'baronson(a)acm.org'; > > > Ameneh.Zahir-Emami(a)alcatel.fr > > > Subject: Re: Comments on MTD-107a > > > > > > > > > > > > Hi, Everyone, this is just to answer to Roy's remark > > > Hi Radhika, > > > I agree with you when you say that "the lower layer mobility may > > cause > > > an impact on > > > the higher layer (e.g., H.323) as well. If it is so, the proper > > > abstraction > > > in the higher layer (e.g., H.323) should be there to take care of > > this > > > situation." > > > That's just the reason why we have deleted the notion of ?Location > > Area > > > Identity (set of Network of Attachments associated)? and ?Temporary > > > Identity?. but added the notions of "change of NPOA or of H323 Point of > > > Attachment may need to be dealt with > > > within H323 scope". > > > I'd better see alias @" in the list of concepts used by H323 mobility > > > instead of "Temporary Id" that looks (for me with too much of a mobile > > > culture I admit) like the temporary Identifier allocated on radio to > > hide > > > the permanent user identity > > > Could you explain the need of paging > > > Best regards > > > L. Thiebaut > > > > > > > > -------------------------------------------------------------------------- > > > -------------------------------------------------------------------- > > > > > > > > > Hi, Everyone: > > > > > > We are in receipt of the contribution from Alcatel (MTD-107a: Contact - > > > Laurent Thiebaut). For the interest of time, I take the liberty to offer > > > my > > > comments. > > > > > > I fully agree with the proposal of Laurent that H.323 Mobility should > > > focus > > > only on the H.323 mobility layer. In fact, the terms of reference of the > > > H.323 mobility group has also confirmed this. However, some specific > > texts > > > that Laurent have proposed may create some confusions. Let me expalin as > > > follows : > > > > > > If the lower layer mobility (e.g., radio link or network layer) is > > > transparent to the H.323 layer, nothing needs to done in the H.323 > > > application layer. However, the lower layer mobility may cause an impact > > > on > > > the higher layer (e.g., H.323) as well. If it is so, the proper > > > abstraction > > > in the higher layer (e.g., H.323) should be there to take care of this > > > situation. > > > > > > For example, switching of cells (e.g., cellular IP) may not cause any > > > impact > > > in the H.323 layer. In this situation, this mobility is transparent to > > the > > > H.323 layer. In some situation, the swiching of cells may also cause an > > > impact on the H.323 layer (e.g., H.323 point of attachment). In this > > case, > > > resources of the H.323 layer should also be taken care-of accordingly. > > > > > > Temporary IDs may also be needed in the H.323 layer. Contributions are > > > provided why these IDs are needed in the H.323 layer. These are the > > alias > > > addresses and can have an astraction in the H.323 layer. That does NOT > > > mean > > > in anyway that the solution of the H.323 is becoming specific to the > > radio > > > link layer. > > > > > > Similarly, LRQ message sets have the addresses that have been abstracted > > > in > > > the H.323 layer. Contributions have been provided why the paging of the > > > LRQ > > > message is needed in the H.323 layer. > > > > > > (However, I agree with him that location area may NOT be needed in H.323 > > > because the concepts of H.323 zones/domains will be sufficient. In same > > > token, we also do not need the concept of cells in H.323.) > > > > > > I find that texts proposed in the contribution are too restrictive. > > > > > > Finally, I propose that Laurent should keep an eye to the H.323 solution > > > that will be agreed upon should be transparent to the lower layer (e.g., > > > radio link or network layer) as we make more progress in this area. > > > > > > Best regards, > > > Radhika R. Roy > > > AT&T > > > + 1 732 420 1580 > > > rrroy(a)att.com > > > > > > > > > > > > > > > > -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

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

13 Dec '99

Hi, Everyone: Here is the detail of tomorrow's H.323 mobility conference call: Conference Call Information and Agenda Date: December 14,1999 Time: 8:00 AM to 10:00 AM (Pacific Standard Time (PST)) Reservation # 13814047 Number port reserved: 30 Ports Conference Call Bridge call in number: +1 (212)-293-3602 Passcode: 1767395 We provide our sincere thanks to IMTC (Senthil Sengodan, Nokia, senthil.sengodan(a)nokia.com) for facilitating the conference call though providing ports. We also provide thanks to Paul K. Reddy of Intel for conducting the conference and taking notes. Note: All participating companies are welcome to submit Contributions (in addition to previous contributions), which Pertains to 6b, 6c and 7a. The contributions, which are not reviewed during last conference call will be automatically carried over to the December 14, 1999 conference call. Please send your requests for new MTD number for each new contribution you planned to submit for the December 14, 1999 conference to Mr. Paul K. Reddy at paul.k.reddy(a)intel.com. Once you are assigned with a MTD number, please forward the contribution to Mr. Paul K. Reddy to upload all your contributions as zipped files to the reflector at ftp://standard.pictel.com/avc-site/Incoming/H.323_Mobility/ConfCall12141999 directory. Agenda: 1. Call to Order & Opening Remarks 2. Attendance Registration 3. Introduction and Numbering of Contributions: 4. Agenda Review and Approval: MTD-301 4a. Review H.323 Mobility Ad Hoc Meeting report: MTD-302 5. Correspondence to other standards groups TIPHON, IMTC, IMT-2000 ITU-T SG-11, 3GPP for correspondence 6. Old Business MTD-110 (already reviewed) 6a. review Carry over contributions 6b. H.323 Mobility Functional Entities (HLF, VLF, AuF, IWF):MTD-104, MTD-105, MTD-107, MTD-111, MTD-112 6c. H.323 Mobility Architecture: MTD-103, MTD-106 6d. 7. New Business 7a. H.323 Interworking with PLMNs (H.246 Annex E scope, Goal and work plan):MTD-109, MTD-108 8. Meeting Schedule 8a. Discuss next conference call meetings 9. Review Assignments 10. Review Workplan 11. Open Discussion 12. Adjourn ----------------------------------------------------------------------- December 8, 1999 Conference Call Meeting Summary 1. Call to Order & Opening Remarks Conference call started at 8:05 am, Monday, December 8, 1999 hosted by IMTC (International Multimedia Teleconferencing Consortium). 2. Attendance Registration See roster below. Introduction and Numbering of Contributions: Contributions which were upload and are available for review at: http://standards.pictel.com/ftp/avc-site/Incoming/H323_Mobility/ConfCall1214 1999 and http://standards.pictel.com/ftp/avc-site/9910_Red 3. Agenda Review and Approval Contribution MTD-201 (Agenda, was introduced by conference call chair) reviewed and accepted as modified (Assigned the AT&T new contribution MTD-111 to agenda item 6b) 4. Review H.323 Mobility Ad Hoc Meeting report: MTD-202 Contribution MTD-202 - Conference call chair introduced the last conference call report and reviewed and approved with no modifications. 5. Correspondence to other standards groups none 6. Old Business : MTD-110 none 6a. review Carryover contributions 6b. H.323 Mobility Functional Entities (HLF, VLF, AuF, IWF):- MTD-104, MTD-105, MTD-107, MTD-111 Contribution MTD-104: Nokia continued the introduction of the H.323 Annex H functional architecture and reference points document. · After much discussion on the new the interfaces between HLF, VLF, AuF and existing H.323 network, the group agreed that H.323 Mobility architecture figure 1 from Nokia's contribution shall be accepted with the following two additions to the figure and then added into H.323 Annex H baseline document. 1. Add new interface from Visiting network VLF to Home network HLF 2. Also, add the Gateway and show the appropriate interface in the H.323 Mobility architecture figure · Nokia introduced the rest of the contribution with scenarios as FYI at this point. · Nokia was given the assignment to update the Architecture figure and send it to the H.323 Annex H editor to include in the H.323 Annex H baseline document. Contribution MTD-111: was introduced by AT&T, which is related to the Architecture document. Which was discussed and accepted as information only. Contributions MTD-105: was introduced by Ericsson, the group asked Ericsson to modify and resubmit the document after showing the exact text changes to H.323 Annex H definition document. Contribution MTD-106 and MTD-107: Alcatel introduced the MTD-106 and MTD-107 together. Due to the lack of time during December 8,1999 conference call, Alcatel contributions will be carried over to next conference call. 6c. H.323 Mobility Architecture: MTD-103, MTD-106 Contributions MTD-103 is carried over to next conference call, which is scheduled on December 14,1999. 6d. 7. New Business 7a. H.323 Interworking with PLMNs (H.246 Annex E scope, terms of reference and work plan): MTD-109, MTD-108 Contributions MTD-108 and MTD-109 are carried over to next conference call, which is scheduled on December 14,1999. 8. Meeting Schedule 8a. Discuss next conference call meetings: H.323 Mobility Ad Hoc group agreed to have next conference call on December 14, 1999 from 8:00 AM to 10:00 AM (Pacific Standard Time (PST)) and IMTC to make arrangement for the conference call bridge. 9. Review Assignments None 10. Review Workplan None 11. Open Discussion None 12. Adjourn Conference call Meeting adjourned Wednesday, December 08, 1999 at 10:10 AM (PST). Table 1: Contributions submitted and carried over from previous Conference Call for H.323 Mobility Conference Call on December 08, 1999 Previous MTD MTD Source Title MTDs in the Conf. Call, Dec., 08, 1999 201 Intel H.323 Mobility Ad Hoc Group Conference Call Agenda & Bridge information. 202 Intel H.323 Mobility Ad Hoc Group Nov., 29,1999 Conference call Report 5a 103 Motorola Integrating 3GPP's option-1 architecture into the H.323 wireless IP mobility system and a full migration from GPRS to a Multimedia IP network proposal 6 104 Nokia H.323 Annex H Functional Architecture and Reference Points 7 105 Ericsson "Definition of terms for H.323 Annex H". 8 106 Alcatel Integrating 3GPP's architecture into the H.323 wireless IP mobility system 9 107 Alcatel Clear Split of functions between Call Control and (radio) Access networks /Annex-H (User, Terminal and Service Mobility in H.323) 10a 108 Motorola IMT-2000 Global Roaming and Interworking Scenarios 13 109 Intel H.246 Annex E Goal and Workplan 03b 110 Motorola Updated H.323 Annex H document 111 AT&T H.323 Annex H Functional Architecture and Reference Points 112 AT&T Extension of H.323 Protocol for Mobility Table 2: Attendance Registration for H.323 Mobility Conference Calls Name Company Phone FAX E-Mail Paul K. Reddy Intel Corporation 503-264-9896 503-264-3375 paul.k.reddy(a)intel.com Vineet Kumar Intel Corporation 503-264-3439 503-264-3375 vineet.kumar(a)intel.com Jaakko Sundquist Nokia jaakko.sundquist(a)nokia.com Peeter Pruuden Nokia peeter.pruuden(a)nokia.com Senthil Sengodan Nokia senthil.sengodan(a)nokia.com Pekka Rissanen Nokia pekka.ja.rissanen(a)nokia.com Radhika R. Roy AT&T rrroy(a)att.com Marc Roelands Siemens marc.roelands(a)siemens.atea.be Edgar Martinez Motorola martinze(a)cig.mot.com Paul Guram Motorola lpg019(a)email.mot.com Milo Orsic Lucent Technology orsic(a)lucent.com Stephen Terrill Ericsson stephen.terrill(a)ericsson.com Gösta Linder Ericsson gosta.linder(a)lme.ericsson.se Anders Svennevik Ericsson Anders.Svennevik(a)era.ericsson.se Paul E. Jones Cisco +1 919-392-6948 +1 919-392 -6801 paul.jones(a)ties.itu.int Manjari Asawa Cisco masawa(a)cisco.com Barry Aronson Toshiba Corp. baronson(a)acm.org Laurent Thiebaut Alcatel +33 (0)1 3077 0645 laurent.thiebaut(a)alcatel.fr Nicolas Tran Alcatel Nicolas.Tran(a)alcatel.fr Ameneh Zahir-Emami Alcatel Ameneh.Zahir-Emami(a)alcatel.fr Note: Please check your information and email it to paul.k.reddy(a)intel.com with your phone numbers and any corrections Best regards, Radhika R. Roy, AT&T H.323 Ad Hoc Mobility Group +1 732 420 1580 rroy(a)att.com

1 0

Re: [Robustess] D.225 from Chile
by Maureen Stillman 13 Dec '99

13 Dec '99

Enclosed is the document you requested. -- maureen -----Original Message----- From: EXT Orit Levin [mailto:orit@radvision.com] Sent: Monday, December 13, 1999 2:05 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: [Robustess] D.225 from Chile Hello Maureen and the others! Could you, please, send to me the full D.225 from Chile. Thanks a lot. Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com <http://www.radvision.com> orit(a)radvision.com <mailto:orit@radvision.com>

1 0

[Robustess] D.225 from Chile
by Orit Levin 13 Dec '99

13 Dec '99

Hello Maureen and the others! Could you, please, send to me the full D.225 from Chile. Thanks a lot. Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com

1 0

H.323 Annex L Conference Call Details
by Dave Walker 13 Dec '99

13 Dec '99

Here are the details and the agenda for this Wednesday's conference call on H.323 Annex L. I've provided some initial thoughts on the agenda items. ---------------------------------------------------------- Call Details ------------ date - 15 December 1999 (Wednesday) time - 11:00 EST phone - 1 800 267 6244 (North America only, sorry) 1 613 592 2122 (international) You'll reach the Mitel switchboard - ask them for Dave Walker's conference call! ---------------------------------------------------------- Agenda ------ 1. introduction of participants 2. positioning Annex L in relation to other flavours of H.323 2.1. H.450 H.450 describes peer-to-peer functional signalling for a well-defined set of supplementary services. Interoperability of non-standard services is limited. Definition of new services is a lengthy process. 2.2. H.323 H.323 supports both peer-peer and limited client-server models with limited support for supplementary services. 2.3. H.248 H.248 is purely client-server typically without any knowledge of call signalling. There is no explicit linkage to H.323 although H.323 may be used transparently to the MG. Given support for appropriate pre-defined packages, it should be possible to attain interoperability of non-standard features. Entities supporting H.248 do not necessarily interwork with H.323 entities. 2.4. H.323 Annex K Annex K offers flexibility of services for EPs which support HTML/WML. Limited control over media streams is available except via nonstandard APIs. Annex L offers extended control opportunities to Annex K based systems. 2.5. H.323 Annex L Annex L enables the interoperability of non-standard features that is offered by H.248, while ensuring compatibility with existing H.323 networks. Annex L is designed to enable full flexibility of non-standard supplementary services to H.323 version 1 and version 2 EPs. 3. requirements 3.1. level of backwards compatibility Explicit support for Annex L is via the presence of suitably encoded nonStandardControl in H323-UU-PDU (note that I still want to rename this field to alternateControl). I insist that v1 and v2 EPs be able to participate in the control aspect of the protocol if they support Keypad and Display and provide some means to inject desired escape sequences. 3.2. IA5/Unicode Display and Keypad require IA5. The requirement for Unicode is undeniable. IA5 is the same as U+0000 to U+00FF. Display and Keypad coding shall be IA5 unless the recieving entity has previously indicated support for Unicode. Use of Unicode could be negociated (or configured), or each usage could be tagged. 3.3. graphics support Sophisticated support can come from HTML. Do we need anything else? I think simple support for a bit-mapped display could be easily added, do we need it? and what protocol should be used? 3.4. HTML/WML based My belief is that Annex K addresses this entirely. While it would be easy to to add "HTML" or something as a type of capability, I don't think it reasonable to attempt to transport these pages/decks via H.323 signalling. So the option seems to be to add a mechanism for sending URLs in Annex L. The only advantage this would seem to present is the use of fields that exist in v1 and forward. 3.5. FA and FI Adding Feature Activation and Feature Indication. These are defined in Q.932 as Feature Key protocol. As defined there, two new information elements would be required. Alternatively, the information otherwise provided by these IEs could be text-encoded in the Keypad and Display IEs. 4. architectural models This is kind of addressed by item 2 in the agenda. We need some diagrams illustrating this and also some presenting locations of Feature Server with respect to controlled EPs and other H.323 entities. 5. document restructure - All of the ASN.1 encoding should be moved to its own section. - Description of all of the fields is required (taking H.225.0 as an example). 6. enhancements/changes to existing protocol (APC-1660) 6.1. text based One issue is the limiting size of Keypad and Display. The ability to handle larger sizes is a capability that could be negoctiated. Another issue is whether management aspects should be text based or ASN.1 based (as presented in APC-1660). 6.2. graphics? 6.3. HTML/WML beyond Annex K? 7. work plan Needs a section describing the procedures, as well as a few examples including full signalling MSCs. Volunteers? We need a section that describes minimal functionality (one or two flavours of).

1 0

[Robustness] conference call reminder -- Tuesday, Dec. 14 11AM ES T USA
by Maureen Stillman 13 Dec '99

13 Dec '99

The conference call for robustness, arranged by Nokia, 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. Hope to talk with you on Tuesday. -- 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: H.323 meeting:?
by Roy, Radhika R, ALARC 12 Dec '99

12 Dec '99

Hi Ed: December 14: 11-1 PM EST USA. IMTC will provide the conf port. Paul is supposed to let me know in detail. I told Paul that I would request you to conduct the meeting in case he could not attend the meeting from Japan. Thanks, Radhika > -----Original Message----- > From: Edgar Martinez [1] [SMTP:martinze@cig.mot.com] > Sent: Sunday, December 12, 1999 2:56 PM > To: Roy, Radhika R, ALARC; H.323 Mobility > Subject: H.323 meeting:? > > Hi Radhika, > > I like to know when is the next conference call. > > -- > 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 meeting:?
by Edgar Martinez [1] 12 Dec '99

12 Dec '99

Hi Radhika, I like to know when is the next conference call. -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Re: [Robustness] Conference Call
by Kumar, Vineet 10 Dec '99

10 Dec '99

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

Re: I-D ACTION:draft-ietf-megaco-reqs-09.txt
by Tom-PT Taylor 10 Dec '99

10 Dec '99

I propose WG Last Call based on this document, with the expiry two weeks hence (24 December). Changes from the previous version are as follows: - removed reqt 5.6 c) Support general test capabilities, for example loopbacks through the MG to test DSP operation. It was agreed that inward loopbacks are outside the scope of the protocol - they are not part of call control, so would be handled by some other maintenance protocol. Thus the above requirement is deleted. - reqt 5.7 a) - changed word call to connection - table in section 11 - removed wiretap - reqt 11.1.3.1 a) rewording of 2nd bullet on addressing - didn't mean wildcarding, meant instead allowing the gateway to choose (part of) the identifier The references need to be completed still, and there may be an editor's note or two that should still come out. > -----Original Message----- > From: Internet-Drafts(a)IETF.ORG [SMTP:Internet-Drafts@IETF.ORG] > Sent: Friday, December 10, 1999 8:08 AM > To: MEGACO(a)STANDARDS.NORTELNETWORKS.COM > Subject: I-D ACTION:draft-ietf-megaco-reqs-09.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Media Gateway Control Working Group of > the IETF. > > Title : Media Gateway control protocol architecture and > requirements > Author(s) : N. Greene, M. Ramalho, B. Rosen > Filename : draft-ietf-megaco-reqs-09.txt > Pages : 45 > Date : 09-Dec-99 > > TThis document describes protocol requirements for the Media Gateway > control protocol between a Media Gateway Controller and a Media Gateway. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-megaco-reqs-09.txt > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-megaco-reqs-09.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv(a)ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-megaco-reqs-09.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. << Message: >>

1 0

Question! MCU cascading
by Jun-young Heo 10 Dec '99

10 Dec '99

Hi everyone! I have a question about MCU cascading. I know MC cascading from reading H.323v2 recommendation. But, i'm not sure how to control media distribution. I think MasterMC knows only capset of local terminals connected directly. so, MasterMC can't make a SCM(selected communication mode) about all terminals. How MasterMC knows it? Eventually, I want to know about MP cascading excatly. One more question. Is SessionID in message related to logical channel and CommunicationModeCommand, distributed by MC? H.245 recommendation says, "Only the master can create the session identification." at p.81. But, Netmeeting and ViewStation which I tested create session ID itselft by convention(Audio:1, Video:2). Is it right? I wish experts advise to me. thanks for reading. bye.

1 0

[Robustness] RADVision's input for the conference call
by Orit Levin 09 Dec '99

09 Dec '99

Hello Maureen and all the others! Please count on two RADVision's legs for the conference: one for myself and the other for RADVision Ltd. in Israel. I am attaching our input to the conference call. The paper discusses problems and possible solutions for GK failure in the middle of managing routed calls. Best Regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com

1 0

[Robustness] Conference Call
by Steve.Edgar＠NOKIA.COM 09 Dec '99

09 Dec '99

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 Annex L Conference Call Announcement
by Dave Walker 09 Dec '99

09 Dec '99

There will be a conference call next week to discuss the evolution of the H.323 stimulus protocol (Annex L), the most recent draft being APC-1660. The call will be on Wednesday, December 15 at 11:00 AM EST. I will be publishing call coordinates and an agenda on Monday. I would appreciate if everyone interested in participating would send me mail so that I can reserve a sufficient number of ports. Regards, Dave Walker Mitel Corporation Ontario, CANADA

2 1

FW: H.323 questions
by Roy, Radhika R, ALARC 09 Dec '99

09 Dec '99

Hi, Everyone: I am enclosing Ben's questions to the SG16 members for their answer because I believe that there are many members who might better insights for taking part in H.323 development. Best regards, Radhika R. Roy AT&T +1 732 420 1580 > -----Original Message----- > From: ben-w(a)jlonline.com [SMTP:ben-w@jlonline.com] > Sent: Thursday, December 09, 1999 4:09 AM > To: Roy, Radhika R, ALARC > Subject: H.323 questiones > > Hi Mr.Radhika , > I have some questiones about Ad Hoc Conference defined in ITU-T > Recommendation H.323. > > H.323 Section 8.4.3.1 states: > > Endpoint 1 creates a conference with Endpoint 2 as follows: > A1) Endpoint 1 sends a Setup message to Endpoint 2 containing a > globally unique CID ? N and conferenceGoal = > create according to the procedure in 8.1. > A2) Endpoint 2 has the following options: > .... > A2d) If Endpoint 2 is an MC(U) that hosts multiple conferences and > wishes to provide Endpoint 1 with a choice > of conferences to join, it can send a Facility message > indicating conferenceListChoice and a list of > conferences that Endpoint 1 may choose from. The list of > conferences is sent as part of the Facility- UUIE. > For backward compatibility, with version 1 endpoints, > conference lists are only provided if the > protocolIdentifier in Endpoint 1's Setup message indicates > that it is version 2 or above. > > Upon receipt of this conferenceListChoice Facility message, > Endpoint 1 may join a conference from the list > of conferences by sending a new Setup message to the MC(U) on > the Call Signalling Channel which contains > the selected CID and which has conferenceGoal = join. If > Endpoint 1 chooses not to join any of the listed > conferences, it shall send a Release Complete message to the > MC(U). > > 1. When EndPoint 1 calling EndPoint 2(MCU),MCU "wishes to provide > Endpoint 1 ...",what > does it mean?Can't any endpoint get a list of conferences?What > decides it's wish? > CUSeeMe Pro and NetMeeting get diferent list of conferences from > MeetingPoint(MCU), I > called MeetingPoint too,but I can't get a list of conferences,I > connected with it just like an > endpoint.Why?Does it mean I have created a new conference in a > MCU?! > 2. If an EndPoint is a standard H.323 client,and MCU provide it with > a list conferences,then it > has only two choices: join or release.It means the EndPoint can't > create a conference!How to > create a conference in a MCU?Who is the initiator? > 3. If I want to learn details about MCU calling procedures,what other > protocols should I study? > > The questiones puzzle me,can you help me ? > > Thanks, > Ben. > email: ben-w(a)jlonline.com <mailto:ben-w@jlonline.com>

2 1

Re: H.245 "receiveAndTransmitAudioCapability" and symmetric codec s
by Tzvi Kasten 09 Dec '99

09 Dec '99

Paul, Regarding your two questions: 1. Do we need a way to express symmetric codecs. - Yes of course! 2. Will using receiveAndTransmit caps for this cause problems - Considering that vendors are already using receiveAndTransmit caps for this and considering that assuming that the endpoint is signaling symmetric codecs in a case where it is not will not break anything in terms of interoperability I would think that the safest way to act when receiving receiveAndTransmit caps is to assume that the capability is symmetrical. As this seems the most convenient way to address the issue of symmetrical codecs and as vendors have already interpreted it and are using it this way I would suggest the document be updated to have the receiveAndTransmit caps be the way to express symmetric codecs. Regards Tzvi Kasten Networking Infrastructures Group Manager Research & Development VCON Ltd. Tel: 09-9590020 ( 972-9-959-0020) Email: zvik(a)vcon.co.il http://www.vcon.com > -----Original Message----- > From: Paul Long [SMTP:plong@SMITHMICRO.COM] > Sent: Tuesday, December 07, 1999 3:35 PM > To: h323implementors(a)imtc.org > Subject: RE: H.245 "receiveAndTransmitAudioCapability" and symmetric > codecs > > Paul, > > The capability table is a sort of artist's pallet, containing all the > colors > that he or she may use. The descriptors, on the other hand, are the > brushes > that mix the colors and apply them to the canvas. Without descriptors, no > modes are expressed--the canvas is blank. (Hey, I think I could write a > haiku about this. :-) ) It is H.245 and not H.323 that stipulates this > (B.2.2.2/H.245v5: "CapabilityDescriptors are used to indicate a terminal's > capability to transmit and receive"), so a referencing Recommendation > would > have to override H.245 to avoid using descriptors, none of which do, as > far > as I know. > > IMO, the purpose of a receiveAndTransmit cap is at minimum to provide a > shorthand replacement for separate receive and transmit caps. From what > I've > seen, that's what vendors by and large use them for. I don't think the > H.245 > authors ever intended receiveAndTransmit caps to stand alone, unreferenced > in the capability table. Moreover, I believe that the authors intended > receiveAndTransmit caps to express symmetric codecs, although this is > clearly not stated in H.245 (or H.323). Finally, I believe we could add > normative text to H.245 that says that, without the slightest possibility > of > breaking existing implementations, receiveAndTransmit caps shall express > symmetric codecs. I've worked through different scenarios and have > convinced > myself of this. > > The two questions I pose to this reflector are, 1) do you agree that we > need > some way to express symmetric codecs and 2) can you see any way that > requiring receiveAndTransmit caps to express this could cause existing > implementations to break or make things any worse than they already are, > i.e., one-way audio? Here's an important point: I am saying that this > _cannot_ break an existing implementation not that it _probably_ won't. > > (Should we move this discussion to the ITU-SG16(a)MAILBAG.INTEL.COM > reflector?) > > Paul Long > Smith Micro Software, Inc. > > -----Original Message----- > From: Paul E. Jones [mailto:paul.jones@ties.itu.int] > Sent: Monday, December 06, 1999 11:33 PM > To: Karl.Klaghofer(a)icn.siemens.de; h323implementors(a)imtc.org > Subject: Re: H.245 "receiveAndTransmitAudioCapability" and symmetric > codecs > > > Karl, > > Here's my interpretation on this topic: > > To indicate simultaneous capabilities, an endpoint will normally send a > capability descriptor table with the transmit and receive capabilities. > Each table entry will list the codecs that may be used simultaneously. > The > remote endpoint may select a single descriptor table entry to use when > selecting channels to open, but may not select one codec from one table > entry and another from another table entry. > > Here's a section from 6.2.8.1/H.323 on this topic: > > --- BEGIN > The terminal's total capabilities are described by a set of > capabilityDescriptor structures, each of which is a single > simultaneousCapabilities structure and a capabilityDescriptorNumber. By > sending more than one capabilityDescriptor, the terminal may signal > dependencies between operating modes by describing different sets of > modes > which it can simultaneously use. For example, a terminal issuing two > capabilityDescriptor structures, one { {H.261, H.263}, {G.711, G.723.1, > G.728} } as in the previous example, and the other { {H.262}, {G.711} }, > means the terminal can also operate the H.262 video codec, but only with > the > low-complexity G.711 audio codec. > --- END > > Inside a given table entry, the endpoint will indicate it's capability > to > transmit G.711, for example, and receive G.711. Rather than insert two > capabilities-- one for transmit capability and one for receive > capability-- > the endpoint will provide a single "receiveAndTransmitAudioCapability". > If > this "combined" capability did not exist, the endpoint could just > examine > the capability descriptor tables looking for descriptor table entries > that > had an acceptable transmit and receive capability and work within that > context. > > Perhaps the main use for the "receiveAndTransmitAudioCapability" is the > case > when there is no capability descriptor tables is transmitted at all. > Suppose you have an audio device that can do G.723 and G.711, but only > one > at a time. Rather than build a capability descriptor table that looks > like > this: > > {G.711 Receive, G.711 Transmit} > {G.723 Receive, G.723 Receive} > > one could simply send over two capabilities, one for G.723 and one for > G.711, that are both "receiveAndTransmitAudioCapabilities". That may > have > been the intention of the sentence you quote below. However, I would > not > that this not legal in H.323. Specifically, H.323 says that ``all H.323 > terminals shall transmit at least one capabilityDescriptor structure.'' > Perhaps this text was inserted to allow other device types other than > H.323 > to avoid using descriptors in simple cases. > > I hope this helps... and is consistent with others' views. > > Paul > > ------------------------------------------------------------------------- > for list subscription instructions, > send email to h323implementors-request(a)imtc.org with text "info"

1 0

FW: Contribution for Conf Call on December 14
by Roy, Radhika R, ALARC 08 Dec '99

08 Dec '99

The SG16 mail server might be working now. > -----Original Message----- > From: Roy, Radhika R, ALARC > Sent: Wednesday, December 08, 1999 3:35 PM > To: Roy, Radhika R, ALARC; 'paul.k.reddy(a)intel.com'; > 'vineet.kumar(a)intel.com'; 'jaakko.sundquist(a)nokia.com'; > 'peeter.pruuden(a)nokia.com'; 'senthil.sengodan(a)nokia.com'; > 'marc.roelands(a)siemens.atea.be'; 'martinze(a)cig.mot.com'; > 'lpg019(a)email.mot.com'; 'orsic(a)lucent.com'; > 'stephen.terrill(a)ericsson.com'; 'gosta.linder(a)lme.ericsson.se'; > 'Anders.Svennevik(a)era.ericsson.se'; 'mike(a)synacom.com'; 'stu(a)synacom.com'; > 'paul.jones(a)ties.itu.int'; 'baronson(a)acm.org'; > 'laurent.thiebaut(a)alcatel.fr'; 'Ameneh.Zahir-Emami(a)alcatel.fr' > Cc: 'Dale.Skran(a)ascend.com'; 'ggf(a)lucent.com'; 'okubo(a)GITI.OR.JP' > Subject: Contribution for Conf Call on December 14 > > Hi, Everyone: > > I am enclosing a contribution for the upcoming conference call on December > 14. > > This is a follow-up discussion of today's conference call. As I explained, > there are three distinct areas where we need to focus to develop the H.323 > mobility protocol. This contribution describes three distinct areas. For > each area contributions are needed. However, some contributions have > provided a complete solution in one of the areas. There contributions need > to be discussed in great detail immediately. For example, AT&T's > contributions - APCs-1651/1652. Similar is the case for other > contributions. > > I am also providing this contribution to all members so that all members > provide their comments immediately. > > Best regards, > Radhika R. Roy > AT&T > +1 732 420 1580 > rrroy(a)att.com > <<MTD-y_ATT.doc>> > > PS: SG16 email reflector is still down. >

1 0

ITU-SG16 Mail List Active Again
by Meyer, Greg W 08 Dec '99

08 Dec '99

Hi: I've discovered that mail lists are like children - they seem to know when you're not looking and will do something you don't want them to. In this case, I was away from my email for several days and that's when this mail reflector decided to have problems. An endless loop caused LISTSERV to stop. I've deleted the offending subscriber and the list should be back online now. My apologies for any inconvenience. Greg Meyer Intel Corporation mailto:greg.w.meyer@intel.com +1.503.264.9506

1 0

IGNORE THIS EMAIL: testing to see if this reflector is working
by Kumar, Vineet 08 Dec '99

08 Dec '99

testing to see if this reflector is working

1 0