- sg16-avd - lists.packetizer.com

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 31 May '00

31 May '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

R:H.248 change document
by Tosco Federico 31 May '00

31 May '00

Good! Federico > ---------- > Da: Glen Freundlich[SMTP:ggf@LUCENT.COM] > Risposta a: Mailing list for parties associated with ITU-T Study Group > 16 > Inviato: mercoledì 31 maggio 2000 19.29 > A: ITU-SG16(a)MAILBAG.INTEL.COM > Oggetto: H.248 change document > > Greetings, > > I have placed 3 files in the Incoming directory of the pictel ftp site: > > H248-for-decision-changes-wsynt.zip - The change document showing the > specific modifications to the determined H.248 as finalized at the Osaka > meeting. > > H248-for-decision-wcm.zip - The entire H.248 document with changes to > the determined document highlighted. > > H248-for-decision-wcm.zip - H.248 with all changes accepted (the clean > document). > > Regards, > Glen > > > -- > 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

1 0

Re: H.323 Annex O
by Tom-PT Taylor 31 May '00

31 May '00

Gee, I'm usually the lawyer. I stand corrected on this point. > -----Original Message----- > From: Scott Bradner [SMTP:sob@HARVARD.EDU] > Sent: Wednesday, May 31, 2000 10:56 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Annex O > > > 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. > > lets be careful here - > > current Copyright law says there is always Copyright IPR in any document > even > if the document has no copyright statement on it. > > the IETF requires that authors of IETF documents give the IETF (actually > ISOC > for legal reasons) the right to publish the douments, allow others to > publish the documents as-is, and, in most cases, the right to make > derivative > works within the IETF standards process - the author retains all other > rights > > the IETF can not grant the right for any other organization to make > derivative rigts because we do not get that right from the authors > > but the authors can give their own OK if they want > > that said, I do not think its a real good idea to have two > organizations working off the same base documents to come up > with different results - it just confuses the community - so > I would rather that one organization take the token to lead but > that people from both organizations work together if possible > > Scott > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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 Chip Sharp 31 May '00

31 May '00

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

2 1

Re: H.323-SIP Appendix of H.246 (Previously Annex O)
by Roy, Radhika R, ALARC 31 May '00

31 May '00

Hi, Orit and All: It is a very good proposal that H.246 SIP-H.323 Interworking APPENDIX will be an informational. In this case, I guess that we can also refer any IETF's Informational RFCs (including SIP-H.323 Interworking), if needed, in this APPENDIX because it does not need to have the "normative" references. Best regards, Radhika R. Roy > -----Original Message----- > From: Orit Levin [SMTP:orit@radvision.com] > Sent: Wednesday, May 31, 2000 10:29 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.323-SIP Appendix of H.246 (Previously Annex O) > > Good morning! A small clarification. > SG16 proposed to organized H.323-SIP work as an APPENDIX (i.e. > "informative"document) of H.246. H.246 is an umbrella for many signaling > gateways (such as H.320, ISUP, Mobile Networks, etc.). This Appendix will > happen only if contributions on H.323-SIP will be brought to SG16. It was > also noticed, that it is preferable to have architectural proposals, > defining preferred mode of operation, capabilities, versions, etc., rather > then containing detailed messages flows. Just a reminder, in ITU > everything is driven by contributions only. > > 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 <http://www.radvision.com> > orit(a)radvision.com <mailto:orit@radvision.com> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 Scott Bradner 31 May '00

31 May '00

> 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. lets be careful here - current Copyright law says there is always Copyright IPR in any document even if the document has no copyright statement on it. the IETF requires that authors of IETF documents give the IETF (actually ISOC for legal reasons) the right to publish the douments, allow others to publish the documents as-is, and, in most cases, the right to make derivative works within the IETF standards process - the author retains all other rights the IETF can not grant the right for any other organization to make derivative rigts because we do not get that right from the authors but the authors can give their own OK if they want that said, I do not think its a real good idea to have two organizations working off the same base documents to come up with different results - it just confuses the community - so I would rather that one organization take the token to lead but that people from both organizations work together if possible Scott ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.323-SIP Appendix of H.246 (Previously Annex O)
by Orit Levin 31 May '00

31 May '00

Good morning! A small clarification. SG16 proposed to organized H.323-SIP work as an APPENDIX (i.e. "informative"document) of H.246. H.246 is an umbrella for many signaling gateways (such as H.320, ISUP, Mobile Networks, etc.). This Appendix will happen only if contributions on H.323-SIP will be brought to SG16. It was also noticed, that it is preferable to have architectural proposals, defining preferred mode of operation, capabilities, versions, etc., rather then containing detailed messages flows. Just a reminder, in ITU everything is driven by contributions only. 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(a)radvision.com

1 0

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

31 May '00

Yes, a few comments: 1 It seems that all current implementations that we could think of would simply ignore the tunnelling information if the fastStart element is present. This means, that there would be no interoperability problems. Fast start would be sucessfull, but not tunnelling, which would mean that tunnelling would have to happen after the SETUP message, as per H.323v2 and v3. 2 There is a small possibility that an implementation would acutally give priority to the tunnelling information instead of the fastStart element (v2 and v3 don't say what would happen if they are present, they just say not to do it). In that particular case, the fastStart would fail but the tunnelling would be successful. So the worst case scenario is that fastStart fails, but "fast tunnelling" is successful. This doesn't seem to me to be a real interoperability problem. In any case, it seems that case 1 is much more likely. > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Monday, May 29, 2000 7:46 PM > To: Mailing list for parties associated with ITU-T Study > Group 16; pete > Cc: Audet, Francois [SC9:4K02:EXCH]; Alexander (Sasha) Ruditsky; Dale > Skran > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > Pete, Sasha, Francois, Dale, et al, > > I have concerns about this document that differ from Pete's. > However, since > discussion on this document has started, I thought I might as > well express > my concerns now while the material is fresh on people's minds. > > The issue has to do with the very first sentence of the > proposal, which says > to strike "shall not" and replace it with "may". So, V2 > devices shall not > send a fastStart element and an H.245 message in SETUP, but > V4 may. This > seems to be a serious backward compatibility issue. If a V2 > device were to > receive a SETUP containing fastStart and an encapsulated > H.245 message, what > would it do? I believe the behavior is not defined. > > Would somebody like to comment? > > Paul > > ----- Original Message ----- > From: "Pete Cordell" <pete(a)TECH-KNOW-WARE.COM> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Saturday, May 20, 2000 1:57 PM > Subject: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > > I note that TD-26 has been accepted to show how TCS can be > conveyed in > > parallel with fast start. > > > > However, the example shows the use of call proceeding for > receiving TCS > back > > from the remote endpoint. This is not typically an > end-to-end message, > and > > therefore how the procedure works with the gatekeeper > routed model needs > to > > be addressed. > > > > Possible solutions are: > > > > 1. Refer to the new text that says it is the responsibility of the > > gatekeeper to forward any tunnelled message for which none > is available > > using FACILITY. (There might be some objection from some to using a > > facility message this early in the call setup process though.) > > > > 2. Restrict the tunnelling (and probably the fast start > info) to Alerting, > > Connect and Facility, which generally are end-to-end. I > believe this is > > compatible with the latest procedures for deciding when > fast start has > been > > ignored. > > > > Which ever option is chosen, it would also be nice to have > a picture for > it > > also! > > > > 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 > > > >

4 5

Re: H.323 Annex O
by Roy, Radhika R, ALARC 31 May '00

31 May '00

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(a)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(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Annex O > > 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(a)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(a)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(a)att.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 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 31 May '00

31 May '00

Hi, Paul and All: May be many people did the similar or the same thing. Who knows what we can call it - "invention" or "prior art." The bottom line is that we have contributions in the IETF in the public domain for the SIP-H.323 Interworking, and these contributions are theirs. We cannot use their proposed solutions unless they permit. However, if there are people who claim that they did it before those contributions, they need to speak out now bringing their contributions. Unless they do, we have no way of knowing this. We have also seen Chip Sharp's and Scott Bradner's email. Their emails further clarify the process of the both organizations: IETF and ITU. This is one of the problems that we need to sort out. One way of doing is that we can create an Informational RFC as all authors of those contributions have agreed to do so. We can then see whether this Informational RFC can be made a standard one as stated below: 1. To see whether this can be made a standard track RFC in the IETF or 2. To use the Informational/Standardtrack RFC to the SG16 to make a formal standard in the SG16 (if the normative reference cannot be used for the Informational RFC, we have to find out some other ways how we can do this [e.g., SIP WG Chair can request that individuals be appointed formal ISOC/IETF representatives to the ITU-T]) To meet the backward compatibility (e.g., Roni mentioned it) and other concerns, we can work out this as well (both in the Informational/Standardtrack RFC/IETF and SG16). Considering all OPTIONs, the above two steps seem to be the most reasonable way to proceed. Best regards, Radhika R. Roy > -----Original Message----- > From: Paul E. Jones [SMTP:paulej@PACKETIZER.COM] > Sent: Wednesday, May 31, 2000 1:35 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Annex O > > 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(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: H.323 Annex O
by Roy, Radhika R, ALARC 31 May '00

31 May '00

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(a)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(a)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(a)att.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

3 2

Re: H.323 Annex O
by Scott Bradner 31 May '00

31 May '00

some notes on Chip's message at ">>" Scott (ISOC VP-Standards) ------------ 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. >> in addition working group chairs can request that individuals be >> appopinted formal ISOC (IETF) representives to ITU-T meetings >> by the ISOC VP-standards working with the IAB (teh ISOC is an ITU-T >> member) 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. >> nor should it be since an RFC with informational status carries no >> implication of IETF review, support or approval ...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. >> the ISOC gave a blanket approval years ago 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. >> specifically - the process worked out for megaco is described in A.5 >> but it is listes as the least desirable way to work together - it is >> far cleaner for one organization to take respoinsibility for publishing >> the document (with input from the other) and the other organization >> create a simple document that points to the offical document ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 Tom-PT Taylor 30 May '00

30 May '00

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(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Annex O > > 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(a)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(a)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(a)att.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: H.323 Annex O
by Roy, Radhika R, ALARC 30 May '00

30 May '00

Hi, Everyone: I fully agree with Ms. Levin's proposal. Her proposal provides the opportunity to resolve all issues that I have been talking about. I personally appreciate the foresightedness of Ms. Levin. Best regards, Radhika R. Roy > -----Original Message----- > From: Orit Levin [SMTP:orit@radvision.com] > Sent: Tuesday, May 30, 2000 10:57 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Annex O > > Hello all! > As the editor of H.323 Annex O, I would like to expand Roni's precise > recap > and add a few words about the objectives of Annex O. (BTW, the full > version > appears in APC-1776 and TD-40a from Osaka meeting) > H.323 specification defines means for building multimedia communication > services over any Packet Based Network, among them Internet. However, in > order to deploy efficient and globally interoperable Internet based H.323 > systems, definitions for using Internet protocols and technologies > (complementary to H.323) in context of H.323 Specification should be > defined. > This work will be organized in Annex O named "Internet protocols and > Technologies (complementary to H.323) in context of H.323 Specification". > The first material towards Annex O addresses the use of DNS technology in > context of H.323 and includes (1) definition of H323-URL scheme and (2) > use > cases of H323-URL and other URL schemes in H.323 messages and H.323 > systems. > I hope and believe, that H.246 new Appendix (H.323-SIP Interworking) and > corresponding attempts in IETF (listed by Mr. Roy) will define their > solution(s) in accordance with the procedures of Annex O. > 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(a)radvision.com > -----Original Message----- > From: Roni Even <Roni_e(a)ACCORD.CO.IL> > To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> > Date: Sunday, May 28, 2000 5:50 AM > 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(a)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(a)att.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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 Paul Long 30 May '00

30 May '00

(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 Orit Levin 30 May '00

30 May '00

Hello all! As the editor of H.323 Annex O, I would like to expand Roni's precise recap and add a few words about the objectives of Annex O. (BTW, the full version appears in APC-1776 and TD-40a from Osaka meeting) H.323 specification defines means for building multimedia communication services over any Packet Based Network, among them Internet. However, in order to deploy efficient and globally interoperable Internet based H.323 systems, definitions for using Internet protocols and technologies (complementary to H.323) in context of H.323 Specification should be defined. This work will be organized in Annex O named Internet protocols and Technologies (complementary to H.323) in context of H.323 Specification. The first material towards Annex O addresses the use of DNS technology in context of H.323 and includes (1) definition of H323-URL scheme and (2) use cases of H323-URL and other URL schemes in H.323 messages and H.323 systems. I hope and believe, that H.246 new Appendix (H.323-SIP Interworking) and corresponding attempts in IETF (listed by Mr. Roy) will define their solution(s) in accordance with the procedures of Annex O. 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(a)radvision.com -----Original Message----- From: Roni Even <Roni_e(a)ACCORD.CO.IL> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: Sunday, May 28, 2000 5:50 AM 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(a)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(a)att.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

On TD26 - Fast TCS and M/S negotiation in H.323v4
by Pete Cordell 30 May '00

30 May '00

I note that TD-26 has been accepted to show how TCS can be conveyed in parallel with fast start. However, the example shows the use of call proceeding for receiving TCS back from the remote endpoint. This is not typically an end-to-end message, and therefore how the procedure works with the gatekeeper routed model needs to be addressed. Possible solutions are: 1. Refer to the new text that says it is the responsibility of the gatekeeper to forward any tunnelled message for which none is available using FACILITY. (There might be some objection from some to using a facility message this early in the call setup process though.) 2. Restrict the tunnelling (and probably the fast start info) to Alerting, Connect and Facility, which generally are end-to-end. I believe this is compatible with the latest procedures for deciding when fast start has been ignored. Which ever option is chosen, it would also be nice to have a picture for it also! 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

FW: MEGACO errata
by Tom-PT Taylor 28 May '00

28 May '00

I'm forwarding this to the SG 16 list copy the Megaco list because I think the MTP address was firmed up at Red Bank. Can anyone account for the failure to accommodate longer MTP addresses? Was it simply because the intention was to use Annex I transport within an ITU environment only? > -----Original Message----- > From: dacollins(a)notes.primeco.com [SMTP:dacollins@notes.primeco.com] > Sent: Friday, May 26, 2000 1:03 PM > To: Taylor, Tom-PT [NORSE:B901:EXCH] > Subject: MEGACO errata > > > > Hi Tom, > Having had a look at the latest version of the MEGACO spec, I noticed > something > odd. The mId may be an MTP address. However, the MTP address is defined in > both > the ABNF and ASN.1 specifications as being 2 octets in length. The ASN.1 > description provides a comment that the point code (PC) is 14 bits and the > network indicator (NI) is two bits. > This is only correct for the ITU version of SS7. > In several countries, different versions of SS7 are used and different > addressing schemes are used. In many countries, including the US, Canada > and > China, the PC is 24 bits long, with the NI still at two bits, for a total > of 26 > bits. Therefore, to use an MTP address for the mId in those countries, the > definition of the mId needs to change. > > I hope this helps in finalizing the spec. > > Daniel Collins > >

2 1

Re: H.323 Annex O
by Roni Even 28 May '00

28 May '00

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(a)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(a)att.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: FW: MEGACO errata
by Chip Sharp 26 May '00

26 May '00

I looked back through my files. It was set to 5 octets in TD33 that was submitted to SG16 in Geneva. I've got a marked up version of TD-33a created 5 pm on 2/13 that still has 5 octets in it. TD-102 that was produced on 2/15/00 had it changed to 2 octets. I could not find any contributions, delayed contributions or TDs that suggested changing this value, so I can only assume it was added during the discussions between 2/13 (Sun) and 2/15 (Tues). At 03:08 PM 5/26/00 -0500, Tom-PT Taylor wrote: >I'm forwarding this to the SG 16 list copy the Megaco list because I think >the MTP address was firmed up at Red Bank. Can anyone account for the >failure to accommodate longer MTP addresses? Was it simply because the >intention was to use Annex I transport within an ITU environment only? >-----Original Message----- From: dacollins(a)notes.primeco.com >[SMTP:dacollins@notes.primeco.com] Sent: Friday, May 26, 2000 1:03 >PM To: Taylor, Tom-PT [NORSE:B901:EXCH] Subject: MEGACO errata > > > >Hi Tom, Having had a look at the latest version of the MEGACO spec, I >noticed something odd. The mId may be an MTP address. However, the MTP >address is defined in both the ABNF and ASN.1 specifications as being 2 >octets in length. The ASN.1 description provides a comment that the point >code (PC) is 14 bits and the network indicator (NI) is two bits. This is >only correct for the ITU version of SS7. In several countries, different >versions of SS7 are used and different addressing schemes are used. In >many countries, including the US, Canada and China, the PC is 24 bits >long, with the NI still at two bits, for a total of 26 bits. Therefore, >to use an MTP address for the mId in those countries, the definition of >the mId needs to change. > >I hope this helps in finalizing the spec. > >Daniel Collins ------------------------------------------------------------------- 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

1 0

Re: FW: MEGACO errata
by Chip Sharp 26 May '00

26 May '00

In your email "Changes made in Geneva" is the following cryptic statement: ...snip... >Annex A.2 > -- comment sets initial version to 1 > -- mtpAddress size corrected ...snip... I don't remember what this meant and I don't remember much of Geneva, but I seem to remember this issue coming up somewhere. Hopefully this will give you a pointer to start with. Chip At 03:08 PM 5/26/00 -0500, Tom-PT Taylor wrote: >I'm forwarding this to the SG 16 list copy the Megaco list because I think >the MTP address was firmed up at Red Bank. Can anyone account for the >failure to accommodate longer MTP addresses? Was it simply because the >intention was to use Annex I transport within an ITU environment only? >-----Original Message----- From: dacollins(a)notes.primeco.com >[SMTP:dacollins@notes.primeco.com] Sent: Friday, May 26, 2000 1:03 >PM To: Taylor, Tom-PT [NORSE:B901:EXCH] Subject: MEGACO errata > > > >Hi Tom, Having had a look at the latest version of the MEGACO spec, I >noticed something odd. The mId may be an MTP address. However, the MTP >address is defined in both the ABNF and ASN.1 specifications as being 2 >octets in length. The ASN.1 description provides a comment that the point >code (PC) is 14 bits and the network indicator (NI) is two bits. This is >only correct for the ITU version of SS7. In several countries, different >versions of SS7 are used and different addressing schemes are used. In >many countries, including the US, Canada and China, the PC is 24 bits >long, with the NI still at two bits, for a total of 26 bits. Therefore, >to use an MTP address for the mId in those countries, the definition of >the mId needs to change. > >I hope this helps in finalizing the spec. > >Daniel Collins ------------------------------------------------------------------- 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

1 0