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

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