[H.323-SIP/Internet] The reason.

Orit Levin orit at radvision.com
Thu Mar 2 13:00:20 EST 2000


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 at radvision.com
-----Original Message-----
From: Bahman Mobasser <bahman.mobasser at alcatel.fr>
To: Orit Levin <orit at radvision.com>; ITU-SG16 at mailbag.cps.intel.com
<ITU-SG16 at 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 at 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 at mailbag.cps.intel.com] On Behalf Of Orit Levin
>Sent: mardi 29 février 2000 18:28
>To: ITU-SG16 at 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 at radvision.com
>-----Original Message-----
>From: Bahman Mobasser <bahman.mobasser at ALCATEL.FR>
>To: ITU-SG16 at MAILBAG.INTEL.COM <ITU-SG16 at 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 at 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 at mailbag.cps.intel.com] On Behalf Of Orit Levin
>Sent:   lundi 28 février 2000 17:25
>To:     ITU-SG16 at 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 at radvision.com
>-----Original Message-----
>From: Henning Schulzrinne <hgs at CS.COLUMBIA.EDU>
>To: ITU-SG16 at MAILBAG.INTEL.COM <ITU-SG16 at 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
>



More information about the sg16-avd mailing list