Please see my response sent to Paul.
No one has ruled out that there cannot be another BOF where the consensus for the standardtrack RFC can be sought once the Informational RFC for the SIP-H.323 Interworking is finalized (Please see SIP WG Co-Chair's and my email sent after the SIP-H.323 Interworking BOF in the SIP mailing list. Why did you not contradict those emails then?).
Chip Sharp further made it clear in his email the problems of using the IETF drafts if the authors cannot participate in the ITU meetings no matter whether there is IPR or not.
-----Original Message----- From: Tom-PT Taylor [SMTP:taylor@NORTELNETWORKS.COM] Sent: Tuesday, May 30, 2000 9:29 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: H.323 Annex O
Radhika, you make some dubious comments here. As you know, I laid out a management procedure for coordination between the two groups in the February meeting. SG 16 has not chosen to adopt it yet, but may do so in the future. In the meantime, I must remark that there was a really strong consensus in the IETF that they would not do standards-track work on interworking. You are being overly optimistic when you suggest otherwise.
The other thing is that you should read the boilerplate on Internet Drafts. With rare exception, they are made freely available, in contradiction to what you suggest in the final paragraph of this note. If AT&T or another company proves to have IPR in a solution standardized by the ITU-T, they are free to enforce their patent on their chosen terms if another company chooses to practice it, but that has nothing to do with the standardization process.
-----Original Message-----From: Roy, Radhika R, ALARC [SMTP:rrroy@ATT.COM] Sent: Tuesday, May 30, 2000 9:59 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: H.323 Annex O
Hi, Roni: The important thing is that an Informational RFC for the SIP-H.323Interworking 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. Weshould NOT encourage non-compatible standards for the same thing.
There are also no mechanisms in the ITU-T SG16 to accept thecontributions 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 notbe 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 basedon well written contributions as I described in my email.
Why does the SG16 like to re-invent the wheel since this work isalready progressing based on invented solutions submitted by the companies in the IETF?
If you think that any improvements need to be done in the solutionsproposed 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 thathas 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,
It
is expected that this annex will cover the following topics:
H.323-SIP InterworkingInteworking 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):
SIP-H.323 Interworking Requirements RFC (Informational): byJuly-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:
Agrawal, Roy, and Palawat, "SIP-H.323 InterworkingRequirements,"
draft-agrawal-roy-palawat-sip-h323-interworking-00.txt, IETF, June
Singh and Schulzrinne, "Interworking Between SIP/SDP andH.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:
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.comFor help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.comFor 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