Re: [sip-h323] Re: H323/SIP Interworking - way forward
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@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@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
participants (1)
-
Roy, Radhika R, ALARC