- sg16-avd - lists.packetizer.com

Re: proposal for SIP as single call control protocol in 3GPP
by Barry Aronson 09 Mar '00

09 Mar '00

Bob, Do you perhaps mean RFC 2543? Barry At 05:23 3/6/00 -0800, Callaghan, Robert wrote: >It should be noted that an important phase is contained in this document. >It states that SIP is "position SIP as an ideal protocol to modify and >enhance to meet the R2000 requirements." This can be translated into "We >want our own protocol based in SIP." > >It will be interest to see if the results are fully compatible with RFC 2546 >(SIP). > >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: Michaely, Boaz [mailto:Boaz_Michaely@ICOMVERSE.COM] >Sent: Monday, March 06, 2000 2:54 AM >To: ITU-SG16(a)mailbag.cps.intel.com >Subject: proposal for SIP as single call control protocol in 3GPP > > >All, >This proposal comes from: >AT&T, BT, Japan Telecom, Lucent, Nokia, Nortel, Rogers Wireless, T-Mobil, >Telenor, Telia. >For those who are unaware, Release 2000 is conceived as THE most important >activity regarding the future of VoIP in the sense that in a few short years >wireless will become the dominant way of communication (more than wireline). >3GPP now discusses "Release 2000" which is the architecture for that future >mobile network, where everything is over IP, including the media. > >This material is for discussion in Tokyo, March 6-9. > >Thought you should know, > Boaz > >Boaz Michaely >Senior System Architect, Corporate >Comverse Network Systems >Tel: +972 (3) 766-3844 , Mobile +972 (50) 39-30-17 >http://people.itu.int/~michaely >mailto:boaz_michaely@comverse.com > > > > > -----Original Message----- > > From: Lobley,NC,Nigel,NZCA R [mailto:nigel.lobley@BT.COM] > > Sent: Friday, March 03, 2000 1:40 PM > > To: 3GPP_TSG_SA_WG2(a)LIST.ETSI.FR > > Subject: Inputs from BT and a number of companies > > > > > > Dear all > > > > Please find attached a couple of papers for S2 next week. > > > > See you in Japan > > > > Nigel > > Barry Aronson E-mail: baronson(a)ieee.org Toshiba Corp. Voice: +1 978-232-3994 33 Lake Shore Ave. Fax: +1 978-232-9220 Beverly, MA 01915-1907 Video: H.320, H.323, and H.324 by prior arrangement

1 0

Re: FYI - SIP-H.323 Interworking BOF
by Roy, Radhika R, ALARC 08 Mar '00

08 Mar '00

Dear Colleagues, It is not a bad idea that people should discuss this item as a small group depending on their interest. However, if people have a general interest to discuss it in the SG16 reflector, it is their choice. No one individual or a company should restrict it. Let us understand the norm of using the SG16 reflector first. Best regards, Radhika R. Roy > -----Original Message----- > From: Sebestyen Istvan ICN M CS 27 [SMTP:Istvan.Sebestyen@ICN.SIEMENS.DE] > Sent: Wednesday, March 08, 2000 12:57 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: FYI - SIP-H.323 Interworking BOF > Importance: High > > Dear Colleagues, > > I don't want to hurt anybody,... > > but I understand that Martin Euchner is getting a bit inpatient, me too. > It > is really necessary that for an issue that has received in the last ITU-T > SG16 meeting let me say a relatively modest support, now everybody on the > SG16 Reflector has to "listen" the detailed discussion what should be > done, > why, where, when... etc. Would it not be possible that those individuals, > who have an apparent interest in the SIP/H.323 interoperability topic > discuss this first among themselves and the contributions get introduced > only at the next SG16 meeting in May or at least when the contributions > are > finished? > > I hope on your understanding. > > Many 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: Roy, Radhika R, ALARC[SMTP:rrroy@ATT.COM] > > Reply To: Mailing list for parties associated with ITU-T Study Group > > 16 > > Sent: Wednesday, March 08, 2000 5:27 PM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: FYI - SIP-H.323 Interworking BOF > > > > Hi, Everyone: > > > > ITU-T and IETF are the formal standard bodies to create standards for > > H.323 > > and SIP, respectively, and the interworking standard between the two is > > also > > a part of it.. > > > > However, all inputs from other organizations will definitely be > welcomed. > > > > Best regards, > > Radhika R. Roy > > AT&T > > > > > -----Original Message----- > > > From: Euchner Martin [SMTP:Martin.Euchner@MCHP.SIEMENS.DE] > > > Sent: Wednesday, March 08, 2000 4:16 AM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: FYI - SIP-H.323 Interworking BOF > > > > > > just for your information for those interested in H.323/SIP: > > > > > > I would like to draw your attention to an activity group already > > debating > > > H.323-SIP interworking for quite a while: IMTC aHIT!. To my knowledge > > they > > > already came out with some first results on architectures and > > interworking > > > scenarios. Please get in touch with this group and consider their > > results. > > > see also http://www.imtc.org/act_ahit.htm > > > <http://www.imtc.org/act_ahit.htm> > > > and discussions on their mailing list. > > > > > > Thus, it appears to me that there are already quite a few groups > (IETF, > > > IMTC, ETSI) discussing H323/SIP interworking. I do not quite see > > necessity > > > to have ITU-T SG16 as yet another group for this topic. > > > > > > regards > > > > > > Martin. > > > > > > > ----------------------------------------------------------------------- > > > | Dipl.-Inf. Phone: +49 89 636-46201 > > > | Martin Euchner Fax : +49 89 636-48000 > > > | Siemens AG > > > | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de > > > | mailto:martin.euchner@ties.itu.int > > > | Otto-Hahn-Ring 6 Intranet: > > > > > > http://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG1 > > > 6/ > > > index.html > > > | D-81730 Muenchen Internet: http://www.siemens.de > > > | __________________ > > > | Germany > > > > ----------------------------------------------------------------------- > > > > > > > > > -----Original Message----- > > > From: Joon Maeng [SMTP:joon_maeng@VTEL.COM] > > > Sent: Saturday, March 04, 2000 6:56 PM > > > To: ITU-SG16(a)mailbag.cps.intel.com > > > Subject: Re: FYI - SIP-H.323 Interworking BOF > > > > > > Roy, you your are right. It is focused on the SIP and H.323 > > > interworking. > > > I attached the tentative agenda for the BOF. Depending on the > > > speakers we > > > identify, the agenda may inlcude some presenters but the main > > > focus > > > will not > > > be modified. > > > Regards, > > > Joon > > > > > > > ------------------------------------------------------------------------ > > > BOF: SIP and H.323 Interworking (sip323) > > > Area: Transport > > > Time requested: one 1 hour slot > > > Chairs: Joon Maeng <joon_maeng(a)vtel.com> > > > Dave Walker <drwalker(a)ss8networks.com> > > > > > > Description: > > > > > > There are two competing standards in the industry for > > establishing > > > and > > > managing real-time interactive media communications over IP. > > One > > > is > > > the > > > proposed IETF standard, Session Initiation Protocol (RFC > 2543), > > > and > > > the > > > other is the ITU recommendation, H.323. Although they use the > > > same > > > protocol (RTP) for media streaming, they cannot establish > calls > > > between > > > them. In the absence of any formal interoperability > standards, > > > many > > > vendors are beginning to develop proprietary application > > gateways > > > for > > > interworking between SIP and H.323. > > > > > > In order to provide interoperability between the two > standards, > > it > > > is > > > urgent to define a common interworking specifications for the > > > industry. > > > The recognition of the need for this interworking > specification > > > has > > > lead > > > to calls for its development from both manufacturers and > service > > > providers, individually and through industry consortia (such > as > > > IMTC) > > > and other bodies concerned with interoperability (such as > ETSI). > > > > > > In this BOF, we are going to discuss SIP and H.323 > interworking > > > issues, > > > execution plans and the scope of the work. > > > > > > Agenda: > > > > > > - Do we need SIP-H.323 interworking? > > > - Coordination with other groups? > > > - Scope of interworking > > > - Outcome of the work? > > > - Suggestions? > > > > > > Helpful reading: > > > - draft-singh-sip-h323-00.txt > > > - SIP: Session Initiation Protocol (RFC 2543) > > > - SDP: Session Description Protocol (RFC 2327) > > > - ITU recommendations: H.323, H.225.0, H.245 > > > > > > > -----Original Message----- > > > > From: Roy, Radhika R, ALARC [mailto:rrroy@att.com] > > > > Sent: Friday, March 03, 2000 3:12 PM > > > > To: ITU-SG16(a)mailbag.cps.intel.com > > > > Subject: Re: FYI - SIP-H.323 Interworking BOF > > > > > > > > > > > > Hi, Everyone: > > > > > > > > It appears that BOF is focused only on SIP-H.323 > Interworking > > > (not > > > > H.323-Internet Interworking as titled by Orit). I guess > that > > > > Joon and Dave > > > > will clarify this better. > > > > > > > > Best regards, > > > > Radhika R. Roy > > > > AT&T > > > > > > > > > -----Original Message----- > > > > > From: Orit Levin [SMTP:orit@radvision.com] > > > > > Sent: Friday, March 03, 2000 3:57 PM > > > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > > > Subject: Re: FYI - SIP-H.323 Interworking BOF > > > > > > > > > > Great! > > > > > I am attaching the revised so far TOR. Please, send your > > > comments. > > > > > Hope you will find it useful in Australia. > > > > > 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: Joon Maeng <joon_maeng(a)VTEL.COM> > > > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > <ITU-SG16(a)MAILBAG.INTEL.COM> > > > > > Date: Thursday, March 02, 2000 8:18 PM > > > > > Subject: FYI - SIP-H.323 Interworking BOF > > > > > > > > > > > > > > > >Hi folks. There will be a SIP-H.323 Interworking BOF at > > > > the IETF meeting > > > > > in > > > > > >Australia. Dave Walker with SS8 Networks and I will > chair > > > > the BOF. You > > > > > can > > > > > >find the agenda at > > > http://www.ietf.org/meetings/IETF-47.html when IETF > > > > posts > > > > >agendas. > > > > >Regards, > > > > >Joon << File: H323-Internet.zip >> > >

1 0

H.323 Mobility Contribution
by Roy, Radhika R, ALARC 08 Mar '00

08 Mar '00

Hi, Paul and Jaakko: With respect to our upcoming H.323 mobility conference call, I like to point out that I plan to discuss "Mobility Management" scenarios. The contribution related to this scenario can be found in "Section 6 - Mobility Management (Pages 32-41)" of AT&T Contribution - "D.354 (WP/2/16): H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility" provided in the last SG16 Feb'00 meeting held in Geneva. I would appreciate, if you would upload the document in the server. This contribution is available in the ITU-T SG16 Web site as well. (If time permits, I may re-write this as a stand-alone paper before the conference call. I am not sure whether I would be able to do this.) Best regards, Radhika R. Roy AT&T +1 732 420 1580 Tel rrroy(a)att.com

1 0

Re: FYI - SIP-H.323 Interworking BOF
by Sebestyen Istvan ICN M CS 27 08 Mar '00

08 Mar '00

Dear Colleagues, I don't want to hurt anybody,... but I understand that Martin Euchner is getting a bit inpatient, me too. It is really necessary that for an issue that has received in the last ITU-T SG16 meeting let me say a relatively modest support, now everybody on the SG16 Reflector has to "listen" the detailed discussion what should be done, why, where, when... etc. Would it not be possible that those individuals, who have an apparent interest in the SIP/H.323 interoperability topic discuss this first among themselves and the contributions get introduced only at the next SG16 meeting in May or at least when the contributions are finished? I hope on your understanding. Many 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: Roy, Radhika R, ALARC[SMTP:rrroy@ATT.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Wednesday, March 08, 2000 5:27 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: FYI - SIP-H.323 Interworking BOF > > Hi, Everyone: > > ITU-T and IETF are the formal standard bodies to create standards for > H.323 > and SIP, respectively, and the interworking standard between the two is > also > a part of it.. > > However, all inputs from other organizations will definitely be welcomed. > > Best regards, > Radhika R. Roy > AT&T > > > -----Original Message----- > > From: Euchner Martin [SMTP:Martin.Euchner@MCHP.SIEMENS.DE] > > Sent: Wednesday, March 08, 2000 4:16 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: FYI - SIP-H.323 Interworking BOF > > > > just for your information for those interested in H.323/SIP: > > > > I would like to draw your attention to an activity group already > debating > > H.323-SIP interworking for quite a while: IMTC aHIT!. To my knowledge > they > > already came out with some first results on architectures and > interworking > > scenarios. Please get in touch with this group and consider their > results. > > see also http://www.imtc.org/act_ahit.htm > > <http://www.imtc.org/act_ahit.htm> > > and discussions on their mailing list. > > > > Thus, it appears to me that there are already quite a few groups (IETF, > > IMTC, ETSI) discussing H323/SIP interworking. I do not quite see > necessity > > to have ITU-T SG16 as yet another group for this topic. > > > > regards > > > > Martin. > > > > ----------------------------------------------------------------------- > > | Dipl.-Inf. Phone: +49 89 636-46201 > > | Martin Euchner Fax : +49 89 636-48000 > > | Siemens AG > > | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de > > | mailto:martin.euchner@ties.itu.int > > | Otto-Hahn-Ring 6 Intranet: > > > http://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG1 > > 6/ > > index.html > > | D-81730 Muenchen Internet: http://www.siemens.de > > | __________________ > > | Germany > > ----------------------------------------------------------------------- > > > > > > -----Original Message----- > > From: Joon Maeng [SMTP:joon_maeng@VTEL.COM] > > Sent: Saturday, March 04, 2000 6:56 PM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: FYI - SIP-H.323 Interworking BOF > > > > Roy, you your are right. It is focused on the SIP and H.323 > > interworking. > > I attached the tentative agenda for the BOF. Depending on the > > speakers we > > identify, the agenda may inlcude some presenters but the main > > focus > > will not > > be modified. > > Regards, > > Joon > > > > ------------------------------------------------------------------------ > > BOF: SIP and H.323 Interworking (sip323) > > Area: Transport > > Time requested: one 1 hour slot > > Chairs: Joon Maeng <joon_maeng(a)vtel.com> > > Dave Walker <drwalker(a)ss8networks.com> > > > > Description: > > > > There are two competing standards in the industry for > establishing > > and > > managing real-time interactive media communications over IP. > One > > is > > the > > proposed IETF standard, Session Initiation Protocol (RFC 2543), > > and > > the > > other is the ITU recommendation, H.323. Although they use the > > same > > protocol (RTP) for media streaming, they cannot establish calls > > between > > them. In the absence of any formal interoperability standards, > > many > > vendors are beginning to develop proprietary application > gateways > > for > > interworking between SIP and H.323. > > > > In order to provide interoperability between the two standards, > it > > is > > urgent to define a common interworking specifications for the > > industry. > > The recognition of the need for this interworking specification > > has > > lead > > to calls for its development from both manufacturers and service > > providers, individually and through industry consortia (such as > > IMTC) > > and other bodies concerned with interoperability (such as ETSI). > > > > In this BOF, we are going to discuss SIP and H.323 interworking > > issues, > > execution plans and the scope of the work. > > > > Agenda: > > > > - Do we need SIP-H.323 interworking? > > - Coordination with other groups? > > - Scope of interworking > > - Outcome of the work? > > - Suggestions? > > > > Helpful reading: > > - draft-singh-sip-h323-00.txt > > - SIP: Session Initiation Protocol (RFC 2543) > > - SDP: Session Description Protocol (RFC 2327) > > - ITU recommendations: H.323, H.225.0, H.245 > > > > > -----Original Message----- > > > From: Roy, Radhika R, ALARC [mailto:rrroy@att.com] > > > Sent: Friday, March 03, 2000 3:12 PM > > > To: ITU-SG16(a)mailbag.cps.intel.com > > > Subject: Re: FYI - SIP-H.323 Interworking BOF > > > > > > > > > Hi, Everyone: > > > > > > It appears that BOF is focused only on SIP-H.323 Interworking > > (not > > > H.323-Internet Interworking as titled by Orit). I guess that > > > Joon and Dave > > > will clarify this better. > > > > > > Best regards, > > > Radhika R. Roy > > > AT&T > > > > > > > -----Original Message----- > > > > From: Orit Levin [SMTP:orit@radvision.com] > > > > Sent: Friday, March 03, 2000 3:57 PM > > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > > Subject: Re: FYI - SIP-H.323 Interworking BOF > > > > > > > > Great! > > > > I am attaching the revised so far TOR. Please, send your > > comments. > > > > Hope you will find it useful in Australia. > > > > 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: Joon Maeng <joon_maeng(a)VTEL.COM> > > > > To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> > > > > Date: Thursday, March 02, 2000 8:18 PM > > > > Subject: FYI - SIP-H.323 Interworking BOF > > > > > > > > > > > > >Hi folks. There will be a SIP-H.323 Interworking BOF at > > > the IETF meeting > > > > in > > > > >Australia. Dave Walker with SS8 Networks and I will chair > > > the BOF. You > > > > can > > > > >find the agenda at > > http://www.ietf.org/meetings/IETF-47.html when IETF > > > posts > > > >agendas. > > > >Regards, > > > >Joon << File: H323-Internet.zip >> >

1 0

Re: [sip-h323] Re: H323/SIP Interworking - way forward
by Roy, Radhika R, ALARC 08 Mar '00

08 Mar '00

Hi, David and Orit: David has a raised an interesting point. I guess that we can start with an interworking GW approach first: SIP Network and H.323 Network. Replacing GK and SIP server with a super server is an interesting idea. One way of looking into it may be that the supper server contains the properties of the SIP-H.323 interworking GW. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Wang, Dave [SMTP:dwang@NUERA.COM] > Sent: Tuesday, March 07, 2000 6:28 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [sip-h323] Re: H323/SIP Interworking - way forward > > Hi Orit, > > To support and extend existing install base, let say an existing H.323 > network, with working GW and GK, how would we add this super-Server ? > Would > we need to remove existing GK first ? > > In cases that we want to connect a working H.323 network with a working > SIP > network operated by two separate administrations, not sure how to replace > both GK and SIP Server with a single super-Server ? > > David > > > -----Original Message----- > > From: Orit Levin [mailto:orit@radvision.com] > > Sent: Tuesday, March 07, 2000 12:25 PM > > To: sip-h323(a)egroups.com; ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: [sip-h323] Re: H323/SIP Interworking - way forward > > > > > > Hello folks! > > Scoping our work in terms of scenarios... > > There are a lot of possible topologies that we would like to > > address. It > > will be difficult to prioritize among them because it depends on each > > company niche. I think that an exercise, done by the authors of > > "Interworking Between SIP/SDP and H.323" Internet Draft, is a > > great example > > for this statement. In all cases it would involve Gatekeeper/Proxy and > > Gateway of some kind, as either logical or physical entities. > > > > In my opinion, the first requirement for our work should be > > defined as: "the > > end devices should be interoperable regardless of signaling > > protocol they > > support". The fastest way to address this requirement is to cover the > > topology where the end users are connected to a super-Server > > supporting > > both H.323 and SIP and solving the IWF as an internal logic (including > > address translation). The outcome of this work should be the > > recognition of > > protocols' details or/and features preventing from transparent (to the > > users) interworking. Then we can either profile further or, > > alternatively, > > feed the new requirements into the protocols. > > > > It is, by no means, prevents us from discussion about more complicated > > topologies. Nevertheless, without solving the simplest case, > > it is hard to > > get focused. > > My two cents, > > 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: Kundan Singh <kns10(a)cs.columbia.edu> > > To: 'sip-h323(a)egroups.com' <sip-h323(a)egroups.com> > > Date: Tuesday, March 07, 2000 10:51 AM > > Subject: [sip-h323] Re: H323/SIP Interworking - way forward > > > > > > > > > >> Hi Paul, > > >> > > >> Thanks for the understanding. I like your ideas very much > > and would love > > to > > >> limit my implementation to just this five. How about we > > all bounce this > > with > > >> other contacts of ours and see how long this can hold up. > > >> > > >> My one remainimg question, in regards to the trivial cases > > that we ruled > > out > > >> early on that doesn't involve any IWF : how does we know > > a-prior that we > > >> don't need, or need, the IWF ? Therefore, from a end-to-end service > > >> prespective, i.e. above the protocol conversion, we would > > still need to > > have > > >> a way to identify when IWF is needed. > > > > > >This functionality may be provided by the registration servers > > >(e.g., SIP registrars and H.323 gatekeepers) present in the > > >network. Ideally, one H.323 gatekeeper with SIP/H323 IWF > > >listening at the gatekeepers multicast address can resolve > > >all address requests originated from H.323 network and > > >destined for a SIP entity. So an H.323 entity just need to > > >send LRQ to the gatekeeper's welknown multicast address > > without knowing > > >whether the destination is in SIP or H.323 network. > > >GK/IWF will capture the message find out if the > > >destination is reachable in SIP network (e.g., using SIP > > >OPTIONS message). > > > > > >In the other direction, its simple. Since the GK is equipped with > > >IWF (SIP/H323 translation) it can forward all H.323 registrations to > > >the SIP server. So, the H323 entities can be reached through that > > >particular SIP server. > > > > > >Likewise, SR/IWF may also be used to provide transparent > > >address resolution. > > > > > >However, it would be nice if the IWF is not part of > > >a regitration server and, still, can resolve the address. > > > > > >Regards > > > > > >Kundan > > > > > > > > > > > > > > > > > > > > > > > >------------------------------------------------------------- > > ----------- > > >To Post a message, send it to: sip-h323(a)eGroups.com > > >To Unsubscribe, send a blank message to: > > sip-h323-unsubscribe(a)eGroups.com > > > > > >------------------------------------------------------------- > > ----------- > > >DON'T HATE YOUR RATE! > > >Get a NextCard Visa, in 30 seconds! Get rates as low as > > >0.0% Intro or 9.9% Fixed APR and no hidden fees. > > >Apply NOW! > > >http://click.egroups.com/1/2065/2/_/302437/_/952444292/ > > > > > >eGroups.com Home: http://www.egroups.com/group/sip-h323/ > > >http://www.egroups.com - Simplifying group communications > > > > > > > > > > > > -------------------------------------------------------------- > > ---------- > > To Post a message, send it to: sip-h323(a)eGroups.com > > To Unsubscribe, send a blank message to: > > sip-h323-unsubscribe(a)eGroups.com > > > > -------------------------------------------------------------- > > ---------- > > Planning a party? iParty.com is your complete source for > > party planning and > > supplies, with everything you need to throw the perfect party! > > http://click.egroups.com/1/1635/2/_/302437/_/952460660/ > > > > -- Check out your group's private Chat room > > -- http://www.egroups.com/ChatPage?listName=sip-h323&m=1 > > > >

1 0

RE: SIP-H.323 Interworking Call Scenarios
by Roy, Radhika R, ALARC 08 Mar '00

08 Mar '00

Hemant, Vipin, I feel encouraged to explore these basic features proposed by you for H.323-SIP interworking. I would suggest other members to provide their comments as well. Best regards, Radhika R. Roy AT&T +1 732 420 1580 Tel rrroy(a)att.com > -----Original Message----- > From: Hemant Agrawal [SMTP:hemantag@graffiti.net] > Sent: Wednesday, March 08, 2000 8:08 AM > To: schulzrinne(a)cs.columbia.edu; jdrosen(a)dynamicsoft.com; > kns10(a)cs.columbia.edu; korpim(a)sbs.de; karl.klaghofer(a)vs.siemens.de; Roy, > Radhika R, ALARC; alan.johnston(a)wcom.com; steven.r.donovan(a)wcom.com; > Kevin.Summers(a)wcom.com; dean.willis(a)wcom.com; henry.sinnreich(a)wcom.com; > VIPIN PALAWAT; agboh(a)helios.iihe.ac.be; Robert.Sparks(a)wcom.com > Cc: Chris.Cunningham(a)wcom.com; orit(a)radvision.com; > taylor(a)NORTELNETWORKS.COM; joon_maeng(a)vtel.com; drwalker(a)ss8networks.com; > paul.jones(a)TIES.ITU.INT; Dilber, Ayse, ALARC; stephen.terrill(a)ericsson.com > Subject: SIP-H.323 Interworking Call Scenarios > > Hi All, > There was a continuous discussion on the different configuration for the > SIP - H.323 interworking. > > In our opinion, it would be better if some basic features (like Call > Transfer, Call Hold and Call forwarding) is also added as part of the > discussion. > > We are enclosing some call flow examples of SIP-H.323 interworking. Please > give your comments on these call flows. Our stress is on the call features > and others are just informational. We have specified few issues also > inorder > to make these protocols interwork. > > Kindly let us know if you agree to include the feature discussion also as > part of the SIP - H.323 interworking. We are ready to put our efforts for > the feature interworking. > > Best Regards > > Hemant Agarwal > Vipin Palawat > > << File: SIP-H.323 Call Examples.txt >>

1 0

SIP-H.323 Interworking Call Scenarios
by Hemant Agrawal 08 Mar '00

08 Mar '00

Hi All, There was a continuous discussion on the different configuration for the SIP - H.323 interworking. In our opinion, it would be better if some basic features (like Call Transfer, Call Hold and Call forwarding) is also added as part of the discussion. We are enclosing some call flow examples of SIP-H.323 interworking. Please give your comments on these call flows. Our stress is on the call features and others are just informational. We have specified few issues also inorder to make these protocols interwork. Kindly let us know if you agree to include the feature discussion also as part of the SIP - H.323 interworking. We are ready to put our efforts for the feature interworking. Best Regards Hemant Agarwal Vipin Palawat

1 0

Re: FYI - SIP-H.323 Interworking BOF
by Euchner Martin 08 Mar '00

08 Mar '00

just for your information for those interested in H.323/SIP: I would like to draw your attention to an activity group already debating H.323-SIP interworking for quite a while: IMTC aHIT!. To my knowledge they already came out with some first results on architectures and interworking scenarios. Please get in touch with this group and consider their results. see also http://www.imtc.org/act_ahit.htm <http://www.imtc.org/act_ahit.htm> and discussions on their mailing list. Thus, it appears to me that there are already quite a few groups (IETF, IMTC, ETSI) discussing H323/SIP interworking. I do not quite see necessity to have ITU-T SG16 as yet another group for this topic. regards Martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | mailto:martin.euchner@ties.itu.int | Otto-Hahn-Ring 6 Intranet: http://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG16/ index.html | D-81730 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Joon Maeng [SMTP:joon_maeng@VTEL.COM] Sent: Saturday, March 04, 2000 6:56 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: FYI - SIP-H.323 Interworking BOF Roy, you your are right. It is focused on the SIP and H.323 interworking. I attached the tentative agenda for the BOF. Depending on the speakers we identify, the agenda may inlcude some presenters but the main focus will not be modified. Regards, Joon ------------------------------------------------------------------------ BOF: SIP and H.323 Interworking (sip323) Area: Transport Time requested: one 1 hour slot Chairs: Joon Maeng <joon_maeng(a)vtel.com> Dave Walker <drwalker(a)ss8networks.com> Description: There are two competing standards in the industry for establishing and managing real-time interactive media communications over IP. One is the proposed IETF standard, Session Initiation Protocol (RFC 2543), and the other is the ITU recommendation, H.323. Although they use the same protocol (RTP) for media streaming, they cannot establish calls between them. In the absence of any formal interoperability standards, many vendors are beginning to develop proprietary application gateways for interworking between SIP and H.323. In order to provide interoperability between the two standards, it is urgent to define a common interworking specifications for the industry. The recognition of the need for this interworking specification has lead to calls for its development from both manufacturers and service providers, individually and through industry consortia (such as IMTC) and other bodies concerned with interoperability (such as ETSI). In this BOF, we are going to discuss SIP and H.323 interworking issues, execution plans and the scope of the work. Agenda: - Do we need SIP-H.323 interworking? - Coordination with other groups? - Scope of interworking - Outcome of the work? - Suggestions? Helpful reading: - draft-singh-sip-h323-00.txt - SIP: Session Initiation Protocol (RFC 2543) - SDP: Session Description Protocol (RFC 2327) - ITU recommendations: H.323, H.225.0, H.245 > -----Original Message----- > From: Roy, Radhika R, ALARC [mailto:rrroy@att.com] > Sent: Friday, March 03, 2000 3:12 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: FYI - SIP-H.323 Interworking BOF > > > Hi, Everyone: > > It appears that BOF is focused only on SIP-H.323 Interworking (not > H.323-Internet Interworking as titled by Orit). I guess that > Joon and Dave > will clarify this better. > > Best regards, > Radhika R. Roy > AT&T > > > -----Original Message----- > > From: Orit Levin [SMTP:orit@radvision.com] > > Sent: Friday, March 03, 2000 3:57 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: FYI - SIP-H.323 Interworking BOF > > > > Great! > > I am attaching the revised so far TOR. Please, send your comments. > > Hope you will find it useful in Australia. > > 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: Joon Maeng <joon_maeng(a)VTEL.COM> > > To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> > > Date: Thursday, March 02, 2000 8:18 PM > > Subject: FYI - SIP-H.323 Interworking BOF > > > > > > >Hi folks. There will be a SIP-H.323 Interworking BOF at > the IETF meeting > > in > > >Australia. Dave Walker with SS8 Networks and I will chair > the BOF. You > > can > > >find the agenda at http://www.ietf.org/meetings/IETF-47.html when IETF > posts > >agendas. > >Regards, > >Joon << File: H323-Internet.zip >>

1 0

Re: [sip-h323] Re: H323/SIP Interworking - way forward
by Tom-PT Taylor 07 Mar '00

07 Mar '00

We're talking software here, not boxes. It seems fairly clear to me that the usual rule for signalling interworking applies: it has to be done somewhere, and the choice of where depends on the particular context. Back to my first point: in the first case, you have to add SIP<=>H.323 interworking software at one or more GW. In the second case, the GK will interact with SIP second-line components (registration servers, redirect servers, etc.) via TRIP or Annex G, depending whose border elements speak the other network's language. Call signalling interworking still has to happen at the GW level, by definition. > -----Original Message----- > From: Wang, Dave [SMTP:dwang@NUERA.COM] > Sent: Tuesday, March 07, 2000 6:28 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [sip-h323] Re: H323/SIP Interworking - way forward > > Hi Orit, > > To support and extend existing install base, let say an existing H.323 > network, with working GW and GK, how would we add this super-Server ? > Would > we need to remove existing GK first ? > > In cases that we want to connect a working H.323 network with a working > SIP > network operated by two separate administrations, not sure how to replace > both GK and SIP Server with a single super-Server ? > > David > > > -----Original Message----- > > From: Orit Levin [mailto:orit@radvision.com] > > Sent: Tuesday, March 07, 2000 12:25 PM > > To: sip-h323(a)egroups.com; ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: [sip-h323] Re: H323/SIP Interworking - way forward > > > > > > Hello folks! > > Scoping our work in terms of scenarios... > > There are a lot of possible topologies that we would like to > > address. It > > will be difficult to prioritize among them because it depends on each > > company niche. I think that an exercise, done by the authors of > > "Interworking Between SIP/SDP and H.323" Internet Draft, is a > > great example > > for this statement. In all cases it would involve Gatekeeper/Proxy and > > Gateway of some kind, as either logical or physical entities. > > > > In my opinion, the first requirement for our work should be > > defined as: "the > > end devices should be interoperable regardless of signaling > > protocol they > > support". The fastest way to address this requirement is to cover the > > topology where the end users are connected to a super-Server > > supporting > > both H.323 and SIP and solving the IWF as an internal logic (including > > address translation). The outcome of this work should be the > > recognition of > > protocols' details or/and features preventing from transparent (to the > > users) interworking. Then we can either profile further or, > > alternatively, > > feed the new requirements into the protocols. > > > > It is, by no means, prevents us from discussion about more complicated > > topologies. Nevertheless, without solving the simplest case, > > it is hard to > > get focused. > > My two cents, > > 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: Kundan Singh <kns10(a)cs.columbia.edu> > > To: 'sip-h323(a)egroups.com' <sip-h323(a)egroups.com> > > Date: Tuesday, March 07, 2000 10:51 AM > > Subject: [sip-h323] Re: H323/SIP Interworking - way forward > > > > > > > > > >> Hi Paul, > > >> > > >> Thanks for the understanding. I like your ideas very much > > and would love > > to > > >> limit my implementation to just this five. How about we > > all bounce this > > with > > >> other contacts of ours and see how long this can hold up. > > >> > > >> My one remainimg question, in regards to the trivial cases > > that we ruled > > out > > >> early on that doesn't involve any IWF : how does we know > > a-prior that we > > >> don't need, or need, the IWF ? Therefore, from a end-to-end service > > >> prespective, i.e. above the protocol conversion, we would > > still need to > > have > > >> a way to identify when IWF is needed. > > > > > >This functionality may be provided by the registration servers > > >(e.g., SIP registrars and H.323 gatekeepers) present in the > > >network. Ideally, one H.323 gatekeeper with SIP/H323 IWF > > >listening at the gatekeepers multicast address can resolve > > >all address requests originated from H.323 network and > > >destined for a SIP entity. So an H.323 entity just need to > > >send LRQ to the gatekeeper's welknown multicast address > > without knowing > > >whether the destination is in SIP or H.323 network. > > >GK/IWF will capture the message find out if the > > >destination is reachable in SIP network (e.g., using SIP > > >OPTIONS message). > > > > > >In the other direction, its simple. Since the GK is equipped with > > >IWF (SIP/H323 translation) it can forward all H.323 registrations to > > >the SIP server. So, the H323 entities can be reached through that > > >particular SIP server. > > > > > >Likewise, SR/IWF may also be used to provide transparent > > >address resolution. > > > > > >However, it would be nice if the IWF is not part of > > >a regitration server and, still, can resolve the address. > > > > > >Regards > > > > > >Kundan > > > > > > > > > > > > > > > > > > > > > > > >------------------------------------------------------------- > > ----------- > > >To Post a message, send it to: sip-h323(a)eGroups.com > > >To Unsubscribe, send a blank message to: > > sip-h323-unsubscribe(a)eGroups.com > > > > > >------------------------------------------------------------- > > ----------- > > >DON'T HATE YOUR RATE! > > >Get a NextCard Visa, in 30 seconds! Get rates as low as > > >0.0% Intro or 9.9% Fixed APR and no hidden fees. > > >Apply NOW! > > >http://click.egroups.com/1/2065/2/_/302437/_/952444292/ > > > > > >eGroups.com Home: http://www.egroups.com/group/sip-h323/ > > >http://www.egroups.com - Simplifying group communications > > > > > > > > > > > > -------------------------------------------------------------- > > ---------- > > To Post a message, send it to: sip-h323(a)eGroups.com > > To Unsubscribe, send a blank message to: > > sip-h323-unsubscribe(a)eGroups.com > > > > -------------------------------------------------------------- > > ---------- > > Planning a party? iParty.com is your complete source for > > party planning and > > supplies, with everything you need to throw the perfect party! > > http://click.egroups.com/1/1635/2/_/302437/_/952460660/ > > > > -- Check out your group's private Chat room > > -- http://www.egroups.com/ChatPage?listName=sip-h323&m=1 > > > >

1 0

Re: [sip-h323] Re: H323/SIP Interworking - way forward
by Wang, Dave 07 Mar '00

07 Mar '00

Hi Orit, To support and extend existing install base, let say an existing H.323 network, with working GW and GK, how would we add this super-Server ? Would we need to remove existing GK first ? In cases that we want to connect a working H.323 network with a working SIP network operated by two separate administrations, not sure how to replace both GK and SIP Server with a single super-Server ? David > -----Original Message----- > From: Orit Levin [mailto:orit@radvision.com] > Sent: Tuesday, March 07, 2000 12:25 PM > To: sip-h323(a)egroups.com; ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [sip-h323] Re: H323/SIP Interworking - way forward > > > Hello folks! > Scoping our work in terms of scenarios... > There are a lot of possible topologies that we would like to > address. It > will be difficult to prioritize among them because it depends on each > company niche. I think that an exercise, done by the authors of > "Interworking Between SIP/SDP and H.323" Internet Draft, is a > great example > for this statement. In all cases it would involve Gatekeeper/Proxy and > Gateway of some kind, as either logical or physical entities. > > In my opinion, the first requirement for our work should be > defined as: "the > end devices should be interoperable regardless of signaling > protocol they > support". The fastest way to address this requirement is to cover the > topology where the end users are connected to a super-Server > supporting > both H.323 and SIP and solving the IWF as an internal logic (including > address translation). The outcome of this work should be the > recognition of > protocols' details or/and features preventing from transparent (to the > users) interworking. Then we can either profile further or, > alternatively, > feed the new requirements into the protocols. > > It is, by no means, prevents us from discussion about more complicated > topologies. Nevertheless, without solving the simplest case, > it is hard to > get focused. > My two cents, > 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: Kundan Singh <kns10(a)cs.columbia.edu> > To: 'sip-h323(a)egroups.com' <sip-h323(a)egroups.com> > Date: Tuesday, March 07, 2000 10:51 AM > Subject: [sip-h323] Re: H323/SIP Interworking - way forward > > > > > >> Hi Paul, > >> > >> Thanks for the understanding. I like your ideas very much > and would love > to > >> limit my implementation to just this five. How about we > all bounce this > with > >> other contacts of ours and see how long this can hold up. > >> > >> My one remainimg question, in regards to the trivial cases > that we ruled > out > >> early on that doesn't involve any IWF : how does we know > a-prior that we > >> don't need, or need, the IWF ? Therefore, from a end-to-end service > >> prespective, i.e. above the protocol conversion, we would > still need to > have > >> a way to identify when IWF is needed. > > > >This functionality may be provided by the registration servers > >(e.g., SIP registrars and H.323 gatekeepers) present in the > >network. Ideally, one H.323 gatekeeper with SIP/H323 IWF > >listening at the gatekeepers multicast address can resolve > >all address requests originated from H.323 network and > >destined for a SIP entity. So an H.323 entity just need to > >send LRQ to the gatekeeper's welknown multicast address > without knowing > >whether the destination is in SIP or H.323 network. > >GK/IWF will capture the message find out if the > >destination is reachable in SIP network (e.g., using SIP > >OPTIONS message). > > > >In the other direction, its simple. Since the GK is equipped with > >IWF (SIP/H323 translation) it can forward all H.323 registrations to > >the SIP server. So, the H323 entities can be reached through that > >particular SIP server. > > > >Likewise, SR/IWF may also be used to provide transparent > >address resolution. > > > >However, it would be nice if the IWF is not part of > >a regitration server and, still, can resolve the address. > > > >Regards > > > >Kundan > > > > > > > > > > > > > > > >------------------------------------------------------------- > ----------- > >To Post a message, send it to: sip-h323(a)eGroups.com > >To Unsubscribe, send a blank message to: > sip-h323-unsubscribe(a)eGroups.com > > > >------------------------------------------------------------- > ----------- > >DON'T HATE YOUR RATE! > >Get a NextCard Visa, in 30 seconds! Get rates as low as > >0.0% Intro or 9.9% Fixed APR and no hidden fees. > >Apply NOW! > >http://click.egroups.com/1/2065/2/_/302437/_/952444292/ > > > >eGroups.com Home: http://www.egroups.com/group/sip-h323/ > >http://www.egroups.com - Simplifying group communications > > > > > > > -------------------------------------------------------------- > ---------- > To Post a message, send it to: sip-h323(a)eGroups.com > To Unsubscribe, send a blank message to: > sip-h323-unsubscribe(a)eGroups.com > > -------------------------------------------------------------- > ---------- > Planning a party? iParty.com is your complete source for > party planning and > supplies, with everything you need to throw the perfect party! > http://click.egroups.com/1/1635/2/_/302437/_/952460660/ > > -- Check out your group's private Chat room > -- http://www.egroups.com/ChatPage?listName=sip-h323&m=1 > >

1 0

Re: [sip-h323] Re: H323/SIP Interworking - way forward
by Roy, Radhika R, ALARC 07 Mar '00

07 Mar '00

Hi, Orit: I support your proposal and it can be the starting point: "Interworking Between SIP/SDP and H.323" Once we start our work based on this, we can really address all other work items as appropriate. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Orit Levin [SMTP:orit@radvision.com] > Sent: Tuesday, March 07, 2000 3:25 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [sip-h323] Re: H323/SIP Interworking - way forward > > Hello folks! > Scoping our work in terms of scenarios... > There are a lot of possible topologies that we would like to address. It > will be difficult to prioritize among them because it depends on each > company niche. I think that an exercise, done by the authors of > "Interworking Between SIP/SDP and H.323" Internet Draft, is a great > example > for this statement. In all cases it would involve Gatekeeper/Proxy and > Gateway of some kind, as either logical or physical entities. > > In my opinion, the first requirement for our work should be defined as: > "the > end devices should be interoperable regardless of signaling protocol they > support". The fastest way to address this requirement is to cover the > topology where the end users are connected to a super-Server supporting > both H.323 and SIP and solving the IWF as an internal logic (including > address translation). The outcome of this work should be the recognition > of > protocols' details or/and features preventing from transparent (to the > users) interworking. Then we can either profile further or, alternatively, > feed the new requirements into the protocols. > > It is, by no means, prevents us from discussion about more complicated > topologies. Nevertheless, without solving the simplest case, it is hard to > get focused. > My two cents, > 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: Kundan Singh <kns10(a)cs.columbia.edu> > To: 'sip-h323(a)egroups.com' <sip-h323(a)egroups.com> > Date: Tuesday, March 07, 2000 10:51 AM > Subject: [sip-h323] Re: H323/SIP Interworking - way forward > > > > > >> Hi Paul, > >> > >> Thanks for the understanding. I like your ideas very much and would > love > to > >> limit my implementation to just this five. How about we all bounce this > with > >> other contacts of ours and see how long this can hold up. > >> > >> My one remainimg question, in regards to the trivial cases that we > ruled > out > >> early on that doesn't involve any IWF : how does we know a-prior that > we > >> don't need, or need, the IWF ? Therefore, from a end-to-end service > >> prespective, i.e. above the protocol conversion, we would still need to > have > >> a way to identify when IWF is needed. > > > >This functionality may be provided by the registration servers > >(e.g., SIP registrars and H.323 gatekeepers) present in the > >network. Ideally, one H.323 gatekeeper with SIP/H323 IWF > >listening at the gatekeepers multicast address can resolve > >all address requests originated from H.323 network and > >destined for a SIP entity. So an H.323 entity just need to > >send LRQ to the gatekeeper's welknown multicast address without knowing > >whether the destination is in SIP or H.323 network. > >GK/IWF will capture the message find out if the > >destination is reachable in SIP network (e.g., using SIP > >OPTIONS message). > > > >In the other direction, its simple. Since the GK is equipped with > >IWF (SIP/H323 translation) it can forward all H.323 registrations to > >the SIP server. So, the H323 entities can be reached through that > >particular SIP server. > > > >Likewise, SR/IWF may also be used to provide transparent > >address resolution. > > > >However, it would be nice if the IWF is not part of > >a regitration server and, still, can resolve the address. > > > >Regards > > > >Kundan > > > > > > > > > > > > > > > >------------------------------------------------------------------------ > >To Post a message, send it to: sip-h323(a)eGroups.com > >To Unsubscribe, send a blank message to: sip-h323-unsubscribe(a)eGroups.com > > > >------------------------------------------------------------------------ > >DON'T HATE YOUR RATE! > >Get a NextCard Visa, in 30 seconds! Get rates as low as > >0.0% Intro or 9.9% Fixed APR and no hidden fees. > >Apply NOW! > >http://click.egroups.com/1/2065/2/_/302437/_/952444292/ > > > >eGroups.com Home: http://www.egroups.com/group/sip-h323/ > >http://www.egroups.com - Simplifying group communications > > > >

1 0

Re: [sip-h323] Re: H323/SIP Interworking - way forward
by Orit Levin 07 Mar '00

07 Mar '00

Hello folks! Scoping our work in terms of scenarios... There are a lot of possible topologies that we would like to address. It will be difficult to prioritize among them because it depends on each company niche. I think that an exercise, done by the authors of "Interworking Between SIP/SDP and H.323" Internet Draft, is a great example for this statement. In all cases it would involve Gatekeeper/Proxy and Gateway of some kind, as either logical or physical entities. In my opinion, the first requirement for our work should be defined as: "the end devices should be interoperable regardless of signaling protocol they support". The fastest way to address this requirement is to cover the topology where the end users are connected to a super-Server supporting both H.323 and SIP and solving the IWF as an internal logic (including address translation). The outcome of this work should be the recognition of protocols' details or/and features preventing from transparent (to the users) interworking. Then we can either profile further or, alternatively, feed the new requirements into the protocols. It is, by no means, prevents us from discussion about more complicated topologies. Nevertheless, without solving the simplest case, it is hard to get focused. My two cents, 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: Kundan Singh <kns10(a)cs.columbia.edu> To: 'sip-h323(a)egroups.com' <sip-h323(a)egroups.com> Date: Tuesday, March 07, 2000 10:51 AM Subject: [sip-h323] Re: H323/SIP Interworking - way forward > >> Hi Paul, >> >> Thanks for the understanding. I like your ideas very much and would love to >> limit my implementation to just this five. How about we all bounce this with >> other contacts of ours and see how long this can hold up. >> >> My one remainimg question, in regards to the trivial cases that we ruled out >> early on that doesn't involve any IWF : how does we know a-prior that we >> don't need, or need, the IWF ? Therefore, from a end-to-end service >> prespective, i.e. above the protocol conversion, we would still need to have >> a way to identify when IWF is needed. > >This functionality may be provided by the registration servers >(e.g., SIP registrars and H.323 gatekeepers) present in the >network. Ideally, one H.323 gatekeeper with SIP/H323 IWF >listening at the gatekeepers multicast address can resolve >all address requests originated from H.323 network and >destined for a SIP entity. So an H.323 entity just need to >send LRQ to the gatekeeper's welknown multicast address without knowing >whether the destination is in SIP or H.323 network. >GK/IWF will capture the message find out if the >destination is reachable in SIP network (e.g., using SIP >OPTIONS message). > >In the other direction, its simple. Since the GK is equipped with >IWF (SIP/H323 translation) it can forward all H.323 registrations to >the SIP server. So, the H323 entities can be reached through that >particular SIP server. > >Likewise, SR/IWF may also be used to provide transparent >address resolution. > >However, it would be nice if the IWF is not part of >a regitration server and, still, can resolve the address. > >Regards > >Kundan > > > > > > > >------------------------------------------------------------------------ >To Post a message, send it to: sip-h323(a)eGroups.com >To Unsubscribe, send a blank message to: sip-h323-unsubscribe(a)eGroups.com > >------------------------------------------------------------------------ >DON'T HATE YOUR RATE! >Get a NextCard Visa, in 30 seconds! Get rates as low as >0.0% Intro or 9.9% Fixed APR and no hidden fees. >Apply NOW! >http://click.egroups.com/1/2065/2/_/302437/_/952444292/ > >eGroups.com Home: http://www.egroups.com/group/sip-h323/ >http://www.egroups.com - Simplifying group communications > >

1 0

[Fwd: Summary Of Errors Found In Megaco/H.248 Protocol Document]
by Glen Freundlich 07 Mar '00

07 Mar '00

1 0

Re: proposal for SIP as single call control protocol in 3GPP
by Callaghan, Robert 06 Mar '00

06 Mar '00

It should be noted that an important phase is contained in this document. It states that SIP is "position SIP as an ideal protocol to modify and enhance to meet the R2000 requirements." This can be translated into "We want our own protocol based in SIP." It will be interest to see if the results are fully compatible with RFC 2546 (SIP). 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: Michaely, Boaz [mailto:Boaz_Michaely@ICOMVERSE.COM] Sent: Monday, March 06, 2000 2:54 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: proposal for SIP as single call control protocol in 3GPP All, This proposal comes from: AT&T, BT, Japan Telecom, Lucent, Nokia, Nortel, Rogers Wireless, T-Mobil, Telenor, Telia. For those who are unaware, Release 2000 is conceived as THE most important activity regarding the future of VoIP in the sense that in a few short years wireless will become the dominant way of communication (more than wireline). 3GPP now discusses "Release 2000" which is the architecture for that future mobile network, where everything is over IP, including the media. This material is for discussion in Tokyo, March 6-9. Thought you should know, Boaz Boaz Michaely Senior System Architect, Corporate Comverse Network Systems Tel: +972 (3) 766-3844 , Mobile +972 (50) 39-30-17 http://people.itu.int/~michaely mailto:boaz_michaely@comverse.com > -----Original Message----- > From: Lobley,NC,Nigel,NZCA R [mailto:nigel.lobley@BT.COM] > Sent: Friday, March 03, 2000 1:40 PM > To: 3GPP_TSG_SA_WG2(a)LIST.ETSI.FR > Subject: Inputs from BT and a number of companies > > > Dear all > > Please find attached a couple of papers for S2 next week. > > See you in Japan > > Nigel >

1 0

proposal for SIP as single call control protocol in 3GPP
by Michaely, Boaz 06 Mar '00

06 Mar '00

All, This proposal comes from: AT&T, BT, Japan Telecom, Lucent, Nokia, Nortel, Rogers Wireless, T-Mobil, Telenor, Telia. For those who are unaware, Release 2000 is conceived as THE most important activity regarding the future of VoIP in the sense that in a few short years wireless will become the dominant way of communication (more than wireline). 3GPP now discusses "Release 2000" which is the architecture for that future mobile network, where everything is over IP, including the media. This material is for discussion in Tokyo, March 6-9. Thought you should know, Boaz Boaz Michaely Senior System Architect, Corporate Comverse Network Systems Tel: +972 (3) 766-3844 , Mobile +972 (50) 39-30-17 http://people.itu.int/~michaely mailto:boaz_michaely@comverse.com > -----Original Message----- > From: Lobley,NC,Nigel,NZCA R [mailto:nigel.lobley@BT.COM] > Sent: Friday, March 03, 2000 1:40 PM > To: 3GPP_TSG_SA_WG2(a)LIST.ETSI.FR > Subject: Inputs from BT and a number of companies > > > Dear all > > Please find attached a couple of papers for S2 next week. > > See you in Japan > > Nigel >

1 0

FW: Please upload the decided/determined/approved texts
by Mike Buckley 06 Mar '00

06 Mar '00

I have uploaded TD126rev1 (WP2) from the last meeting which contains the draft text of the new Annex N (QoS) of H.323. Mike Buckley (editor) ____________________ Begin Forwarded Message __________________________ Date: Sat Feb 19 02:34:29 +0900 2000 From: internet!TIES.ITU.INT!sakae.okubo (Sakae OKUBO) Subject: Please upload the decided/determined/approved texts To: internet!MAILBAG.INTEL.COM!ITU-SG16 Content-Type: Text Content-Length: 703 Dear Editors, Could you please upload your documents of decision, determination or approval at the /Incoming of the PictureTel ftp site? Please make an announce through the reflector when you have uploaded your documents. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

2 1

Re: H.225 Annex G
by Michael Fortinsky 05 Mar '00

05 Mar '00

Hi Greg, H.225.0 Annex G provides more than just address resolution. A short list of the functionality Annex G supports includes: - support for different interdomain architectures (e.g., hierarchical, peer-to-peer, clearing house) - service relationships between domain (the interdomain security mechanisms are negotiated at the level of service relationships) - static and dynamic provisioning of address information - address resolution - usage information exchange - authorization of calls Regarding your question about usage information, see the descriptions of the UsageSpec (1.8.2.4.5) and Pricing Information (1.8.2.3.2) structures, and the UsageRequest (1.8.2.25) and UsageIndication (1.8.2.28) messages (and the related confirmation and rejection messages) for more information. Michael Fortinsky ----------------------------------------------------------------- Senior Program Manager, IP Telephony Group, VocalTec Communications Ltd. Email: mike(a)vocaltec.com Tel: 972 9 9707768 Fax: 972 9 9561867 Greg Herlein <gherlein(a)HERLEIN.COM> on 03/03/2000 03:39:00 PM Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> To: ITU-SG16(a)mailbag.cps.intel.com cc: (bcc: Michael Fortinsky) Subject: H.225 Annex G H.225 Annex G does not seem to have any meat - is it *just* a border information exchange mechanism, or is it intended to provide EDI the way OSP does (ie, exchanging usage information)? >From my review, this annex looks like it does not provide any AAA functionality between administrative domains... though it does discuss address resolution. I'm looking at: http://standard.pictel.com/ftp/avc-site/9905_San/H.225.0_Annex_G_990528.zip Am I missing something, or is that all Annex G is supposed to do? Greg /************************************************************** Greg Herlein gherlein(a)herlein.com ***************************************************************/

1 0

Re: FYI - SIP-H.323 Interworking BOF
by Joon Maeng 04 Mar '00

04 Mar '00

Roy, you your are right. It is focused on the SIP and H.323 interworking. I attached the tentative agenda for the BOF. Depending on the speakers we identify, the agenda may inlcude some presenters but the main focus will not be modified. Regards, Joon ------------------------------------------------------------------------ BOF: SIP and H.323 Interworking (sip323) Area: Transport Time requested: one 1 hour slot Chairs: Joon Maeng <joon_maeng(a)vtel.com> Dave Walker <drwalker(a)ss8networks.com> Description: There are two competing standards in the industry for establishing and managing real-time interactive media communications over IP. One is the proposed IETF standard, Session Initiation Protocol (RFC 2543), and the other is the ITU recommendation, H.323. Although they use the same protocol (RTP) for media streaming, they cannot establish calls between them. In the absence of any formal interoperability standards, many vendors are beginning to develop proprietary application gateways for interworking between SIP and H.323. In order to provide interoperability between the two standards, it is urgent to define a common interworking specifications for the industry. The recognition of the need for this interworking specification has lead to calls for its development from both manufacturers and service providers, individually and through industry consortia (such as IMTC) and other bodies concerned with interoperability (such as ETSI). In this BOF, we are going to discuss SIP and H.323 interworking issues, execution plans and the scope of the work. Agenda: - Do we need SIP-H.323 interworking? - Coordination with other groups? - Scope of interworking - Outcome of the work? - Suggestions? Helpful reading: - draft-singh-sip-h323-00.txt - SIP: Session Initiation Protocol (RFC 2543) - SDP: Session Description Protocol (RFC 2327) - ITU recommendations: H.323, H.225.0, H.245 > -----Original Message----- > From: Roy, Radhika R, ALARC [mailto:rrroy@att.com] > Sent: Friday, March 03, 2000 3:12 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: FYI - SIP-H.323 Interworking BOF > > > Hi, Everyone: > > It appears that BOF is focused only on SIP-H.323 Interworking (not > H.323-Internet Interworking as titled by Orit). I guess that > Joon and Dave > will clarify this better. > > Best regards, > Radhika R. Roy > AT&T > > > -----Original Message----- > > From: Orit Levin [SMTP:orit@radvision.com] > > Sent: Friday, March 03, 2000 3:57 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: FYI - SIP-H.323 Interworking BOF > > > > Great! > > I am attaching the revised so far TOR. Please, send your comments. > > Hope you will find it useful in Australia. > > 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: Joon Maeng <joon_maeng(a)VTEL.COM> > > To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> > > Date: Thursday, March 02, 2000 8:18 PM > > Subject: FYI - SIP-H.323 Interworking BOF > > > > > > >Hi folks. There will be a SIP-H.323 Interworking BOF at > the IETF meeting > > in > > >Australia. Dave Walker with SS8 Networks and I will chair > the BOF. You > > can > > >find the agenda at http://www.ietf.org/meetings/IETF-47.html when IETF > posts > >agendas. > >Regards, > >Joon << File: H323-Internet.zip >>

1 0

Re: FYI - SIP-H.323 Interworking BOF
by Roy, Radhika R, ALARC 03 Mar '00

03 Mar '00

Hi, Everyone: It appears that BOF is focused only on SIP-H.323 Interworking (not H.323-Internet Interworking as titled by Orit). I guess that Joon and Dave will clarify this better. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Orit Levin [SMTP:orit@radvision.com] > Sent: Friday, March 03, 2000 3:57 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: FYI - SIP-H.323 Interworking BOF > > Great! > I am attaching the revised so far TOR. Please, send your comments. > Hope you will find it useful in Australia. > 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: Joon Maeng <joon_maeng(a)VTEL.COM> > To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> > Date: Thursday, March 02, 2000 8:18 PM > Subject: FYI - SIP-H.323 Interworking BOF > > > >Hi folks. There will be a SIP-H.323 Interworking BOF at the IETF meeting > in > >Australia. Dave Walker with SS8 Networks and I will chair the BOF. You > can > >find the agenda at http://www.ietf.org/meetings/IETF-47.html when IETF > posts > >agendas. > >Regards, > >Joon << File: H323-Internet.zip >>

1 0

Re: FYI - SIP-H.323 Interworking BOF
by Orit Levin 03 Mar '00

03 Mar '00

Great! I am attaching the revised so far TOR. Please, send your comments. Hope you will find it useful in Australia. 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: Joon Maeng <joon_maeng(a)VTEL.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: Thursday, March 02, 2000 8:18 PM Subject: FYI - SIP-H.323 Interworking BOF >Hi folks. There will be a SIP-H.323 Interworking BOF at the IETF meeting in >Australia. Dave Walker with SS8 Networks and I will chair the BOF. You can >find the agenda at http://www.ietf.org/meetings/IETF-47.html when IETF posts >agendas. >Regards, >Joon

1 0

Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt
by Matt Holdrege 03 Mar '00

03 Mar '00

I agree with narrowing of options, but market reality means the MGC's in most cases must support both. That's what I was referring to. At 01:21 PM 3/3/00 -0500, Rosen, Brian wrote: >Matt > >The protocol states MGCs SHOULD support both. That is not >a requirement. > >The purpose of a profile is to narrow down the breadth that the >protocol specifies so that you can plug an MG into an MGC and you >KNOW that they will play. This is generally NOT the case with >a random MG plugging into a random MGC - there are lots and lots >of things that would make them not compatible, and still both >be conformant to the protocol. > >For each and every option possible in the protocol, a well defined >profile should specify a minimum requirement. A conformant >device should be able to go above the minimum. This means in >every profile, a choice will be made on encoding. If this is >not done, then a customer cannot tell by comparing the profile >of an MG whether it will be compatible with his MGC. He should >absolutely be able to do this. > >In this case, if an MGC advertises that it conforms to the IPPhone >profile, but does not support text encoding, it is not out >of compliance with either the protocol or the profile. If you >try to plug a binary-only IPPhone into such a system, it won't >work. That is, in my opinion, unacceptable. > >I will even go so far as to say that the minimum is also the >preferred - even if the device can do more, the point of a profile >is to specify a set of option choices that will allow 100% >compatibility. If you have a device that REQUIRES some profile x >PLUS some feature y, then it would be better to define a new >profile as being an extension of x to include y. > >Brian > > > -----Original Message----- > > From: Matt Holdrege [mailto:holdrege@lucent.com] > > Sent: Friday, March 03, 2000 12:56 PM > > To: Rosen, Brian > > Cc: ITU-SG16(a)mailbag.cps.INTEL.COM > > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > > > > > > If MGC's must support both text and binary, what does it hurt > > to allow IP > > phones to do either? > >

1 0

Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt
by Rosen, Brian 03 Mar '00

03 Mar '00

Matt The protocol states MGCs SHOULD support both. That is not a requirement. The purpose of a profile is to narrow down the breadth that the protocol specifies so that you can plug an MG into an MGC and you KNOW that they will play. This is generally NOT the case with a random MG plugging into a random MGC - there are lots and lots of things that would make them not compatible, and still both be conformant to the protocol. For each and every option possible in the protocol, a well defined profile should specify a minimum requirement. A conformant device should be able to go above the minimum. This means in every profile, a choice will be made on encoding. If this is not done, then a customer cannot tell by comparing the profile of an MG whether it will be compatible with his MGC. He should absolutely be able to do this. In this case, if an MGC advertises that it conforms to the IPPhone profile, but does not support text encoding, it is not out of compliance with either the protocol or the profile. If you try to plug a binary-only IPPhone into such a system, it won't work. That is, in my opinion, unacceptable. I will even go so far as to say that the minimum is also the preferred - even if the device can do more, the point of a profile is to specify a set of option choices that will allow 100% compatibility. If you have a device that REQUIRES some profile x PLUS some feature y, then it would be better to define a new profile as being an extension of x to include y. Brian > -----Original Message----- > From: Matt Holdrege [mailto:holdrege@lucent.com] > Sent: Friday, March 03, 2000 12:56 PM > To: Rosen, Brian > Cc: ITU-SG16(a)mailbag.cps.INTEL.COM > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > > > If MGC's must support both text and binary, what does it hurt > to allow IP > phones to do either? >

1 0

Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt
by Matt Holdrege 03 Mar '00

03 Mar '00

If MGC's must support both text and binary, what does it hurt to allow IP phones to do either?

1 0

Re: [H.323-SIP/Internet] The reason.
by Roy, Radhika R, ALARC 03 Mar '00

03 Mar '00

Hi, Christian, Orit, and Bahman: I guess that Orit will put together all the items in the TOR document. Once we agree on the plan, I believe that work will proceed accordingly. We will discuss each item when one brings contributions. We will definitely be able to keep our work progressed according to the TOR document based on our consensus. I believe that we can make it. First, let us agree on TOR. Best regards, Radhika R. Roy AT&T +1 732 420 1580 > -----Original Message----- > From: Christian Groves [SMTP:Christian.Groves@ERICSSON.COM] > Sent: Thursday, March 02, 2000 5:04 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323-SIP/Internet] The reason. > > G'Day Orit and Bahman, > > Thanks for your support on the proposal. I don't mind this being added > as proposed work method. I think now the task is to start defining step > 1 which I believe is discussed at the moment. I think the challenge will > be to keep people working as per the work plan. > > Cheers, Christian > > Orit Levin wrote: > > > > Hello Bahman! > > I agree (without furiously) that Christian's proposal is excellent. I > > already incorporated it into the proposed ToR. (I hope he doesn't > mind...) > > It also reflects most of the points raised on the mailing list so far. > In my > > opinion it applies very good to H.323-SIP interworking issue. > > > > As to H.323 using Internet services, I haven't change my opinion. I will > > clarify it in the document adding new examples (based on inputs I am > > receiving from people). > > 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: Bahman Mobasser <bahman.mobasser(a)alcatel.fr> > > To: Orit Levin <orit(a)radvision.com>; ITU-SG16(a)mailbag.cps.intel.com > > <ITU-SG16(a)mailbag.cps.intel.com> > > Date: Thursday, March 02, 2000 12:35 PM > > Subject: RE: [H.323-SIP/Internet] The reason. > > > > >Orit- > > > > > >I think, as they say, we're furiously agreeing. What I wrote on your > option > > >two was a bit in shorthand. Of course, like you, I consider that H.323 > has > > >been designed for RTP and Internet use from the beginning. What I meant > was > > >if we (i.e., COM16), now say we're *starting* work on H.323 > interworking > > >with internet that would confuse everybody and me specially. It would > > >suggest that H.323 does not work on internet today. > > > > > >I found the organisation of work proposed by Christian Groves very good > and > > >logical. I read his proposal as being sequential, i.e., a number of > steps > > >which follow each other. This could be our work-plan. > > > > > >Bahman > > > > > >----------------------------------------------------- > > >Bahman Mobasser Tel: +33 1 30771608 > > >Alcatel Mobile: +33 6 12091822 > > >10 rue Latécoère Fax: +33 1 30779914 > > >78140 Vélizy Voice & Fax Mail: +33 1 5301 0789 > > >France Roaming email: Bahman(a)Bahman.org > > >----------------------------------------------------- > > > > > >[[ MAPI 1.0 storage : 4355 in winmail.dat ]] > > > > > >-----Original Message----- > > >From: Mailing list for parties associated with ITU-T Study Group 16 > > >[mailto:ITU-SG16@mailbag.cps.intel.com] On Behalf Of Orit Levin > > >Sent: mardi 29 février 2000 18:28 > > >To: ITU-SG16(a)mailbag.cps.intel.com > > >Subject: Re: [H.323-SIP/Internet] The reason. > > > > > >Bahman, > > >I definitely agree with the interpretation of (1). I think that > protocol's > > >requirements and reasonable topology definition should be addressed by > > SG16. > > >In regards to (2), I tend to disagree. H.323 has been using RTP > > >specification from the very beginning. I don't think that today anyone > > >doubts the intelligence behind this decision. I believe the benefit of > > >using required services in an interoperable manner is more important > that > > >being afraid of sending the wrong signals. > > >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: Bahman Mobasser <bahman.mobasser(a)ALCATEL.FR> > > >To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> > > >Date: Tuesday, February 29, 2000 11:40 AM > > >Subject: Re: [H.323-SIP/Internet] The reason. > > > > > > > > >Orit- > > > > > >In my opinion what would most useful would a restrictive interpretation > of > > >1, and I will explain: what is needed is the specification of an > H.323-SIP > > >call. Depending on the network configuration assumptions (i.e., what > > >equipment is between the two end-points), the mapping needs will become > > >clear. > > > > > >On this option I share your point of view- while this may be > politically > > >incorrect, I think inviting everybody to the Picnic does not > necessarily > > >advance things. If one organisation (IETF) has taken the lead in doing > > this, > > >then the best thing to do is to encourage them by taking proposals > there. > > > > > >2 confuses me too much and sends, in my opinion, completely the wrong > > >signals and should be avoided. > > > > > >Bahman > > > > > >----------------------------------------------------- > > >Bahman Mobasser Tel: +33 1 30771608 > > >Alcatel Mobile: +33 6 12091822 > > >10 rue Latécoère Fax: +33 1 30779914 > > >78140 Vélizy Voice & Fax Mail: +33 1 5301 0789 > > >France Roaming email: Bahman(a)Bahman.org > > >----------------------------------------------------- > > > > > >[[ MAPI 1.0 storage : 4140 in winmail.dat ]] > > > > > >-----Original Message----- > > >From: Mailing list for parties associated with ITU-T Study Group 16 > > >[mailto:ITU-SG16@mailbag.cps.intel.com] On Behalf Of Orit Levin > > >Sent: lundi 28 février 2000 17:25 > > >To: ITU-SG16(a)mailbag.cps.intel.com > > >Subject: Re: [H.323-SIP/Internet] The reason. > > > > > >Hello! > > >I can see two (hardly overlapping) directions to move forward: > > >(1) H.323 - SIP interworking by mapping/translation > > >(2) Definition of how H.323 takes use of Internet services being > defined by > > >IETF > > > > > >In the regards to (1), my personal preference would be to leave this > work > > >under the IETF process. I suspect they had a perfect reason being the > first > > >to start this work. It doesn't mean SG16 shouldn't prevent them from > > making > > >mistakes on H.323 side. > > > > > >In regards to (2), I think it has to be addressed by H.323 as a part of > > >H.323. I would love to see more comments on this (less political) part > of > > >the work. > > > > > >In the meanwhile I am putting all the suggestions and alternatives in > the > > >updated paper (which is not attached yet). > > >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: Henning Schulzrinne <hgs(a)CS.COLUMBIA.EDU> > > >To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> > > >Date: Sunday, February 27, 2000 10:57 PM > > >Subject: Re: [H.323-SIP/Internet] The reason. > > > > > > > > >>Since my name popped up in a recent email discussion, a few remarks: > > >> > > >>1) Yes, the SIP-H.323 list was created by myself; it is open to > anybody. > > >>While its creation was triggered by the interest generated by a > proposal > > >>(Internet draft) written by Kundan Singh (a student of mine) and > myself, > > >>it is open to any discussion related to the topic of interworking. > > >>(Discussions about the relative merits of protocols are decidedly less > > >>appreciated.) Whether people use this mailing list or create something > > >>new and different is obviously beyond my control. > > >> > > >>The creation of the mailing list was done without any implied IETF > > >>endorsement or even endorsement of other SIP authors. (I hope they > don't > > >>mind too much...) > > >> > > >>2) In this context, there is one important difference between the ITU > > >>and IETF standardization process which particularly affects this > > >>discussion. While all ITU recommendations are "standards", most IETF > > >>RFCs are not. For the case at hand, it would probably be considered > > >>inappropriate for a standards-track RFC except, with lots of stretch > of > > >>the imagination, a BCP (best current practice). If an interoperability > > >>document does get published within the IETF, it is likely to appear as > > >>an Informational or possibly Experimental RFC. In this particular > case, > > >>as long as the signaling gateway looks like a valid SIP or H.323 > entity, > > >>the other SIP and H.323 entities won't know that it is talking to the > > >>"other side" (you can insert "dark side" or "the enemy" if you are so > > >>inclined). > > >> > > >>As our initial document points out, there is probably a range of > > >>solutions that satisfy this basic criterion, depending on (for > example) > > >>to what extent X entities are visible in Y land. > > >> > > >>In my view, publishing any such interoperability document has the > > >>primary benefit of saving implementors of such devices, should they > > >>become popular, a bit of thinking time and maybe avoid some pitfalls. > > >>They are not strictly *necessary* - anybody could derive one of the > > >>modes that we described or something different, as long as it > satisfies > > >>the basic "in Rome, do as the Romans" criterion mentioned earlier. > > >> > > >>Thus, given that a standards-track document is not really called for > on > > >>the IETF side, this effort could be significantly simpler than, say, > the > > >>Megaco/H.248 effort. My rough perception is that the IESG will > basically > > >>ask at publication time whether the document suggested as an > > >>Informational RFC violates IETF protocols (SIP and SDP, in this case). > > >>If not, and it does no other harm (e.g., broadcasting a RAS-like query > > >>to all SIP nodes in the Internet or something similarly stupid), the > > >>IETF process should be relatively straightforward, even without a lot > of > > >>cooperation machinery, liaison agreements and the like. I realize that > > >>this assessment is probably hopelessly naive, but I am concerned that > > >>the collective effort expended on meta-discussions is rapidly > > >>approaching the effort that seems to be necessary to write an > > >>interoperability document for basic services, including the time to > > >>implement it. > > >> > > >>We'd be happy to provide the infrastructure for meetings, allowing the > > >>ITU participants to use their H.323 phones to call our SIP phones > using > > >>our gateway implementation :-) No, we won't charge the ITU for these > > >>translation services :-) > > >> > > >>Regards, > > >> > > >>Henning > > >

1 0

Re: Multiple phone on the same node
by Hans Viens 03 Mar '00

03 Mar '00

Hi Chris, if I understand (please, correct me if I'm wrong) I have to make 4 RRQ to specify the gatekeeper the Enpoint type of each port I have ? i.e. 1. RRQ -> EndpointType=Terminal; 2. RRQ -> EndpointType=Terminal; 3. RRQ -> EndpointType=Terminal; 3. RRQ -> EndpointType=Gateway; I other work I make 4 RRQ with the Enpoint type ? Best regards, Hans > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] > Sent: Friday, March 03, 2000 4:25 AM > To: hviens(a)mediatrix.com > Cc: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Multiple phone on the same node > > > Hans, > > It is perfectly possible to register a single H.323 device > with multiple > functionalities. To put this another way, EndpointType, > which is an element of > RRQ, is a SEQUENCE. > > Chris > > Hans Viens wrote: > > > > Hi, > > > > I have a product which has a unique IP address (one node). > This device has 1 > > Ethernet port, 1 PSTN port and 3 phones connected on it. I > want to take > > advantage of the PSTN port and Ethernet port to make it act like a > > H.323/PSTN gateway. Also, each phone can be use as a H.323 terminal > > endpoint. > > > > My problem is: how could I registered my device to a > gatekeeper (knowing the > > Gateway functionnality of the device and its 3 terminal > endpoints) ? Is it > > possible to registered a device (1 IP address) which has multiple > > functionnalities (i.e. Terminal and Gateway) ? > > > > If anyone could help, I would appreciate it! > > > > Hans > > -- > Dr Chris Purvis -- Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > Winkfield Row, Berkshire. RG42 6LY ENGLAND > Phone: +44 1344 899 007 > Fax: +44 1344 899 001 >

2 1