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