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

Bahman Mobasser bahman.mobasser at ALCATEL.FR
Thu Mar 2 12:35:03 EST 2000


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