FYI - SIP-H.323 Interworking BOF

Joon Maeng joon_maeng at VTEL.COM
Thu Mar 2 20:07:37 EST 2000


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 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