H.323 Annex O

Wed May 31 20:20:43 EDT 2000

Hello Roy,

I abit confused at all these emails flying around about the H.246
SIP-H.323 Appendix. There are alot of could's and would's in the Sg16
meeting report and I believe the underlying sentiment was that we would
let the IETF continue with their work and monitor it. At a later stage
we could reference this work in an informational Appendix.

I agree on your desire to have one document describing the Interworking.
I hope that interested parties contribute to the work done in the IETF
rather than starting competing work in SG16 at this stage.

Regards, Christian

"Roy, Radhika R, ALARC" wrote:
>
> Hi, Glen:
>
> It is nice to know that an H.246 SIP-H.323 Interworking APPENDIX will be
> created.
>
> Per earlier emails, it appears that this APPENDIX will be informational one.
>
> With respect to presenting the contributions, I tried to bring contributions
> including authors of the Internet Drafts for the SIP-H.323 Interworking in
> the last SG16 meeting held in Geneva on February 2000. However, the US Dept
> of State did not accept the contributions of the organizations (e.g.,
> Universities) and companies who were not the members of the ITU-T SG16
> (either independently or jointly with other companies who are the members of
> the ITU-T).
>
> However, in IETF, it has not been the case. That is why, the authors of
> those internet drafts are working to create an Informational RFC.
>
> Now it appears that the SG16 will also be creating an informational
> APPENDIX.
>
> It appears that the IETF's Informational RFC will be produced first.
>
> Let us keep our eyes open how we can create a unified informational standard
> cooperating in both standard organizations. Some suggestions have been made
> in the earlier emails.
>
> Our objectives should be to create one single standard for the same thing.
>
> Best regards,
> Radhika R. Roy
>
> > -----Original Message-----
> > From: Glen Freundlich [SMTP:ggf at LUCENT.COM]
> > Sent: Wednesday, May 31, 2000 12:34 PM
> > To:   ITU-SG16 at MAILBAG.INTEL.COM
> > Subject:      Re: H.323 Annex O
> >
> > While it is true that work is progressed through written contributions to
> > study
> > group and rapporteurs' meetings, those written contributions can be
> > created
> > jointly via email, conference calls, over a plate of bull fries at Bruce's
> > Bar,
> > etc. Note that joint creation of a contribution does not guarantee its
> > approval
> > (although probability of approval certainly increases when a larger group
> > of
> > people are involved in the creation of a proposal).
> >
> > In the case of a jointly created contribution, it seems reasonable that
> > someone
> > from that group would be able to present the contribution at a meeting. If
> > someone has a contribution they would like to present at a meeting, but is
> > unable
> > to attend, it's certainly possible to ask someone who plans to attend the
> > meeting
> > to present the material.
> >
> > As for the SIP-H.323 interworking annex, check the meeting report:
> >
> > "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."
> >
> > SIP-H.323 interworking would be described in an appendix to H.246 (not
> > H.323
> > Annex O). This would describe the "preferred interworking mode", which
> > would
> > specify, for example, the use of H.323 fast start. It might describe the
> > relationship between the functional entities (e.g., is the SIP-H.323
> > interworking
> > function in a gateway or gatekeeper for the H.323 side, and in a SIP proxy
> > for
> > the SIP side?). It would describe message mapping (e.g., the H.323 Setup
> > message
> > maps to a SIP Invite message, and the called party number IE is mapped to
> > the To
> > header).
> >
> > Glen
> >
> >
> > Chip Sharp wrote:
> >
> > > At 09:59 AM 5/30/00 -0400, Roy, Radhika R, ALARC wrote:
> > > ...snip...
> > > >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 true that SG16 still operates mainly on the basis of written
> > > contributions to meetings and not on mail lists like IETF WG.  It is
> > also
> > > true that non-ITU members have a hard time participating in ITU SG
> > > work.  Even if a company is an ITU member, attending all the meetings
> > > around the world is a travel burden on small companies (even big
> > > companies). However, an IETF WG can submit a written contribution to
> > SG16
> > > via existing mechanisms. Usually, this is initiated via consensus of the
> > WG
> > > and/or by WG chair via the ISOC VP - Standards.  Of course, it requires
> > > someone to represent that contribution at the SG16 meetings.  The SG16
> > > Rapporteurs have been very open in the past to inviting non-ITU member
> > > experts to Rapporteur Meetings to further the work.  The SG16 mail list
> > has
> > > been one of the more active SG mail lists in actually discussing
> > technical
> > > issues.  And SG16's working documents are available for review as well
> > (at
> > > least from Rapporteur's Meetings).  It will be nice if ITU could codify
> > > some of these examples at WTSA.
> > >
> > > I understand the desire to do the work in one place.  It is also true
> > that
> > > SG16 can reference an IETF RFC in its recommendations.  However, if it
> > is
> > > an informational RFC, it can't be a normative reference in ITU.
> > > ...snip...
> > > >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".
> > >
> > > Remember an ITU Recommendation cannot make a normative reference to an
> > > Informational RFC.
> > > If there is no new protocol work being done, the H.323-SIP interworking
> > > could conceivably become a BCP (Best Current Practice) some day.
> > >
> > > >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.
> > >
> > > The ITU can incorporate by (normative or non-normative) reference to any
> > > RFC.  The IETF has an IPR policy that isn't too different from ITU (I
> > don't
> > > think).  Current A.5 procedures require that IETF provide a written
> > > agreement to allow normative references to an RFC (I don't remember ever
> > > seeing one of these, but there may be a blanket agreement).  There are
> > > proposals to drop this requirement in the next version of A.5.
> > >
> > > Any IPR contained in IETF RFCs are covered by IETF IPR policy.  It is
> > true
> > > that a company that has declared IPR in an IETF RFC may not know it is
> > > being referenced in ITU and therefore may not submit an IPR statement to
> > > ITU.  Therefore the IPR would only be covered by the IETF IPR statement
> > > (this brings up interesting legal questions, but I'll leave that up to
> > the
> > > lawyers.).  This should only be a real problem if the invention were
> > > included in the ITU Recommendation by some means other than reference.
> > >
> > > So the bottom line is that there are mechanisms to share work in ITU and
> > > IETF even without all the formal mechanisms worked out between Megaco
> > and
> > > Q.14.  However, if the work is going to be cooperative, such an
> > agreement
> > > is probably desirable.
> > >
> > > Good Luck!
> > > Chip
> > >
> > > -------------------------------------------------------------------
> > > Chip Sharp                 CTO Consulting Engineering
> > > Cisco Systems
> > > Reality - Love it or Leave it.
> > > http://www.netaid.org
> > > -------------------------------------------------------------------
> > >
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > For help on this mail list, send "HELP ITU-SG16" in a message to
> > > listserv at mailbag.intel.com
> >
> > --
> > Glen Freundlich                       ggf at lucent.com
> > Lucent Technologies                   office: +1 303 538 2899
> > 11900 N. Pecos                        fax: +1 303 538 3907
> > Westminster, Colorado 80234  USA
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv at mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com