From root@core3.amsl.com Mon Jul 13 06:30:01 2009 Return-Path: X-Original-To: speermint@ietf.org Delivered-To: speermint@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7EE7E3A6DB7; Mon, 13 Jul 2009 06:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090713133001.7EE7E3A6DB7@core3.amsl.com> Date: Mon, 13 Jul 2009 06:30:01 -0700 (PDT) Cc: speermint@ietf.org Subject: [Speermint] I-D Action:draft-ietf-speermint-voipthreats-01.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 13:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : SPEERMINT Security Threats and Suggested Countermeasures Author(s) : S. Niccolini, et al. Filename : draft-ietf-speermint-voipthreats-01.txt Pages : 24 Date : 2009-07-13 This memo presents the different security threats related to SPEERMINT, classifying them into threats to the Lookup Function (LUF), Location Routing Function (LRF), to the Signaling Function (SF) and to the Media Function (MF). The different instances of the threats are briefly introduced inside the classification. Finally, the existing security solutions for SIP and RTP/RTCP are presented to describe the countermeasures currently available for such threats. Security requirements for SPEERMINT can be found in draft-ietf-speermint-requirements. The objective of this document is to identify and enumerate SPEERMINT-specific threat vectors and to give guidance for implementers on selecting appropriate countermeasures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-voipthreats-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-speermint-voipthreats-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13062849.I-D@ietf.org> --NextPart-- From Jan.Seedorf@nw.neclab.eu Mon Jul 13 06:38:21 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6994328C2E4 for ; Mon, 13 Jul 2009 06:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.771 X-Spam-Level: X-Spam-Status: No, score=-1.771 tagged_above=-999 required=5 tests=[AWL=0.828, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mymFN-fpu7Bs for ; Mon, 13 Jul 2009 06:38:20 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 9D1533A6DBF for ; Mon, 13 Jul 2009 06:38:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id F395C2C00C51C for ; Mon, 13 Jul 2009 15:38:50 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNfN6JZ5IjX0 for ; Mon, 13 Jul 2009 15:38:50 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id D6CCA2C0004E5 for ; Mon, 13 Jul 2009 15:38:45 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jul 2009 15:38:45 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new version of draft-ietf-speermint-voipthreats submitted Thread-Index: AcoDvz4qdcRkiQQoQ/WxSMYc6+hwhw== From: "Jan Seedorf" To: Subject: [Speermint] new version of draft-ietf-speermint-voipthreats submitted X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 13:38:21 -0000 Dear all, We have just submitted the -01 version of = draft-ietf-speermint-voipthreats. We addressed all the comments received = at IETF-73 and on the list, and made some editorial changes. We are = looking forward to comments and most importantly to feedback from real = implementers of SSP-peering (I know there are some of the subscribed to = this list :)). Let us know if some threats or countermeasures are = missing or if something is not clearly written in the document. Kind regards, Jan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jan Seedorf Research Scientist NEC Europe Ltd., NEC Laboratories Europe, Network Division=09 Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-221 Fax: +49 (0)6221 4342-155 e-mail: jan.seedorf@nw.neclab.eu=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014=20 From jason_livingood@cable.comcast.com Mon Jul 20 07:46:00 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 781D83A6941 for ; Mon, 20 Jul 2009 07:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AS53qm5hOLYc for ; Mon, 20 Jul 2009 07:45:59 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 8E1BC3A6C34 for ; Mon, 20 Jul 2009 07:45:59 -0700 (PDT) Received: from ([10.52.116.31]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.46307405; Mon, 20 Jul 2009 10:45:25 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 10:45:25 -0400 Received: from 75.196.150.95 ([75.196.150.95]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Mon, 20 Jul 2009 14:45:24 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Mon, 20 Jul 2009 10:45:22 -0400 From: "Livingood, Jason" To: Message-ID: Thread-Topic: Draft Agenda for IETF 75 Thread-Index: AcoJSLVzEgOO+72xd0eDmNWjsha2Qw== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3330931522_96014" X-OriginalArrivalTime: 20 Jul 2009 14:45:25.0485 (UTC) FILETIME=[B786F1D0:01CA0948] Subject: [Speermint] Draft Agenda for IETF 75 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 14:46:00 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3330931522_96014 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Has been posted at http://www.ietf.org/proceedings/75/agenda/speermint.txt Our WG session will take place on Friday of IETF week. Do not hesitate to suggest agenda changes. Regards Jason --B_3330931522_96014 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Draft Agenda for IETF 75 Has been posted at http://www.ietf.org/proceedings/75/agenda/speermint.txt

Our WG session will take place on Friday of IETF week.

Do not hesitate to suggest agenda changes.

Regards
Jason --B_3330931522_96014-- From Jan.Seedorf@nw.neclab.eu Wed Jul 22 02:05:54 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9E403A6E7E for ; Wed, 22 Jul 2009 02:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.827 X-Spam-Level: X-Spam-Status: No, score=-0.827 tagged_above=-999 required=5 tests=[AWL=-0.642, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLkocd1MV0zn for ; Wed, 22 Jul 2009 02:05:54 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id CA7503A6E13 for ; Wed, 22 Jul 2009 02:05:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 1B49F2C02047C for ; Wed, 22 Jul 2009 10:43:26 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJBzy3NsaqWY for ; Wed, 22 Jul 2009 10:43:26 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id F0D712C01CB01 for ; Wed, 22 Jul 2009 10:43:20 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Jul 2009 10:43:19 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF-75 Agenda: link to draft-ietf-speermint-voipthreats is not working Thread-Index: AcoKqHauGyyGOFr7Q/SYC/GD9XE08w== From: "Jan Seedorf" To: Subject: [Speermint] IETF-75 Agenda: link to draft-ietf-speermint-voipthreats is not working X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 09:05:54 -0000 Dear chairs, When checking out the agenda for IETF-75, I found that the link for our = draft "draft-ietf-speermint-voipthreats" is not working. Can you please = replace it with this one: http://tools.ietf.org/html/draft-ietf-speermint-voipthreats-01 Thanks, Jan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jan Seedorf Research Scientist NEC Europe Ltd., NEC Laboratories Europe, Network Division=09 Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-221 Fax: +49 (0)6221 4342-155 e-mail: jan.seedorf@nw.neclab.eu=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014=20 From john.elwell@siemens-enterprise.com Fri Jul 31 06:00:58 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50C183A67AD for ; Fri, 31 Jul 2009 06:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eCgkmId8P8Y for ; Fri, 31 Jul 2009 06:00:57 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 77D013A6A35 for ; Fri, 31 Jul 2009 06:00:57 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KNN0022ODH094@siemenscomms.co.uk> for speermint@ietf.org; Fri, 31 Jul 2009 14:00:36 +0100 (BST) Date: Fri, 31 Jul 2009 14:00:34 +0100 From: "Elwell, John" To: speermint@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00233D618@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: draft-hancock-sip-interconnect-guideline - offerless INVITE requests Thread-Index: AcoR3uRmnjO6mH0VQ6m/eXEokvo+1Q== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [Speermint] draft-hancock-sip-interconnect-guideline - offerless INVITE requests X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 13:00:58 -0000 One of the points mentioned during this afternoon's presentation was restricting the scope to basic 2-way call establishment **not** using 3PCC, which implies no support for offerless INVITE requests. I tried to make a comment via Jabber, but it was not taken to the mic. This would be an unacceptable limitation of the scope. Enterprises make substantial use of 3PCC techniques, including third party call establishment. This necessitates an offerless INVITE request to one of the parties. For example, I use my web browser to establish a call to you. The device I wish to use is my cellphone, so it sends an offerless INVITE request to, which will be routed to a PSTN gateway. The PSTN gateway returns an SDP offer that can be used in the INVITE request towards you (who might also be reachable via a PSTN gateway, or directly via SIP). If the initial offerless INVITE request is carried inter-domain before reaching the PSTN gateway, it needs to get through. Note that this concern applies not just to enterprise-to-enterprise (if the scope of the document were to be extended to include this), but to any interconnect interface. John From gunnar.hellstrom@omnitor.se Fri Jul 31 07:10:39 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBE4E28C0FF for ; Fri, 31 Jul 2009 07:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5uDufqBTDPZ for ; Fri, 31 Jul 2009 07:10:39 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by core3.amsl.com (Postfix) with ESMTP id 881FC28C226 for ; Fri, 31 Jul 2009 07:10:38 -0700 (PDT) Received: (qmail 44892 invoked from network); 31 Jul 2009 14:10:43 -0000 Received: from s34.loopia.se (HELO s128.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 31 Jul 2009 14:10:43 -0000 Received: (qmail 76036 invoked from network); 31 Jul 2009 14:10:36 -0000 Received: from m83-185-71-175.cust.tele2.se (HELO GunnarH) (gunnar.hellstrom@omnitor.se@[83.185.71.175]) (envelope-sender ) by s128.loopia.se (qmail-ldap-1.03) with SMTP for ; 31 Jul 2009 14:10:36 -0000 From: "Gunnar Hellstrom" To: References: <20090713190001.A44BA3A6C20@core3.amsl.com> Date: Fri, 31 Jul 2009 16:10:20 +0200 Message-ID: <001501ca11e8$b0221930$65148182@GunnarH> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoD7SI81/G4dVUTQSmDG4vv65ixkAN7hMbg In-Reply-To: <20090713190001.A44BA3A6C20@core3.amsl.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Cc: d.hancock@cablelabs.com Subject: [Speermint] Missing media in draft-hancock-sip-interconnect-guidelines-01.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 14:10:40 -0000 I find it very sad to limit the scope of this specification to audio only, and ask to widen the scope at least to real-time conversational sessions including real-time text, video and audio. One motivation is that the work with emergency service calls in ECRIT require a possibility to use real-time text, video and audio in emergency calls. Such calls might need to be routed over a sip interconnection, and thus need to get full support for its media. ( emergency calls are within the scope list of this draft. ) There are a number of other valid reasons for this request. Hoping that it can accepted, I give here a first set of edit proposals to bring the draft up to proper multimedia status. **************************************** In 1.1 change from "1.1. Scope The document focuses on the interworking procedures required to support basic telephone service, including the following capabilities: o On-net to on-net calls " To " 1.1. Scope The document focuses on the interworking procedures required to support basic real-time conversational service, including the following capabilities: o Video o Real-time text o On-net to on-net calls " In 5.1.1. change from " 5.1.1. SDP Requirements SIP entities involved in session peering MUST support the SDP requirements defined in [RFC4566]. A SIP entity involved in session peering MUST include only one media (m=) descriptor in an SDP offer to a peer network. If a SIP entity involved in session peering receives an SDP offer containing multiple media descriptors, it SHOULD act on the first audio descriptor with a non-zero port. " To " 5.1.1. SDP Requirements SIP entities involved in session peering MUST support the SDP requirements defined in [RFC4566]. A SIP entity involved in session peering MUST include only one media (m=) descriptor per desired media stream in an SDP offer to a peer network. If a SIP entity involved in session peering receives an SDP offer containing multiple media descriptors, it MUST act on the media descriptors and include all of them in the same order in the response, including non-zero ports and zero ports for the offered media according to its capabilities as specified in [RFC 3264] Offer - Answer model. An offered session MUST NOT be rejected because it offers more media than the responding entity can handle. " These wew just the apparent initial edits after rapid browsing of the draft. There is likely more to do to complete the topic. - /Gunnar -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, July 13, 2009 9:00 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-hancock-sip-interconnect-guidelines-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : draft-hancock-sip-interconnect-guidelines-01 Author(s) : D. Hancock, D. Malas Filename : draft-hancock-sip-interconnect-guidelines-01.txt Pages : 25 Date : 2009-07-13 As Session Initiation Protocol (SIP) peering becomes more widely accepted by service providers the need to define an interconnect guideline becomes of greater value. This document takes into consideration the SIP and commonly used SIP extensions, and it defines a fundamental set of requirements for SIP Service Providers (SSPs) to implement within their signaling functions (SFs) or Signaling Path Border Elements (SBEs) for peering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hancock-sip-interconnect-guideline s-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From btdingle@gmail.com Fri Jul 31 23:58:00 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3DCC3A68D3 for ; Fri, 31 Jul 2009 23:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-4Y9sppx1h8 for ; Fri, 31 Jul 2009 23:57:59 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id CDBFD3A6891 for ; Fri, 31 Jul 2009 23:57:58 -0700 (PDT) Received: by bwz19 with SMTP id 19so1545925bwz.37 for ; Fri, 31 Jul 2009 23:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=kpDOsH+mOrMtjxlcmH8bnGDjgPgg6bH9q/1F5rPNr20=; b=kiIBF9tkjcstxZioKuQY2OdnGjDlzhPFWbznWQrpcou09qHo1YckmQxQwn01rk+ftU pP+TyYNvSKHBJh0HCtNswnsPPcRb9GSVojF6HMP75AndCA48jpXlp3YxwKtr/p1b2fv1 M08K4sRKzYQExzUTa6QbGNTAk5PPO5lsFNNeE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rGtZXsNZW5rmN7Q3BKxtaZ3Tqdo1FqC4ptjHRszuU9ymxnzOg+d/yMHMGgAruWssNO Q5JO8y8QG2seRnH2ezA9PN1zAWFjx5wdhtLwrUfAv5grIX0h1WXMvjPNzX60jGGBDyjc qJVQuov0UhE0skFDKaKJhYkBO9LKPTo4439xQ= MIME-Version: 1.0 Received: by 10.239.163.69 with SMTP id o5mr344026hbd.40.1249109878123; Fri, 31 Jul 2009 23:57:58 -0700 (PDT) In-Reply-To: <001501ca11e8$b0221930$65148182@GunnarH> References: <20090713190001.A44BA3A6C20@core3.amsl.com> <001501ca11e8$b0221930$65148182@GunnarH> Date: Sat, 1 Aug 2009 16:57:58 +1000 Message-ID: <7f31a07a0907312357g5782f798s1c3598fa1e3ff016@mail.gmail.com> From: Barry Dingle To: speermint@ietf.org, Gunnar Hellstrom Content-Type: multipart/alternative; boundary=001485f1a1bc922efa04700f0ec2 Cc: d.hancock@cablelabs.com Subject: Re: [Speermint] Missing media in draft-hancock-sip-interconnect-guidelines-01.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2009 06:58:00 -0000 --001485f1a1bc922efa04700f0ec2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi, I support the comments of Gunnar Hellstrom regarding the need for strong support of real-time text and video conversational services in addition to voice in the SIP-Interconnect Guidelines. RFC5012 (ECRIT Requirements) in Section 5 has a requirement Re4 which states: Re4. Multi-mode communication: IP-based emergency calls MUST support multiple communication modes, including, for example, audio, video, and text. Motivation: Within the PSTN, voice and text telephony (often called TTY or text-phone in North America) are the only commonly supported media. Emergency calling must support a variety of media. Such media should include voice, conversational text (RFC 4103 [RFC4103]), instant messaging, and video. SPEERMINT must support these services at the Interconnect point as part of support of access to Emergency Services if it is to be taken seriously as an alternative Interconnect for public telecommunications based on IP. /Barry Barry Dingle Fellow of University of Melbourne, Electrical and Electronic Eng., Australia Fixed - +61(0)3-9725-3937 Mob - +61(0)41-911-7578 > Supporter of Linux + Open Source software On Sat, Aug 1, 2009 at 12:10 AM, Gunnar Hellstrom < gunnar.hellstrom@omnitor.se> wrote: > I find it very sad to limit the scope of this specification to audio only, > and ask to widen the scope at least to real-time conversational sessions > including real-time text, video and audio. > > One motivation is that the work with emergency service calls in ECRIT > require a possibility to use real-time text, video and audio in emergency > calls. Such calls might need to be routed over a sip interconnection, and > thus need to get full support for its media. ( emergency calls are within > the scope list of this draft. ) > > There are a number of other valid reasons for this request. > > Hoping that it can accepted, I give here a first set of edit proposals to > bring the draft up to proper multimedia status. > > **************************************** > In 1.1 change from > "1.1. Scope > > The document focuses on the interworking procedures required to > support basic telephone service, including the following > capabilities: > > o On-net to on-net calls > " > To > " > 1.1. Scope > > The document focuses on the interworking procedures required to > support basic real-time conversational service, including the following > capabilities: > > o Video > o Real-time text > o On-net to on-net calls > " > > In 5.1.1. change from > " > 5.1.1. SDP Requirements > > SIP entities involved in session peering MUST support the SDP > requirements defined in [RFC4566]. A SIP entity involved in session > peering MUST include only one media (m=) descriptor in an SDP offer > to a peer network. If a SIP entity involved in session peering > receives an SDP offer containing multiple media descriptors, it > SHOULD act on the first audio descriptor with a non-zero port. > " > To > " > 5.1.1. SDP Requirements > > SIP entities involved in session peering MUST support the SDP > requirements defined in [RFC4566]. A SIP entity involved in session > peering MUST include only one media (m=) descriptor per desired media > stream in an SDP offer to a peer network. > > If a SIP entity involved in session peering receives an SDP offer > containing multiple media descriptors, it MUST act on the media > descriptors and include all of them in the same order in the > response, including non-zero ports and zero ports for the offered > media according to its capabilities as specified in [RFC 3264] > Offer - Answer model. An offered session MUST NOT be rejected > because it offers more media than the responding entity can handle. > " > > These wew just the apparent initial edits after rapid browsing of the > draft. > There is likely more to do to complete the topic. > - > > /Gunnar > > > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Monday, July 13, 2009 9:00 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-hancock-sip-interconnect-guidelines-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : draft-hancock-sip-interconnect-guidelines-01 > Author(s) : D. Hancock, D. Malas > Filename : draft-hancock-sip-interconnect-guidelines-01.txt > Pages : 25 > Date : 2009-07-13 > > As Session Initiation Protocol (SIP) peering becomes more widely accepted > by > service providers the need to define an interconnect guideline becomes of > greater value. This document takes into consideration the SIP and commonly > used SIP extensions, and it defines a fundamental set of requirements for > SIP Service Providers > (SSPs) to implement within their signaling functions (SFs) or Signaling > Path > Border Elements (SBEs) for peering. > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-hancock-sip-interconnect-guideline > s-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www.ietf.org/mailman/listinfo/speermint > --001485f1a1bc922efa04700f0ec2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,

I support the comments of Gunnar Hellstrom regarding the need fo= r=C2=A0 strong support of real-time text and video conversational services= in addition to voice in the SIP-Interconnect Guidelines.

RFC5012 (= ECRIT Requirements) in Section 5 has a requirement Re4 which states:

Re4.  Multi-mode communication:  IP-based emergency calls MUST sup=
port multiple communication modes, including, for example,
      audio, =
video, and text.

      Motivation: Within the PSTN, voice and text t=
elephony (often called TTY or text-phone in North America) are the only com=
monly

      supported media.  Emergency calling must support a variety of media. =
 Such media should include voice, conversational text (RFC
      4103 [R=
FC4103]), instant messaging, and video.
SPEERMINT must support the= se services at the Interconnect point as part of support of access to Emerg= ency Services if it is to be taken seriously as an alternative Interconnect= for public telecommunications based on IP.

/Barry

Barry Dingle
Fellow of University of Melbourne, Electr= ical and Electronic Eng., Australia
Fixed - +61(0)3-9725-3937 =C2=A0 = =C2=A0Mob - +61(0)41-911-7578
> Supporter of Linux + Open Source soft= ware


On Sat, Aug 1, 2009 at 12:10 AM, Gunnar = Hellstrom <gunnar.hellstrom@omnitor.se> wrote:
I find it very sad to limit the scope of this specification to audio only,<= br> and ask to widen the scope at least to real-time conversational sessions including real-time text, video and audio.

One motivation is that the work with emergency service calls in ECRIT
require a possibility to use real-time text, video and audio in emergency calls. Such calls might need to be routed over a sip interconnection, and thus need to get full support for its media. ( emergency calls are within the scope list of this draft. )

There are a number of other valid reasons for this request.

Hoping that it can accepted, I give here a first set of edit proposals to bring the draft up to proper multimedia status.

****************************************
In 1.1 =C2=A0change from
"1.1. =C2=A0Scope

=C2=A0 The document focuses on the interworking procedures required to
=C2=A0 support basic telephone service, including the following
=C2=A0 capabilities:

=C2=A0 o =C2=A0On-net to on-net calls
"
To
"
1.1. =C2=A0Scope

=C2=A0 The document focuses on the interworking procedures required to
=C2=A0 support basic real-time conversational service, including the follo= wing
=C2=A0 capabilities:

=C2=A0 o =C2=A0Video
=C2=A0 o =C2=A0Real-time text
=C2=A0 o =C2=A0On-net to on-net calls
"

In 5.1.1. =C2=A0change from
"
5.1.1. =C2=A0SDP Requirements

=C2=A0 SIP entities involved in session peering MUST support the SDP
=C2=A0 requirements defined in [RFC4566]. =C2=A0A SIP entity involved in s= ession
=C2=A0 peering MUST include only one media (m=3D) descriptor in an SDP off= er
=C2=A0 to a peer network. =C2=A0If a SIP entity involved in session peerin= g
=C2=A0 receives an SDP offer containing multiple media descriptors, it
=C2=A0 SHOULD act on the first audio descriptor with a non-zero port.
"
To
"
5.1.1. =C2=A0SDP Requirements

=C2=A0 SIP entities involved in session peering MUST support the SDP
=C2=A0 requirements defined in [RFC4566]. =C2=A0A SIP entity involved in s= ession
=C2=A0 peering MUST include only one media (m=3D) descriptor per desired m= edia
=C2=A0 stream in an SDP offer to a peer network.

=C2=A0 If a SIP entity involved in session peering receives an SDP offer =C2=A0 containing multiple media descriptors, it MUST act on the media
=C2=A0 descriptors and include all of them in the same order in the
=C2=A0 response, including non-zero ports and zero ports for the offered =C2=A0 media according to its capabilities as specified in [RFC 3264]
=C2=A0 Offer - Answer model. An offered session MUST NOT be rejected
=C2=A0 because it offers more media than the responding entity can handle.=
"

These wew just the apparent initial edits after rapid browsing of the draft= .
There is likely more to do to complete the topic.
-

/Gunnar


-----Original Message-----
From: i-d-announce-bounces= @ietf.org [mailto:i-d-= announce-bounces@ietf.org]
On Behalf Of Internet-Drafts@ie= tf.org
Sent: Monday, July 13, 2009 9:00 PM
To: i-d-announce@ietf.org
Subject: I-D Action:draft-hancock-sip-interconnect-guidelines-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

=C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : draf= t-hancock-sip-interconnect-guidelines-01
=C2=A0 =C2=A0 =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0 : D. Hancock, D.= Malas
=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-han= cock-sip-interconnect-guidelines-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 25 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2009-07-13

As Session Initiation Protocol (SIP) peering becomes more widely accepted b= y
service providers the need to define an interconnect guideline becomes of greater value. =C2=A0This document takes into consideration the SIP and com= monly
used SIP extensions, and it defines a fundamental set of requirements for SIP Service Providers
(SSPs) to implement within their signaling functions (SFs) or Signaling Pat= h
Border Elements (SBEs) for peering.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-dra= fts/draft-hancock-sip-interconnect-guideline
s-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www.ietf.org/mailman/listinfo/speermint

--001485f1a1bc922efa04700f0ec2--