Hi, Roni: The important thing is that an Informational RFC for the SIP-H.323 Interworking is under way (with a possibility to standard RFC) in the IETF and the contributions that invented the interworking solution are also there (in the IETF). So, I am afraid that two non-compatible standards will emerge. We should NOT encourage non-compatible standards for the same thing. There are also no mechanisms in the ITU-T SG16 to accept the contributions for the companies that can afford to communicate via emails only. I guess that the best way is to have the RFC from the IETF that will have all inputs from all companies that invented the interworking solution. The SG16 can then have the RFC for their use to make a formal standard (with more additions if needed). It is well understood that the mapping between SDP and H.245 can not be done so easily and that is why an interworking standard is so urgent. If the informational RFC of the IETF does not cover the H.263+ parameters, the SG16 can then add those things. Or, any companies that like to address these parameters can also submit contributions as the IETF drafts (or send an email to the eGroup) proposing a solution. The SIP-H.323 interworking work is well under way in the IETF based on well written contributions as I described in my email. Why does the SG16 like to re-invent the wheel since this work is already progressing based on invented solutions submitted by the companies in the IETF? If you think that any improvements need to be done in the solutions proposed in the contributions of the IETF (please see the references provided in my email), please submit the proposal in the IETF. We can then use the Informational RFC as an input for a formal standard in the SG16. In this way, we can get the best the both worlds having a "single common standard for SIP-H.323 Interworking". The key is that the SG16 cannot use the interworking solution that has been "invented" by the other companies or institutions without their consent and participation. I personally feel very strongly that the SG16 cannot not "invent" a NEW interworking solution of its own that will NOT include the solutions proposed by others in the IETF. I hope that this will clarify the situation. Best regards, Radhika R. Roy
-----Original Message----- From: Roni Even [SMTP:Roni_e@ACCORD.CO.IL] Sent: Sunday, May 28, 2000 6:44 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: H.323 Annex O
Roy, The summary from Q14 states that SIP-H.323 interworking will be an appendix that will map messages for simple audio calls. and would defines preferred interworking mode. See the text bellow from TD-21b Roni Even
6.1.1 APC-1776 - Terms of Reference for H.323 - Internet Interworking [H.323-Internet Interworking Group] [joint with Q.12, Q.13] Q.15 discussed some SIP matters - SDP does not currently provide enough detail to describe H.263+ parameters.
Call signaling could be captured in an appendix to H.246. This appendix would first address simple audio interworking, covering topics such as mapping messages between H.323 and SIP. This is work that is currently in progress in the IETF (not an official work item at this time, but an unofficial task in the SIP working group). This appendix would define the "preferred interworking mode" of H.323; we'd expect the SIP experts to define the preferred interworking mode of SIP. We need to capture the essence of each of the functional entities. Contributions are requested.
There was agreement that a new annex to H.323 to address how H.323 could utilize a variety of internet services. Section 3 of APC-1776 is a good basis for this work.
-----Original Message----- From: Roy, Radhika R, ALARC [SMTP:rrroy@ATT.COM] Sent: Fri, May 26, 2000 9:30 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: H.323 Annex O
Mr. M. F. TOSCO Chairman ITU-T SG16 WP2
Dear Mr. TOSCO:
We are very much pleased to see that an H.323 Annex O (Internet Protocols and Technologies Complementary to H.323) has been opened in the joint meeting of Q.13/16 and Q.13/16 held in Osaka, Japan on May 15-19, 2000. It is expected that this annex will cover the following topics:
1. H.323-SIP Interworking 2. Inteworking between H.323 and other IETF Protocols (e.g., TRIP, etc.)
With respect to item 1 (H.323-SIP Interworking), it has been noted in the meeting report that the IETF is also working to develop an Informational RFC (a standard track RFC is also a possibility) for the SIP-H.323 interworking. The way this work in the IETF is progressing is as follows (I believe that the editor of H.323 Annex O is also fully aware of this work of the IETF):
1. SIP-H.323 Interworking Requirements RFC (Informational): by July-December, 2000 (tentative) 2. SIP-H.323 Interworking RFC (Informational): December 2000 - March 2001 (tentative)
The Internet-Drafts and documents that are being provided to develop the RFC are as follows:
1. Agrawal, Roy, and Palawat, "SIP-H.323 Interworking Requirements," draft-agrawal-roy-palawat-sip-h323-interworking-00.txt, IETF, June 2000. 2. Singh and Schulzrinne, "Interworking Between SIP/SDP and H.323", draft- singh-sip-h323-00.txt, IETF, January 2000. 3. C. Agbah, "SIP and H.323 Signaling Gateway."
It is expected that the SIP-H.323 Interworking RFC will be based primarily on the above documents along with suggestions made via emails and conference calls.
People could take many those contributions to the ITU-T SG16 for the SIP-H.323 Interworking in the last SG16 February'00 meeting. However, it was found that many companies and institutions that invented the interworking solution could not afford to provide the membership fees of the ITU-T, and some of them even could not afford to make a foreign trip for the standard meeting. But this has not been the case for the IETF where the email has been good enough to work for developing the standard.
Therefore, I am proposing the following to harmonize the work of these two organizations so that the complementary standards are created in the ITU-T SG16 and IETF:
1. Let the IETF produce the SIP-H.323 interworking RFC, while we, the ITU-T SG16, will develop the H.323-TRIP and/or other IETF protocols Interworking standard. 2. Should the IETF do not develop the standard track SIP-H.323 RFC, we, the ITU-T SG16, might consider how IETF's SIP-H.323 Interworking (Informational) RFC can be made a formal standard.
I hope this suggestion will be acceptable to all of us.
Best regards,
Radhika R. Roy AT&T Delegation Manager in the ITU-T SG16 (WP1, WP2, & WP3) 200 Laurel Avenue, Middletown, NJ 07748, USA +1 732 420 1580 Tel +1 732 368 1195 Fax rrroy@att.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Radhika,
The key is that the SG16 cannot use the interworking solution that has been "invented" by the other companies or institutions without their consent and participation. I personally feel very strongly that the SG16 cannot not "invent" a NEW interworking solution of its own that will NOT include the solutions proposed by others in the IETF.
I like this one... I've already built a SIP/H.323 interworking device-- a long time ago, before any group in any standards organization was formed to work on the issue. I would question whether such an IWF could even be called an "invention", as it is certainly "prior art". Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Hi, Roni:
The important thing is that an Informational RFC for the SIP-H.323 Interworking is under way (with a possibility to standard RFC) in the IETF and the contributions that invented the interworking solution are also
(in the IETF).
So, I am afraid that two non-compatible standards will emerge. We should NOT encourage non-compatible standards for the same thing.
There are also no mechanisms in the ITU-T SG16 to accept the contributions for the companies that can afford to communicate via emails only. I guess that the best way is to have the RFC from the IETF that will have all inputs from all companies that invented the interworking solution. The SG16 can then have the RFC for their use to make a formal standard (with more additions if needed).
It is well understood that the mapping between SDP and H.245 can not be done so easily and that is why an interworking standard is so urgent. If the informational RFC of the IETF does not cover the H.263+ parameters, the SG16 can then add those things. Or, any companies that like to address these parameters can also submit contributions as the IETF drafts (or send an email to the eGroup) proposing a solution.
The SIP-H.323 interworking work is well under way in the IETF based on well written contributions as I described in my email.
Why does the SG16 like to re-invent the wheel since this work is already progressing based on invented solutions submitted by the companies in the IETF?
If you think that any improvements need to be done in the solutions
in the contributions of the IETF (please see the references provided in my email), please submit the proposal in the IETF. We can then use the Informational RFC as an input for a formal standard in the SG16. In this way, we can get the best the both worlds having a "single common standard for SIP-H.323 Interworking".
The key is that the SG16 cannot use the interworking solution that has been "invented" by the other companies or institutions without their consent and participation. I personally feel very strongly that the SG16 cannot not "invent" a NEW interworking solution of its own that will NOT include the solutions proposed by others in the IETF.
I hope that this will clarify the situation.
Best regards,
Radhika R. Roy
-----Original Message----- From: Roni Even [SMTP:Roni_e@ACCORD.CO.IL] Sent: Sunday, May 28, 2000 6:44 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: H.323 Annex O
Roy, The summary from Q14 states that SIP-H.323 interworking will be an appendix that will map messages for simple audio calls. and would defines
interworking mode. See the text bellow from TD-21b Roni Even
6.1.1 APC-1776 - Terms of Reference for H.323 - Internet Interworking [H.323-Internet Interworking Group] [joint with Q.12, Q.13] Q.15 discussed some SIP matters - SDP does not currently provide enough detail to describe H.263+ parameters.
Call signaling could be captured in an appendix to H.246. This appendix would first address simple audio interworking, covering topics such as mapping messages between H.323 and SIP. This is work that is currently in progress in the IETF (not an official work item at this time, but an unofficial task in the SIP working group). This appendix would define
"preferred interworking mode" of H.323; we'd expect the SIP experts to define the preferred interworking mode of SIP. We need to capture the essence of each of the functional entities. Contributions are requested.
There was agreement that a new annex to H.323 to address how H.323 could utilize a variety of internet services. Section 3 of APC-1776 is a good basis for this work.
-----Original Message----- From: Roy, Radhika R, ALARC [SMTP:rrroy@ATT.COM] Sent: Fri, May 26, 2000 9:30 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: H.323 Annex O
Mr. M. F. TOSCO Chairman ITU-T SG16 WP2
Dear Mr. TOSCO:
We are very much pleased to see that an H.323 Annex O (Internet Protocols and Technologies Complementary to H.323) has been opened in the joint meeting of Q.13/16 and Q.13/16 held in Osaka, Japan on May 15-19,
is expected that this annex will cover the following topics:
1. H.323-SIP Interworking 2. Inteworking between H.323 and other IETF Protocols (e.g., TRIP, etc.)
With respect to item 1 (H.323-SIP Interworking), it has been noted in
meeting report that the IETF is also working to develop an Informational RFC (a standard track RFC is also a possibility) for the SIP-H.323 interworking. The way this work in the IETF is progressing is as follows (I believe
It the that
the editor of H.323 Annex O is also fully aware of this work of the IETF):
1. SIP-H.323 Interworking Requirements RFC (Informational): by July-December, 2000 (tentative) 2. SIP-H.323 Interworking RFC (Informational): December 2000 - March 2001 (tentative)
The Internet-Drafts and documents that are being provided to develop
RFC are as follows:
1. Agrawal, Roy, and Palawat, "SIP-H.323 Interworking Requirements," draft-agrawal-roy-palawat-sip-h323-interworking-00.txt, IETF, June
Roy, As I remmember, one of the reason for having the interworking as an appendix was due to the fact that there is no agreement between the two groups to keep the interworking and backward compatability in future releases of SIP or H.323. Thanks Roni ----- Original Message ----- From: "Roy, Radhika R, ALARC" <rrroy@ATT.COM> To: <ITU-SG16@MAILBAG.INTEL.COM> Sent: Tuesday, May 30, 2000 3:59 PM Subject: Re: H.323 Annex O there proposed preferred the 2000. the 2000.
2. Singh and Schulzrinne, "Interworking Between SIP/SDP and H.323", draft- singh-sip-h323-00.txt, IETF, January 2000. 3. C. Agbah, "SIP and H.323 Signaling Gateway."
It is expected that the SIP-H.323 Interworking RFC will be based primarily on the above documents along with suggestions made via emails and conference calls.
People could take many those contributions to the ITU-T SG16 for the SIP-H.323 Interworking in the last SG16 February'00 meeting. However, it was found that many companies and institutions that invented the interworking solution could not afford to provide the membership fees of the ITU-T, and some of them even could not afford to make a foreign trip for the standard meeting. But this has not been the case for the IETF where the email has been good enough to work for developing the standard.
Therefore, I am proposing the following to harmonize the work of these two organizations so that the complementary standards are created in the ITU-T SG16 and IETF:
1. Let the IETF produce the SIP-H.323 interworking RFC, while we, the ITU-T SG16, will develop the H.323-TRIP and/or other IETF protocols Interworking standard. 2. Should the IETF do not develop the standard track SIP-H.323 RFC, we, the ITU-T SG16, might consider how IETF's SIP-H.323 Interworking (Informational) RFC can be made a formal standard.
I hope this suggestion will be acceptable to all of us.
Best regards,
Radhika R. Roy AT&T Delegation Manager in the ITU-T SG16 (WP1, WP2, & WP3) 200 Laurel Avenue, Middletown, NJ 07748, USA +1 732 420 1580 Tel +1 732 368 1195 Fax rrroy@att.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (3)
-
Paul E. Jones -
Roni Even -
Roy, Radhika R, ALARC