- sg16-avd - lists.packetizer.com

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