[Sipping] IEEE Network special Issue on VoIP Security
"Ram Dantu" <rdantu@egw.unt.edu> Thu, 12 May 2005 03:51 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW4jO-0006Xc-Ha; Wed, 11 May 2005 23:51:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW4jK-0006XS-34 for sipping@megatron.ietf.org; Wed, 11 May 2005 23:51:22 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26996 for <sipping@ietf.org>; Wed, 11 May 2005 23:51:19 -0400 (EDT)
Received: from mailhost.unt.edu ([129.120.209.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW4yy-0006Ef-51 for sipping@ietf.org; Thu, 12 May 2005 00:07:32 -0400
Received: from iatro (localhost.localdomain [127.0.0.1]) by mail3 (Postfix) with SMTP id 9D13E73ECD for <sipping@ietf.org>; Wed, 11 May 2005 22:51:08 -0500 (CDT)
Received: from gwia.unt.edu (gwia.unt.edu [129.120.221.21]) by mailhost.unt.edu (Postfix) with ESMTP id EAE4A73ED0 for <sipping@ietf.org>; Wed, 11 May 2005 22:50:59 -0500 (CDT)
Received: from SMTP-MTA by gwia.unt.edu with Novell_GroupWise; Wed, 11 May 2005 22:50:59 -0500
Message-Id: <s2828c53.063@gwia.unt.edu>
X-Mailer: Novell GroupWise Internet Agent 6.5.4
Date: Wed, 11 May 2005 22:45:06 -0500
From: Ram Dantu <rdantu@egw.unt.edu>
To: Donghua.Jiang@alltel.com, Samir.Chatterjee@cgu.edu, henry@sinnreich.net
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d008c19e97860b8641c1851f84665a75
Content-Transfer-Encoding: quoted-printable
Cc: Christian.Stredicke@snom.de, sipping@ietf.org
Subject: [Sipping] IEEE Network special Issue on VoIP Security
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
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>
Sender: sipping-bounces@ietf.org
Errors-To: sipping-bounces@ietf.org
We are going to edit IEEE Network special issue on VoIP Security. We invite submissions for this special issue and the due date is October 15, 2005. See the following link for more details (http://www.comsoc.org/pubs/net/ntwrk/cfpnetwork3Q06.htm) Ram Dantu Dipak Ghosal Henning Schulzrinne PS: IEEE Network was the number two most-cited journal in electrical and electronics engineering, number one cited journal in telecommunications, and the number two cited journal in computer science hardware and architecture, and computer science information systems in 2003, according to the annual Journal Citation Report (2003 edition) published by the Institute for Scientific Information. >>> <Donghua.Jiang@alltel.com> 05/11/05 11:43 AM >>> Samir, I think it is kind of fair for the referees to ask for more than just the three approaches that you have evaluated. You may have different interests than the academic referees'. Since there are many ways of implementing NAT and security in SIP based VoIP solution, it is a good idea for your group to look into different approaches and to provide the journal or the industry with a fair view of what the best approach is. Best regards, Jane -----Original Message----- From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org]On Behalf Of Samir Chatterjee Sent: Wednesday, May 11, 2005 10:45 AM To: henry@sinnreich.net Cc: sipping@ietf.org; Christian Stredicke Subject: RE: [Sipping] Details on SBC Thanks to all who responded to my query. I would like to give a background on why I requested this info. My lab had conducted detailed performance evaluation of three most well-known standard based approach to solving the SIP-NAT issue. We created testbeds for testing STUN, UPnP and IPFreedome which is proprietary from Ridgeway and quite popular (believe they do a variation of TURN). When the paper was submitted to an academic journal for publication, the referees came back saying why we haven;t studied SBCs and why not ICE. Frankly we could not get any open source solution to ICE and SBCs solving this problem was new to us. What I am hearing is that SBC may solve this problem but IETF is having hard time understanding what it is and can/should do. Besides there is no open implementation of ICE that one could test for traffic and other performance issues. Wonder why even academic refereees get carried away by vendor hypes then. Samir -----Original Message----- From: sipping-bounces@ietf.org on behalf of henry@sinnreich.net Sent: Wed 5/11/2005 8:06 AM To: Samir Chatterjee Cc: 'Christian Stredicke'; sipping@ietf.org Subject: RE: [Sipping] Details on SBC Samir, SIP is specified in a collection of standards documents and the SBC is not part of SIP. The requirements for NAT are quite stable and formulated in http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-01.txt The NAT traversal scenarios with detailed messages are given in http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-02.txt This should give you enough to implement ICE and avoid SBC products for all the reasons discussed on this list, if one can actually specify what an SBC is. 100's of attendees at the IETF BOFs on SBC could not. See the report in the attached. No doubt there are many SBC vendors who will assert to meet your needs, so you can make the decision for yourself if you want to go with the SIP standard or use SBC. See the attached for more details. Thanks, Henry Henry Sinnreich pulver.com 115 Broadhollow Rd Suite 225 Melville, NY 11747 USA _____ From: Christian Stredicke [ mailto:Christian.Stredicke@snom.de] Sent: Wednesday, May 11, 2005 5:18 AM To: Samir Chatterjee Cc: sipping@ietf.org Subject: RE: [Sipping] Details on SBC Hi Samir, also take a look at http://snom.com/download/natf_211.pdf. There is some explanations of what we are going. At least. We did ICE ("local media path optimization") in the beginning, but because of the latest changes in the draft we decided not to do any more changes until this is in a stable state. We don't like moving targets. And practically it does not seem to play the role that we thought it would do. Today I would say it is more important to locate the nearest SBC for the UA (for a globally operating ITSP). CS _____ From: sipping-bounces@ietf.org [ mailto:sipping-bounces@ietf.org] On Behalf Of Samir Chatterjee Sent: Saturday, May 07, 2005 12:46 AM To: sipping@ietf.org Subject: [Sipping] Details on SBC Hi: We are looking for some details on SBC and how they work in terms of call flows etc. Any pointers? Also, does someone know of an actual implementation of ICE for NAT/FW traversal. It could be either commercial or open-source. Something that we could test for performance. Any help would be appreciated. Dr. Samir Chatterjee Founding Director, NCL http://ncl.cgu.edu School of Information Science Claremont Graduate University 130 East 9th Street Claremont, CA 91711 (P) 909-607-4651 (F) 909-621-8564 http://fac.cgu.edu/~chatters ****************************************************************************************** The information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, ALLTEL requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else. _______________________________________________ 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