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

3 Mar 2000

      Hi, Christian, Orit, and Bahman:

I guess that Orit will put together all the items in the TOR document. Once
we agree on the plan, I believe that work will proceed accordingly. We will
discuss each item when one brings contributions. We will definitely be able
to keep our work progressed according to the TOR document based on our
consensus.

I believe that we can make it.

First, let us agree on TOR.

Best regards,
Radhika R. Roy
AT&T
+1 732 420 1580
...
-----Original Message-----
From: Christian Groves [SMTP:Christian.Groves@ERICSSON.COM]
Sent: Thursday, March 02, 2000 5:04 PM
To:   ITU-SG16@MAILBAG.INTEL.COM
Subject:      Re: [H.323-SIP/Internet] The reason.
G'Day Orit and Bahman,
Thanks for your support on the proposal. I don't mind this being added
as proposed work method. I think now the task is to start defining step
1 which I believe is discussed at the moment. I think the challenge will
be to keep people working as per  the work plan.
Cheers, Christian
Orit Levin wrote:
...
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
...
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@radvision.com
-----Original Message-----
From: Bahman Mobasser <bahman.mobasser@alcatel.fr>
To: Orit Levin <orit@radvision.com>; ITU-SG16@mailbag.cps.intel.com
<ITU-SG16@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
...
...
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@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@mailbag.cps.intel.com] On Behalf Of Orit Levin
Sent: mardi 29 février 2000 18:28
To: ITU-SG16@mailbag.cps.intel.com
Subject: Re: [H.323-SIP/Internet] The reason.
Bahman,
I definitely agree with the interpretation of (1). I think that
...
...
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
...
...
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@radvision.com
-----Original Message-----
From: Bahman Mobasser <bahman.mobasser@ALCATEL.FR>
To: ITU-SG16@MAILBAG.INTEL.COM <ITU-SG16@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
...
...
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
...
...
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@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@mailbag.cps.intel.com] On Behalf Of Orit Levin
Sent:   lundi 28 février 2000 17:25
To:     ITU-SG16@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
...
...
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@radvision.com
-----Original Message-----
From: Henning Schulzrinne <hgs@CS.COLUMBIA.EDU>
To: ITU-SG16@MAILBAG.INTEL.COM <ITU-SG16@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
...
...
...
(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,
mind...)
option
protocol's
that
politically
there.
the
proposal
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

Roy, Radhika R, ALARC

tags

participants (1)