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

Re: [H.323-SIP/Internet] The reason.
by Sebestyen Istvan ICN M CS 27 25 Feb '00

25 Feb '00

Dear Colleagues, I was present at the SG16 meeting, and have also read now carefully the meeting report. There is really at this point in time in the ITU no new "workitem" or "question" open for this work. Certainly this might change if based on contributions SG16 decides so. You might, however, be interested that in the IMTC a lot of very similar work is already being done. Have a view of the program of the aHIT! Working Group (chaired by Ayse Dilber (adilber(a)att.com)) of AT&T), described below. I am sure Ayse will be more than happy to see more active co-workers pushing the work of aHIT! ahead. The aHIT! program was approved within the IMTC in November 1999, and now it is running full speed. Kind regards, Istvan sebestyen aHIT! AG's Objectives: - Identify VoIP and Multimedia Applications (i.e., VoIP, FoIP, Conferencing, Instant Messaging, etc.) which will enable service providers to implement end-to-end services; - Identify Interworking Scenarios (i.e., between H.323 and SIP/H.248-MEGACO/cable/etc.) to achieve interworking between different protocols to support multi-vendor and multi-service provider environments; - Develop technical interoperability documents per application and per scenario to guide service providers and vendors to implement seamless, secure, global VoIP and Multimedia Applications; - Encourage, define and participate in global VoIP and Multimedia applications trials between member service providers and vendors - Provide a forum for open technical exchange; - Support, promote and participate in IMTC/ETSI testing events. aHIT! AG Work Plan: 1) Define technical lower layer communications capabilities and protocols for each application. 2) Work on interworking between H.323 and SIP/NCS/H.248-MEGACO. 3) Introduce the value-added functionalities and enhanced services. 4) Develop and publish technical interoperability documents per application/scenario starting from 2Q00. aHIT! AG will address the following issues for each application,: Performance/QoS Reliability Naming/Numbering/Addressing Settlements/Billing Fax Support OAM&P Support Number Portability Interworking Issues(i.e.,H.323/SIP/MEGACO/NCS and CCS/PSTN) Enhanced Services (i.e., roaming) -------------------------------------------------------------------------- Dr. Istvan Sebestyen Siemens AG, ICN M CS27, Hofmannstr. 51 D-81359 Munich Tel:+49-89-722-47230 Fax:+49-89-722-47713 E-Mail office: istvan.sebestyen(a)icn.siemens.de; istvan(a)sebestyen.de E-mail private: istvan_sebestyen(a)yahoo.com; Siemens Intranet:http://netinfo.icn.siemens.de/es/team/essp/team/essp4 Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de ---------------------------------------------------------------------------- ---------------- > ---------- > From: Roy, Radhika R, ALARC[SMTP:rrroy@ATT.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Friday, February 25, 2000 1:58 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: [H.323-SIP/Internet] The reason. > > Hi, Everyone: > > I am in full agreement with Orit. I guess that this has also been the case > for many people who had been present in the SG16 meeting. > > More importantly, when I talked to Glen, he clearly indicated that we > should > bring contributions to get the work started. The interworking between > H.323 > and SIP may belong Q.14 (although it has to be discussed jointly with Q.13 > and Q.14). > > There has been a very strong interest for the work of H.323-SIP > Interworking. A large number of people throughout the world (starting from > the ITU-T and IETF) is contacting me. > > The primary goal of the standard bodies is to provide "INTEROPERABILITY." > > Best regards, > Radhika R. Roy > AT&T > +1 732 420 1580 > rrroy(a)att.com > >

1 0

Re: [H.323-SIP/Internet] The reason.
by Sebestyen Istvan ICN M CS 27 25 Feb '00

25 Feb '00

Many thanks for all the information on this from all sides. I think Tom Taylor's summary captures best where we are, and what the solution should be, and I agree with him. If there is a need (which might very well be...) to clean up any "mess" that might have resulted from the SIP vs. H.323 standardization effort, that should be done by more neutral third parties that have more distance to the detailed H.323 and SIP standardization and who concentrate on interoperability such as ETSI TIPHON or IMTC (where development engineers try to figure out in their implementation what was really meant in the standards, and might try to make H.323 an SIP systems peacefully cooperate). So, this is my contribution to the "Q.13 and Q.14 invitation on how to approach > the work". > Regards, Istvan Sebestyen -------------------------------------------------------------------------- Dr. Istvan Sebestyen Siemens AG, ICN M CS27, Hofmannstr. 51 D-81359 Munich Tel:+49-89-722-47230 Fax:+49-89-722-47713 E-Mail office: istvan.sebestyen(a)icn.siemens.de; istvan(a)sebestyen.de E-mail private: istvan_sebestyen(a)yahoo.com; Siemens Intranet:http://netinfo.icn.siemens.de/es/team/essp/team/essp4 Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de ---------------------------------------------------------------------------- ---------------- > ---------- > From: Tom-PT Taylor[SMTP:taylor@NORTELNETWORKS.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Thursday, February 24, 2000 10:34 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: [H.323-SIP/Internet] The reason. > > I should make one thing clear, as it does not seem to be outside the IETF. > There is only one official version of SIP: that presented in RFC 2705. > BUT, just as SG 16 works on successive versions of H.323, the IETF is > working on the next version of SIP. It is the discussion of what should > be in the core specification next time around versus what should be in > various extension documents which may be causing the confusion in people's > minds. BTW, it seems to me that extensions are roughly the IETF > equivalent of ITU-T options. > > That said, I agree with Bob that all that came out of the discussion was a > feeling that the terms of any such work need to be hammered out, plus a > willingness to consider further contributions so long as they don't get > too detailed. > > Looks to me like this work is going to be done in TIPHON and the > interoperability consortia. Neither the IETF nor the ITU-T really seems > to want it at this point. > > -----Original Message----- > From: Callaghan, Robert [SMTP:Robert.Callaghan@ICN.SIEMENS.COM] > Sent: Thursday, February 24, 2000 4:10 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323-SIP/Internet] The reason. > > Orit, > > This is the statement from the Q.14 meeting report: > > ======= Start > > 3.8.5.1 D.352 - H.323-SIP Interworking [AT&T, et al] > This was presented together with D.413. Comments included: > · Concerns about joint development with IETF > · Which version of SIP would be used? > · Suggest postponing this until the next study period - need to look > > at how Q.13 and Q.14 were formulated 4 years ago and see how output > compares > with phrasing of work in these questions > · Activities should include comparing call models, media signaling > · Concerns about increased travel - maybe this should not be done in > > SG16 > · Forming a new question might not be the best answer - this would > split the expertise in SG16 again (as Q.13 and Q.14 have moved away from > joint sessions) > · Need to work from official process of IETF (i.e., use only the > IETF > equivalent of a Recommendation) > · Consider gatekeepers working with TRIP > Individuals saw merit in the work. Invite contributions on how to approach > > the work. Need to get scenarios for progressing work in a controlled > architectural approach. Ms. Levin has volunteered to draft a framework. > See additional notes in Q.13 meeting report. > > ======= End > > This is the statement in the Q.13 report: > > ======= Start > > D.413(2/16) [Canada] - Interworking Between H.323 and SIP > Networks > > This calls for the creation of an interoperability question in SG16, > that > would cover among other things, H.323/SIP interworking. > > With regard to both D.352/D.413, it was noted that there are several > > versions of SIP, it is hard to start any work to interoperate with SIP as > SIP is ill-defined at this point in time. The wisdom of starting a new > question near the end of the study period was also questioned. It was > also > mentioned that a great deal of work needs to be done in terms of defining > the procedures and architecture that would apply to this work. One > suggestion is that interoperability should be between standards bodies > such > as the ITU and IETF, and this should be the focus of the work, i.e. that > the > target is official IETF RFCs and not SIP type documents produced by > various > other bodies. There were various expressions of support that this should > be > studied, and contributions related to architectures and priorities are > solicited. It was agreed that contributions should address both Q13 and > Q14. > > ======= End > > I cannot see in these statements any thing representing an agreement > as to > the work to be performed. Your attached terms of reference were not > approved at the working party, which is required, nor in the Question > meeting. Without an agreement as to the scope, I do not see how to move > the > work forward, even if many people see it as valuable. Therefore you paper > on > terms of reference can be accepted as a contribution to the Osaka meeting > for discussion. > > I do know that the proposal for a new question was rejected at the > question > level, and not brought forward to the working party or study group level. > > Talking to Dale, I know that he wants to start the work with H.225.0 > Annex G > to TRIP. Other items are to follow. > > For me one of the problems is the culture clash. I do not feel that > the ITU > should represent itself as SIP experts and I do not accept any IETF person > > as an H.323 expert. Therefore the work should be done jointly. No one > wants to repeat the process used by H.248, so what is the process to be > used? > > Bob > > ------------------------------------------------------------------ > Robert Callaghan > Siemens Information and Communication Networks > Tel: +1.561.997.3756 Fax: +1.561.997.3403 > Email: Robert.Callaghan(a)ICN.Siemens.com > ------------------------------------------------------------------ > > > -----Original Message----- > From: Orit Levin [ mailto:orit@radvision.com] > Sent: Thursday, February 24, 2000 2:27 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: [H.323-SIP/Internet] The reason. > > > Hello Sebestyen! > There is additional chapter from Q.14 Report with the same meaning, but I > am > sure it doesn't answer your question. During Geneva meeting additional > related aspects were discussed. In my previous mail I was referring to the > > attached paper. (You will find references to relevant contributions in > this > paper.) Currently this paper is one of the opinions and possible > directions. > We are having this discussion on the list in order to get an understanding > > of the work we would like to pursue and prepare contributions for Osaka > meeting. > 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: Sebestyen Istvan ICN M CS 27 <Istvan.Sebestyen(a)icn.siemens.de> > To: ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com>; 'Orit > > Levin' <orit(a)radvision.com> > Date: Thursday, February 24, 2000 2:02 PM > Subject: RE: [H.323-SIP/Internet] The reason. > > > >Orit, > >I am a bit confused on what should be done here. I have only found in > TD-74 > >(ITU-T SG16 Working Party 2 Report) the following passages: > > > >"D.352(2/16) [Various] - H.323 SIP Interworking > > > >This document calls for a joint ITU-T/IETF study of H.323/SIP > interworking. > > > > > >D.413(2/16) [Canada] - Interworking Between H.323 and SIP Networks > > > >This calls for the creation of an interoperability question in SG16, that > > >would cover among other things, H.323/SIP interworking. > > > >With regard to both D.352/D.413, it was noted that there are several > >versions of SIP, it is hard to start any work to interoperate with SIP as > > >SIP is ill-defined at this point in time. The wisdom of starting a new > >question near the end of the study period was also questioned. It was > also > >mentioned that a great deal of work needs to be done in terms of defining > > >the procedures and architecture that would apply to this work. One > >suggestion is that interoperability should be between standards bodies > such > >as the ITU and IETF, and this should be the focus of the work, i.e. that > the > >target is official IETF RFCs and not SIP type documents produced by > various > >other bodies. There were various expressions of support that this should > > be > >studied, and contributions related to architectures and priorities are > >solicited. It was agreed that contributions should address both Q13 and > >Q14." > > > >Is there anything else as "Mission Statement" for the interim work? > > > >Regards, > >Istvan > > > >------------------------------------------------------------------------- > - > >Dr. Istvan Sebestyen > >Siemens AG, ICN M CS27, > >Hofmannstr. 51 D-81359 Munich > >Tel:+49-89-722-47230 > >Fax:+49-89-722-47713 > >E-Mail office: istvan.sebestyen(a)icn.siemens.de; istvan(a)sebestyen.de > >E-mail private: istvan_sebestyen(a)yahoo.com; > >Siemens Intranet: http://netinfo.icn.siemens.de/es/team/essp/team/essp4 > >Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de > >------------------------------------------------------------------------- > -- > - > >---------------- > > > >> ---------- > >> From: Orit Levin[SMTP:orit@radvision.com] > >> Reply To: Orit Levin > >> Sent: Thursday, February 24, 2000 6:53 PM > >> To: ITU-SG16(a)mailbag.cps.intel.com > >> Subject: [H.323-SIP/Internet] The reason. > >> > >> Hi! > >> I would like to highlight the reason of "H.323-XXX" work in ITU-T as > >> described in the initial paper. > >> > >> H.323 is NOT new to Internet. Internet is evolving and new > specifications > >> in "IP telephony" area are being defined in IETF. This is a time to > >> consider each one of these specifications to be applied to H.323. If > found > >> useful from technical point of view (as a kind of Back End Services) or > > >> just as required for interworking purposes (such as H.323-SIP > scenarios), > >> standard definitions for H.323 should be formulated. These two are > >> connected since the first definitely helps the second. > >> > >> The written above agenda is a proposal for the work scope. Based on our > > >> discussions, it seems like more then one company would like to see this > > >> work beyond the topic of H.323-SIP interoperability. (forget the name > :-) > >> ) If we agree that standardization is needed for this kind of work, the > > >> only possible way to do it is to participate in ITU-T process (with all > > >> its meaning). > >> > >> Currently we are in the beginning of the process sorting out topics of > our > >> interest. I think most of us are aware of the work being done in other > >> organizations. We would like to see experts (including from TIPHON and > >> IETF) presenting their concepts to ITU (starting from the mailing list) > > >> keeping us from repeating their work and being aligned with them. > >> > >> 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

H.225 GK discovery and DNS queries - use of DNS SRV RR
by Jean-Francois Mule 24 Feb '00

24 Feb '00

H.225 version 2, Appendix IV paragraph IV.1.1.2.2.1 includes an informative section on the use of DNS to discover gatekeeper services. This may also be in version 3 (did not check the exact paragraph though). The IETF recently published an update for the DNS SRV resource record (it is RFC 2782 - see below). The main changes are in the format of the SRV RR (service and protocol names now start with an underscore). The underscores were needed to prevent the name collisions with the hosts which happen to have the name in the format <service>.<protocol>.<domain>. This has any impact on the endpoints' SRV lookups on some implementations. It should be referenced in the implementors' guide for future reference. Regards, Jean-Francois. PS: RFC2782 ftp://ftp.isi.edu/in-notes/rfc2782.txt -------------------------------------------------------------- Jean-François Mulé Clarent Corporation - Standards & Architecture Group T: +1 650 481-2835 jfm(a)clarent.com "It takes time to do it right, but there is no shorter way." --Watts S. Humphrey --------------------------------------------------------------

1 0

Re: [H.323-SIP/Internet] The reason.
by Orit Levin 24 Feb '00

24 Feb '00

Dear Rob! Yes, believe me, I read the official report very carefully. The whole idea is to present "the terms of reference" as a contribution for Osaka meeting. I do not see how it prevents to move the work forward, especially if many people see it as valuable. BTW: Who said the work shouldn't be done jointly? My point was that it may start from documents and people, rather then from "ITU and IETF". And after all we are NOT talking about joined standard definition. In worst case about joined Network definition. :-)) Cheers, 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: Callaghan, Robert <Robert.Callaghan(a)icn.siemens.com> To: 'Orit Levin' <orit(a)radvision.com>; ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com> Date: Thursday, February 24, 2000 4:09 PM Subject: RE: [H.323-SIP/Internet] The reason. Orit, This is the statement from the Q.14 meeting report: ======= Start 3.8.5.1 D.352 - H.323-SIP Interworking [AT&T, et al] This was presented together with D.413. Comments included: · Concerns about joint development with IETF · Which version of SIP would be used? · Suggest postponing this until the next study period - need to look at how Q.13 and Q.14 were formulated 4 years ago and see how output compares with phrasing of work in these questions · Activities should include comparing call models, media signaling · Concerns about increased travel - maybe this should not be done in SG16 · Forming a new question might not be the best answer - this would split the expertise in SG16 again (as Q.13 and Q.14 have moved away from joint sessions) · Need to work from official process of IETF (i.e., use only the IETF equivalent of a Recommendation) · Consider gatekeepers working with TRIP Individuals saw merit in the work. Invite contributions on how to approach the work. Need to get scenarios for progressing work in a controlled architectural approach. Ms. Levin has volunteered to draft a framework. See additional notes in Q.13 meeting report. ======= End This is the statement in the Q.13 report: ======= Start D.413(2/16) [Canada] - Interworking Between H.323 and SIP Networks This calls for the creation of an interoperability question in SG16, that would cover among other things, H.323/SIP interworking. With regard to both D.352/D.413, it was noted that there are several versions of SIP, it is hard to start any work to interoperate with SIP as SIP is ill-defined at this point in time. The wisdom of starting a new question near the end of the study period was also questioned. It was also mentioned that a great deal of work needs to be done in terms of defining the procedures and architecture that would apply to this work. One suggestion is that interoperability should be between standards bodies such as the ITU and IETF, and this should be the focus of the work, i.e. that the target is official IETF RFCs and not SIP type documents produced by various other bodies. There were various expressions of support that this should be studied, and contributions related to architectures and priorities are solicited. It was agreed that contributions should address both Q13 and Q14. ======= End I cannot see in these statements any thing representing an agreement as to the work to be performed. Your attached terms of reference were not approved at the working party, which is required, nor in the Question meeting. Without an agreement as to the scope, I do not see how to move the work forward, even if many people see it as valuable. Therefore you paper on terms of reference can be accepted as a contribution to the Osaka meeting for discussion. I do know that the proposal for a new question was rejected at the question level, and not brought forward to the working party or study group level. Talking to Dale, I know that he wants to start the work with H.225.0 Annex G to TRIP. Other items are to follow. For me one of the problems is the culture clash. I do not feel that the ITU should represent itself as SIP experts and I do not accept any IETF person as an H.323 expert. Therefore the work should be done jointly. No one wants to repeat the process used by H.248, so what is the process to be used? Bob ------------------------------------------------------------------ Robert Callaghan Siemens Information and Communication Networks Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Orit Levin [mailto:orit@radvision.com] Sent: Thursday, February 24, 2000 2:27 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [H.323-SIP/Internet] The reason. Hello Sebestyen! There is additional chapter from Q.14 Report with the same meaning, but I am sure it doesn't answer your question. During Geneva meeting additional related aspects were discussed. In my previous mail I was referring to the attached paper. (You will find references to relevant contributions in this paper.) Currently this paper is one of the opinions and possible directions. We are having this discussion on the list in order to get an understanding of the work we would like to pursue and prepare contributions for Osaka meeting. 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: Sebestyen Istvan ICN M CS 27 <Istvan.Sebestyen(a)icn.siemens.de> To: ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com>; 'Orit Levin' <orit(a)radvision.com> Date: Thursday, February 24, 2000 2:02 PM Subject: RE: [H.323-SIP/Internet] The reason. >Orit, >I am a bit confused on what should be done here. I have only found in TD-74 >(ITU-T SG16 Working Party 2 Report) the following passages: > >"D.352(2/16) [Various] - H.323 SIP Interworking > >This document calls for a joint ITU-T/IETF study of H.323/SIP interworking. > > >D.413(2/16) [Canada] - Interworking Between H.323 and SIP Networks > >This calls for the creation of an interoperability question in SG16, that >would cover among other things, H.323/SIP interworking. > >With regard to both D.352/D.413, it was noted that there are several >versions of SIP, it is hard to start any work to interoperate with SIP as >SIP is ill-defined at this point in time. The wisdom of starting a new >question near the end of the study period was also questioned. It was also >mentioned that a great deal of work needs to be done in terms of defining >the procedures and architecture that would apply to this work. One >suggestion is that interoperability should be between standards bodies such >as the ITU and IETF, and this should be the focus of the work, i.e. that the >target is official IETF RFCs and not SIP type documents produced by various >other bodies. There were various expressions of support that this should be >studied, and contributions related to architectures and priorities are >solicited. It was agreed that contributions should address both Q13 and >Q14." > >Is there anything else as "Mission Statement" for the interim work? > >Regards, >Istvan > >-------------------------------------------------------------------------- >Dr. Istvan Sebestyen >Siemens AG, ICN M CS27, >Hofmannstr. 51 D-81359 Munich >Tel:+49-89-722-47230 >Fax:+49-89-722-47713 >E-Mail office: istvan.sebestyen(a)icn.siemens.de; istvan(a)sebestyen.de >E-mail private: istvan_sebestyen(a)yahoo.com; >Siemens Intranet:http://netinfo.icn.siemens.de/es/team/essp/team/essp4 >Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de >--------------------------------------------------------------------------- - >---------------- > >> ---------- >> From: Orit Levin[SMTP:orit@radvision.com] >> Reply To: Orit Levin >> Sent: Thursday, February 24, 2000 6:53 PM >> To: ITU-SG16(a)mailbag.cps.intel.com >> Subject: [H.323-SIP/Internet] The reason. >> >> Hi! >> I would like to highlight the reason of "H.323-XXX" work in ITU-T as >> described in the initial paper. >> >> H.323 is NOT new to Internet. Internet is evolving and new specifications >> in "IP telephony" area are being defined in IETF. This is a time to >> consider each one of these specifications to be applied to H.323. If found >> useful from technical point of view (as a kind of Back End Services) or >> just as required for interworking purposes (such as H.323-SIP scenarios), >> standard definitions for H.323 should be formulated. These two are >> connected since the first definitely helps the second. >> >> The written above agenda is a proposal for the work scope. Based on our >> discussions, it seems like more then one company would like to see this >> work beyond the topic of H.323-SIP interoperability. (forget the name :-) >> ) If we agree that standardization is needed for this kind of work, the >> only possible way to do it is to participate in ITU-T process (with all >> its meaning). >> >> Currently we are in the beginning of the process sorting out topics of our >> interest. I think most of us are aware of the work being done in other >> organizations. We would like to see experts (including from TIPHON and >> IETF) presenting their concepts to ITU (starting from the mailing list) >> keeping us from repeating their work and being aligned with them. >> >> 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: [H.323-SIP/Internet] The reason.
by Tom-PT Taylor 24 Feb '00

24 Feb '00

I should make one thing clear, as it does not seem to be outside the IETF. There is only one official version of SIP: that presented in RFC 2705. BUT, just as SG 16 works on successive versions of H.323, the IETF is working on the next version of SIP. It is the discussion of what should be in the core specification next time around versus what should be in various extension documents which may be causing the confusion in people's minds. BTW, it seems to me that extensions are roughly the IETF equivalent of ITU-T options. That said, I agree with Bob that all that came out of the discussion was a feeling that the terms of any such work need to be hammered out, plus a willingness to consider further contributions so long as they don't get too detailed. Looks to me like this work is going to be done in TIPHON and the interoperability consortia. Neither the IETF nor the ITU-T really seems to want it at this point. > -----Original Message----- > From: Callaghan, Robert [SMTP:Robert.Callaghan@ICN.SIEMENS.COM] > Sent: Thursday, February 24, 2000 4:10 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323-SIP/Internet] The reason. > > Orit, > > This is the statement from the Q.14 meeting report: > > ======= Start > > 3.8.5.1 D.352 - H.323-SIP Interworking [AT&T, et al] > This was presented together with D.413. Comments included: > · Concerns about joint development with IETF > · Which version of SIP would be used? > · Suggest postponing this until the next study period - need to look > at how Q.13 and Q.14 were formulated 4 years ago and see how output > compares > with phrasing of work in these questions > · Activities should include comparing call models, media signaling > · Concerns about increased travel - maybe this should not be done in > SG16 > · Forming a new question might not be the best answer - this would > split the expertise in SG16 again (as Q.13 and Q.14 have moved away from > joint sessions) > · Need to work from official process of IETF (i.e., use only the > IETF > equivalent of a Recommendation) > · Consider gatekeepers working with TRIP > Individuals saw merit in the work. Invite contributions on how to approach > the work. Need to get scenarios for progressing work in a controlled > architectural approach. Ms. Levin has volunteered to draft a framework. > See additional notes in Q.13 meeting report. > > ======= End > > This is the statement in the Q.13 report: > > ======= Start > > D.413(2/16) [Canada] - Interworking Between H.323 and SIP Networks > > This calls for the creation of an interoperability question in SG16, that > would cover among other things, H.323/SIP interworking. > > With regard to both D.352/D.413, it was noted that there are several > versions of SIP, it is hard to start any work to interoperate with SIP as > SIP is ill-defined at this point in time. The wisdom of starting a new > question near the end of the study period was also questioned. It was > also > mentioned that a great deal of work needs to be done in terms of defining > the procedures and architecture that would apply to this work. One > suggestion is that interoperability should be between standards bodies > such > as the ITU and IETF, and this should be the focus of the work, i.e. that > the > target is official IETF RFCs and not SIP type documents produced by > various > other bodies. There were various expressions of support that this should > be > studied, and contributions related to architectures and priorities are > solicited. It was agreed that contributions should address both Q13 and > Q14. > > ======= End > > I cannot see in these statements any thing representing an agreement as to > the work to be performed. Your attached terms of reference were not > approved at the working party, which is required, nor in the Question > meeting. Without an agreement as to the scope, I do not see how to move > the > work forward, even if many people see it as valuable. Therefore you paper > on > terms of reference can be accepted as a contribution to the Osaka meeting > for discussion. > > I do know that the proposal for a new question was rejected at the > question > level, and not brought forward to the working party or study group level. > > Talking to Dale, I know that he wants to start the work with H.225.0 Annex > G > to TRIP. Other items are to follow. > > For me one of the problems is the culture clash. I do not feel that the > ITU > should represent itself as SIP experts and I do not accept any IETF person > as an H.323 expert. Therefore the work should be done jointly. No one > wants to repeat the process used by H.248, so what is the process to be > used? > > Bob > > ------------------------------------------------------------------ > Robert Callaghan > Siemens Information and Communication Networks > Tel: +1.561.997.3756 Fax: +1.561.997.3403 > Email: Robert.Callaghan(a)ICN.Siemens.com > ------------------------------------------------------------------ > > > -----Original Message----- > From: Orit Levin [mailto:orit@radvision.com] > Sent: Thursday, February 24, 2000 2:27 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: [H.323-SIP/Internet] The reason. > > > Hello Sebestyen! > There is additional chapter from Q.14 Report with the same meaning, but I > am > sure it doesn't answer your question. During Geneva meeting additional > related aspects were discussed. In my previous mail I was referring to the > attached paper. (You will find references to relevant contributions in > this > paper.) Currently this paper is one of the opinions and possible > directions. > We are having this discussion on the list in order to get an understanding > of the work we would like to pursue and prepare contributions for Osaka > meeting. > 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: Sebestyen Istvan ICN M CS 27 <Istvan.Sebestyen(a)icn.siemens.de> > To: ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com>; 'Orit > Levin' <orit(a)radvision.com> > Date: Thursday, February 24, 2000 2:02 PM > Subject: RE: [H.323-SIP/Internet] The reason. > > > >Orit, > >I am a bit confused on what should be done here. I have only found in > TD-74 > >(ITU-T SG16 Working Party 2 Report) the following passages: > > > >"D.352(2/16) [Various] - H.323 SIP Interworking > > > >This document calls for a joint ITU-T/IETF study of H.323/SIP > interworking. > > > > > >D.413(2/16) [Canada] - Interworking Between H.323 and SIP Networks > > > >This calls for the creation of an interoperability question in SG16, that > >would cover among other things, H.323/SIP interworking. > > > >With regard to both D.352/D.413, it was noted that there are several > >versions of SIP, it is hard to start any work to interoperate with SIP as > >SIP is ill-defined at this point in time. The wisdom of starting a new > >question near the end of the study period was also questioned. It was > also > >mentioned that a great deal of work needs to be done in terms of defining > >the procedures and architecture that would apply to this work. One > >suggestion is that interoperability should be between standards bodies > such > >as the ITU and IETF, and this should be the focus of the work, i.e. that > the > >target is official IETF RFCs and not SIP type documents produced by > various > >other bodies. There were various expressions of support that this should > be > >studied, and contributions related to architectures and priorities are > >solicited. It was agreed that contributions should address both Q13 and > >Q14." > > > >Is there anything else as "Mission Statement" for the interim work? > > > >Regards, > >Istvan > > > >------------------------------------------------------------------------- > - > >Dr. Istvan Sebestyen > >Siemens AG, ICN M CS27, > >Hofmannstr. 51 D-81359 Munich > >Tel:+49-89-722-47230 > >Fax:+49-89-722-47713 > >E-Mail office: istvan.sebestyen(a)icn.siemens.de; istvan(a)sebestyen.de > >E-mail private: istvan_sebestyen(a)yahoo.com; > >Siemens Intranet:http://netinfo.icn.siemens.de/es/team/essp/team/essp4 > >Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de > >------------------------------------------------------------------------- > -- > - > >---------------- > > > >> ---------- > >> From: Orit Levin[SMTP:orit@radvision.com] > >> Reply To: Orit Levin > >> Sent: Thursday, February 24, 2000 6:53 PM > >> To: ITU-SG16(a)mailbag.cps.intel.com > >> Subject: [H.323-SIP/Internet] The reason. > >> > >> Hi! > >> I would like to highlight the reason of "H.323-XXX" work in ITU-T as > >> described in the initial paper. > >> > >> H.323 is NOT new to Internet. Internet is evolving and new > specifications > >> in "IP telephony" area are being defined in IETF. This is a time to > >> consider each one of these specifications to be applied to H.323. If > found > >> useful from technical point of view (as a kind of Back End Services) or > >> just as required for interworking purposes (such as H.323-SIP > scenarios), > >> standard definitions for H.323 should be formulated. These two are > >> connected since the first definitely helps the second. > >> > >> The written above agenda is a proposal for the work scope. Based on our > >> discussions, it seems like more then one company would like to see this > >> work beyond the topic of H.323-SIP interoperability. (forget the name > :-) > >> ) If we agree that standardization is needed for this kind of work, the > >> only possible way to do it is to participate in ITU-T process (with all > >> its meaning). > >> > >> Currently we are in the beginning of the process sorting out topics of > our > >> interest. I think most of us are aware of the work being done in other > >> organizations. We would like to see experts (including from TIPHON and > >> IETF) presenting their concepts to ITU (starting from the mailing list) > >> keeping us from repeating their work and being aligned with them. > >> > >> 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: [H.323-SIP/Internet] The reason.
by Callaghan, Robert 24 Feb '00

24 Feb '00

Orit, This is the statement from the Q.14 meeting report: ======= Start 3.8.5.1 D.352 - H.323-SIP Interworking [AT&T, et al] This was presented together with D.413. Comments included: · Concerns about joint development with IETF · Which version of SIP would be used? · Suggest postponing this until the next study period - need to look at how Q.13 and Q.14 were formulated 4 years ago and see how output compares with phrasing of work in these questions · Activities should include comparing call models, media signaling · Concerns about increased travel - maybe this should not be done in SG16 · Forming a new question might not be the best answer - this would split the expertise in SG16 again (as Q.13 and Q.14 have moved away from joint sessions) · Need to work from official process of IETF (i.e., use only the IETF equivalent of a Recommendation) · Consider gatekeepers working with TRIP Individuals saw merit in the work. Invite contributions on how to approach the work. Need to get scenarios for progressing work in a controlled architectural approach. Ms. Levin has volunteered to draft a framework. See additional notes in Q.13 meeting report. ======= End This is the statement in the Q.13 report: ======= Start D.413(2/16) [Canada] - Interworking Between H.323 and SIP Networks This calls for the creation of an interoperability question in SG16, that would cover among other things, H.323/SIP interworking. With regard to both D.352/D.413, it was noted that there are several versions of SIP, it is hard to start any work to interoperate with SIP as SIP is ill-defined at this point in time. The wisdom of starting a new question near the end of the study period was also questioned. It was also mentioned that a great deal of work needs to be done in terms of defining the procedures and architecture that would apply to this work. One suggestion is that interoperability should be between standards bodies such as the ITU and IETF, and this should be the focus of the work, i.e. that the target is official IETF RFCs and not SIP type documents produced by various other bodies. There were various expressions of support that this should be studied, and contributions related to architectures and priorities are solicited. It was agreed that contributions should address both Q13 and Q14. ======= End I cannot see in these statements any thing representing an agreement as to the work to be performed. Your attached terms of reference were not approved at the working party, which is required, nor in the Question meeting. Without an agreement as to the scope, I do not see how to move the work forward, even if many people see it as valuable. Therefore you paper on terms of reference can be accepted as a contribution to the Osaka meeting for discussion. I do know that the proposal for a new question was rejected at the question level, and not brought forward to the working party or study group level. Talking to Dale, I know that he wants to start the work with H.225.0 Annex G to TRIP. Other items are to follow. For me one of the problems is the culture clash. I do not feel that the ITU should represent itself as SIP experts and I do not accept any IETF person as an H.323 expert. Therefore the work should be done jointly. No one wants to repeat the process used by H.248, so what is the process to be used? Bob ------------------------------------------------------------------ Robert Callaghan Siemens Information and Communication Networks Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Orit Levin [mailto:orit@radvision.com] Sent: Thursday, February 24, 2000 2:27 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [H.323-SIP/Internet] The reason. Hello Sebestyen! There is additional chapter from Q.14 Report with the same meaning, but I am sure it doesn't answer your question. During Geneva meeting additional related aspects were discussed. In my previous mail I was referring to the attached paper. (You will find references to relevant contributions in this paper.) Currently this paper is one of the opinions and possible directions. We are having this discussion on the list in order to get an understanding of the work we would like to pursue and prepare contributions for Osaka meeting. 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: Sebestyen Istvan ICN M CS 27 <Istvan.Sebestyen(a)icn.siemens.de> To: ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com>; 'Orit Levin' <orit(a)radvision.com> Date: Thursday, February 24, 2000 2:02 PM Subject: RE: [H.323-SIP/Internet] The reason. >Orit, >I am a bit confused on what should be done here. I have only found in TD-74 >(ITU-T SG16 Working Party 2 Report) the following passages: > >"D.352(2/16) [Various] - H.323 SIP Interworking > >This document calls for a joint ITU-T/IETF study of H.323/SIP interworking. > > >D.413(2/16) [Canada] - Interworking Between H.323 and SIP Networks > >This calls for the creation of an interoperability question in SG16, that >would cover among other things, H.323/SIP interworking. > >With regard to both D.352/D.413, it was noted that there are several >versions of SIP, it is hard to start any work to interoperate with SIP as >SIP is ill-defined at this point in time. The wisdom of starting a new >question near the end of the study period was also questioned. It was also >mentioned that a great deal of work needs to be done in terms of defining >the procedures and architecture that would apply to this work. One >suggestion is that interoperability should be between standards bodies such >as the ITU and IETF, and this should be the focus of the work, i.e. that the >target is official IETF RFCs and not SIP type documents produced by various >other bodies. There were various expressions of support that this should be >studied, and contributions related to architectures and priorities are >solicited. It was agreed that contributions should address both Q13 and >Q14." > >Is there anything else as "Mission Statement" for the interim work? > >Regards, >Istvan > >-------------------------------------------------------------------------- >Dr. Istvan Sebestyen >Siemens AG, ICN M CS27, >Hofmannstr. 51 D-81359 Munich >Tel:+49-89-722-47230 >Fax:+49-89-722-47713 >E-Mail office: istvan.sebestyen(a)icn.siemens.de; istvan(a)sebestyen.de >E-mail private: istvan_sebestyen(a)yahoo.com; >Siemens Intranet:http://netinfo.icn.siemens.de/es/team/essp/team/essp4 >Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de >--------------------------------------------------------------------------- - >---------------- > >> ---------- >> From: Orit Levin[SMTP:orit@radvision.com] >> Reply To: Orit Levin >> Sent: Thursday, February 24, 2000 6:53 PM >> To: ITU-SG16(a)mailbag.cps.intel.com >> Subject: [H.323-SIP/Internet] The reason. >> >> Hi! >> I would like to highlight the reason of "H.323-XXX" work in ITU-T as >> described in the initial paper. >> >> H.323 is NOT new to Internet. Internet is evolving and new specifications >> in "IP telephony" area are being defined in IETF. This is a time to >> consider each one of these specifications to be applied to H.323. If found >> useful from technical point of view (as a kind of Back End Services) or >> just as required for interworking purposes (such as H.323-SIP scenarios), >> standard definitions for H.323 should be formulated. These two are >> connected since the first definitely helps the second. >> >> The written above agenda is a proposal for the work scope. Based on our >> discussions, it seems like more then one company would like to see this >> work beyond the topic of H.323-SIP interoperability. (forget the name :-) >> ) If we agree that standardization is needed for this kind of work, the >> only possible way to do it is to participate in ITU-T process (with all >> its meaning). >> >> Currently we are in the beginning of the process sorting out topics of our >> interest. I think most of us are aware of the work being done in other >> organizations. We would like to see experts (including from TIPHON and >> IETF) presenting their concepts to ITU (starting from the mailing list) >> keeping us from repeating their work and being aligned with them. >> >> 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: [H.323-SIP/Internet] The reason.
by Orit Levin 24 Feb '00

24 Feb '00

Hello Sebestyen! There is additional chapter from Q.14 Report with the same meaning, but I am sure it doesn't answer your question. During Geneva meeting additional related aspects were discussed. In my previous mail I was referring to the attached paper. (You will find references to relevant contributions in this paper.) Currently this paper is one of the opinions and possible directions. We are having this discussion on the list in order to get an understanding of the work we would like to pursue and prepare contributions for Osaka meeting. 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: Sebestyen Istvan ICN M CS 27 <Istvan.Sebestyen(a)icn.siemens.de> To: ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com>; 'Orit Levin' <orit(a)radvision.com> Date: Thursday, February 24, 2000 2:02 PM Subject: RE: [H.323-SIP/Internet] The reason. >Orit, >I am a bit confused on what should be done here. I have only found in TD-74 >(ITU-T SG16 Working Party 2 Report) the following passages: > >"D.352(2/16) [Various] - H.323 SIP Interworking > >This document calls for a joint ITU-T/IETF study of H.323/SIP interworking. > > >D.413(2/16) [Canada] - Interworking Between H.323 and SIP Networks > >This calls for the creation of an interoperability question in SG16, that >would cover among other things, H.323/SIP interworking. > >With regard to both D.352/D.413, it was noted that there are several >versions of SIP, it is hard to start any work to interoperate with SIP as >SIP is ill-defined at this point in time. The wisdom of starting a new >question near the end of the study period was also questioned. It was also >mentioned that a great deal of work needs to be done in terms of defining >the procedures and architecture that would apply to this work. One >suggestion is that interoperability should be between standards bodies such >as the ITU and IETF, and this should be the focus of the work, i.e. that the >target is official IETF RFCs and not SIP type documents produced by various >other bodies. There were various expressions of support that this should be >studied, and contributions related to architectures and priorities are >solicited. It was agreed that contributions should address both Q13 and >Q14." > >Is there anything else as "Mission Statement" for the interim work? > >Regards, >Istvan > >-------------------------------------------------------------------------- >Dr. Istvan Sebestyen >Siemens AG, ICN M CS27, >Hofmannstr. 51 D-81359 Munich >Tel:+49-89-722-47230 >Fax:+49-89-722-47713 >E-Mail office: istvan.sebestyen(a)icn.siemens.de; istvan(a)sebestyen.de >E-mail private: istvan_sebestyen(a)yahoo.com; >Siemens Intranet:http://netinfo.icn.siemens.de/es/team/essp/team/essp4 >Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de >--------------------------------------------------------------------------- - >---------------- > >> ---------- >> From: Orit Levin[SMTP:orit@radvision.com] >> Reply To: Orit Levin >> Sent: Thursday, February 24, 2000 6:53 PM >> To: ITU-SG16(a)mailbag.cps.intel.com >> Subject: [H.323-SIP/Internet] The reason. >> >> Hi! >> I would like to highlight the reason of "H.323-XXX" work in ITU-T as >> described in the initial paper. >> >> H.323 is NOT new to Internet. Internet is evolving and new specifications >> in "IP telephony" area are being defined in IETF. This is a time to >> consider each one of these specifications to be applied to H.323. If found >> useful from technical point of view (as a kind of Back End Services) or >> just as required for interworking purposes (such as H.323-SIP scenarios), >> standard definitions for H.323 should be formulated. These two are >> connected since the first definitely helps the second. >> >> The written above agenda is a proposal for the work scope. Based on our >> discussions, it seems like more then one company would like to see this >> work beyond the topic of H.323-SIP interoperability. (forget the name :-) >> ) If we agree that standardization is needed for this kind of work, the >> only possible way to do it is to participate in ITU-T process (with all >> its meaning). >> >> Currently we are in the beginning of the process sorting out topics of our >> interest. I think most of us are aware of the work being done in other >> organizations. We would like to see experts (including from TIPHON and >> IETF) presenting their concepts to ITU (starting from the mailing list) >> keeping us from repeating their work and being aligned with them. >> >> 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: [H.323-SIP/Internet] The reason.
by Sebestyen Istvan ICN M CS 27 24 Feb '00

24 Feb '00

Orit, I am a bit confused on what should be done here. I have only found in TD-74 (ITU-T SG16 Working Party 2 Report) the following passages: "D.352(2/16) [Various] - H.323 SIP Interworking This document calls for a joint ITU-T/IETF study of H.323/SIP interworking. D.413(2/16) [Canada] - Interworking Between H.323 and SIP Networks This calls for the creation of an interoperability question in SG16, that would cover among other things, H.323/SIP interworking. With regard to both D.352/D.413, it was noted that there are several versions of SIP, it is hard to start any work to interoperate with SIP as SIP is ill-defined at this point in time. The wisdom of starting a new question near the end of the study period was also questioned. It was also mentioned that a great deal of work needs to be done in terms of defining the procedures and architecture that would apply to this work. One suggestion is that interoperability should be between standards bodies such as the ITU and IETF, and this should be the focus of the work, i.e. that the target is official IETF RFCs and not SIP type documents produced by various other bodies. There were various expressions of support that this should be studied, and contributions related to architectures and priorities are solicited. It was agreed that contributions should address both Q13 and Q14." Is there anything else as "Mission Statement" for the interim work? Regards, Istvan -------------------------------------------------------------------------- Dr. Istvan Sebestyen Siemens AG, ICN M CS27, Hofmannstr. 51 D-81359 Munich Tel:+49-89-722-47230 Fax:+49-89-722-47713 E-Mail office: istvan.sebestyen(a)icn.siemens.de; istvan(a)sebestyen.de E-mail private: istvan_sebestyen(a)yahoo.com; Siemens Intranet:http://netinfo.icn.siemens.de/es/team/essp/team/essp4 Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de ---------------------------------------------------------------------------- ---------------- > ---------- > From: Orit Levin[SMTP:orit@radvision.com] > Reply To: Orit Levin > Sent: Thursday, February 24, 2000 6:53 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: [H.323-SIP/Internet] The reason. > > Hi! > I would like to highlight the reason of "H.323-XXX" work in ITU-T as > described in the initial paper. > > H.323 is NOT new to Internet. Internet is evolving and new specifications > in "IP telephony" area are being defined in IETF. This is a time to > consider each one of these specifications to be applied to H.323. If found > useful from technical point of view (as a kind of Back End Services) or > just as required for interworking purposes (such as H.323-SIP scenarios), > standard definitions for H.323 should be formulated. These two are > connected since the first definitely helps the second. > > The written above agenda is a proposal for the work scope. Based on our > discussions, it seems like more then one company would like to see this > work beyond the topic of H.323-SIP interoperability. (forget the name :-) > ) If we agree that standardization is needed for this kind of work, the > only possible way to do it is to participate in ITU-T process (with all > its meaning). > > Currently we are in the beginning of the process sorting out topics of our > interest. I think most of us are aware of the work being done in other > organizations. We would like to see experts (including from TIPHON and > IETF) presenting their concepts to ITU (starting from the mailing list) > keeping us from repeating their work and being aligned with them. > > 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

[H.323-SIP/Internet] The reason.
by Orit Levin 24 Feb '00

24 Feb '00

Hi! I would like to highlight the reason of "H.323-XXX" work in ITU-T as described in the initial paper. H.323 is NOT new to Internet. Internet is evolving and new specifications in "IP telephony" area are being defined in IETF. This is a time to consider each one of these specifications to be applied to H.323. If found useful from technical point of view (as a kind of Back End Services) or just as required for interworking purposes (such as H.323-SIP scenarios), standard definitions for H.323 should be formulated. These two are connected since the first definitely helps the second. The written above agenda is a proposal for the work scope. Based on our discussions, it seems like more then one company would like to see this work beyond the topic of H.323-SIP interoperability. (forget the name :-) ) If we agree that standardization is needed for this kind of work, the only possible way to do it is to participate in ITU-T process (with all its meaning). Currently we are in the beginning of the process sorting out topics of our interest. I think most of us are aware of the work being done in other organizations. We would like to see experts (including from TIPHON and IETF) presenting their concepts to ITU (starting from the mailing list) keeping us from repeating their work and being aligned with them. 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: [H.323Mobility:]
by Kumar, Vineet 24 Feb '00

24 Feb '00

Paul, March 24 will NOT be good for me since I will be flying to Australia for the IETF meeting. My suggestion on conference calls is to pick a day (Monday, Tuesday, etc. ) and time when all conference calls will happen. I think it is hard to get an aggreement every time on the day/time of the conference time. vineet -----Original Message----- From: Guram Paul-LPG019 [mailto:lpg019@EMAIL.MOT.COM] Sent: Wednesday, February 23, 2000 4:16 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323Mobility:] Hi ad hoc Mob. Group 1. We will continue, as previously, and use the URL (ftp://standard.pictel.com/avc-site/Mobility-adhoc/ ) which has been allocated for our group's use. New contributions to start as (Mobility document) MDs to distinguish from the old numerous numbering schemes (for MTD,e.g. mtd03, mtd 201, etc.). I suggest we start at md010 as the first contribution with md001 to md009 to be used for management activities (to be defined later). When contributing, look at the ftp site for the next number available, reserve it by announcing to group, then (if no conflict of numbers) load it onto the site. OR we could ask one of Paul (R or G), Roy, or for Jaakko to control the allocation of the numbers, if you think that would be a better way which avoids clash of same number being used. 2. Jaakko has sent us the zipped file with the TD129 from Geneva for Annex H. This is the document Jaakko will work on as the base-line document and Jaakko, could this be put onto the ftp site as Annex H version 03 (version 01 being Red Bank output, version 2 being ad hoc group input into Geneva, and version 3 being Geneva output). Following on from Nicolas Tran's comments, there are already (minor) changes to be made to version 3, and this will be done as part of regular editor update. Similarly for the ToR document. Is that acceptable ? 3. Apart from Radhika, I have not received availability information for our next conf. call from anyone else. Please let me know which dates are most suitable from 20-24 March to enable me to arrange for an appropriate date. Regards Paul -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@att.com] Sent: 23 February 2000 15:58 To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [H.323Mobility:] Hi, Paul and Jaakko: Many thanks for the information. Paul Guram: Please provide a well thought convention for the document number. For example, MTD.xxx would be given to diiferentiate from the reqular TDs. One request to you: Once a numbering convention is used, please try to stick to that rule (if we change the rule in the middle, it creates confusions as it happened last time). Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Jaakko Sundquist [SMTP:jaakko.sundquist@NOKIA.COM] > Sent: Wednesday, February 23, 2000 9:01 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323Mobility:] > > Hi Radhika et al, > > There seems to be a subdirectory in the pictel-site for mobility. The URL > is: ftp://standard.pictel.com/avc-site/Mobility-adhoc/ . I suggest that we > will put our contributions there. It would be nice to have some naming > convention (such as the MTD-xxx scheme) for the documents. Maybe Paul > should > assign these numbers as he is now the moderator for the teleconferences... > > - Jaakko Sundquist > > -----Original Message----- > From: EXT Roy, Radhika R, ALARC [mailto:rrroy@att.com] > Sent: Wednesday, February 23, 2000 3:34 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: [H.323Mobility:] > > Hi, Jaakko: > > I agree with your reply that was also reflected in my > earlier email. > > I have a question to you and Paul Guram: Have you guys > decided where the > incoming contributions for the Ad Hoc group to be sent and > where the URL > would be for accessing to that website? If it is so, > please > let all of us > know soon. > > Paul Guram: Are you close to decide the meeting date and > time as well? > > Best regards, > Radhika R. Roy > > > > -----Original Message----- > > From: Jaakko Sundquist [SMTP:jaakko.sundquist@NOKIA.COM] > > Sent: Wednesday, February 23, 2000 3:37 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: [H.323Mobility:] > > > > Hi all, > > > > I'm sending here the documents related to H.323 Annex H > that were > > accomplished in the Geneva meeting by the ad hoc > mobility > group. Included > > are the draft Annex H, the Terms of Reference for it as > well as the > > meeting > > minutes (quite short) of the ad hoc group meetings in > Geneva. > > > > As Mr. Tran pointed out the location area had been left > to > the VLF-section > > of the draft annex. This is my mistake and I apologize > for > any confusion > > it > > has created. I did not, however, take it off from the > document I am > > sending > > here, this is the document that was produced as a TD in > Geneva, but I will > > remove the location area from the subsequent versions of > the draft annex. > > As for the TMSI, etc. concepts, in my view it is quite > unnecessary to > > argue > > about these, the TMSI is already included in the > proposed > new alias > > address > > type: UIM. Many of these concepts are, as I understand, > already needed in > > H.246 Annex E, which addresses one scenario of the > mobility problem. I > > would > > see the VLR functionality of the H.246 Annex E IWF as > really the VLF we > > have > > defined as a new mobility functional entity, thus the > identifiers TMSI, > > etc. > > would be needed in the VLF at least in some cases. > However, it might be > > suitable to indicate that all of the identifiers > mentioned > in the VLF (and > > other) section(s) are not mandatory. > > > > <<GenevaMobility.zip>> > > > > - Jaakko Sundquist > > ------------------------------------------------------- > > In a hole in the ground there lived a hobbit. > > Not a nasty, dirty, wet hole, filled with the ends of > > worms and an oozy smell, nor yet a dry, bare, > > sandy hole with nothing in it to sit down on or to eat: > > it was a hobbit-hole, and that means comfort. > > ------------------------------------------------------- > << > File: > > GenevaMobility.zip >>

1 0