- sg16-avd - lists.packetizer.com

Lessons learned from H.248/Megaco collaboration
by Greg Ratta 28 Feb '00

28 Feb '00

As we step back from the events of the recent interactions of the ITU and the IETF concerning the "collaboration" on the specification of H.248 / MEGACO, it is clear - at least to me - that there is opportunity for improvement in the manner in which such collaboration is executed. I have purposefully delayed the transmission of this message to allow some reduction of the tension; however, it is important that this issue be addressed before we forget entirely, because I fear that two potential results could be either resistance to any future collaboration or the establishment of a rigid 'one size fits all' process. Either of these results would be detrimental to the operations of both organizations and to the needs of the industry and its consumers. It surprised me that, even at the final hours of determination of the ITU specification, there was no written agreement between the management teams of the respective organizations. In horror, I watched the various collections of individuals spinning towards conclusions without a common understanding of what agreements existed, or what the next step should be in the sister organization (and sometimes in their own organization!), or how to reach the end game. My conclusion is that the single most effective process improvement would be to require that an agreement on the process / project plan be written down and signed-off by the "appropriate management team" of the two organizations at the start of any future collaboration. TSAG and the ISOC VP for Standards should draw up this requirement and indicate what the "appropriate management team" means. Such an agreement would allow the leadership to manage the expectations of their respective organizations and form a structure for the front line - essentially volunteer - group leaders to follow. My comments should not be mis-interpretted as a criticism of any one - or collection - of individuals; we all share some level of culpability for the manner in which past events have played out. My desire is to improve the chance of success in future collaboration. Success for me means not only achieving the most technically correct and optimal specification, but respecting the dignity of all the participants and the processes of the involved organizations. Greg Ratta, Vice Chairman, ITU-T WP 1/11, Broadband Signalling Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta(a)lucent.com

1 0

Re: In Defense Of Cooperation
by Roy, Radhika R, ALARC 28 Feb '00

28 Feb '00

Hi, Everyone: Like Mike Buckley, Bob Callaghan has also made excellent points. Both have provided due credits to the people who worked hard to make it happen. In the end, the whole world has been benefited. The final credit belongs to all people of the two great standard organizations: ITU-T and IETF. So far the IP Telephony is concerned, it appears that both ITU-T and IETF have to work cooperatively in many areas for the foreseeable future because they need each other for interworking among their standards. It is a need for the interest of the users of the whole world. Keeping the great spirit, let us see how we can work better in the future. As per suggestion of Bob, we would request Tom to have a post analysis what we need to have for more successes like this overcoming the cultural clashes between the two great organizations for the benefit of the international community. Best regards, Radhika R. Roy AT&T (732) 420 1580 rrroy(a)att.com > -----Original Message----- > From: Callaghan, Robert [SMTP:Robert.Callaghan@ICN.SIEMENS.COM] > Sent: Monday, February 28, 2000 3:21 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: In Defense Of Cooperation > > Tom, > > I have to agree that the H.248/Megaco project, in the end, is a success. > And much of the success is the process and cultural knowledge that was > gained. Yes, at this point, everyone is suffering some pain. However, > very little greatness is gained without pain. > > The group culture and dynamic is very different between the ITU-T and the > IETF. It is hard for anyone to gain trust in a partner, when you do not > know or understand what the partner is doing. If you don't understand > what a partner is doing, can you trust that you understand what he is > thinking? (YES; but with time and effort!) > > Again, I think that an important success of this work is that it > succeeded. However, we need to understand, as much as possible, as to why > and how it succeeded. This is why I asked you (Tom) to do a post project > debriefing paper. It will help little if this only details corrections to > errors. To be useful, it must detail the successes, including all the > little successes. From this information it will be possible to determine > how to do a cooperation project again. Without this information, most > people will be afraid to try a cooperation project in the fear that it > will just as painful as second time. > > An important part of the success is the core group of people who > participated in all the IETF and the ITU-T activities. I doubt this this > will be typical of any future work. So the question will remain how to > share work between the normal ITU-T process involving contributions at > meetings and the IETF process involving, to a greater extent, work shared > over a mailing list. Both processes are valid, but their dynamics are > very different. (The two groups cannot even agree on a document format > that can be shared between the two groups.) > > There have been many intemperate statements made by too many people > regarding IETF and ITU-T. This is not limited to the H.248/Megaco > project. These statements will not help progress; but in many cases > represent the fears of the individual groups. IETF and ITU-T originated > in very different environments. The future shock is these environments > are becoming one. Neither group has the totality of knowledge. Both > groups have a valid pool of knowledge that adds to the whole and from > which all can learn. But how to bring this sharing about? The > H.248/Megaco project was a start. Let us find away to continue. > > Robert Callaghan > > ------------------------------------------------------------------ > Robert Callaghan > Siemens Information and Communication Networks > Tel: +1.561.997.3756 Fax: +1.561.997.3403 > Email: Robert.Callaghan(a)ICN.Siemens.com > ------------------------------------------------------------------ > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > Sent: Sunday, February 27, 2000 7:43 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: In Defense Of Cooperation > > > > Paul Jones used the term "H.248/Megaco fiasco", and Dale Skran was > quite intemperate in his criticism of the joint effort when he spoke in > Geneva. I was not in a position to raise much of a defense there, because > it would have conflicted with Glen's positioning of the H.248 work as > stable. Now that that issue is water under the bridge, I would like to > suggest that it really has been quite a successful project. I don't think > we should go at it in quite the same way in the future, but we should not > come away totally discouraged about the prospects for IETF/ITU-T > cooperation. > > Here are bases for my conclusion: > > We have been technically successful, and what we have created is > better than it would have been if created in either body separately. To > be specific, we retained a great deal of the thinking and experience which > went into MGCP, but escaped the limitations MGCP's connection model > imposed on the use of different bearer types and multiple media. > > There is a perception that the IETF decision model is lacking > because so much had to be done at the ITU-T meetings. However, the > grueling effort put in at the latter resulted partly because of > fundamental conflict to which Q.13-14 has been unaccustomed (Monterey and > much of Red Bank in particular) and partly because there was so much to > cover. This may have given the impression that the IETF didn't do > anything on their watch, but we did work through a lot of material. > Moreover, both Q. 14/16 and Megaco made a host of decisions which have > shaped the final protocol. > > I have pleaded guilty to a failure to complete IETF process in > timely fashion. There was a brief window of opportunity in early December > when it seemed that the list was quieting down. If I had made Last Call > at that point, the long list of issues which was contributed into the > Geneva meeting would instead have been forced into the open at an early > enough point that IETF process could still have been completed in time for > the Geneva meeting. I consider this to be a tactical failure, in that > real work was done in the intervening month and a half, and the protocol > specification is the better for it. > > We have come to a point where SG 16 is thoroughly mistrustful of the > IETF as a partner, and has shown this distrust by negotiating a contract > for further progress on H.248/Megaco down to the last detail. The pity is > that I could see that SG 16 was overly anxious to do its part, from > Santiago onwards. We were not really ready for determination at that > point, and we were not ready for decision coming out of Red Bank. I can > understand that SG 16 feels betrayed because the IETF was not finished in > time, but the fact is that the job was bigger than the schedule allowed > for. > > This is why, if I am ever involved in a project like this again, I > will insist that the IETF and ITU-T working together create an IETF > Proposed Standard before determination ever happens. The opportunity for > false expectations and artificially tight deadlines will thus never arise, > and both sides will be the happier for it. > > Tom Taylor > Advisor -- Emerging Carrier IP Standards > E-mail: taylor(a)nortelnetworks.com (internally, Tom-PT Taylor) > Phone and FAX: +1 613 736 0961 >

1 0

Re: In Defense Of Cooperation
by Callaghan, Robert 28 Feb '00

28 Feb '00

Tom, I have to agree that the H.248/Megaco project, in the end, is a success. And much of the success is the process and cultural knowledge that was gained. Yes, at this point, everyone is suffering some pain. However, very little greatness is gained without pain. The group culture and dynamic is very different between the ITU-T and the IETF. It is hard for anyone to gain trust in a partner, when you do not know or understand what the partner is doing. If you don't understand what a partner is doing, can you trust that you understand what he is thinking? (YES; but with time and effort!) Again, I think that an important success of this work is that it succeeded. However, we need to understand, as much as possible, as to why and how it succeeded. This is why I asked you (Tom) to do a post project debriefing paper. It will help little if this only details corrections to errors. To be useful, it must detail the successes, including all the little successes. >From this information it will be possible to determine how to do a cooperation project again. Without this information, most people will be afraid to try a cooperation project in the fear that it will just as painful as second time. An important part of the success is the core group of people who participated in all the IETF and the ITU-T activities. I doubt this this will be typical of any future work. So the question will remain how to share work between the normal ITU-T process involving contributions at meetings and the IETF process involving, to a greater extent, work shared over a mailing list. Both processes are valid, but their dynamics are very different. (The two groups cannot even agree on a document format that can be shared between the two groups.) There have been many intemperate statements made by too many people regarding IETF and ITU-T. This is not limited to the H.248/Megaco project. These statements will not help progress; but in many cases represent the fears of the individual groups. IETF and ITU-T originated in very different environments. The future shock is these environments are becoming one. Neither group has the totality of knowledge. Both groups have a valid pool of knowledge that adds to the whole and from which all can learn. But how to bring this sharing about? The H.248/Megaco project was a start. Let us find away to continue. Robert Callaghan ------------------------------------------------------------------ Robert Callaghan Siemens Information and Communication Networks Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] Sent: Sunday, February 27, 2000 7:43 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: In Defense Of Cooperation Paul Jones used the term "H.248/Megaco fiasco", and Dale Skran was quite intemperate in his criticism of the joint effort when he spoke in Geneva. I was not in a position to raise much of a defense there, because it would have conflicted with Glen's positioning of the H.248 work as stable. Now that that issue is water under the bridge, I would like to suggest that it really has been quite a successful project. I don't think we should go at it in quite the same way in the future, but we should not come away totally discouraged about the prospects for IETF/ITU-T cooperation. Here are bases for my conclusion: We have been technically successful, and what we have created is better than it would have been if created in either body separately. To be specific, we retained a great deal of the thinking and experience which went into MGCP, but escaped the limitations MGCP's connection model imposed on the use of different bearer types and multiple media. There is a perception that the IETF decision model is lacking because so much had to be done at the ITU-T meetings. However, the grueling effort put in at the latter resulted partly because of fundamental conflict to which Q.13-14 has been unaccustomed (Monterey and much of Red Bank in particular) and partly because there was so much to cover. This may have given the impression that the IETF didn't do anything on their watch, but we did work through a lot of material. Moreover, both Q. 14/16 and Megaco made a host of decisions which have shaped the final protocol. I have pleaded guilty to a failure to complete IETF process in timely fashion. There was a brief window of opportunity in early December when it seemed that the list was quieting down. If I had made Last Call at that point, the long list of issues which was contributed into the Geneva meeting would instead have been forced into the open at an early enough point that IETF process could still have been completed in time for the Geneva meeting. I consider this to be a tactical failure, in that real work was done in the intervening month and a half, and the protocol specification is the better for it. We have come to a point where SG 16 is thoroughly mistrustful of the IETF as a partner, and has shown this distrust by negotiating a contract for further progress on H.248/Megaco down to the last detail. The pity is that I could see that SG 16 was overly anxious to do its part, from Santiago onwards. We were not really ready for determination at that point, and we were not ready for decision coming out of Red Bank. I can understand that SG 16 feels betrayed because the IETF was not finished in time, but the fact is that the job was bigger than the schedule allowed for. This is why, if I am ever involved in a project like this again, I will insist that the IETF and ITU-T working together create an IETF Proposed Standard before determination ever happens. The opportunity for false expectations and artificially tight deadlines will thus never arise, and both sides will be the happier for it. Tom Taylor Advisor -- Emerging Carrier IP Standards E-mail: taylor(a)nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961

1 0

Call for Papers - Oct. 2000 IEEE Communications Magazine Feature Topic on Advanced Signaling and Control in Next Generation Networks
by Seshadri Mohan 28 Feb '00

28 Feb '00

If you have suitable papers, consider submitting for review. Call for Papers attached below. Seshadri Mohan Telcordia Technologies (See attached file: CALLForPapersF.doc)

1 0

H.323/SIP interworking mailing list
by Henning Schulzrinne 28 Feb '00

28 Feb '00

It has been pointed out that I forgot to give details about the interworking mailing list. Here they are: I've set a mailing list for those interested in the discussion of SIP/H.323 interworking. Discussion is *not* limited to the draft written by Kundan Singh and myself. The list is not moderated, but you have to be a member to post (to minimize spam). Discussions about the merits of signaling protocols are considered off-topic. An archive of the discussion is available at the URL below. You can subscribe at http://www.egroups.com/group/sip-h323/ by clicking on "group info" or by sending email to sip-h323-subscribe(a)egroups.com -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs

1 0

Re: [H.323-SIP/Internet] The reason.
by Roy, Radhika R, ALARC 28 Feb '00

28 Feb '00

Hi, Everyone: I understand what Paul has pointed out. We know that a lot work needs to be done when it comes to an agreement between the two standard organizations: ITU-T SG16 and IETF. We have seen how other works had been done in the past cooperatively despite the difficulty. However, there is a crying need in the industry for the H.323-SIP interoperability standard. We are always optimistic that the good-will will always prevail for the benefit of the user community of the whole world as these standard organizations are committed to provide interoperability. We not talking about the work for the H.323-SIP interoperability that is being done in other forums (e.g., IMTC, ETSI/TIPHON, and others). These works will go on and they did in the past, and as they will be doing now. We are working for an internationally acceptable standard where both ITU-T and IETF will make it a formal standard. Accordingly, we are working as per agreement made in the last SG16 (Feb'00) meeting: To bring contributions in the SG16 ( - in Q.14/16 and joint discussions will be held for both Q.13 and Q.14). It can also been seen that a request has also been sent to the IETF for a BOF session in the upcoming meeting (March'00). Efforts are underway to overcome all difficulties. I appreciate Paul to clarify all aspects of difficulties that we might have to face for working in this new area and we are also counting on Paul's support for our effort as well. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Paul E. Jones [SMTP:paul.jones@TIES.ITU.INT] > Sent: Sunday, February 27, 2000 1:15 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323-SIP/Internet] The reason. > > Folks, > > I agree that the goal of a standards body is to create specifications to > allow interoperability. However, this is "delicate" territory. This work > is not similar to creating a new annex to H.246 wherein the ITU specifies > interoperability between various systems or protocols defined elsewhere in > the ITU. This work involves describing how to interwork an ITU system > with > an IETF RFC. > > It's not an impossible task, but one that may lead to tremendous debate. > It > is quite obvious that some members of the ITU and some members of the IETF > have very basic philosophical differences. I can tell you that some > members > of the IETF will quickly reject anything the ITU does to standardize > interoperability. I can also tell you that some of those members will > also > reject anything ETSI does, as well. > > This is not to say that I am opposed to such an effort-- if companies > support the idea, that is enough of an indication to me that people feel > it's necessary and should be done. However, if we head down that path, I > really believe that this should be a joint effort between the ITU and the > IETF. Why? Because there are strengths and weaknesses with both > protocols > and one could easily introduce bias into such a specification in such a > way > as to highlight the strengths of one protocol and the weaknesses of the > other. > > And, of course, everyone here knows that H.323 is far superior to SIP, > right? :-) > > Again, I do not disagree with the work. However, as sad and pathetic as > this statement may sound, it's true: the IETF members (especially the > supporters of SIP) have little respect for the ITU and, unless we do this > jointly, our lone efforts are likely to not be well received. I've > already > heard enough negative remarks about the efforts the ITU is undertaking > (especially in SG13) to describe new Internet protocols; the claims are > that > "that is work the IETF does and the ITU has no business doing it". > > It has already been suggested that a third party may be the better choice > for such a work. Mr. Taylor mentioned that ETSI may already be doing > this. > Did I understand that correctly? If that's the case, and if we can get > the > IETF to agree to allow them to do such work, we should probably let them > do > the work. > > Paul > > ----- Original Message ----- > From: "Roy, Radhika R, ALARC" <rrroy(a)ATT.COM> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Friday, February 25, 2000 7:58 AM > Subject: Re: [H.323-SIP/Internet] The reason. > > > > Hi, Everyone: > > > > I am in full agreement with Orit. I guess that this has also been the > case > > for many people who had been present in the SG16 meeting. > > > > More importantly, when I talked to Glen, he clearly indicated that we > should > > bring contributions to get the work started. The interworking between > H.323 > > and SIP may belong Q.14 (although it has to be discussed jointly with > Q.13 > > and Q.14). > > > > There has been a very strong interest for the work of H.323-SIP > > Interworking. A large number of people throughout the world (starting > from > > the ITU-T and IETF) is contacting me. > > > > The primary goal of the standard bodies is to provide > "INTEROPERABILITY." > > > > Best regards, > > Radhika R. Roy > > AT&T > > +1 732 420 1580 > > rrroy(a)att.com > > > > > -----Original Message----- > > > From: Orit Levin [SMTP:orit@radvision.com] > > > Sent: Thursday, February 24, 2000 4:42 PM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: [H.323-SIP/Internet] The reason. > > > > > > Dear Rob! > > > Yes, believe me, I read the official report very carefully. > > > The whole idea is to present "the terms of reference" as a > contribution > > > for > > > Osaka meeting. > > > I do not see how it prevents to move the work forward, especially if > many > > > people see it as valuable. > > > > > > BTW: Who said the work shouldn't be done jointly? My point was that > it > > > may > > > start from documents and people, rather then from "ITU and IETF". And > > > after > > > all we are NOT talking about joined standard definition. In worst case > > > about > > > joined Network definition. :-)) > > > > > > Cheers, > > > 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 > > > -----Original Message----- > > > From: Callaghan, Robert <Robert.Callaghan(a)icn.siemens.com> > > > To: 'Orit Levin' <orit(a)radvision.com>; ITU-SG16(a)mailbag.cps.intel.com > > > <ITU-SG16(a)mailbag.cps.intel.com> > > > Date: Thursday, February 24, 2000 4:09 PM > > > Subject: RE: [H.323-SIP/Internet] The reason. > > > > > > > > > Orit, > > > > > > This is the statement from the Q.14 meeting report: > > > > > > ======= Start > > > > > > 3.8.5.1 D.352 - H.323-SIP Interworking [AT&T, et al] > > > This was presented together with D.413. Comments included: > > > · Concerns about joint development with IETF > > > · Which version of SIP would be used? > > > · Suggest postponing this until the next study period - need to look > > > at how Q.13 and Q.14 were formulated 4 years ago and see how output > > > compares > > > with phrasing of work in these questions > > > · Activities should include comparing call models, media signaling > > > · Concerns about increased travel - maybe this should not be done in > > > SG16 > > > · Forming a new question might not be the best answer - this would > > > split the expertise in SG16 again (as Q.13 and Q.14 have moved away > from > > > joint sessions) > > > · Need to work from official process of IETF (i.e., use only the IETF > > > equivalent of a Recommendation) > > > · Consider gatekeepers working with TRIP > > > Individuals saw merit in the work. Invite contributions on how to > approach > > > the work. Need to get scenarios for progressing work in a controlled > > > architectural approach. Ms. Levin has volunteered to draft a > framework. > > > See additional notes in Q.13 meeting report. > > > > > > ======= End > > > > > > This is the statement in the Q.13 report: > > > > > > ======= Start > > > > > > D.413(2/16) [Canada] - Interworking Between H.323 and SIP Networks > > > > > > This calls for the creation of an interoperability question in SG16, > that > > > would cover among other things, H.323/SIP interworking. > > > > > > With regard to both D.352/D.413, it was noted that there are several > > > versions of SIP, it is hard to start any work to interoperate with SIP > as > > > SIP is ill-defined at this point in time. The wisdom of starting a > new > > > question near the end of the study period was also questioned. It was > > > also > > > mentioned that a great deal of work needs to be done in terms of > defining > > > the procedures and architecture that would apply to this work. One > > > suggestion is that interoperability should be between standards > bodies > > > such > > > as the ITU and IETF, and this should be the focus of the work, i.e. > that > > > the > > > target is official IETF RFCs and not SIP type documents produced by > > > various > > > other bodies. There were various expressions of support that this > should > > > be > > > studied, and contributions related to architectures and priorities are > > > solicited. It was agreed that contributions should address both Q13 > and > > > Q14. > > > > > > ======= End > > > > > > I cannot see in these statements any thing representing an agreement > as > to > > > the work to be performed. Your attached terms of reference were not > > > approved at the working party, which is required, nor in the Question > > > meeting. Without an agreement as to the scope, I do not see how to > move > > > the > > > work forward, even if many people see it as valuable. Therefore you > paper > > > on > > > terms of reference can be accepted as a contribution to the Osaka > meeting > > > for discussion. > > > > > > I do know that the proposal for a new question was rejected at the > > > question > > > level, and not brought forward to the working party or study group > level. > > > > > > Talking to Dale, I know that he wants to start the work with H.225.0 > Annex > > > G > > > to TRIP. Other items are to follow. > > > > > > For me one of the problems is the culture clash. I do not feel that > the > > > ITU > > > should represent itself as SIP experts and I do not accept any IETF > person > > > as an H.323 expert. Therefore the work should be done jointly. No > one > > > wants to repeat the process used by H.248, so what is the process to > be > > > used? > > > > > > Bob > > > > > > ------------------------------------------------------------------ > > > Robert Callaghan > > > Siemens Information and Communication Networks > > > Tel: +1.561.997.3756 Fax: +1.561.997.3403 > > > Email: Robert.Callaghan(a)ICN.Siemens.com > > > ------------------------------------------------------------------ > > > > > > > > > -----Original Message----- > > > From: Orit Levin [mailto:orit@radvision.com] > > > Sent: Thursday, February 24, 2000 2:27 PM > > > To: ITU-SG16(a)mailbag.cps.intel.com > > > Subject: Re: [H.323-SIP/Internet] The reason. > > > > > > > > > Hello Sebestyen! > > > There is additional chapter from Q.14 Report with the same meaning, > but > I > > > am > > > sure it doesn't answer your question. During Geneva meeting additional > > > related aspects were discussed. In my previous mail I was referring to > the > > > attached paper. (You will find references to relevant contributions in > > > this > > > paper.) Currently this paper is one of the opinions and possible > > > directions. > > > We are having this discussion on the list in order to get an > understanding > > > of the work we would like to pursue and prepare contributions for > Osaka > > > meeting. > > > 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 > > > -----Original Message----- > > > From: Sebestyen Istvan ICN M CS 27 <Istvan.Sebestyen(a)icn.siemens.de> > > > To: ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com>; > 'Orit > > > Levin' <orit(a)radvision.com> > > > Date: Thursday, February 24, 2000 2:02 PM > > > Subject: RE: [H.323-SIP/Internet] The reason. > > > > > > > > > >Orit, > > > >I am a bit confused on what should be done here. I have only found in > > > TD-74 > > > >(ITU-T SG16 Working Party 2 Report) the following passages: > > > > > > > >"D.352(2/16) [Various] - H.323 SIP Interworking > > > > > > > >This document calls for a joint ITU-T/IETF study of H.323/SIP > > > interworking. > > > > > > > > > > > >D.413(2/16) [Canada] - Interworking Between H.323 and SIP Networks > > > > > > > >This calls for the creation of an interoperability question in SG16, > that > > > >would cover among other things, H.323/SIP interworking. > > > > > > > >With regard to both D.352/D.413, it was noted that there are several > > > >versions of SIP, it is hard to start any work to interoperate with > SIP > as > > > >SIP is ill-defined at this point in time. The wisdom of starting a > new > > > >question near the end of the study period was also questioned. It > was > > > also > > > >mentioned that a great deal of work needs to be done in terms of > defining > > > >the procedures and architecture that would apply to this work. One > > > >suggestion is that interoperability should be between standards > bodies > > > such > > > >as the ITU and IETF, and this should be the focus of the work, i.e. > that > > > the > > > >target is official IETF RFCs and not SIP type documents produced by > > > various > > > >other bodies. There were various expressions of support that this > should > > > be > > > >studied, and contributions related to architectures and priorities > are > > > >solicited. It was agreed that contributions should address both Q13 > and > > > >Q14." > > > > > > > >Is there anything else as "Mission Statement" for the interim work? > > > > > > > >Regards, > > > >Istvan > > > > > > > > >------------------------------------------------------------------------- > > > - > > > >Dr. Istvan Sebestyen > > > >Siemens AG, ICN M CS27, > > > >Hofmannstr. 51 D-81359 Munich > > > >Tel:+49-89-722-47230 > > > >Fax:+49-89-722-47713 > > > >E-Mail office: istvan.sebestyen(a)icn.siemens.de; istvan(a)sebestyen.de > > > >E-mail private: istvan_sebestyen(a)yahoo.com; > > > >Siemens > Intranet:http://netinfo.icn.siemens.de/es/team/essp/team/essp4 > > > >Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de > > > > >------------------------------------------------------------------------- > > > -- > > > - > > > >---------------- > > > > > > > >> ---------- > > > >> From: Orit Levin[SMTP:orit@radvision.com] > > > >> Reply To: Orit Levin > > > >> Sent: Thursday, February 24, 2000 6:53 PM > > > >> To: ITU-SG16(a)mailbag.cps.intel.com > > > >> Subject: [H.323-SIP/Internet] The reason. > > > >> > > > >> Hi! > > > >> I would like to highlight the reason of "H.323-XXX" work in ITU-T > as > > > >> described in the initial paper. > > > >> > > > >> H.323 is NOT new to Internet. Internet is evolving and new > > > specifications > > > >> in "IP telephony" area are being defined in IETF. This is a time to > > > >> consider each one of these specifications to be applied to H.323. > If > > > found > > > >> useful from technical point of view (as a kind of Back End > Services) > or > > > >> just as required for interworking purposes (such as H.323-SIP > > > scenarios), > > > >> standard definitions for H.323 should be formulated. These two are > > > >> connected since the first definitely helps the second. > > > >> > > > >> The written above agenda is a proposal for the work scope. Based on > our > > > >> discussions, it seems like more then one company would like to see > this > > > >> work beyond the topic of H.323-SIP interoperability. (forget the > name > > > :-) > > > >> ) If we agree that standardization is needed for this kind of work, > the > > > >> only possible way to do it is to participate in ITU-T process (with > all > > > >> its meaning). > > > >> > > > >> Currently we are in the beginning of the process sorting out topics > of > > > our > > > >> interest. I think most of us are aware of the work being done in > other > > > >> organizations. We would like to see experts (including from TIPHON > and > > > >> IETF) presenting their concepts to ITU (starting from the mailing > list) > > > >> keeping us from repeating their work and being aligned with them. > > > >> > > > >> 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

Re: [H.323Mobility:]
by Jaakko Sundquist 28 Feb '00

28 Feb '00

22th and 23th are also fine with me... - Jaakko -----Original Message----- From: EXT Gösta Linder (LME) [mailto:Gosta.Linder@LME.ERICSSON.SE] Sent: Thursday, February 24, 2000 10:00 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [H.323Mobility:] Paul, 22 and 23 are fine with me/Gösta -----Original Message----- From: Guram Paul-LPG019 [mailto:lpg019@EMAIL.MOT.COM] Sent: den 24 februari 2000 01:16 To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [H.323Mobility:] Hi ad hoc Mob. Group 1. We will continue, as previously, and use the URL (ftp://standard.pictel.com/avc-site/Mobility-adhoc/ ) which has been allocated for our group's use. New contributions to start as (Mobility document) MDs to distinguish from the old numerous numbering schemes (for MTD,e.g. mtd03, mtd 201, etc.). I suggest we start at md010 as the first contribution with md001 to md009 to be used for management activities (to be defined later). When contributing, look at the ftp site for the next number available, reserve it by announcing to group, then (if no conflict of numbers) load it onto the site. OR we could ask one of Paul (R or G), Roy, or for Jaakko to control the allocation of the numbers, if you think that would be a better way which avoids clash of same number being used. 2. Jaakko has sent us the zipped file with the TD129 from Geneva for Annex H. This is the document Jaakko will work on as the base-line document and Jaakko, could this be put onto the ftp site as Annex H version 03 (version 01 being Red Bank output, version 2 being ad hoc group input into Geneva, and version 3 being Geneva output). Following on from Nicolas Tran's comments, there are already (minor) changes to be made to version 3, and this will be done as part of regular editor update. Similarly for the ToR document. Is that acceptable ? 3. Apart from Radhika, I have not received availability information for our next conf. call from anyone else. Please let me know which dates are most suitable from 20-24 March to enable me to arrange for an appropriate date. Regards Paul -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@att.com] Sent: 23 February 2000 15:58 To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [H.323Mobility:] Hi, Paul and Jaakko: Many thanks for the information. Paul Guram: Please provide a well thought convention for the document number. For example, MTD.xxx would be given to diiferentiate from the reqular TDs. One request to you: Once a numbering convention is used, please try to stick to that rule (if we change the rule in the middle, it creates confusions as it happened last time). Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Jaakko Sundquist [SMTP:jaakko.sundquist@NOKIA.COM] > Sent: Wednesday, February 23, 2000 9:01 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323Mobility:] > > Hi Radhika et al, > > There seems to be a subdirectory in the pictel-site for mobility. The URL > is: ftp://standard.pictel.com/avc-site/Mobility-adhoc/ . I suggest that we > will put our contributions there. It would be nice to have some naming > convention (such as the MTD-xxx scheme) for the documents. Maybe Paul > should > assign these numbers as he is now the moderator for the teleconferences... > > - Jaakko Sundquist > > -----Original Message----- > From: EXT Roy, Radhika R, ALARC [mailto:rrroy@att.com] > Sent: Wednesday, February 23, 2000 3:34 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: [H.323Mobility:] > > Hi, Jaakko: > > I agree with your reply that was also reflected in my > earlier email. > > I have a question to you and Paul Guram: Have you guys > decided where the > incoming contributions for the Ad Hoc group to be sent and > where the URL > would be for accessing to that website? If it is so, > please > let all of us > know soon. > > Paul Guram: Are you close to decide the meeting date and > time as well? > > Best regards, > Radhika R. Roy > > > > -----Original Message----- > > From: Jaakko Sundquist [SMTP:jaakko.sundquist@NOKIA.COM] > > Sent: Wednesday, February 23, 2000 3:37 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: [H.323Mobility:] > > > > Hi all, > > > > I'm sending here the documents related to H.323 Annex H > that were > > accomplished in the Geneva meeting by the ad hoc > mobility > group. Included > > are the draft Annex H, the Terms of Reference for it as > well as the > > meeting > > minutes (quite short) of the ad hoc group meetings in > Geneva. > > > > As Mr. Tran pointed out the location area had been left > to > the VLF-section > > of the draft annex. This is my mistake and I apologize > for > any confusion > > it > > has created. I did not, however, take it off from the > document I am > > sending > > here, this is the document that was produced as a TD in > Geneva, but I will > > remove the location area from the subsequent versions of > the draft annex. > > As for the TMSI, etc. concepts, in my view it is quite > unnecessary to > > argue > > about these, the TMSI is already included in the > proposed > new alias > > address > > type: UIM. Many of these concepts are, as I understand, > already needed in > > H.246 Annex E, which addresses one scenario of the > mobility problem. I > > would > > see the VLR functionality of the H.246 Annex E IWF as > really the VLF we > > have > > defined as a new mobility functional entity, thus the > identifiers TMSI, > > etc. > > would be needed in the VLF at least in some cases. > However, it might be > > suitable to indicate that all of the identifiers > mentioned > in the VLF (and > > other) section(s) are not mandatory. > > > > <<GenevaMobility.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. > > ------------------------------------------------------- > << > File: > > GenevaMobility.zip >>

1 0

Re: [H.323Mobility:]
by Jaakko Sundquist 28 Feb '00

28 Feb '00

Hi Paul, 2. Jaakko has sent us the zipped file with the TD129 from Geneva for Annex H. This is the document Jaakko will work on as the base-line document and Jaakko, could this be put onto the ftp site as Annex H version 03 (version 01 being Red Bank output, version 2 being ad hoc group input into Geneva, and version 3 being Geneva output). Following on from Nicolas Tran's comments, there are already (minor) changes to be made to version 3, and this will be done as part of regular editor update. Similarly for the ToR document. Is that acceptable ? Otherwise fine, but using a name like "H.323 Annex H version 3" would sound like the document is the third decided version. Thus I would suggest that we call it "H.323 Annex H draft 3", or something like that. Is that name acceptable to all? I will put the document under that name to the pictel ftp-site tomorrow, if no objections arise before that. - Jaakko

1 0

Re: H.323 Annex D
by Mike Nilsson 28 Feb '00

28 Feb '00

Paul, > > There have been recent changes to H.245 ASN.1 to support T.38. At least > there have been some proposed changes. Unfortunately, I missed much of > that discussion. The meeting report says that those changes were added to > H.245v6. > > Mike, is it true that the T.38-related changes from H.245v4 to H.245v6 > were nothing more than additions to H.245-- not "changes", per se. Also, > did the proposed changes (from TD8/WP2, I believe) make it into H.245v6? > The 'T.38 changes' are additions rather than changes - simply more syntax after the extension markers. The changes described in TD8/WP2 are in H.245V6. Mike ********************************************************************** * Mike Nilsson Tel: +44 1473 645413 * * Applications Technology Group Fax: +44 1473 645011 * * Internet and Multimedia Applications Email: mike.nilsson(a)bt.com * * BT Advanced Communications Technology Centre [B54 Room 94] * * Adastral Park * * Martlesham Heath * * Ipswich IP5 3RE * * UK * **********************************************************************

1 0

Re: first draft of H.225.0 Annex G version 2
by Michaely, Boaz 28 Feb '00

28 Feb '00

Well done, Mike .. An note (editorial ?) which people may want to consider: The reference to ASN.1 probably needs to be updated, as the latest version is from December 1997. I am no expert on ASN.1 so I have no knowledge on whether there is a sound reason to actually refer to the outdated recommendation. The updated reference is : ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation Best regards, Boaz Boaz Michaely Senior System Architect, Corporate Comverse Network Systems Tel: +972 (3) 766-3844 , Mobile +972 (50) 39-30-17 http://people.itu.int/~michaely mailto:boaz_michaely@comverse.com > -----Original Message----- > From: Michael Fortinsky [mailto:Michael_Fortinsky@VOCALTEC.COM] > Sent: Monday, February 28, 2000 11:52 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: first draft of H.225.0 Annex G version 2 > > > > During the recent Geneva ITU-SG16 meeting, it was decided to > start working > on version2 of H.225.0 Annex G. > The current goal is to determine version2 at the Nov, 2000 > SG16 meeting. > > For those of you who aren't aware of this - I have assumed > the editorship > responsibility for H.225.0 Annex G (the editor > was Boaz Michaely). > > Attached is a first draft of version 2. It includes the following: > > (1) Editorial corrections to version 1 > > (2) Integration of the following changes from the H.323 > Implementers Guide > (pl-92.doc from Geneva): > - [6.10.1 from Impl Guide] changes related to Multiple Usage > Indications for the Same Call - sections 1.7.4.1, 1.7.4, 1.8.2.28 > - [6.10.2 from Impl Guide] changes related to Identifying the > Terminated Service Relationship - sections 1.8.2, 1.8.2.6 > - [6.10.3 from Impl Guide] changes related to the > Need to Provide > a replyAddress when using Bi-directional Connections - section 1.8.2 > - [6.10.4 from Impl Guide] changes related to Sending > UsageIndications without a Service Relationship - sections > 1.7.4, 1.8.2.5 > - [6.10.5 from Impl Guide] changes to the ASN.1 - section 2 > - [6.10.6 from Impl Guide] changes related to Clarification > Related to Service Relationships - section 6.8.2.4.5 > - [6.10.7 from Impl Guide] changes related to > UsageIndicationRejection reasons - section 1.8.2.30 > - [6.10.8 from Impl Guide] corrections to tables and > diagrams - > sections 1.9.1, 1.9.1.1, 1.9.2, 1.9.2.1 > > (3) changes resulting from D347 from the Geneva SG16 meeting > (Feb, 2000) - > sections 1.8.2.3, 1.8.2.17, 1.8.2.18, 2 > > (4) changes resulting from D449 from the Geneva SG16 meeting > (Feb, 2000) - > sections 1.7.4, 1.7.4.2, 1.8.2.5, 1.8.2.6, 1.8.2.7, 2 > > > Any comments and/or contributions are welcome. > > > (See attached file: H.225.0 Annex G v2.zip) > > > Michael Fortinsky > ----------------------------------------------------------------- > Senior Program Manager, IP Telephony Group, VocalTec > Communications Ltd. > Email: mike(a)vocaltec.com Tel: 972 9 9707768 Fax: > 972 9 9561867 >

1 0

first draft of H.225.0 Annex G version 2
by Michael Fortinsky 28 Feb '00

28 Feb '00

During the recent Geneva ITU-SG16 meeting, it was decided to start working on version2 of H.225.0 Annex G. The current goal is to determine version2 at the Nov, 2000 SG16 meeting. For those of you who aren't aware of this - I have assumed the editorship responsibility for H.225.0 Annex G (the editor was Boaz Michaely). Attached is a first draft of version 2. It includes the following: (1) Editorial corrections to version 1 (2) Integration of the following changes from the H.323 Implementers Guide (pl-92.doc from Geneva): - [6.10.1 from Impl Guide] changes related to Multiple Usage Indications for the Same Call - sections 1.7.4.1, 1.7.4, 1.8.2.28 - [6.10.2 from Impl Guide] changes related to Identifying the Terminated Service Relationship - sections 1.8.2, 1.8.2.6 - [6.10.3 from Impl Guide] changes related to the Need to Provide a replyAddress when using Bi-directional Connections - section 1.8.2 - [6.10.4 from Impl Guide] changes related to Sending UsageIndications without a Service Relationship - sections 1.7.4, 1.8.2.5 - [6.10.5 from Impl Guide] changes to the ASN.1 - section 2 - [6.10.6 from Impl Guide] changes related to Clarification Related to Service Relationships - section 6.8.2.4.5 - [6.10.7 from Impl Guide] changes related to UsageIndicationRejection reasons - section 1.8.2.30 - [6.10.8 from Impl Guide] corrections to tables and diagrams - sections 1.9.1, 1.9.1.1, 1.9.2, 1.9.2.1 (3) changes resulting from D347 from the Geneva SG16 meeting (Feb, 2000) - sections 1.8.2.3, 1.8.2.17, 1.8.2.18, 2 (4) changes resulting from D449 from the Geneva SG16 meeting (Feb, 2000) - sections 1.7.4, 1.7.4.2, 1.8.2.5, 1.8.2.6, 1.8.2.7, 2 Any comments and/or contributions are welcome. (See attached file: H.225.0 Annex G v2.zip) Michael Fortinsky ----------------------------------------------------------------- Senior Program Manager, IP Telephony Group, VocalTec Communications Ltd. Email: mike(a)vocaltec.com Tel: 972 9 9707768 Fax: 972 9 9561867

1 0

Re: [H.323-SIP/Internet] The reason.
by Henning Schulzrinne 27 Feb '00

27 Feb '00

Since my name popped up in a recent email discussion, a few remarks: 1) Yes, the SIP-H.323 list was created by myself; it is open to anybody. While its creation was triggered by the interest generated by a proposal (Internet draft) written by Kundan Singh (a student of mine) and myself, it is open to any discussion related to the topic of interworking. (Discussions about the relative merits of protocols are decidedly less appreciated.) Whether people use this mailing list or create something new and different is obviously beyond my control. The creation of the mailing list was done without any implied IETF endorsement or even endorsement of other SIP authors. (I hope they don't mind too much...) 2) In this context, there is one important difference between the ITU and IETF standardization process which particularly affects this discussion. While all ITU recommendations are "standards", most IETF RFCs are not. For the case at hand, it would probably be considered inappropriate for a standards-track RFC except, with lots of stretch of the imagination, a BCP (best current practice). If an interoperability document does get published within the IETF, it is likely to appear as an Informational or possibly Experimental RFC. In this particular case, as long as the signaling gateway looks like a valid SIP or H.323 entity, the other SIP and H.323 entities won't know that it is talking to the "other side" (you can insert "dark side" or "the enemy" if you are so inclined). As our initial document points out, there is probably a range of solutions that satisfy this basic criterion, depending on (for example) to what extent X entities are visible in Y land. In my view, publishing any such interoperability document has the primary benefit of saving implementors of such devices, should they become popular, a bit of thinking time and maybe avoid some pitfalls. They are not strictly *necessary* - anybody could derive one of the modes that we described or something different, as long as it satisfies the basic "in Rome, do as the Romans" criterion mentioned earlier. Thus, given that a standards-track document is not really called for on the IETF side, this effort could be significantly simpler than, say, the Megaco/H.248 effort. My rough perception is that the IESG will basically ask at publication time whether the document suggested as an Informational RFC violates IETF protocols (SIP and SDP, in this case). If not, and it does no other harm (e.g., broadcasting a RAS-like query to all SIP nodes in the Internet or something similarly stupid), the IETF process should be relatively straightforward, even without a lot of cooperation machinery, liaison agreements and the like. I realize that this assessment is probably hopelessly naive, but I am concerned that the collective effort expended on meta-discussions is rapidly approaching the effort that seems to be necessary to write an interoperability document for basic services, including the time to implement it. We'd be happy to provide the infrastructure for meetings, allowing the ITU participants to use their H.323 phones to call our SIP phones using our gateway implementation :-) No, we won't charge the ITU for these translation services :-) Regards, Henning

1 0

Re: In Defense Of Cooperation
by Mike Buckley 27 Feb '00

27 Feb '00

While agreeing wholeheartedly with Paul Jones's reply to Francois Menard I side with Tom's in his conclusion that the Megaco/H.248 collaboration has been a success. I would go further, and say I think it has been an outstanding achievement, considering the odds that were stacked against it. I would list among these: 1. Deep philosophical differences of approach between the two Standards bodies in the way a Standard emerges and the decision processes involved, 2. Strongly held technical beliefs on both sides; arising partly from 'religion' and partly from conflicting strategic objectives, 2. Vested commercial interests on the part of some of the key players, 3. A marketing campaign going on in the background, aimed at replacing H.323 with SIP/SDP, To talk of mistrust and suspicion is to grossly simplify the situation. Having said all this, I would like to thank and congratulate all involved for bringing this effort to such a successful conclusion. In particular, I think we all owe a debt of gratitude to Tom for the way he has negotiated all these obstacles with patience and good humour and for the way he has straddled two very different cultures and two very different processes. I would also like to thank John Segers for the long hours of frustrating work involved in producing a well written and well structured document from the amorphous scratchings he inherited. Its a thankless task being an ITU editor and I think John deserves a special thanks, particularly for the 48 hours or more that he went without sleep during the meeting to get the final version of the document ready. Despite all these problems, I believe we will see a lot more of this type of co- operation. Why, because its the only approach that makes sense. The market demands interoperability in the area of VoIP and this can only be achieved by collaboration between the two Standards bodies involved. Going forward, I would suggest that an MOU is drawn up early in the process not at the end. A detailed MOU is not something to apologise for, its just good business practice, and a practice that results in the minimum of misunderstandings and mistrust. Finally, let's not let the process(es) on each side get in the way of progress. I think the less process involved the better. A document should be approved when consensus agree its ready for approval. Two sets of beaurocratic hurdles don't help matters, they just slow things down. Mike Buckley ____________________ Begin Original Message ___________________________ Date: Sun Feb 27 19:43:19 -0500 2000 From: internet!NORTELNETWORKS.COM!taylor (Tom-PT Taylor) Subject: In Defense Of Cooperation To: internet!MAILBAG.INTEL.COM!ITU-SG16 Content-Type: multipart Content-Length: 7439 Paul Jones used the term "H.248/Megaco fiasco", and Dale Skran was quite intemperate in his criticism of the joint effort when he spoke in Geneva. I was not in a position to raise much of a defense there, because it would have conflicted with Glen's positioning of the H.248 work as stable. Now that that issue is water under the bridge, I would like to suggest that it really has been quite a successful project. I don't think we should go at it in quite the same way in the future, but we should not come away totally discouraged about the prospects for IETF/ITU-T cooperation. Here are bases for my conclusion: We have been technically successful, and what we have created is better than it would have been if created in either body separately. To be specific, we retained a great deal of the thinking and experience which went into MGCP, but escaped the limitations MGCP's connection model imposed on the use of different bearer types and multiple media. There is a perception that the IETF decision model is lacking because so much had to be done at the ITU-T meetings. However, the grueling effort put in at the latter resulted partly because of fundamental conflict to which Q.13-14 has been unaccustomed (Monterey and much of Red Bank in particular) and partly because there was so much to cover. This may have given the impression that the IETF didn't do anything on their watch, but we did work through a lot of material. Moreover, both Q. 14/16 and Megaco made a host of decisions which have shaped the final protocol. I have pleaded guilty to a failure to complete IETF process in timely fashion. There was a brief window of opportunity in early December when it seemed that the list was quieting down. If I had made Last Call at that point, the long list of issues which was contributed into the Geneva meeting would instead have been forced into the open at an early enough point that IETF process could still have been completed in time for the Geneva meeting. I consider this to be a tactical failure, in that real work was done in the intervening month and a half, and the protocol specification is the better for it. We have come to a point where SG 16 is thoroughly mistrustful of the IETF as a partner, and has shown this distrust by negotiating a contract for further progress on H.248/Megaco down to the last detail. The pity is that I could see that SG 16 was overly anxious to do its part, from Santiago onwards. We were not really ready for determination at that point, and we were not ready for decision coming out of Red Bank. I can understand that SG 16 feels betrayed because the IETF was not finished in time, but the fact is that the job was bigger than the schedule allowed for. This is why, if I am ever involved in a project like this again, I will insist that the IETF and ITU-T working together create an IETF Proposed Standard before determination ever happens. The opportunity for false expectations and artificially tight deadlines will thus never arise, and both sides will be the happier for it. Tom Taylor Advisor -- Emerging Carrier IP Standards E-mail: taylor(a)nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961

1 0

Re: In Defense Of Cooperation
by Scott Bradner 27 Feb '00

27 Feb '00

thanks for the review Scott

1 0

H.323 Annex D
by Francois Audet 27 Feb '00

27 Feb '00

Hi, I'm not sure who is editor of H.323 Annex D, but... It seems that there is no reference in Annex D of what version of H.323 and H.245 is required for the procedures to work. There is no way to indicate T.38 or even support of UDP vs. TCP transport in H.245v2. I think the answer is that H.245v4 or later is required. Perhaps somebody can clarify if this is correct. In any case, we definitively need to specify in H.323 Annex D which version of H.245 is required... ----- François Audet Tel:+1 408 565 5675 mailto:audet@NortelNetworks.com <mailto:audet@NortelNetworks.com> Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com <http://www.nortelnetworks.com/>

3 3

Re: [H.323-SIP/Internet] The reason.
by Roy, Radhika R, ALARC 27 Feb '00

27 Feb '00

Hi, Everyone: I am in full agreement with Orit. I guess that this has also been the case for many people who had been present in the SG16 meeting. More importantly, when I talked to Glen, he clearly indicated that we should bring contributions to get the work started. The interworking between H.323 and SIP may belong Q.14 (although it has to be discussed jointly with Q.13 and Q.14). There has been a very strong interest for the work of H.323-SIP Interworking. A large number of people throughout the world (starting from the ITU-T and IETF) is contacting me. The primary goal of the standard bodies is to provide "INTEROPERABILITY." Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com > -----Original Message----- > From: Orit Levin [SMTP:orit@radvision.com] > Sent: Thursday, February 24, 2000 4:42 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323-SIP/Internet] The reason. > > Dear Rob! > Yes, believe me, I read the official report very carefully. > The whole idea is to present "the terms of reference" as a contribution > for > Osaka meeting. > I do not see how it prevents to move the work forward, especially if many > people see it as valuable. > > BTW: Who said the work shouldn't be done jointly? My point was that it > may > start from documents and people, rather then from "ITU and IETF". And > after > all we are NOT talking about joined standard definition. In worst case > about > joined Network definition. :-)) > > Cheers, > 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 > -----Original Message----- > From: Callaghan, Robert <Robert.Callaghan(a)icn.siemens.com> > To: 'Orit Levin' <orit(a)radvision.com>; ITU-SG16(a)mailbag.cps.intel.com > <ITU-SG16(a)mailbag.cps.intel.com> > Date: Thursday, February 24, 2000 4:09 PM > Subject: RE: [H.323-SIP/Internet] The reason. > > > Orit, > > This is the statement from the Q.14 meeting report: > > ======= Start > > 3.8.5.1 D.352 - H.323-SIP Interworking [AT&T, et al] > This was presented together with D.413. Comments included: > · Concerns about joint development with IETF > · Which version of SIP would be used? > · Suggest postponing this until the next study period - need to look > at how Q.13 and Q.14 were formulated 4 years ago and see how output > compares > with phrasing of work in these questions > · Activities should include comparing call models, media signaling > · Concerns about increased travel - maybe this should not be done in > SG16 > · Forming a new question might not be the best answer - this would > split the expertise in SG16 again (as Q.13 and Q.14 have moved away from > joint sessions) > · Need to work from official process of IETF (i.e., use only the IETF > equivalent of a Recommendation) > · Consider gatekeepers working with TRIP > Individuals saw merit in the work. Invite contributions on how to approach > the work. Need to get scenarios for progressing work in a controlled > architectural approach. Ms. Levin has volunteered to draft a framework. > See additional notes in Q.13 meeting report. > > ======= End > > This is the statement in the Q.13 report: > > ======= Start > > D.413(2/16) [Canada] - Interworking Between H.323 and SIP Networks > > This calls for the creation of an interoperability question in SG16, that > would cover among other things, H.323/SIP interworking. > > With regard to both D.352/D.413, it was noted that there are several > versions of SIP, it is hard to start any work to interoperate with SIP as > SIP is ill-defined at this point in time. The wisdom of starting a new > question near the end of the study period was also questioned. It was > also > mentioned that a great deal of work needs to be done in terms of defining > the procedures and architecture that would apply to this work. One > suggestion is that interoperability should be between standards bodies > such > as the ITU and IETF, and this should be the focus of the work, i.e. that > the > target is official IETF RFCs and not SIP type documents produced by > various > other bodies. There were various expressions of support that this should > be > studied, and contributions related to architectures and priorities are > solicited. It was agreed that contributions should address both Q13 and > Q14. > > ======= End > > I cannot see in these statements any thing representing an agreement as to > the work to be performed. Your attached terms of reference were not > approved at the working party, which is required, nor in the Question > meeting. Without an agreement as to the scope, I do not see how to move > the > work forward, even if many people see it as valuable. Therefore you paper > on > terms of reference can be accepted as a contribution to the Osaka meeting > for discussion. > > I do know that the proposal for a new question was rejected at the > question > level, and not brought forward to the working party or study group level. > > Talking to Dale, I know that he wants to start the work with H.225.0 Annex > G > to TRIP. Other items are to follow. > > For me one of the problems is the culture clash. I do not feel that the > ITU > should represent itself as SIP experts and I do not accept any IETF person > as an H.323 expert. Therefore the work should be done jointly. No one > wants to repeat the process used by H.248, so what is the process to be > used? > > Bob > > ------------------------------------------------------------------ > Robert Callaghan > Siemens Information and Communication Networks > Tel: +1.561.997.3756 Fax: +1.561.997.3403 > Email: Robert.Callaghan(a)ICN.Siemens.com > ------------------------------------------------------------------ > > > -----Original Message----- > From: Orit Levin [mailto:orit@radvision.com] > Sent: Thursday, February 24, 2000 2:27 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: [H.323-SIP/Internet] The reason. > > > Hello Sebestyen! > There is additional chapter from Q.14 Report with the same meaning, but I > am > sure it doesn't answer your question. During Geneva meeting additional > related aspects were discussed. In my previous mail I was referring to the > attached paper. (You will find references to relevant contributions in > this > paper.) Currently this paper is one of the opinions and possible > directions. > We are having this discussion on the list in order to get an understanding > of the work we would like to pursue and prepare contributions for Osaka > meeting. > 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 > -----Original Message----- > From: Sebestyen Istvan ICN M CS 27 <Istvan.Sebestyen(a)icn.siemens.de> > To: ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com>; 'Orit > Levin' <orit(a)radvision.com> > Date: Thursday, February 24, 2000 2:02 PM > Subject: RE: [H.323-SIP/Internet] The reason. > > > >Orit, > >I am a bit confused on what should be done here. I have only found in > TD-74 > >(ITU-T SG16 Working Party 2 Report) the following passages: > > > >"D.352(2/16) [Various] - H.323 SIP Interworking > > > >This document calls for a joint ITU-T/IETF study of H.323/SIP > interworking. > > > > > >D.413(2/16) [Canada] - Interworking Between H.323 and SIP Networks > > > >This calls for the creation of an interoperability question in SG16, that > >would cover among other things, H.323/SIP interworking. > > > >With regard to both D.352/D.413, it was noted that there are several > >versions of SIP, it is hard to start any work to interoperate with SIP as > >SIP is ill-defined at this point in time. The wisdom of starting a new > >question near the end of the study period was also questioned. It was > also > >mentioned that a great deal of work needs to be done in terms of defining > >the procedures and architecture that would apply to this work. One > >suggestion is that interoperability should be between standards bodies > such > >as the ITU and IETF, and this should be the focus of the work, i.e. that > the > >target is official IETF RFCs and not SIP type documents produced by > various > >other bodies. There were various expressions of support that this should > be > >studied, and contributions related to architectures and priorities are > >solicited. It was agreed that contributions should address both Q13 and > >Q14." > > > >Is there anything else as "Mission Statement" for the interim work? > > > >Regards, > >Istvan > > > >------------------------------------------------------------------------- > - > >Dr. Istvan Sebestyen > >Siemens AG, ICN M CS27, > >Hofmannstr. 51 D-81359 Munich > >Tel:+49-89-722-47230 > >Fax:+49-89-722-47713 > >E-Mail office: istvan.sebestyen(a)icn.siemens.de; istvan(a)sebestyen.de > >E-mail private: istvan_sebestyen(a)yahoo.com; > >Siemens Intranet:http://netinfo.icn.siemens.de/es/team/essp/team/essp4 > >Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de > >------------------------------------------------------------------------- > -- > - > >---------------- > > > >> ---------- > >> From: Orit Levin[SMTP:orit@radvision.com] > >> Reply To: Orit Levin > >> Sent: Thursday, February 24, 2000 6:53 PM > >> To: ITU-SG16(a)mailbag.cps.intel.com > >> Subject: [H.323-SIP/Internet] The reason. > >> > >> Hi! > >> I would like to highlight the reason of "H.323-XXX" work in ITU-T as > >> described in the initial paper. > >> > >> H.323 is NOT new to Internet. Internet is evolving and new > specifications > >> in "IP telephony" area are being defined in IETF. This is a time to > >> consider each one of these specifications to be applied to H.323. If > found > >> useful from technical point of view (as a kind of Back End Services) or > >> just as required for interworking purposes (such as H.323-SIP > scenarios), > >> standard definitions for H.323 should be formulated. These two are > >> connected since the first definitely helps the second. > >> > >> The written above agenda is a proposal for the work scope. Based on our > >> discussions, it seems like more then one company would like to see this > >> work beyond the topic of H.323-SIP interoperability. (forget the name > :-) > >> ) If we agree that standardization is needed for this kind of work, the > >> only possible way to do it is to participate in ITU-T process (with all > >> its meaning). > >> > >> Currently we are in the beginning of the process sorting out topics of > our > >> interest. I think most of us are aware of the work being done in other > >> organizations. We would like to see experts (including from TIPHON and > >> IETF) presenting their concepts to ITU (starting from the mailing list) > >> keeping us from repeating their work and being aligned with them. > >> > >> 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 > >>

4 4

H.450 Enabled App Server
by David Hoke 27 Feb '00

27 Feb '00

Technical Group Members, I am building a Global Ipbx service based on H.323 and hope to use H.450 as the basis for transferring calls among media processing applications (i.e. Voicemail, Auto Attendant etc) as well as stations. I seek an applications media processing gateway that would have H.323/H.450 on the VoIP side and ECTF (S.100 and H.1xx) or equivalent on the application side... like a Dialogic DM3 but with H.450 and no built-in trunk connections. I want to gateway to DSP based applications not trunks. I want to avoid the common VoIP/CTI work around which requires converting VoIP to a trunk call then locally patching the trunk to app servers. In this way I could immediately use existing CTI applications via the iPBX service without using inefficient work arounds. Please help identify specified product or make alternate suggestions for achieving the same result. Thank You, David Hoke CTO ViaWorldNet 1 Meadowood Rd Carriage House Rosemont, PA 19010 USA davidh(a)publicinternetcorp.com 1-610-331-6010

1 0

Missing text in H.341
by Sakae OKUBO 27 Feb '00

27 Feb '00

Dear H.341 MIB experts, Please respond to the attached request. This is the last opportunity to correct the text of H.341 which was decided in May 1999. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** From: "Trabulsi, Sami" <sami.trabulsi(a)itu.int> To: "Okubo, Sakae (TIES)" <Sakae.Okubo(a)ties.itu.int>,"'irina(a)ennovatenetworks.com'" <irina(a)ennovatenetworks.com> Cc: "Freundlich, Glen (TIES)" <Glen.Freundlich(a)ties.itu.int>,"Bigi, Fabio" <Fabio.Bigi(a)itu.int> Subject: FW: Missing text in H.341 Date: Fri, 25 Feb 2000 19:10:04 +0100 Dear Ms. Suconick, Dear Mr. Okubo Dear Mr. Maeng, As TSB is in the process of H.341 publication, I made a quick comparison of different occurences of the structure. It seems that just one line is missing. The wording of this line could be the following (shown in upper case letters): h320McuTerminalStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF H320McuTerminalStatsTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information about entities that are CONNECTED TO THE ENTITY. IT IS A LIST OF CONNECTED TERMINALS. The number of entries equals to the number of terminals." ::= { h320McuTerminal 2 } Could you please correct/confirm/complete this structure ? Best regards Sami Trabulsi TSB - editing department +41 22 730 5000 Email: sami.trabulsi(a)itu.int -----Original Message----- From: Sakae OKUBO [mailto:sakae.okubo@ties.itu.int] Sent: vendredi, 18. f $B;W (Brier 2000 18:31 To: irina(a)ennovatenetworks.com Cc: Glen Freundlich; Fabio Bigi Subject: Missing text in H.341 Dear Ms. Irina Suconick, Dear Mr. Joon Maeng, ITU-TSB is going to publish H.341 decided in Satiago last May. The following syntax is missing some text after "that are" in the middle: ---------- h320McuTerminalMCUPhoneNumber OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..25)) MAX-ACCESS read-only STATUS current DESCRIPTION "The MCU phone number." ::= { h320McuTerminalStatusTableEntry 11 } h320McuTerminalStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF H320McuTerminalStatsTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information about entities that are The number of entries equals to the number of terminals." ::= { h320McuTerminal 2 } h320McuTerminalStatsTableEntry OBJECT-TYPE SYNTAX H320McuTerminalStatsTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "It contains objects that describe a terminal." INDEX { h320McuTerminalId } ::= { h320McuTerminalStatsTable 1 } ---------- I tried to find if there is an answer in the past documents, but failed. Could you please advise me of the missing text as soon as possible, by next Wednesday at the latest? Otherwise H.341 will be published as it is. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Please upload the decided/determined/approved texts
by Sakae OKUBO 27 Feb '00

27 Feb '00

Dear Editors, Could you please upload your documents of decision, determination or approval at the /Incoming of the PictureTel ftp site? Please make an announce through the reflector when you have uploaded your documents. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

6 5

Do You Want to Be a Millionaire?
by CA$HFLOWEB 27 Feb '00

27 Feb '00

Dear , Have you ever sat in front of your PC and thought that there must be some way to use this powerful piece of technology to make extra money, but didn't have slightest idea how to go about doing it? Welcome to the world of Mail Order! Now before you get the idea that this will involve a lot of stamp-licking and trips to the post office, let me say that this business is not like the traditional mail-ordering business. Instead of a lot of paperwork, your PC will be accomplishing the bulk of the work much faster and easier than if it was done manually. The total investment for this opportunity is $5.00 (no kidding!) and the cost of five postage stamps. The rest of the work will be done by your PC, and will only involve a small amount of time behind the keyboard. But once again, I'd like to ask that you follow the instructions carefully. The success or failure of this plan depends on the honesty and integrity of its participants. If the plan is followed to the letter, it cannot fail. go to the following link http://www.cashfloweb.freeservers.com. Once you are there, download the program from the main page and start making money. Best Regards, CA$HFLOWEB

1 0

Re: H.323 Annex D
by Roy, Radhika R, ALARC 27 Feb '00

27 Feb '00

Hi, Everyone: In addition to Frank Audet's comments, I like to know whether H.323 Annex D was determined in the last SG16 meeting [I do not see it in the table, p27, TD-74 (plen)]. Thanks, Radhika R. Roy AT&T > -----Original Message----- > From: Francois Audet [SMTP:audet@NORTELNETWORKS.COM] > Sent: Friday, February 25, 2000 1:56 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.323 Annex D > > Hi, > > I'm not sure who is editor of H.323 Annex D, but... > > It seems that there is no reference in Annex D of what version of H.323 > and H.245 is required for the procedures to work. There is no way to > indicate T.38 or even support of UDP vs. TCP transport in H.245v2. > > I think the answer is that H.245v4 or later is required. Perhaps somebody > can clarify if this is correct. > > In any case, we definitively need to specify in H.323 Annex D which > version of H.245 is required... > > ----- > François Audet Tel:+1 408 565 5675 <mailto:audet@NortelNetworks.com> > Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com > <http://www.nortelnetworks.com/> > >

2 1

Re: Registered payload types for G.723.1/G.729
by Chip Sharp 26 Feb '00

26 Feb '00

I'd recommend that as SG16 defines new encoding types that it register them with IANA. Theoretically, someone could register your codepoints for a different algorithm. Chip At 01:11 PM 2/23/00 -0800, Hutton, Charles wrote: >I have the same concerns for G.729E. > > >Charles (Chuck) Hutton >Strategic Architecture Engineering >Wireless Local Technology Group >AT&T Wireless Services >PO Box 97059 >Redmond, WA 98073 (USPS only) >9461 Willows Road >Redmond, WA 98052 (FEDEX/UPS) >425-702-2938 Voice >425-702-2518 FAX >charles.hutton(a)attws.com > > > ---------- > > From: Frank Derks[SMTP:frank.derks@PHILIPS.COM] > > Reply To: Mailing list for parties associated with ITU-T Study Group > > 16 > > Sent: Wednesday, February 23, 2000 8:46 AM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: Registered payload types for G.723.1/G.729 > > > > <<File: FILE0001>> > > Tom, > > > > section 3 of RFC1890 indeed specifies how additional payload types have to > > be registered with the IANA. > > Table 2 in section 7 specifies the assigned (and unassigned) payload types > > at the time of publication of the > > RFC (presumably). This table is no longer in line with the table that can > > be found at the IANA Web site > > (http://www.isi.edu/in-notes/iana/assignments/rtp-parameters) however. > > > > Since G.729 is not present in either of these tables, it would seem that > > somebody will need to undertake > > the action to do so. Especially because H.225.0 _does_ specify a payload > > type for G.729 and I think it is > > desirable that the code that is being used is not assigned (inadvertently) > > to some other codec. > > > > Whose responsibility would it be to do so? ITU-SG16? > > > > ----------------------------------------------------- > > Frank Derks |Tel +31 35 6893238 | > > Advanced Development |Fax +31 35 6891030 | > > Philips Business Communications|P.O. Box 32 | > > |1200 JD Hilversum | > > |The Netherlands | > > ----------------------------------------------------| > > E-mail: mailto:frank.derks@philips.com | > > WWW: http://www.sopho.philips.com | > > ----------------------------------------------------- > > > > > > > > > > > > taylor@NORTELNETWORKS.COM@SMTP@MAILBAG.INTEL.COM on 23/02/2000 17:24:37 > > Please respond to ITU-SG16@MAILBAG.INTEL.COM@SMTP > > Sent by: ITU-SG16(a)MAILBAG.INTEL.COM > > To: ITU-SG16@MAILBAG.INTEL.COM@SMTP > > cc: > > Subject: Re: Registered payload types for G.723.1/G.729 > > Classification: Restricted > > As I understand it (and I'd better be right, because I have to do similar > > things for H.248!) the stuff initially defined in the RFC that sets up the > > registration process (RFC 1890) does not go into the IANA database -- only > > subsequent registrations. > > > > > -----Original Message----- > > > From: Frank Derks [SMTP:frank.derks@PHILIPS.COM] > > > Sent: Tuesday, February 22, 2000 10:30 AM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Registered payload types for G.723.1/G.729 > > > > > > H.225.0 specifies that the payload types for G.723.1 and G.729 are 4 and > > > 18 respectively. > > > When I take a look at the registered payload types at the IANA, these > > two > > > codecs are > > > not listed. > > > > > > Does this mean that the IANA list is not up-to-date or that these codecs > > > are not officially > > > registered. > > > > > > Frank > > > > > > ----------------------------------------------------- > > > Frank Derks |Tel +31 35 6893238 | > > > Advanced Development |Fax +31 35 6891030 | > > > Philips Business Communications|P.O. Box 32 | > > > |1200 JD Hilversum | > > > |The Netherlands | > > > ----------------------------------------------------| > > > E-mail: mailto:frank.derks@philips.com | > > > WWW: http://www.sopho.philips.com | > > > ----------------------------------------------------- > > > > > > > > Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. --------------------------------------------------

4 4

Re: [H.323-SIP/Internet] The reason.
by Joon Maeng 25 Feb '00

25 Feb '00

FYI - I asked the IETF area directors to give me a guidance on requesting a BOF. I have not heard anything yet. I'll keep you posted. Regards, Joon > -----Original Message----- > From: Roy, Radhika R, ALARC [mailto:rrroy@att.com] > Sent: Friday, February 25, 2000 5:02 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: [H.323-SIP/Internet] The reason. > > > Hi, Everyone: > > Both Dave and Joon made good points. In addition to the > upcoming SG16 Rap. > meeting, I would assume that Joon, Dave, and others will also > be willing to > work for the BOF in the upcoming IETF meeting (March'00). > > We have to focus in both organizations: IETF and SG16. Once > we show our > interest, the rest will be fine. > > The most important point is that we have start our work: SIP-H.323 > Interworking Standard. > > Best regards, > Radhika R. Roy > AT&T > > > -----Original Message----- > > From: Dave Walker [SMTP:drwalker@ss8networks.com] > > Sent: Friday, February 25, 2000 5:35 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: [H.323-SIP/Internet] The reason. > > > > It depends what the outcome of the work is. The first step > must be to > > define what our goals are. I don't want to pre-judge what > the outcome > > is going to be until I know what we're actually trying to achieve. > > > > One possible eventual outcome could be an H.246 type document that > > provides a message by message, field by field mapping > between H.323 and > > SIP, or we might only define a high level profile that states which > > procedures an implementation should and should not use in > order to ensure > > interworking (e.g. "H.323 endpoints shall use fast > connect"). So it's > > not clear that we're going to need an ITU recommendation, > possibly a BCP > > RFC or some ITU equivalent might suffice. If the SIP and/or H.323 > > specifications need to be changed to address our interworking goals, > > it's again not clear that new standards are needed, both > SIP and H.323 > > can tweaked if needed. If its determined that one or both of the > > protocols needs a major overhaul in order to support > interworking, then > > it's probably a sign that the goals for interworking > weren't appropriate. > > > > What we need to do is to ensure that all interested parties > are able to > > participate fully in the discussions. That kind of open > process is the > > norm in the IETF. I'd be unhappy to see a situation where I had to > > spend thousands of dollars to join a consortium just to access a few > > drafts or subscribe to a mailing list. > > > > The argument is often made that the ITU has the H.323 > experts and the IETF > > has the SIP experts, but in fact the overlap of these > experts is probably > > larger than they'd care to admit. Despite what is written > in the meeting > > report, there is enough interest in SG16 to keep the work > moving there. > > There is obviously interest in the IETF as well. > > > > I agree with the proposal that a BOF be held at the next IETF where > > interested experts can attempt to resolve the scope of the > work and gauge > > the IETF's interest in owning it. Due to the reluctance shown by SG > > management in the recent SG16 meeting, the door certainly > seems open to > > allowing the IETF ownership. Input to the BOF should at least be an > > I-D based on the document written by RadVision, as well as the > > Singh/Schulzrinne draft. > > > > Dave Walker > > SS8 Networks > > Ottawa Canada > > > > > > -----Original Message----- > > From: Mailing list for parties associated with ITU-T Study Group 16 > > [mailto:ITU-SG16@MAILBAG.INTEL.COM]On Behalf Of Joon Maeng > > Sent: Friday, February 25, 2000 3:35 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: [H.323-SIP/Internet] The reason. > > > > > > I would propose that it should be a combined work with > IETF. Ideally we > > should get ITU recommendation number and ITU RFC number for the same > > document when it is complete. If you look at SIP-H.323 > interworking, > > there > > are certain components that have to be standardized. (We > will need more > > than > > interworking guidelines.) > > Regards, > > Joon > > > > > -----Original Message----- > > > From: Roy, Radhika R, ALARC [mailto:rrroy@att.com] > > > Sent: Friday, February 25, 2000 10:46 AM > > > To: ITU-SG16(a)mailbag.cps.intel.com > > > Subject: Re: [H.323-SIP/Internet] The reason. > > > > > > > > > Hi, Everyone: > > > > > > We are all aware that many works related to H.323-SIP > > > Interworking works are > > > being proposed including IMTC and TIPHON. I am also in > touch with Ayse > > > Dilber of AT&T. These organizations are primarily chartered for > > > interoperability agreements, testing, etc. and do NOT create > > > standards per > > > se. Like TIPHON, they are willing to send a liaison to > the ITU-T SG16 > > > recommending the requirements. > > > > > > In the same fashion, TIPHON and IMTC are also working for > > > H.323 mobility > > > works. That does not mean that the SG16 should not do the > > > H.323 mobility > > > work. > > > > > > The H.323 and SIP standards are created by the ITU-T and > > > IETF, respectively > > > and these standards organizations are the right bodies to > create the > > > standards that are recognized internationally. > > > > > > I am again quoting from decision taken in the last SG16 > meeting TD-74 > > > (Plen), Section 3.8.5.1, p-48: > > > > > > "... Invite contributions on how to approach the work. Need > > > to get scenarios > > > for progressing work in a controlled architectural approach. > > > Ms. Levin has > > > volunteered to draft a framework. ..." > > > > > > We are proceeding to work along this line in the SG16. > > > > > > Best Regards, > > > Radhika R. Roy > > > AT&T > > > +1 732 420 1580 > > > rrroy(a)att.com > > > > > > > -----Original Message----- > > > > From: Sebestyen Istvan ICN M CS 27 > > > [SMTP:Istvan.Sebestyen@ICN.SIEMENS.DE] > > > > Sent: Friday, February 25, 2000 9:27 AM > > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > > Subject: Re: [H.323-SIP/Internet] The reason. > > > > Importance: High > > > > > > > > Dear Colleagues, > > > > I was present at the SG16 meeting, and have also read now > > > carefully the > > > > meeting report. There is really at this point in time in > > > the ITU no new > > > > "workitem" or "question" open for this work. Certainly this > > > might change > > > > if > > > > based on contributions SG16 decides so. > > > > > > > > You might, however, be interested that in the IMTC a lot of > > > very similar > > > > work is already being done. > > > > Have a view of the program of the aHIT! Working Group > > > (chaired by Ayse > > > > Dilber (adilber(a)att.com)) of AT&T), described below. > > > > I am sure Ayse will be more than happy to see more > active co-workers > > > > pushing > > > > the work of aHIT! ahead. The aHIT! program was approved > > > within the IMTC in > > > > November 1999, and now it is running full speed. > > > > > > > > Kind regards, > > > > Istvan sebestyen > > > > > > > > > > > > > > > > > > > > > > > > aHIT! AG's Objectives: > > > > > > > > - Identify VoIP and Multimedia Applications (i.e., VoIP, FoIP, > > > > Conferencing, > > > > Instant Messaging, etc.) which will enable service > > > providers to implement > > > > end-to-end services; > > > > - Identify Interworking Scenarios (i.e., between H.323 and > > > > SIP/H.248-MEGACO/cable/etc.) to achieve interworking > > > between different > > > > protocols to support multi-vendor and multi-service > > > provider environments; > > > > - Develop technical interoperability documents per > > > application and per > > > > scenario to guide service providers and vendors to > > > implement seamless, > > > > secure, global VoIP and Multimedia Applications; > > > > - Encourage, define and participate in global VoIP and > Multimedia > > > > applications trials between member service providers and vendors > > > > - Provide a forum for open technical exchange; > > > > - Support, promote and participate in IMTC/ETSI testing events. > > > > > > > > aHIT! AG Work Plan: > > > > > > > > 1) Define technical lower layer communications capabilities > > > and protocols > > > > for each application. > > > > 2) Work on interworking between H.323 and SIP/NCS/H.248-MEGACO. > > > > 3) Introduce the value-added functionalities and > enhanced services. > > > > 4) Develop and publish technical interoperability documents per > > > > application/scenario starting from 2Q00. > > > > > > > > aHIT! AG will address the following issues for each > application,: > > > > > > > > Performance/QoS > > > > Reliability > > > > Naming/Numbering/Addressing > > > > Settlements/Billing > > > > Fax Support > > > > OAM&P Support > > > > Number Portability > > > > Interworking Issues(i.e.,H.323/SIP/MEGACO/NCS and CCS/PSTN) > > > > Enhanced Services (i.e., roaming) > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > ------------ > > > > Dr. Istvan Sebestyen > > > > Siemens AG, ICN M CS27, > > > > Hofmannstr. 51 D-81359 Munich > > > > Tel:+49-89-722-47230 > > > > Fax:+49-89-722-47713 > > > > E-Mail office: istvan.sebestyen(a)icn.siemens.de; > istvan(a)sebestyen.de > > > > E-mail private: istvan_sebestyen(a)yahoo.com; > > > > Siemens > > > Intranet:http://netinfo.icn.siemens.de/es/team/essp/team/essp4 > > > > Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de > > > > > > > -------------------------------------------------------------- > > > ------------ > > > > -- > > > > ---------------- > > > > > > > > > ---------- > > > > > From: Roy, Radhika R, ALARC[SMTP:rrroy@ATT.COM] > > > > > Reply To: Mailing list for parties associated with > > > ITU-T Study Group > > > > > 16 > > > > > Sent: Friday, February 25, 2000 1:58 PM > > > > > To: ITU-SG16(a)mailbag.cps.intel.com > > > > > Subject: Re: [H.323-SIP/Internet] The reason. > > > > > > > > > > Hi, Everyone: > > > > > > > > > > I am in full agreement with Orit. I guess that this has > > > also been the > > > > case > > > > > for many people who had been present in the SG16 meeting. > > > > > > > > > > More importantly, when I talked to Glen, he clearly > > > indicated that we > > > > > should > > > > > bring contributions to get the work started. The > > > interworking between > > > > > H.323 > > > > > and SIP may belong Q.14 (although it has to be discussed > > > jointly with > > > > Q.13 > > > > > and Q.14). > > > > > > > > > > There has been a very strong interest for the work of > H.323-SIP > > > > > Interworking. A large number of people throughout the > > > world (starting > > > > from > > > > > the ITU-T and IETF) is contacting me. > > > > > > > > > > The primary goal of the standard bodies is to provide > > > > "INTEROPERABILITY." > > > > > > > > > > Best regards, > > > > > Radhika R. Roy > > > > > AT&T > > > > > +1 732 420 1580 > > > > > rrroy(a)att.com > > > > > > > > > > > > > >

1 0

Re: [H.323-SIP/Internet] The reason.
by Roy, Radhika R, ALARC 25 Feb '00

25 Feb '00

Hi, Everyone: Both Dave and Joon made good points. In addition to the upcoming SG16 Rap. meeting, I would assume that Joon, Dave, and others will also be willing to work for the BOF in the upcoming IETF meeting (March'00). We have to focus in both organizations: IETF and SG16. Once we show our interest, the rest will be fine. The most important point is that we have start our work: SIP-H.323 Interworking Standard. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Dave Walker [SMTP:drwalker@ss8networks.com] > Sent: Friday, February 25, 2000 5:35 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323-SIP/Internet] The reason. > > It depends what the outcome of the work is. The first step must be to > define what our goals are. I don't want to pre-judge what the outcome > is going to be until I know what we're actually trying to achieve. > > One possible eventual outcome could be an H.246 type document that > provides a message by message, field by field mapping between H.323 and > SIP, or we might only define a high level profile that states which > procedures an implementation should and should not use in order to ensure > interworking (e.g. "H.323 endpoints shall use fast connect"). So it's > not clear that we're going to need an ITU recommendation, possibly a BCP > RFC or some ITU equivalent might suffice. If the SIP and/or H.323 > specifications need to be changed to address our interworking goals, > it's again not clear that new standards are needed, both SIP and H.323 > can tweaked if needed. If its determined that one or both of the > protocols needs a major overhaul in order to support interworking, then > it's probably a sign that the goals for interworking weren't appropriate. > > What we need to do is to ensure that all interested parties are able to > participate fully in the discussions. That kind of open process is the > norm in the IETF. I'd be unhappy to see a situation where I had to > spend thousands of dollars to join a consortium just to access a few > drafts or subscribe to a mailing list. > > The argument is often made that the ITU has the H.323 experts and the IETF > has the SIP experts, but in fact the overlap of these experts is probably > larger than they'd care to admit. Despite what is written in the meeting > report, there is enough interest in SG16 to keep the work moving there. > There is obviously interest in the IETF as well. > > I agree with the proposal that a BOF be held at the next IETF where > interested experts can attempt to resolve the scope of the work and gauge > the IETF's interest in owning it. Due to the reluctance shown by SG > management in the recent SG16 meeting, the door certainly seems open to > allowing the IETF ownership. Input to the BOF should at least be an > I-D based on the document written by RadVision, as well as the > Singh/Schulzrinne draft. > > Dave Walker > SS8 Networks > Ottawa Canada > > > -----Original Message----- > From: Mailing list for parties associated with ITU-T Study Group 16 > [mailto:ITU-SG16@MAILBAG.INTEL.COM]On Behalf Of Joon Maeng > Sent: Friday, February 25, 2000 3:35 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323-SIP/Internet] The reason. > > > I would propose that it should be a combined work with IETF. Ideally we > should get ITU recommendation number and ITU RFC number for the same > document when it is complete. If you look at SIP-H.323 interworking, > there > are certain components that have to be standardized. (We will need more > than > interworking guidelines.) > Regards, > Joon > > > -----Original Message----- > > From: Roy, Radhika R, ALARC [mailto:rrroy@att.com] > > Sent: Friday, February 25, 2000 10:46 AM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: [H.323-SIP/Internet] The reason. > > > > > > Hi, Everyone: > > > > We are all aware that many works related to H.323-SIP > > Interworking works are > > being proposed including IMTC and TIPHON. I am also in touch with Ayse > > Dilber of AT&T. These organizations are primarily chartered for > > interoperability agreements, testing, etc. and do NOT create > > standards per > > se. Like TIPHON, they are willing to send a liaison to the ITU-T SG16 > > recommending the requirements. > > > > In the same fashion, TIPHON and IMTC are also working for > > H.323 mobility > > works. That does not mean that the SG16 should not do the > > H.323 mobility > > work. > > > > The H.323 and SIP standards are created by the ITU-T and > > IETF, respectively > > and these standards organizations are the right bodies to create the > > standards that are recognized internationally. > > > > I am again quoting from decision taken in the last SG16 meeting TD-74 > > (Plen), Section 3.8.5.1, p-48: > > > > "... Invite contributions on how to approach the work. Need > > to get scenarios > > for progressing work in a controlled architectural approach. > > Ms. Levin has > > volunteered to draft a framework. ..." > > > > We are proceeding to work along this line in the SG16. > > > > Best Regards, > > Radhika R. Roy > > AT&T > > +1 732 420 1580 > > rrroy(a)att.com > > > > > -----Original Message----- > > > From: Sebestyen Istvan ICN M CS 27 > > [SMTP:Istvan.Sebestyen@ICN.SIEMENS.DE] > > > Sent: Friday, February 25, 2000 9:27 AM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: [H.323-SIP/Internet] The reason. > > > Importance: High > > > > > > Dear Colleagues, > > > I was present at the SG16 meeting, and have also read now > > carefully the > > > meeting report. There is really at this point in time in > > the ITU no new > > > "workitem" or "question" open for this work. Certainly this > > might change > > > if > > > based on contributions SG16 decides so. > > > > > > You might, however, be interested that in the IMTC a lot of > > very similar > > > work is already being done. > > > Have a view of the program of the aHIT! Working Group > > (chaired by Ayse > > > Dilber (adilber(a)att.com)) of AT&T), described below. > > > I am sure Ayse will be more than happy to see more active co-workers > > > pushing > > > the work of aHIT! ahead. The aHIT! program was approved > > within the IMTC in > > > November 1999, and now it is running full speed. > > > > > > Kind regards, > > > Istvan sebestyen > > > > > > > > > > > > > > > > > > aHIT! AG's Objectives: > > > > > > - Identify VoIP and Multimedia Applications (i.e., VoIP, FoIP, > > > Conferencing, > > > Instant Messaging, etc.) which will enable service > > providers to implement > > > end-to-end services; > > > - Identify Interworking Scenarios (i.e., between H.323 and > > > SIP/H.248-MEGACO/cable/etc.) to achieve interworking > > between different > > > protocols to support multi-vendor and multi-service > > provider environments; > > > - Develop technical interoperability documents per > > application and per > > > scenario to guide service providers and vendors to > > implement seamless, > > > secure, global VoIP and Multimedia Applications; > > > - Encourage, define and participate in global VoIP and Multimedia > > > applications trials between member service providers and vendors > > > - Provide a forum for open technical exchange; > > > - Support, promote and participate in IMTC/ETSI testing events. > > > > > > aHIT! AG Work Plan: > > > > > > 1) Define technical lower layer communications capabilities > > and protocols > > > for each application. > > > 2) Work on interworking between H.323 and SIP/NCS/H.248-MEGACO. > > > 3) Introduce the value-added functionalities and enhanced services. > > > 4) Develop and publish technical interoperability documents per > > > application/scenario starting from 2Q00. > > > > > > aHIT! AG will address the following issues for each application,: > > > > > > Performance/QoS > > > Reliability > > > Naming/Numbering/Addressing > > > Settlements/Billing > > > Fax Support > > > OAM&P Support > > > Number Portability > > > Interworking Issues(i.e.,H.323/SIP/MEGACO/NCS and CCS/PSTN) > > > Enhanced Services (i.e., roaming) > > > > > > > > > > > > > > -------------------------------------------------------------- > > ------------ > > > Dr. Istvan Sebestyen > > > Siemens AG, ICN M CS27, > > > Hofmannstr. 51 D-81359 Munich > > > Tel:+49-89-722-47230 > > > Fax:+49-89-722-47713 > > > E-Mail office: istvan.sebestyen(a)icn.siemens.de; istvan(a)sebestyen.de > > > E-mail private: istvan_sebestyen(a)yahoo.com; > > > Siemens > > Intranet:http://netinfo.icn.siemens.de/es/team/essp/team/essp4 > > > Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de > > > > > -------------------------------------------------------------- > > ------------ > > > -- > > > ---------------- > > > > > > > ---------- > > > > From: Roy, Radhika R, ALARC[SMTP:rrroy@ATT.COM] > > > > Reply To: Mailing list for parties associated with > > ITU-T Study Group > > > > 16 > > > > Sent: Friday, February 25, 2000 1:58 PM > > > > To: ITU-SG16(a)mailbag.cps.intel.com > > > > Subject: Re: [H.323-SIP/Internet] The reason. > > > > > > > > Hi, Everyone: > > > > > > > > I am in full agreement with Orit. I guess that this has > > also been the > > > case > > > > for many people who had been present in the SG16 meeting. > > > > > > > > More importantly, when I talked to Glen, he clearly > > indicated that we > > > > should > > > > bring contributions to get the work started. The > > interworking between > > > > H.323 > > > > and SIP may belong Q.14 (although it has to be discussed > > jointly with > > > Q.13 > > > > and Q.14). > > > > > > > > There has been a very strong interest for the work of H.323-SIP > > > > Interworking. A large number of people throughout the > > world (starting > > > from > > > > the ITU-T and IETF) is contacting me. > > > > > > > > The primary goal of the standard bodies is to provide > > > "INTEROPERABILITY." > > > > > > > > Best regards, > > > > Radhika R. Roy > > > > AT&T > > > > +1 732 420 1580 > > > > rrroy(a)att.com > > > > > > > > > >

1 0

Re: [H.323-SIP/Internet] The reason.
by Joon Maeng 25 Feb '00

25 Feb '00

I would propose that it should be a combined work with IETF. Ideally we should get ITU recommendation number and ITU RFC number for the same document when it is complete. If you look at SIP-H.323 interworking, there are certain components that have to be standardized. (We will need more than interworking guidelines.) Regards, Joon > -----Original Message----- > From: Roy, Radhika R, ALARC [mailto:rrroy@att.com] > Sent: Friday, February 25, 2000 10:46 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: [H.323-SIP/Internet] The reason. > > > Hi, Everyone: > > We are all aware that many works related to H.323-SIP > Interworking works are > being proposed including IMTC and TIPHON. I am also in touch with Ayse > Dilber of AT&T. These organizations are primarily chartered for > interoperability agreements, testing, etc. and do NOT create > standards per > se. Like TIPHON, they are willing to send a liaison to the ITU-T SG16 > recommending the requirements. > > In the same fashion, TIPHON and IMTC are also working for > H.323 mobility > works. That does not mean that the SG16 should not do the > H.323 mobility > work. > > The H.323 and SIP standards are created by the ITU-T and > IETF, respectively > and these standards organizations are the right bodies to create the > standards that are recognized internationally. > > I am again quoting from decision taken in the last SG16 meeting TD-74 > (Plen), Section 3.8.5.1, p-48: > > "... Invite contributions on how to approach the work. Need > to get scenarios > for progressing work in a controlled architectural approach. > Ms. Levin has > volunteered to draft a framework. ..." > > We are proceeding to work along this line in the SG16. > > Best Regards, > Radhika R. Roy > AT&T > +1 732 420 1580 > rrroy(a)att.com > > > -----Original Message----- > > From: Sebestyen Istvan ICN M CS 27 > [SMTP:Istvan.Sebestyen@ICN.SIEMENS.DE] > > Sent: Friday, February 25, 2000 9:27 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: [H.323-SIP/Internet] The reason. > > Importance: High > > > > Dear Colleagues, > > I was present at the SG16 meeting, and have also read now > carefully the > > meeting report. There is really at this point in time in > the ITU no new > > "workitem" or "question" open for this work. Certainly this > might change > > if > > based on contributions SG16 decides so. > > > > You might, however, be interested that in the IMTC a lot of > very similar > > work is already being done. > > Have a view of the program of the aHIT! Working Group > (chaired by Ayse > > Dilber (adilber(a)att.com)) of AT&T), described below. > > I am sure Ayse will be more than happy to see more active co-workers > > pushing > > the work of aHIT! ahead. The aHIT! program was approved > within the IMTC in > > November 1999, and now it is running full speed. > > > > Kind regards, > > Istvan sebestyen > > > > > > > > > > > > aHIT! AG's Objectives: > > > > - Identify VoIP and Multimedia Applications (i.e., VoIP, FoIP, > > Conferencing, > > Instant Messaging, etc.) which will enable service > providers to implement > > end-to-end services; > > - Identify Interworking Scenarios (i.e., between H.323 and > > SIP/H.248-MEGACO/cable/etc.) to achieve interworking > between different > > protocols to support multi-vendor and multi-service > provider environments; > > - Develop technical interoperability documents per > application and per > > scenario to guide service providers and vendors to > implement seamless, > > secure, global VoIP and Multimedia Applications; > > - Encourage, define and participate in global VoIP and Multimedia > > applications trials between member service providers and vendors > > - Provide a forum for open technical exchange; > > - Support, promote and participate in IMTC/ETSI testing events. > > > > aHIT! AG Work Plan: > > > > 1) Define technical lower layer communications capabilities > and protocols > > for each application. > > 2) Work on interworking between H.323 and SIP/NCS/H.248-MEGACO. > > 3) Introduce the value-added functionalities and enhanced services. > > 4) Develop and publish technical interoperability documents per > > application/scenario starting from 2Q00. > > > > aHIT! AG will address the following issues for each application,: > > > > Performance/QoS > > Reliability > > Naming/Numbering/Addressing > > Settlements/Billing > > Fax Support > > OAM&P Support > > Number Portability > > Interworking Issues(i.e.,H.323/SIP/MEGACO/NCS and CCS/PSTN) > > Enhanced Services (i.e., roaming) > > > > > > > > > -------------------------------------------------------------- > ------------ > > Dr. Istvan Sebestyen > > Siemens AG, ICN M CS27, > > Hofmannstr. 51 D-81359 Munich > > Tel:+49-89-722-47230 > > Fax:+49-89-722-47713 > > E-Mail office: istvan.sebestyen(a)icn.siemens.de; istvan(a)sebestyen.de > > E-mail private: istvan_sebestyen(a)yahoo.com; > > Siemens > Intranet:http://netinfo.icn.siemens.de/es/team/essp/team/essp4 > > Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de > > > -------------------------------------------------------------- > ------------ > > -- > > ---------------- > > > > > ---------- > > > From: Roy, Radhika R, ALARC[SMTP:rrroy@ATT.COM] > > > Reply To: Mailing list for parties associated with > ITU-T Study Group > > > 16 > > > Sent: Friday, February 25, 2000 1:58 PM > > > To: ITU-SG16(a)mailbag.cps.intel.com > > > Subject: Re: [H.323-SIP/Internet] The reason. > > > > > > Hi, Everyone: > > > > > > I am in full agreement with Orit. I guess that this has > also been the > > case > > > for many people who had been present in the SG16 meeting. > > > > > > More importantly, when I talked to Glen, he clearly > indicated that we > > > should > > > bring contributions to get the work started. The > interworking between > > > H.323 > > > and SIP may belong Q.14 (although it has to be discussed > jointly with > > Q.13 > > > and Q.14). > > > > > > There has been a very strong interest for the work of H.323-SIP > > > Interworking. A large number of people throughout the > world (starting > > from > > > the ITU-T and IETF) is contacting me. > > > > > > The primary goal of the standard bodies is to provide > > "INTEROPERABILITY." > > > > > > Best regards, > > > Radhika R. Roy > > > AT&T > > > +1 732 420 1580 > > > rrroy(a)att.com > > > > > > >

2 1