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

[Roy, Radhika R, ALARC]

Hi, Bahman and Orit,

I agree with Bahman.

Orit, would you please clarify more what do you expect with respect to your
proposals 1 and 2?

Best regards,
Radhika


> -----Original Message-----
> From: Bahman Mobasser [SMTP:bahman.mobasser at ALCATEL.FR]
> Sent: Tuesday, February 29, 2000 11:23 AM
> To:   ITU-SG16 at MAILBAG.INTEL.COM
> 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