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