[sip-h323] Re: H323/SIP Interworking - way forward

Orit Levin orit at radvision.com
Tue Mar 7 15:25:09 EST 2000

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
orit at radvision.com
-----Original Message-----
From: Kundan Singh <kns10 at cs.columbia.edu>
To: 'sip-h323 at egroups.com' <sip-h323 at 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
>> limit my implementation to just this five. How about we all bounce this
>> 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
>> 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
>> 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.
>To Post a message, send it to:   sip-h323 at eGroups.com
>To Unsubscribe, send a blank message to: sip-h323-unsubscribe at eGroups.com
>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!
>eGroups.com Home: http://www.egroups.com/group/sip-h323/
>http://www.egroups.com - Simplifying group communications

More information about the sg16-avd mailing list