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@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 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
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@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 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@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 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
participants (2)
-
Bahman Mobasser -
Orit Levin