RE: [Sipping] SIP-H.323 design team
"Francois Audet" <audet@nortelnetworks.com> Thu, 20 February 2003 21:33 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00431 for <sipping-archive@odin.ietf.org>; Thu, 20 Feb 2003 16:33:23 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KLe7718233 for sipping-archive@odin.ietf.org; Thu, 20 Feb 2003 16:40:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KLe7p18230 for <sipping-web-archive@optimus.ietf.org>; Thu, 20 Feb 2003 16:40:07 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00426 for <sipping-web-archive@ietf.org>; Thu, 20 Feb 2003 16:32:50 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KLbWp18079; Thu, 20 Feb 2003 16:37:32 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KLZkp17256 for <sipping@optimus.ietf.org>; Thu, 20 Feb 2003 16:35:46 -0500
Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00184 for <sipping@ietf.org>; Thu, 20 Feb 2003 16:28:29 -0500 (EST)
Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1KLWDo00580; Thu, 20 Feb 2003 15:32:13 -0600 (CST)
Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1LWHXXMN>; Thu, 20 Feb 2003 13:32:14 -0800
Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D206B7F8FC@zsc3c030.us.nortel.com>
From: Francois Audet <audet@nortelnetworks.com>
To: 'Gonzalo Camarillo' <Gonzalo.Camarillo@lmf.ericsson.se>, 'sipping' <sipping@ietf.org>
Cc: 'Dean Willis' <dwillis@softarmor.com>, 'Rohan Mahy' <rohan@cisco.com>, "'kns10@cs.columbia.edu'" <kns10@cs.columbia.edu>, 'Henning Schulzrinne' <hgs@cs.columbia.edu>, "'alan.johnston@wcom.com'" <alan.johnston@wcom.com>, "'rrroy@att.com'" <rrroy@att.com>
Subject: RE: [Sipping] SIP-H.323 design team
Date: Thu, 20 Feb 2003 13:32:13 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D927.883F712A"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Gonzallo and all, I have a few comments/concerns about this requirement document. - Section 6 states that the IWF shall use the H.323 version 2 Recommendation. I don't believe this is a valid requirement. Many (if not most) implementations are up to versions 3 and 4 these days. We could either say nothing at all about H.323 versions, or require version 2 or above. In H.323, new versions need to be backward compatible with older versions, so this shouldn't be an issue. - Many requirements are extremely vague. For example, things like 6.1.2 a "the IWF shall support all the addressing shcemes of both H.323 and SIP". I'm not sure if this is even feasible. Requirement 8.1.1 is also very vague I also really doubt that it is even possible to do so: I'd recommend writing examples instead of a clear mapping). - Certain requirements seem to modify the behavior that and H.323 endpoint or GK may have. We can not impose system-wide behavioral changes on an existing H.323 (or SIP) network. For example, 6.4 says that the pre-granted ARQ shall be supported by the IWF. It is entirely up to the GK to decide which mode (pre-granted or not) will be used, not the IWF. Perhaps I'm not reading the requirement properly and this requirement is just saying that the IWF needs to support both pre-Granted ARQ and normal ARQ (if it is the case, then this bullet should just be merger with the previous requirement about vague requirements). One of the reason I am thinking that the intent is to prescribe a specific behavior on the H.323 (and SIP) protocol is that the now-expired draft-agrawal-sip-h323-interworking-01.txt was doing so. Are we thinking of ressucitating this draft, or are we thinking of starting from scratch with a different approach? - Section 6.5 uses the INFO method for sending DTMF information. I will point out that H.323v4 supports RFC2833 (the procedures for exchanging the necessary dynamic payload type are similar to the procedures used in SIP). - Section 8.2 I like. - Section 8.4 needs to be clarified (what is "invisible support"?). - Section 12.4 is probably one of the most important to look into. It should explain how the offer/answer model maps to H.323 (both fastStart and mid/call or slow start). It should talk about re-INVITE, UPDATE, OpenLogicalChannnel, a=sendonly/inactive, TCS=0,etc. I am pretty sure that there is no simple mapping as the models are quite different. - There should also be a section on in-band and out-of band media (early media) and how they map. Lastly, we need to make sure that this document is meant to be informative at best. I would much prefer to have document explaining the various mismatches between SIP and H.323 and how to minimize them than a document trying to describe a fixed mapping between the two: more a free-form description of the various "gotchas" that may be encountered when trying to interwork the two protocols. For example, it could explain how opening logical channels in H.323 and the terminal capability set negotiation process differ from the offer/answer model. I see very little benefits in creating a document that would describe only a mapping for "basic call setup" as this is not where people are going to have difficulties. I am convinced that a "simple protocol mapping" approach such as the one defined in the now expired draft-agrawal-sip-h323-interworking-01.txt is not possible and that instead the IWF will have to maintain full call control/state information in order to map properly between the protocols. I think we would be doing developpers and service providers a great disservice by issuing an RFC implying that a simple "protocol mapping" box might be sufficient to allow for interworking between SIP and H.323. I'd rather see no interworking document at all than a simplistic mapping document. Comments? François Audet > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Monday, February 10, 2003 12:17 AM > To: sipping > Cc: Dean Willis; Rohan Mahy; kns10@cs.columbia.edu; Henning > Schulzrinne; alan.johnston@wcom.com; rrroy@att.com > Subject: [Sipping] SIP-H.323 design team > > > Folks, > > The requirements document for SIP-H.323 interworking is advancing: > http://www.ietf.org/internet-drafts/draft-agrawal-sip-h323-interworking-reqs -03.txt Now, it is time to start thinking about the solution document. If there are enough people willing to contribute, we intend to form a design team in SIPPING. The scope of the work will be most likely limited to basic call set-up. Those of you who are interested in being part of such a design team, please let me know. Thanks, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP
- [Sipping] SIP-H.323 design team Gonzalo Camarillo
- [Sipping] RE: SIP-H.323 design team Roy, Radhika R, ALABS
- RE: [Sipping] SIP-H.323 design team Francois Audet
- Re: [Sipping] SIP-H.323 design team Henning Schulzrinne