Re: [sip-h323] Re: H323/SIP Interworking - way forward
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@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@egroups.com; ITU-SG16@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@radvision.com -----Original Message----- From: Kundan Singh kns10@cs.columbia.edu To: 'sip-h323@egroups.com' sip-h323@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@eGroups.com To Unsubscribe, send a blank message to:
sip-h323-unsubscribe@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@eGroups.com To Unsubscribe, send a blank message to: sip-h323-unsubscribe@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
participants (1)
-
Tom-PT Taylor