June 2000 - sg16-avd - lists.packetizer.com

Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Paul Long 03 Jun '00

03 Jun '00

Pete, Table 13/H.225.0v3 shows that the User-to-User IE is mandatory. What IEs do you believe are not mandatory? H.323 states that the fastStart and h245Control components cannot both be present in the Setup message (do I need to quote it again?). A Setup User-to-User IE containing either or neither component is valid; one containing both is clearly invalid. Why do you think otherwise? H.323, by way of Q.931, requires that the called EP respond with ReleaseComplete with cause 100. There is no other appropriate cause. The feature that should be deprecated is the inclusion of both fastStart and h245Control in Setup. I was under the impression that either through IGv3 or H.323v4 this had already made it into the standard. If its not too late, we should simply remove this feature from any proposed text; if it is too late, we should deprecate it because it causes insurmountable backward compatibility problems. Paul -----Original Message----- From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] Sent: Wednesday, May 31, 2000 4:31 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 Paul, I don't really believe that the release cause you cite is valid. The IEs are not mandatory, and (taken by themselves) they don't have invalid content. I don't believe it is the intent of this cause code to signal the sort of thing that we are talking about here either. Are there any other causes and clauses that you think might be more appropriate? Also, when you say "the feature" should be deprecated, what are you referring to as "the feature"? I'm not quite clear. Pete. ============================================= Pete Cordell pete(a)tech-know-ware.com ============================================= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 4

Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Francois Audet 02 Jun '00

02 Jun '00

This has been discussed at lenght many times. Q.931 is in direct conflict with H.225.0 on many points, including mundate tasks like clearing a call. DISCONNECT and RELEASE messages for example are mandatory in Q.931 and forbitten in H.225.0. That is a trivial example. The bottom line, is that there is some sort of common understanding that Q.931-like procedures are used, with a lot of implied exceptions and divergences. The "call control" procedures are not formally described in H.225.0. There was even a suggestion to add them to a further version of H.323. Be my guess... > -----Original Message----- > From: Dave Walker [mailto:drwalker@SS8NETWORKS.COM] > Sent: Thursday, June 01, 2000 11:49 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > I'm not sure this is correct. H.323 section 7.3.1 mandates the use of > Q.931 Annex D procedures. In turn, that Annex uses Q.931 clause 5. > So *that* is what applies in the absence of any overriding provisions > in H.323. So I think that Q.931/5.8.6.2 *should* apply. > > But to re-iterate what Paul asked earlier, if we had a description of > the problem that this was intended to solve, perhaps a less > contentious > solution could be found. > > Regards, > > Dave Walker > SS8 Networks > Ottawa, Canada > > > > Francois Audet wrote: > > > > Except that the section that Paul quotes is in Q.931 and > NOT in H.225.0. > > It has nothing to do with H.225.0. In fact, it talks about a message > > that is not even supported in H.225.0 (i.e., RELEASE). > > > > To reiterate: H.323v2 does not describe how an endpoint > receiving both > > elements shall behave themselves. It just says that the > sender shall not > > include both since it would cancel fast start. This > particular case (wich > > apparently is not supported by any implementation) would > result (if you > > follow the logic of H.323v2) in ignoring fast start and > proceeding with > > H.245 tunnelling. That is NOT a backward compatibility > problem, and it > > does't break anything. > > > > Rejecting the call with cause value 100 is definitively NOT > what H.323v2 says. > > > > > In Q.931, the user-user IE is typically optional, so the > clause that > > > Paul Long's been quoting wouldn't apply. However, since > H.323 makes > > > the UUIE mandatory, it *does* apply in the case under discussion. > > > I think that the statement contained in TD-26, that it preserves > > > backwards compatibility, is completely wrong. The > correct statement > > > should have been that it doesn't break implementations > known to the > > > authors. I agree with Paul that we should try to develop a better > > > solution. > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

2 1

Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Francois Audet 01 Jun '00

01 Jun '00

Except that the section that Paul quotes is in Q.931 and NOT in H.225.0. It has nothing to do with H.225.0. In fact, it talks about a message that is not even supported in H.225.0 (i.e., RELEASE). To reiterate: H.323v2 does not describe how an endpoint receiving both elements shall behave themselves. It just says that the sender shall not include both since it would cancel fast start. This particular case (wich apparently is not supported by any implementation) would result (if you follow the logic of H.323v2) in ignoring fast start and proceeding with H.245 tunnelling. That is NOT a backward compatibility problem, and it does't break anything. Rejecting the call with cause value 100 is definitively NOT what H.323v2 says. > In Q.931, the user-user IE is typically optional, so the clause that > Paul Long's been quoting wouldn't apply. However, since H.323 makes > the UUIE mandatory, it *does* apply in the case under discussion. > I think that the statement contained in TD-26, that it preserves > backwards compatibility, is completely wrong. The correct statement > should have been that it doesn't break implementations known to the > authors. I agree with Paul that we should try to develop a better > solution. > >

2 1

Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Francois Audet 01 Jun '00

01 Jun '00

If they reject the call with cause 100, then it is their implementation that is broken. > -----Original Message----- > From: Paul Long [mailto:Plong@SMITHMICRO.COM] > Sent: Thursday, June 01, 2000 8:04 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > Francois, > > We should not be taking a poll as to whether something would > break existing > implementations. What about vendors that we don't ask, that > don't respond, > or are out of the loop for some reason? A standard is a > contract of sorts. > Breaking contracts is a bad thing in part because future > contracts cannot be > depended on. > > Paul Long > Smith Micro Software, Inc. > > -----Original Message----- > From: Francois Audet [mailto:audet@NORTELNETWORKS.COM] > Sent: Thursday, June 01, 2000 7:34 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > I fully agree with Orit. > > So far, I haven't heard of anybody that actually implemented clearing > the call > if both fastStart and h245Control are present in SETUP. I would argue, > it would > be a very bad implementation, regardless of what they interpreted the > spec > saying. > > This being said, it seems that it will not create any interoperability > problems. > The *worst* case scenario (here again, I haven't heard of anybody that > actually implemented it that way) is that the call would > proceed as fast > > tunnelling (as per the spec) and ignore the fast start. > > The benefits of doing the fastStart and the fast tunnelling > at the same > time > far outweight the theoretical backward compatibility problems. > > If anybody wants to revoke the Osaka agreement, contributions in > Portland are > welcomed. ;^) > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

2 1

Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Francois Audet 01 Jun '00

01 Jun '00

> Francois, > > The UUIE _is_ a Q.931 IE, 5.8.6.2/Q.931 does not exclude this IE, and > neither H.225.0 or H.323 address the issue of how to handle a > UUIE--or any > other IE, for that matter--with invalid content, therefore > the behavior > defined in Q.931 is normative for H.323. An "invalid coding" for an information element does NOT include the content of a User-User information element. By definition, a Q.931 User-user IE can include whatever you feel like. A proper implementation will not reject a call because of the content of the User-user IE. > _All_ of Q.931 is an "ISDN thing," so what's your point? > > Finally, there is much in Q.931 that H.323 does not > reference, but that does > not invalidate the parts of Q.931 that H.323 references. H.323 does not use Q.931. H.225.0 recycled some of the messages (but not all of them). More importantly, it doesn't explicitly use the PROCEDURES of Q.931. There are some stringent timer requirements for example in Q.931 that not used use by H.323. The DISCONNECT and RELEASE messages are not even used. We are not even setting up a bearer channel in H.323 when doing a call setup. In summary, H.225.0 is NOT Q.931.

2 1

Re: H.323 Annex O
by Roy, Radhika R, ALARC 01 Jun '00

01 Jun '00

Hi, Christian: I am glad that you have described what exactly I wanted to say. I completely agree with you. All emails were sent to get the point across that you have just described. Hope that every member will also agree with your clarification. Best regards, Radhika R. Roy > -----Original Message----- > From: Christian Groves [SMTP:Christian.Groves@ERICSSON.COM] > Sent: Wednesday, May 31, 2000 8:21 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Annex O > > 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@LUCENT.COM] > > > Sent: Wednesday, May 31, 2000 12:34 PM > > > To: ITU-SG16(a)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(a)mailbag.intel.com > > > > > > -- > > > Glen Freundlich ggf(a)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(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Francois Audet 01 Jun '00

01 Jun '00

> 5.8.6.2/Q.931: When a SETUP or RELEASE message is received > which has one or > more mandatory information elements with invalid content, a > RELEASE COMPLETE > message with cause No. 100, “invalid information element > contents” shall be > returned." My understanding of this statement is that it is meant to cover Q.931 elemements themselves, NOT UUIE content. As far as Q.931 is concerned, the User-user information element can be coded in whatever way we want. It is an ISDN thing that was carried over in H.225.0. So, my take is that this section is completely irrelevant to the H.245 tunnelling (or in fact H.245 in general). Also, it talks about a message (RELEASE) that is not even supported in H.225.0.

3 2

Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Francois Audet 01 Jun '00

01 Jun '00

Yep. You are correct. > -----Original Message----- > From: Paul Long [mailto:Plong@SMITHMICRO.COM] > Sent: Tuesday, May 30, 2000 8:01 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > (Whoops, I misunderstood. You were talking about actually > tunneling an H.245 > message in Setup. I was thinking you were just indicating > tunneling, which > is of course okay.) > > -----Original Message----- > From: Paul Long [mailto:plong@smithmicro.com] > Sent: Tuesday, May 30, 2000 9:56 AM > To: 'Mailing list for parties associated with ITU-T Study Group 16' > Subject: RE: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > Francois, > > Tunneling and Fast Connect are orthogonal to each other. I > can't find where > v2 or v3 says that they cannot be done in parallel. As a > matter of fact, > this is how we implemented it. We are now very aggressive > with call setup. > What specific problems are there with doing them at the same time? We > haven't found any. > > Paul > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

1 0

Re: H.323 Annex O
by Roy, Radhika R, ALARC 01 Jun '00

01 Jun '00

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@LUCENT.COM] > Sent: Wednesday, May 31, 2000 12:34 PM > To: ITU-SG16(a)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(a)mailbag.intel.com > > -- > Glen Freundlich ggf(a)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(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1