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@att.com
-----Original Message----- From: Orit Levin [SMTP:orit@radvision.com] Sent: Thursday, February 24, 2000 4:42 PM To: ITU-SG16@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@radvision.com -----Original Message----- From: Callaghan, Robert <Robert.Callaghan@icn.siemens.com> To: 'Orit Levin' <orit@radvision.com>; ITU-SG16@mailbag.cps.intel.com <ITU-SG16@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@ICN.Siemens.com ------------------------------------------------------------------
-----Original Message----- From: Orit Levin [mailto:orit@radvision.com] Sent: Thursday, February 24, 2000 2:27 PM To: ITU-SG16@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@radvision.com -----Original Message----- From: Sebestyen Istvan ICN M CS 27 <Istvan.Sebestyen@icn.siemens.de> To: ITU-SG16@mailbag.cps.intel.com <ITU-SG16@mailbag.cps.intel.com>; 'Orit Levin' <orit@radvision.com> Date: Thursday, February 24, 2000 2:02 PM Subject: RE: [H.323-SIP/Internet] The reason.
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@icn.siemens.de; istvan@sebestyen.de E-mail private: istvan_sebestyen@yahoo.com; Siemens Intranet:http://netinfo.icn.siemens.de/es/team/essp/team/essp4 Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de ------------------------------------------------------------------------- --
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
-------------------------------------------------------------------------
----------------
---------- From: Orit Levin[SMTP:orit@radvision.com] Reply To: Orit Levin Sent: Thursday, February 24, 2000 6:53 PM To: ITU-SG16@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@radvision.com
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@att.com
-----Original Message----- From: Orit Levin [SMTP:orit@radvision.com] Sent: Thursday, February 24, 2000 4:42 PM To: ITU-SG16@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@radvision.com -----Original Message----- From: Callaghan, Robert <Robert.Callaghan@icn.siemens.com> To: 'Orit Levin' <orit@radvision.com>; ITU-SG16@mailbag.cps.intel.com <ITU-SG16@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,
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
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
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@ICN.Siemens.com ------------------------------------------------------------------
-----Original Message----- From: Orit Levin [mailto:orit@radvision.com] Sent: Thursday, February 24, 2000 2:27 PM To: ITU-SG16@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
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@radvision.com -----Original Message----- From: Sebestyen Istvan ICN M CS 27 <Istvan.Sebestyen@icn.siemens.de> To: ITU-SG16@mailbag.cps.intel.com <ITU-SG16@mailbag.cps.intel.com>; 'Orit Levin' <orit@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,
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.
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@icn.siemens.de; istvan@sebestyen.de E-mail private: istvan_sebestyen@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@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
work beyond the topic of H.323-SIP interoperability. (forget the name :-) ) If we agree that standardization is needed for this kind of work,
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
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@ATT.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: Friday, February 25, 2000 7:58 AM Subject: Re: [H.323-SIP/Internet] The reason. that paper person the that that this the 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@radvision.com
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.
Paul, I'm going to flame you, so dont take it personally. Paul, please! Such an argumentation coming from the ITU-T worries me quite a bit! Couldn't you think that this may actually have something to do with the fact that 3-4 years of interoperability trials for H.323 in Etsi/ITU/IMTC have lead to an amount of interoperability that was acheived in 1 or 2 bake-offs for SIP. That going to a SIP backeoff is cheap and attending the ITU-T is outrageously expensive. You can try to depict otherwize, but the basics underlying reasons why the ITU-T is doomed to perpetuously deceive IETF participants are still there ... no rough concencus, no running code, membership fees which lock-out small players, closed-policy on publication of standards, closed mailing lists, shall I go on ? The interest in interoperability with SIP is presently a one way relationship which comes from the H.323 people. Thus, it is the same H.323 people whi should consider coming to an industry-open, SIP bake-off. You can try talking Henning Schulzrinne into lettin you in. I'm sorry, but we just dont need the ITU-T, ETSI nor the IMTC slowing us down at the IETF ;-) I think that all of your analysis is rubbish. You could simply bring your stuff at one of the SIP bake-offs and get the feedback you need to go on and experiment a little more with H.323 ... You can try all you want to turn a Gatekeeper into a Proxy server/Redirect server, but it'll probably not happen in the marketplace. This said, I'm sorry for flaming you. -=Francois=-, "the guy who still cares about doing the dirty work when its necessary."
Francois, I do not take your arguments personally. But my statements are statements of fact, nothing more. Allow me to comment on your statements.
Paul wrote:
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.
Couldn't you think that this may actually have something to do with the fact that 3-4 years of interoperability trials for H.323 in Etsi/ITU/IMTC have lead to an amount of interoperability that was acheived in 1 or 2 bake-offs for SIP.
First of all, I should probably make it very clear that I have worked on both H.323 and SIP projects. I am aware of the stengths and weaknesses of each. There is a generally feeling that SIP is so easy and H.323 is much harder. In some ways, that's true-- in particular, the ASN.1 PER requires work. However OSS provides an excellent set of tools for that, so that's really a non-issue. H.323 supports multipoint, multimedia conferences. With H.323, there is the concept of a "conference" in which voice, video, and audio may be used. SIP, on the other hand, is a "session initiation protocol". It is not a conferencing protocol. In fact, since the BYE message is optional, SIP doesn't even exist after the remote party accepts the INVITE message and the ACK is returned. From that point forward, the "session" is nothing more than RTP streams flowing. There have been many H.323 interoperability events. Yes, there have been more problems than at SIP bake-offs, but that's because H.323 is a more complete system with a little more complexity to support multipoint voice, video, and data. But those interop events continue, because the standard continues to grow and evolve-- not because all of the previous events were total failures. Presently, there are literally millions of H.323 devices out there in the world in production networks. There are major carriers using H.323 to provide VoIP-- it's real. As far as I know, there is not one single production network running on SIP. Perhaps Level 3 might be using it between MGCs, but that deserves no special bragging rights. Perhaps I am wrong, but whatever SIP networks exist pales in the shadow of H.323.
That going to a SIP backeoff is cheap and attending the ITU-T is outrageously expensive. You can try to depict otherwize, but the basics underlying reasons why the ITU-T is doomed to perpetuously deceive IETF participants are still there ... no rough concencus, no running code, membership fees which lock-out small players, closed-policy on publication of standards, closed mailing lists, shall I go on ?
The ITU does require concensus and that often leads to a larger protocol. Essentially, some folks want one set of features and another group wants another set. The solution-- if they don't conflict, we add both. However, those additions are almost always optional. Essentially, manufacturers get to introduce into the standard what their customers want or need. As for the price of the ITU... it is a bit expensive, but we do not exclude the public from all meetings. The ITU meetings in Geneva are only for sector members or represetatives of a delegation. If any company wanted to attend the ITU meeting and they were not a sector member, the could most likely contact their government agency (U.S. State department in the US) and ask permission to attend. Most likely, permission would be granted. During the year, we also have "Rapporteur meetings". Those are completely open to the public and we have had IETFers at those meetings. The mailing list is certainly not closed: Intel runs the mailing list! As for the cost of the ITU: I have no control over that. The ITU, being part of the United Nations, has a responsibility to make documents available in multiple languages and provide meetings with interpreters. There are costs associated with that. I suppose the fees charges are necessary in order to maintain their facilities and employee the personel necessary in order to produce the various translations.
The interest in interoperability with SIP is presently a one way relationship which comes from the H.323 people. Thus, it is the same H.323 people whi should consider coming to an industry-open, SIP bake-off. You can try talking Henning Schulzrinne into lettin you in. I'm sorry, but we just dont need the ITU-T, ETSI nor the IMTC slowing us down at the IETF ;-)
Actually, the first H.323/SIP interworking effort was started on the IETF side. I'm not sure who started the list, but I know that Henning publicized the mailing list sip-h323@eGroups.com. I believe it's his list. Your last comment is precisely the kind of attitude I was talking about when I said that "I can also tell you that some of those members will also reject anything ETSI does, as well." It's interesting that members of the ITU will adopt specifications from the IETF or other organizations-- whatever is necessary to meet the requirements-- but that so many IETF people maintain a "holier-than-thou" attitude and are so unwilling to work with other standards bodies.
I think that all of your analysis is rubbish. You could simply bring your stuff at one of the SIP bake-offs and get the feedback you need to go on and experiment a little more with H.323 ... You can try all you want to turn a Gatekeeper into a Proxy server/Redirect server, but it'll probably not happen in the marketplace.
I believe that you have reconfirmed my analysis. Honestly, though, it's not "analysis". It's experience. I have attended IETF meeting and would continue if I had the time. I work with people who do attend the meetings. I know a lot of folks within the IETF and the ITU and I can tell you that there are very basic philosophical differences between the two organizations. As for turning a GK into a proxy server, it's more the other way around: a proxy server is looking more and more like a Gatekeeper these days. And will you see them converge? Quite possibly-- certainly, they are converging functionally.
This said, I'm sorry for flaming you.
I take no offense. But I do believe this exchange (and the recent H.248/MEGACO fiasco) and demonstrated that it is very difficult for the two organizations to work cooperatively. I am still open to a cooperative effort, because I think that is the best thing for our customers. Best Regards, Paul E. Jones Editor, H.323 Cisco Systems, Inc.
Paul, A few comments. 1. My company is not a member of the ITU, but I have attended a few non-rapporteur standards meetings (working-group meetings?) and was only required to request permission to attend from the chair, not a governmental agency. And I doubt whether anyone would be challenged if he or she just walked in uninvited, although that wouldn't be polite. :-) 2. I think Francois was referring to the fact that the IMTC said that as of the beginning of this year they were going to close the H.323 _implementors_ reflector so that only IMTC members could participate. I and others complained. For small companies, even the IMTC's $7500 yearly dues are prohibitive. Smith Micro can afford that but not the ITU's $30,000 dues. The IMTC hasn't closed the reflector so far, so they either forgot (quite likely) or have backed off without formally stating a change in policy. 3. Although it may irritate some folks to pay anything, the cost of a published ITU document is usually insignificant, e.g., 13USD, and the drafts are available at no cost. Paul Long Smith Micro Software, Inc.
participants (4)
-
Francois Menard List Account -
Paul E. Jones -
Paul Long -
Roy, Radhika R, ALARC