From root@core3.amsl.com Tue Dec 1 03:15:01 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 874F33A6850; Tue, 1 Dec 2009 03:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091201111501.874F33A6850@core3.amsl.com> Date: Tue, 1 Dec 2009 03:15:01 -0800 (PST) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-keep-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 11:15: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 Initiation Protocol Core Working Group of the IETF. Title : Indication of support for keep-alive Author(s) : C. Holmberg Filename : draft-ietf-sipcore-keep-01.txt Pages : 11 Date : 2009-12-01 This specification defines a new SIP Via header parameter, "keep" which SIP entities can use to indicate support of the NAT keep-alive techniques defined in SIP Outbound, in cases where the Outbound procedures are not supported or cannot be applied. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 4, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-keep-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-sipcore-keep-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-01031026.I-D@ietf.org> --NextPart-- From christer.holmberg@ericsson.com Tue Dec 1 03:18:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 600833A684A for ; Tue, 1 Dec 2009 03:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 1YnAvwfTeuAs for ; Tue, 1 Dec 2009 03:18:31 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id AC17E28B23E for ; Tue, 1 Dec 2009 03:18:30 -0800 (PST) X-AuditID: c1b4fb24-b7beeae000003a71-1c-4b14fb7d1e4c Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 1D.45.14961.D7BF41B4; Tue, 1 Dec 2009 12:18:21 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 12:18:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA7277.FCC55AAE" Date: Tue, 1 Dec 2009 12:18:20 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft new version: keep Thread-Index: Acpyd/zn41lehazHToWSzx4xIiXFqQ== From: "Christer Holmberg" To: X-OriginalArrivalTime: 01 Dec 2009 11:18:21.0242 (UTC) FILETIME=[FD7469A0:01CA7277] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Draft new version: keep X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 11:18:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA7277.FCC55AAE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version of the keep draft. There are no changes from the previous version, but it had expired. I will produce a new version, with new content, once we get the info issues resolved - it has really taken more time than expected...=20 A new version of the info draft will be submitted tomorrow. Regards, Christer ------_=_NextPart_001_01CA7277.FCC55AAE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft new version: keep

Hi,

I've submitted a new version of the = keep draft. There are no changes from the previous version, but it had = expired.

I will produce a new version, with new = content, once we get the info issues resolved - it has really taken more = time than expected...

A new version of the info draft will be = submitted tomorrow.

Regards,

Christer

------_=_NextPart_001_01CA7277.FCC55AAE-- From oferg@radvision.com Tue Dec 1 03:43:00 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DFC628C0CE for ; Tue, 1 Dec 2009 03:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=1.044, 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 chQpmx3hZJRJ for ; Tue, 1 Dec 2009 03:42:59 -0800 (PST) Received: from eframer.radvision.com (rvil-eframer.radvision.com [80.74.106.104]) by core3.amsl.com (Postfix) with ESMTP id 2666E3A6819 for ; Tue, 1 Dec 2009 03:42:58 -0800 (PST) Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id nB1Bf5Wq013738 for sipcore@ietf.org; Tue, 1 Dec 2009 13:41:05 +0200 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id nB1Bf5OL013732 for ; Tue, 1 Dec 2009 13:41:05 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA727B.443419B2" Date: Tue, 1 Dec 2009 13:41:45 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rfc 5626 and connection-reuse-draft Thread-index: Acpye0K3LjR/HsBqR3We4R/z36Zxew== From: "Ofer Goren" To: Subject: [sipcore] rfc 5626 and connection-reuse-draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 11:43:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA727B.443419B2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All. =20 Going over RFC 5626, it looks like a superset of rules defined in connection-reuse draft. The RFC enhanced the basic feature for UDP, and added a keep alive mechanism, but all and all It looks like they both describe 2 different features describing means to use an open connection for multiple network-transactions from the server side. =20 What are the future plans for this draft? Will it be canceled due to the RFC existence? If not, any views on how those 2 features co-exist on a UE? What if an alias parameter contradicts a flow parameter? =20 Thanks, Ofer =20 _______________________________________________ If you lend someone $20, and never see that person again, it was probably worth the investment.=20 =20 P Before printing this email, kindly think about the environment ------_=_NextPart_001_01CA727B.443419B2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All.

 

Going over RFC 5626, it looks like a superset of = rules defined in connection-reuse draft. The RFC enhanced the basic feature = for UDP, and added a keep alive mechanism, but all and all It looks like they = both describe 2 different features describing means to use an open connection = for multiple network-transactions from the server side.

 

What are the future plans for this draft? Will it = be canceled due to the RFC existence? If not, any views on how those 2 = features co-exist on a UE? What if an alias parameter contradicts a flow = parameter?

 

Thanks,

Ofer

 

_____________= __________________________________

If you lend someone $20, and never see that person again, = it was probably worth the investment.

 

P = = Be= fore = printing this email, kindly think about the = environment

------_=_NextPart_001_01CA727B.443419B2-- From vkg@alcatel-lucent.com Tue Dec 1 06:55:02 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B4903A682B for ; Tue, 1 Dec 2009 06:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 FvMnO9moH5bV for ; Tue, 1 Dec 2009 06:55:01 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 407CD3A67E2 for ; Tue, 1 Dec 2009 06:55:01 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id nB1Esr85018464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Dec 2009 08:54:53 -0600 (CST) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id nB1EsqpV005613; Tue, 1 Dec 2009 08:54:53 -0600 (CST) Message-ID: <4B152E3C.8050904@alcatel-lucent.com> Date: Tue, 01 Dec 2009 08:54:52 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ofer Goren References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: sipcore@ietf.org Subject: Re: [sipcore] rfc 5626 and connection-reuse-draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 14:55:02 -0000 Ofer Goren wrote: > Going over RFC 5626, it looks like a superset of rules defined in > connection-reuse draft. The RFC enhanced the basic feature for UDP, and > added a keep alive mechanism, but all and all It looks like they both > describe 2 different features describing means to use an open connection > for multiple network-transactions from the server side. Ofer: The intersection of sip-outbound (now rfc5626) and sip-connect-reuse is detailed in Section 2 of the sip-connect-reuse draft. > What are the future plans for this draft? sip-connect-reuse is in the RFC editor's queue. It is currently blocked on sip-domain-certs reaching IESG since there is a dependency on sip-domain-certs. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From audet.francois@gmail.com Tue Dec 1 08:50:45 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA5E23A67B6 for ; Tue, 1 Dec 2009 08:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.726 X-Spam-Level: X-Spam-Status: No, score=-1.726 tagged_above=-999 required=5 tests=[AWL=0.873, 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 wuSxeoPmj2tb for ; Tue, 1 Dec 2009 08:50:45 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id DE02F3A67A1 for ; Tue, 1 Dec 2009 08:50:44 -0800 (PST) Received: by bwz23 with SMTP id 23so3741488bwz.29 for ; Tue, 01 Dec 2009 08:50:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=U+RcasUSrujGvwiIFeyxAI1oUtkz6b1wKtn6CKseuQY=; b=ZtkzegMJ8xk5tvKsyRcw0X4lSkwwYhvMjrbKX0jJeLdTMT9hq0SOVA41fKmZLHTMkp gNxw9Ahwy1GtIXGYF/C2Tb3l5WD+9tSu/PTQi6quwP56riMalhGpd1m3eVVMGJ5qCkJ9 Z2tvGZ0Z5WlbbFXsMJmtm4Esbcv1JjbQBHenE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=a/aJrK2NMEu9TOn5u3EvUtx9EYPjMUOVhzYZprprEKzOVdNuG76/sqLkuMNv6dED9K eMmAkL+/rzbERlZoE6vuvyEb0eDCSNnc1V/0yM/dxYel0YCNDVWfEWW9x3e8H3HGvjIA ET1rNpWbRIP7nfkHkF7g3Jos9iz9afnHE06Nc= Received: by 10.204.155.82 with SMTP id r18mr6218059bkw.180.1259686233293; Tue, 01 Dec 2009 08:50:33 -0800 (PST) Received: from ?172.17.1.16? (216.156.83.78.ptr.us.xo.net [216.156.83.78]) by mx.google.com with ESMTPS id 13sm90745bwz.2.2009.12.01.08.50.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Dec 2009 08:50:32 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Francois Audet In-Reply-To: <4B152E3C.8050904@alcatel-lucent.com> Date: Tue, 1 Dec 2009 08:50:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <16533E3A-6F3C-4D32-9EE8-FBE0368D61A8@gmail.com> References: <4B152E3C.8050904@alcatel-lucent.com> To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.1077) Cc: Ofer Goren , sipcore@ietf.org Subject: Re: [sipcore] rfc 5626 and connection-reuse-draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 16:50:45 -0000 On Dec 1, 2009, at 6:54 , Vijay K. Gurbani wrote: > Ofer Goren wrote: >> Going over RFC 5626, it looks like a superset of rules defined in = connection-reuse draft. The RFC enhanced the basic feature for UDP, and = added a keep alive mechanism, but all and all It looks like they both = describe 2 different features describing means to use an open connection = for multiple network-transactions from the server side. >=20 > Ofer: The intersection of sip-outbound (now rfc5626) and > sip-connect-reuse is detailed in Section 2 of the sip-connect-reuse > draft. Another way to view the place under the sun for 5626 vs connect-reuse is = that 5626 is typically going to be used between a UA and a = proxy/registrar, while connect-reuse is expected to be used between = proxies (or with servers such as voicemail servers, conference bridges = and so forth where. From oferg@radvision.com Tue Dec 1 08:52:46 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 980A93A68FD for ; Tue, 1 Dec 2009 08:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.697, 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 BwVnvQV+J4xP for ; Tue, 1 Dec 2009 08:52:45 -0800 (PST) Received: from eframer.radvision.com (rvil-eframer.radvision.com [80.74.106.104]) by core3.amsl.com (Postfix) with ESMTP id 66BC43A67B6 for ; Tue, 1 Dec 2009 08:52:45 -0800 (PST) Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id nB1GoqLs026382 for sipcore@ietf.org; Tue, 1 Dec 2009 18:50:52 +0200 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id nB1GonX7026372; Tue, 1 Dec 2009 18:50:49 +0200 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" Date: Tue, 1 Dec 2009 18:51:31 +0200 Message-ID: In-reply-to: <16533E3A-6F3C-4D32-9EE8-FBE0368D61A8@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc 5626 and connection-reuse-draft Thread-index: Acpypmf5wk4bBuktRkChida0ekaNxQAABlqg References: <4B152E3C.8050904@alcatel-lucent.com> <16533E3A-6F3C-4D32-9EE8-FBE0368D61A8@gmail.com> From: "Ofer Goren" To: "Francois Audet" , "Vijay K. Gurbani" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by eframer.radvision.com id nB1GonX7026372 Cc: sipcore@ietf.org Subject: Re: [sipcore] rfc 5626 and connection-reuse-draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 16:52:46 -0000 Thank you all. Ofer. -----Original Message----- From: Francois Audet [mailto:audet.francois@gmail.com] Sent: Tuesday, December 01, 2009 18:50 To: Vijay K. Gurbani Cc: Ofer Goren; sipcore@ietf.org Subject: Re: [sipcore] rfc 5626 and connection-reuse-draft On Dec 1, 2009, at 6:54 , Vijay K. Gurbani wrote: > Ofer Goren wrote: >> Going over RFC 5626, it looks like a superset of rules defined in connection-reuse draft. The RFC enhanced the basic feature for UDP, and added a keep alive mechanism, but all and all It looks like they both describe 2 different features describing means to use an open connection for multiple network-transactions from the server side. > > Ofer: The intersection of sip-outbound (now rfc5626) and > sip-connect-reuse is detailed in Section 2 of the sip-connect-reuse > draft. Another way to view the place under the sun for 5626 vs connect-reuse is that 5626 is typically going to be used between a UA and a proxy/registrar, while connect-reuse is expected to be used between proxies (or with servers such as voicemail servers, conference bridges and so forth where. From audet.francois@gmail.com Tue Dec 1 19:56:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F08233A682D for ; Tue, 1 Dec 2009 19:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 wEV+DIH9W9n3 for ; Tue, 1 Dec 2009 19:56:09 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 09A003A67AE for ; Tue, 1 Dec 2009 19:56:08 -0800 (PST) Received: by gxk28 with SMTP id 28so3016677gxk.9 for ; Tue, 01 Dec 2009 19:55:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=pJbKQ/D4mN9kfuMd8uU2K+fKxHN2VQtiX9YZw9gSQFM=; b=WokwI5IJtWEA0Gy7rUdQRG187moRDxgBKs2gbr3gXDwKG4I0ipuxB0pLUR/LMsLpmX BZWYz4xq3v7cKF1M+NCPiRAf8oKQBAc+JteycrETp/6zyCS2WQ2KLML4DhBymzkxWD1p feeQ/PRxy432GYQHPkTR6fF+2Qkw4IEVy4oWk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=o16iKMUlHeIsCeIpf0O09vvutzEI+lV3vzK3OhRKNOFlz6moQDnoblv7yEVNrnjxOk PvxcEKUd8jQgpYp8Fmx8eMNEFPDgD0g4vH1OwqrZ/VykwHeVs57ODI4Xw2B3U7e+lr/z WhSODbae8b6E4asYz9KrnfsXsjP+ol9nEzeBU= Received: by 10.91.147.14 with SMTP id z14mr6373922agn.105.1259726156949; Tue, 01 Dec 2009 19:55:56 -0800 (PST) Received: from ?192.168.15.104? (adsl-75-36-210-50.dsl.pltn13.sbcglobal.net [75.36.210.50]) by mx.google.com with ESMTPS id 39sm385972yxd.9.2009.12.01.19.55.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Dec 2009 19:55:55 -0800 (PST) Message-Id: <10A79C23-41FB-4FF8-AD55-2F83D7017EFC@gmail.com> From: Francois Audet To: Shida Schubert In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 1 Dec 2009 19:55:53 -0800 References: <4B13C4FC.5050907@sipstation.com> <98E67934-70CE-49E4-A2C3-05C3EB42573F@skype.net> X-Mailer: Apple Mail (2.936) Cc: sipcore@ietf.org Subject: Re: [sipcore] Some comments on draft-barnes-sipcore-rfc4244bis-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 03:56:10 -0000 That seems pretty reasonable to me. But... Perhaps we can clarify a bit more in explaining why a voicemail system would choose the first versus the last redirecting target. This is typically not a "configuration" as described in your example below (although, it is certainly possible). Typically, a voicemail system will choose the first one IF it is responsible for the mailbox of that target. Obviously, it would be impossible otherwise. In this latter case, the voicemail system would then use the last redirecting number. This is why I don't think we can put "normative" text, but instead "use case examples" as described above. A implementation could decide to always use the last redirecting number. On Nov 30, 2009, at 17:39 , Shida Schubert wrote: > > Francois; > > This was something Cullen asked we add to the draft too. > > I am assuming what we need is to add an explicit text that aids > voicemail server to identify the target of the voicemail box. > > If a call was initially received at Alice then diverted > to Carol, then to Bob which then diverts to voicemail, > the question is for which AoR should the voicemail server > leave a voicemail? > > I think the answer depends on the configuration > of the voicemail server. But with the "mp" tag and > "mp" index we can identify when the mapping > (diversion) took place making it much more > deterministic to identify the target of the voicemail box. > > Looking at the example from the draft below; > > History-Info: ;index=1 > History-Info: ;\ > index=1.1;rc > History-Info: ;index=1.2;mp=1 > History-Info: ;index=1.2.1;rc > History-Info: ;index=1.3;mp=1.2 > History-Info: ;index=1.3.1 > > If the voicemail server is configured to use the voicemail box > of the initial target it can look for the first mp tag and look > at the hi-entry that mp index references (bob@example.com). > > If the voicemail server is configured to use the voicemail box > of the last target then it can look for the last mp tag and look > at the hi-entry that mp index references (carol@example.com) etc. > > Regards > Shida > > On Dec 1, 2009, at 7:56 AM, Francois AUDET wrote: > >> >> On Nov 30, 2009, at 5:13 , Alan Johnston wrote: >> >>> >>> Does this document have a good voicemail example? This is the >>> application I am most interested in, so it would be nice to have a >>> very clear example of this. >>> >> >> That was the intent of section B.2 (in the appendix). >> >> Are you saying you'd want a better voicemail example? Or that we >> add more voicemail examples? What do you have in mind? >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > From audet.francois@gmail.com Tue Dec 1 19:59:55 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA5023A67AE for ; Tue, 1 Dec 2009 19:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 4vv+epUMMjJH for ; Tue, 1 Dec 2009 19:59:55 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id EF5DA3A6880 for ; Tue, 1 Dec 2009 19:59:54 -0800 (PST) Received: by gxk28 with SMTP id 28so3018692gxk.9 for ; Tue, 01 Dec 2009 19:59:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=ChCULfRZw05Rzt0sWDKiu1Bo8y5Mnyke2YdGbYXiqNQ=; b=B/gqi1hiwd2z1cDjWRdfs5m40ofmNCbSWOjxDZetULbswu1dJ/+lROa1bGHnjPE0hI 4GP9frIM+tfCT56bZbP9ms4rS487jZSf1W22glXsu24kcaLKuQOdAVwgjr0rEyN3/IL8 6j9vVNhXPmRB1cQfgmXUcC61onaUcewh3EPyg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=QbQjloSRhzt/PfJo5/FTASjOusax9kSFj/59RAaj5EgOLMY63RrCHF19dj77NJMGyQ PuusBNHaQ4Qudz+5OKRFHpSu9sQyUDeKxTJF2S7eb5heVv/q0zlMQpOM9rvlw7Uu9442 ZXH/Aa5i+qii9M6SVlNfyi2641OvDMAYZJpoY= Received: by 10.151.95.8 with SMTP id x8mr10675497ybl.26.1259726383341; Tue, 01 Dec 2009 19:59:43 -0800 (PST) Received: from ?192.168.15.104? (adsl-75-36-210-50.dsl.pltn13.sbcglobal.net [75.36.210.50]) by mx.google.com with ESMTPS id 15sm412968gxk.4.2009.12.01.19.59.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Dec 2009 19:59:42 -0800 (PST) Message-Id: <120EBF17-8D0F-427B-A1A7-F358F2757361@gmail.com> From: Francois Audet To: sipcore@ietf.org, Christer Holmberg In-Reply-To: <20091201111501.874F33A6850@core3.amsl.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 1 Dec 2009 19:59:39 -0800 References: <20091201111501.874F33A6850@core3.amsl.com> X-Mailer: Apple Mail (2.936) Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-keep-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 03:59:56 -0000 Should update reference to outbound to RFC 5626. On Dec 1, 2009, at 03:15 , Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session Initiation Protocol Core > Working Group of the IETF. > > > Title : Indication of support for keep-alive > Author(s) : C. Holmberg > Filename : draft-ietf-sipcore-keep-01.txt > Pages : 11 > Date : 2009-12-01 > > This specification defines a new SIP Via header parameter, "keep" > which SIP entities can use to indicate support of the NAT keep-alive > techniques defined in SIP Outbound, in cases where the Outbound > procedures are not supported or cannot be applied. > > Status of this Memo > > This Internet-Draft is submitted to IETF in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on June 4, 2010. > > Copyright Notice > > Copyright (c) 2009 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the BSD License. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-keep-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. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From shida@ntt-at.com Tue Dec 1 21:28:34 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF2E3A6765 for ; Tue, 1 Dec 2009 21:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 j6eZeXsjloaf for ; Tue, 1 Dec 2009 21:28:33 -0800 (PST) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [67.18.82.4]) by core3.amsl.com (Postfix) with SMTP id 7602E3A67AB for ; Tue, 1 Dec 2009 21:28:33 -0800 (PST) Received: (qmail 17148 invoked from network); 2 Dec 2009 05:42:18 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway13.websitewelcome.com with SMTP; 2 Dec 2009 05:42:18 -0000 Received: from fl1-118-109-66-179.tky.mesh.ad.jp ([118.109.66.179]:63098 helo=[192.168.1.5]) by gator465.hostgator.com with esmtpa (Exim 4.69) (envelope-from ) id 1NFhl3-00028c-Vj; Tue, 01 Dec 2009 23:28:10 -0600 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <10A79C23-41FB-4FF8-AD55-2F83D7017EFC@gmail.com> Date: Wed, 2 Dec 2009 14:28:22 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <057B55FD-2B09-4296-AB60-6FA7E47EDD37@ntt-at.com> References: <4B13C4FC.5050907@sipstation.com> <98E67934-70CE-49E4-A2C3-05C3EB42573F@skype.net> <10A79C23-41FB-4FF8-AD55-2F83D7017EFC@gmail.com> To: Francois Audet X-Mailer: Apple Mail (2.1077) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Cc: sipcore@ietf.org Subject: Re: [sipcore] Some comments on draft-barnes-sipcore-rfc4244bis-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 05:28:34 -0000 I don't think we need normative text, the whole examples are=20 in appendix anyways, but I think what people want is to have=20 explicit text on how one can determine the first versus the=20 last redirecting target. I am not the one asking for them so=20 I can't speak for them though..=20 Regards Shida On Dec 2, 2009, at 12:55 PM, Francois Audet wrote: > That seems pretty reasonable to me. But... >=20 > Perhaps we can clarify a bit more in explaining why a voicemail system = would choose the first versus the last redirecting target. This is = typically not a "configuration" as described in your example below = (although, it is certainly possible). >=20 > Typically, a voicemail system will choose the first one IF it is = responsible for the mailbox of that target. Obviously, it would be = impossible otherwise. In this latter case, the voicemail system would = then use the last redirecting number. >=20 > This is why I don't think we can put "normative" text, but instead = "use case examples" as described above. A implementation could decide to = always use the last redirecting number. >=20 > On Nov 30, 2009, at 17:39 , Shida Schubert wrote: >=20 >>=20 >> Francois; >>=20 >> This was something Cullen asked we add to the draft too. >>=20 >> I am assuming what we need is to add an explicit text that aids >> voicemail server to identify the target of the voicemail box. >>=20 >> If a call was initially received at Alice then diverted >> to Carol, then to Bob which then diverts to voicemail, >> the question is for which AoR should the voicemail server >> leave a voicemail? >>=20 >> I think the answer depends on the configuration >> of the voicemail server. But with the "mp" tag and >> "mp" index we can identify when the mapping >> (diversion) took place making it much more >> deterministic to identify the target of the voicemail box. >>=20 >> Looking at the example from the draft below; >>=20 >> History-Info: ;index=3D1 >> History-Info: ;\ >> index=3D1.1;rc >> History-Info: ;index=3D1.2;mp=3D1 >> History-Info: ;index=3D1.2.1;rc >> History-Info: ;index=3D1.3;mp=3D1.2 >> History-Info: ;index=3D1.3.1 >>=20 >> If the voicemail server is configured to use the voicemail box >> of the initial target it can look for the first mp tag and look >> at the hi-entry that mp index references (bob@example.com). >>=20 >> If the voicemail server is configured to use the voicemail box >> of the last target then it can look for the last mp tag and look >> at the hi-entry that mp index references (carol@example.com) etc. >>=20 >> Regards >> Shida >>=20 >> On Dec 1, 2009, at 7:56 AM, Francois AUDET wrote: >>=20 >>>=20 >>> On Nov 30, 2009, at 5:13 , Alan Johnston wrote: >>>=20 >>>>=20 >>>> Does this document have a good voicemail example? This is the = application I am most interested in, so it would be nice to have a very = clear example of this. >>>>=20 >>>=20 >>> That was the intent of section B.2 (in the appendix). >>>=20 >>> Are you saying you'd want a better voicemail example? Or that we add = more voicemail examples? What do you have in mind? >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >=20 From audet.francois@gmail.com Tue Dec 1 21:55:58 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ABDC3A6805 for ; Tue, 1 Dec 2009 21:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 e--VFV4WzOIZ for ; Tue, 1 Dec 2009 21:55:57 -0800 (PST) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id 599AE3A67EE for ; Tue, 1 Dec 2009 21:55:57 -0800 (PST) Received: by ywh15 with SMTP id 15so5026821ywh.5 for ; Tue, 01 Dec 2009 21:55:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=QsCbX61k/jsvEcijOzu8nzj/e/hmKafvqI2JZNrK09s=; b=Z2r5CH9AvpCBIDh2FHLNu2M7nfZFT/LhP9KcfqxAg+jxfcq6dZuxzwiRDJZUQf/VKQ yfdfLrBaRkLOlhMzXBJZhzd+VXH4Wx4K/kc7hZ/IQxGUMuOVAdOV3qvoQI0BFH5gnb+x 43FSf5GIL2QtJ52In0OIcCa2nEai31YoQcjXQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=kf9DdtrDoTcC2pdR/ru98qFjGTmbTuq+pgjyQo+zmuB5Iq9IzwlC8HbMdB4PvfvYVr XhcCIO1HsVxbTsvsD1pS2spUp0x3ncB0sxcSscTOCAFchrMMbXXqds2dk1P9UYyjUn5Y z2+1hRM6aniWK7Z+B69t2P0VVKoAmzGp2C+p8= Received: by 10.90.14.35 with SMTP id 35mr681140agn.73.1259733346802; Tue, 01 Dec 2009 21:55:46 -0800 (PST) Received: from ?192.168.15.105? (adsl-75-36-210-50.dsl.pltn13.sbcglobal.net [75.36.210.50]) by mx.google.com with ESMTPS id 4sm422851yxd.34.2009.12.01.21.55.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Dec 2009 21:55:46 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Francois Audet In-Reply-To: <057B55FD-2B09-4296-AB60-6FA7E47EDD37@ntt-at.com> Date: Tue, 1 Dec 2009 21:55:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <059F6FEF-F9CF-4DD1-9A07-2ABFC75D48A4@gmail.com> References: <4B13C4FC.5050907@sipstation.com> <98E67934-70CE-49E4-A2C3-05C3EB42573F@skype.net> <10A79C23-41FB-4FF8-AD55-2F83D7017EFC@gmail.com> <057B55FD-2B09-4296-AB60-6FA7E47EDD37@ntt-at.com> To: Shida Schubert , JENNINGS Cullen X-Mailer: Apple Mail (2.1077) Cc: sipcore@ietf.org Subject: Re: [sipcore] Some comments on draft-barnes-sipcore-rfc4244bis-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 05:55:58 -0000 Cullen, Alan, what do you think? On Dec 1, 2009, at 21:28 , Shida Schubert wrote: >=20 > I don't think we need normative text, the whole examples are=20 > in appendix anyways, but I think what people want is to have=20 > explicit text on how one can determine the first versus the=20 > last redirecting target. I am not the one asking for them so=20 > I can't speak for them though..=20 >=20 > Regards > Shida >=20 > On Dec 2, 2009, at 12:55 PM, Francois Audet wrote: >=20 >> That seems pretty reasonable to me. But... >>=20 >> Perhaps we can clarify a bit more in explaining why a voicemail = system would choose the first versus the last redirecting target. This = is typically not a "configuration" as described in your example below = (although, it is certainly possible). >>=20 >> Typically, a voicemail system will choose the first one IF it is = responsible for the mailbox of that target. Obviously, it would be = impossible otherwise. In this latter case, the voicemail system would = then use the last redirecting number. >>=20 >> This is why I don't think we can put "normative" text, but instead = "use case examples" as described above. A implementation could decide to = always use the last redirecting number. >>=20 >> On Nov 30, 2009, at 17:39 , Shida Schubert wrote: >>=20 >>>=20 >>> Francois; >>>=20 >>> This was something Cullen asked we add to the draft too. >>>=20 >>> I am assuming what we need is to add an explicit text that aids >>> voicemail server to identify the target of the voicemail box. >>>=20 >>> If a call was initially received at Alice then diverted >>> to Carol, then to Bob which then diverts to voicemail, >>> the question is for which AoR should the voicemail server >>> leave a voicemail? >>>=20 >>> I think the answer depends on the configuration >>> of the voicemail server. But with the "mp" tag and >>> "mp" index we can identify when the mapping >>> (diversion) took place making it much more >>> deterministic to identify the target of the voicemail box. >>>=20 >>> Looking at the example from the draft below; >>>=20 >>> History-Info: ;index=3D1 >>> History-Info: ;\ >>> index=3D1.1;rc >>> History-Info: ;index=3D1.2;mp=3D1 >>> History-Info: ;index=3D1.2.1;rc >>> History-Info: ;index=3D1.3;mp=3D1.2 >>> History-Info: ;index=3D1.3.1 >>>=20 >>> If the voicemail server is configured to use the voicemail box >>> of the initial target it can look for the first mp tag and look >>> at the hi-entry that mp index references (bob@example.com). >>>=20 >>> If the voicemail server is configured to use the voicemail box >>> of the last target then it can look for the last mp tag and look >>> at the hi-entry that mp index references (carol@example.com) etc. >>>=20 >>> Regards >>> Shida >>>=20 >>> On Dec 1, 2009, at 7:56 AM, Francois AUDET wrote: >>>=20 >>>>=20 >>>> On Nov 30, 2009, at 5:13 , Alan Johnston wrote: >>>>=20 >>>>>=20 >>>>> Does this document have a good voicemail example? This is the = application I am most interested in, so it would be nice to have a very = clear example of this. >>>>>=20 >>>>=20 >>>> That was the intent of section B.2 (in the appendix). >>>>=20 >>>> Are you saying you'd want a better voicemail example? Or that we = add more voicemail examples? What do you have in mind? >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>=20 >>=20 >=20 From R.Jesske@telekom.de Wed Dec 2 00:12:58 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 939B23A6A5E for ; Wed, 2 Dec 2009 00:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 InumN1mpLv85 for ; Wed, 2 Dec 2009 00:12:57 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 19B9D3A6A5A for ; Wed, 2 Dec 2009 00:12:50 -0800 (PST) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 02 Dec 2009 09:12:36 +0100 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 09:12:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Dec 2009 09:12:33 +0100 Message-ID: <9886E5FCA6D76549A3011068483A4BD40551C3B6@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <057B55FD-2B09-4296-AB60-6FA7E47EDD37@ntt-at.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Some comments on draft-barnes-sipcore-rfc4244bis-03 thread-index: AcpzEEqVfFYd2JrdTfOknJza4wXqCAAEJ3IQ References: <4B13C4FC.5050907@sipstation.com><98E67934-70CE-49E4-A2C3-05C3EB42573F@skype.net><10A79C23-41FB-4FF8-AD55-2F83D7017EFC@gmail.com> <057B55FD-2B09-4296-AB60-6FA7E47EDD37@ntt-at.com> From: To: , X-OriginalArrivalTime: 02 Dec 2009 08:12:35.0214 (UTC) FILETIME=[345142E0:01CA7327] Cc: sipcore@ietf.org Subject: Re: [sipcore] Some comments on draft-barnes-sipcore-rfc4244bis-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 08:12:58 -0000 Hi Shida and Fran=E7ois, I have never heard about an implementation that a forwarding service = will choose the first entry for voicemail. Should I see this more in the surrounding of private networks/PBX? Seen from the diverting user either I would like to forward my call to = an other URI or to an voicemail service. But that is a decision that the = diverting user is taking. Best Regards Roland=20 -----Urspr=FCngliche Nachricht----- Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im = Auftrag von Shida Schubert Gesendet: Mittwoch, 2. Dezember 2009 06:28 An: Francois Audet Cc: sipcore@ietf.org Betreff: Re: [sipcore] Some comments on = draft-barnes-sipcore-rfc4244bis-03 I don't think we need normative text, the whole examples are=20 in appendix anyways, but I think what people want is to have=20 explicit text on how one can determine the first versus the=20 last redirecting target. I am not the one asking for them so=20 I can't speak for them though..=20 Regards Shida On Dec 2, 2009, at 12:55 PM, Francois Audet wrote: > That seems pretty reasonable to me. But... >=20 > Perhaps we can clarify a bit more in explaining why a voicemail system = would choose the first versus the last redirecting target. This is = typically not a "configuration" as described in your example below = (although, it is certainly possible). >=20 > Typically, a voicemail system will choose the first one IF it is = responsible for the mailbox of that target. Obviously, it would be = impossible otherwise. In this latter case, the voicemail system would = then use the last redirecting number. >=20 > This is why I don't think we can put "normative" text, but instead = "use case examples" as described above. A implementation could decide to = always use the last redirecting number. >=20 > On Nov 30, 2009, at 17:39 , Shida Schubert wrote: >=20 >>=20 >> Francois; >>=20 >> This was something Cullen asked we add to the draft too. >>=20 >> I am assuming what we need is to add an explicit text that aids >> voicemail server to identify the target of the voicemail box. >>=20 >> If a call was initially received at Alice then diverted >> to Carol, then to Bob which then diverts to voicemail, >> the question is for which AoR should the voicemail server >> leave a voicemail? >>=20 >> I think the answer depends on the configuration >> of the voicemail server. But with the "mp" tag and >> "mp" index we can identify when the mapping >> (diversion) took place making it much more >> deterministic to identify the target of the voicemail box. >>=20 >> Looking at the example from the draft below; >>=20 >> History-Info: ;index=3D1 >> History-Info: ;\ >> index=3D1.1;rc >> History-Info: ;index=3D1.2;mp=3D1 >> History-Info: ;index=3D1.2.1;rc >> History-Info: ;index=3D1.3;mp=3D1.2 >> History-Info: ;index=3D1.3.1 >>=20 >> If the voicemail server is configured to use the voicemail box >> of the initial target it can look for the first mp tag and look >> at the hi-entry that mp index references (bob@example.com). >>=20 >> If the voicemail server is configured to use the voicemail box >> of the last target then it can look for the last mp tag and look >> at the hi-entry that mp index references (carol@example.com) etc. >>=20 >> Regards >> Shida >>=20 >> On Dec 1, 2009, at 7:56 AM, Francois AUDET wrote: >>=20 >>>=20 >>> On Nov 30, 2009, at 5:13 , Alan Johnston wrote: >>>=20 >>>>=20 >>>> Does this document have a good voicemail example? This is the = application I am most interested in, so it would be nice to have a very = clear example of this. >>>>=20 >>>=20 >>> That was the intent of section B.2 (in the appendix). >>>=20 >>> Are you saying you'd want a better voicemail example? Or that we add = more voicemail examples? What do you have in mind? >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From shida@ntt-at.com Wed Dec 2 00:47:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 376CF3A68B6 for ; Wed, 2 Dec 2009 00:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 1ZLRYpiYbgim for ; Wed, 2 Dec 2009 00:47:37 -0800 (PST) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [67.18.55.5]) by core3.amsl.com (Postfix) with SMTP id 9058A28C176 for ; Wed, 2 Dec 2009 00:47:09 -0800 (PST) Received: (qmail 16281 invoked from network); 2 Dec 2009 09:03:10 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway04.websitewelcome.com with SMTP; 2 Dec 2009 09:03:10 -0000 Received: from fl1-118-109-66-179.tky.mesh.ad.jp ([118.109.66.179]:61866 helo=[192.168.1.5]) by gator465.hostgator.com with esmtpa (Exim 4.69) (envelope-from ) id 1NFkrS-0001GY-QD; Wed, 02 Dec 2009 02:46:59 -0600 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Shida Schubert In-Reply-To: <9886E5FCA6D76549A3011068483A4BD40551C3B6@S4DE8PSAAQB.mitte.t-com.de> Date: Wed, 2 Dec 2009 17:46:57 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <6CE3300B-C549-4A03-95B7-324DCD9EC531@ntt-at.com> References: <4B13C4FC.5050907@sipstation.com><98E67934-70CE-49E4-A2C3-05C3EB42573F@skype.net><10A79C23-41FB-4FF8-AD55-2F83D7017EFC@gmail.com> <057B55FD-2B09-4296-AB60-6FA7E47EDD37@ntt-at.com> <9886E5FCA6D76549A3011068483A4BD40551C3B6@S4DE8PSAAQB.mitte.t-com.de> To: X-Mailer: Apple Mail (2.1077) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Cc: audet.francois@gmail.com, sipcore@ietf.org Subject: Re: [sipcore] Some comments on draft-barnes-sipcore-rfc4244bis-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 08:47:38 -0000 Roland; I agree for service provider like us it's always the=20 last diverting user that is the target for voicemail.=20 I could imagine though that call may be diverted to=20 several people (AoR) before going to a voicemail server=20 within a corporate realm, in which case the target=20 may be the first entry who configured the server to=20 divert calls to several AoRs before diverting to a=20 voicemail server..=20 Regards Shida On Dec 2, 2009, at 5:12 PM, = wrote: > Hi Shida and Fran=E7ois, > I have never heard about an implementation that a forwarding service = will choose the first entry for voicemail. > Should I see this more in the surrounding of private networks/PBX? >=20 > Seen from the diverting user either I would like to forward my call to = an other URI or to an voicemail service. But that is a decision that the = diverting user is taking. >=20 >=20 > Best Regards > Roland=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im = Auftrag von Shida Schubert > Gesendet: Mittwoch, 2. Dezember 2009 06:28 > An: Francois Audet > Cc: sipcore@ietf.org > Betreff: Re: [sipcore] Some comments on = draft-barnes-sipcore-rfc4244bis-03 >=20 >=20 > I don't think we need normative text, the whole examples are=20 > in appendix anyways, but I think what people want is to have=20 > explicit text on how one can determine the first versus the=20 > last redirecting target. I am not the one asking for them so=20 > I can't speak for them though..=20 >=20 > Regards > Shida >=20 > On Dec 2, 2009, at 12:55 PM, Francois Audet wrote: >=20 >> That seems pretty reasonable to me. But... >>=20 >> Perhaps we can clarify a bit more in explaining why a voicemail = system would choose the first versus the last redirecting target. This = is typically not a "configuration" as described in your example below = (although, it is certainly possible). >>=20 >> Typically, a voicemail system will choose the first one IF it is = responsible for the mailbox of that target. Obviously, it would be = impossible otherwise. In this latter case, the voicemail system would = then use the last redirecting number. >>=20 >> This is why I don't think we can put "normative" text, but instead = "use case examples" as described above. A implementation could decide to = always use the last redirecting number. >>=20 >> On Nov 30, 2009, at 17:39 , Shida Schubert wrote: >>=20 >>>=20 >>> Francois; >>>=20 >>> This was something Cullen asked we add to the draft too. >>>=20 >>> I am assuming what we need is to add an explicit text that aids >>> voicemail server to identify the target of the voicemail box. >>>=20 >>> If a call was initially received at Alice then diverted >>> to Carol, then to Bob which then diverts to voicemail, >>> the question is for which AoR should the voicemail server >>> leave a voicemail? >>>=20 >>> I think the answer depends on the configuration >>> of the voicemail server. But with the "mp" tag and >>> "mp" index we can identify when the mapping >>> (diversion) took place making it much more >>> deterministic to identify the target of the voicemail box. >>>=20 >>> Looking at the example from the draft below; >>>=20 >>> History-Info: ;index=3D1 >>> History-Info: ;\ >>> index=3D1.1;rc >>> History-Info: ;index=3D1.2;mp=3D1 >>> History-Info: ;index=3D1.2.1;rc >>> History-Info: ;index=3D1.3;mp=3D1.2 >>> History-Info: ;index=3D1.3.1 >>>=20 >>> If the voicemail server is configured to use the voicemail box >>> of the initial target it can look for the first mp tag and look >>> at the hi-entry that mp index references (bob@example.com). >>>=20 >>> If the voicemail server is configured to use the voicemail box >>> of the last target then it can look for the last mp tag and look >>> at the hi-entry that mp index references (carol@example.com) etc. >>>=20 >>> Regards >>> Shida >>>=20 >>> On Dec 1, 2009, at 7:56 AM, Francois AUDET wrote: >>>=20 >>>>=20 >>>> On Nov 30, 2009, at 5:13 , Alan Johnston wrote: >>>>=20 >>>>>=20 >>>>> Does this document have a good voicemail example? This is the = application I am most interested in, so it would be nice to have a very = clear example of this. >>>>>=20 >>>>=20 >>>> That was the intent of section B.2 (in the appendix). >>>>=20 >>>> Are you saying you'd want a better voicemail example? Or that we = add more voicemail examples? What do you have in mind? >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>=20 >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Wed Dec 2 00:59:41 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66DFA3A6A17 for ; Wed, 2 Dec 2009 00:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 lCHNQoqugYHB for ; Wed, 2 Dec 2009 00:59:40 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id CEF283A6A05 for ; Wed, 2 Dec 2009 00:59:39 -0800 (PST) X-AuditID: c1b4fb24-b7beeae000003a71-34-4b162c72a9a7 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id BE.3B.14961.27C261B4; Wed, 2 Dec 2009 09:59:30 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 09:59:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA732D.BF309136" Date: Wed, 2 Dec 2009 09:59:24 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft new version: draft-ietf-sipcore-info-events Thread-Index: AcpzLb7Lh5r3v7HMQUeW2vZ6PKSQ3Q== From: "Christer Holmberg" To: X-OriginalArrivalTime: 02 Dec 2009 08:59:25.0714 (UTC) FILETIME=[BF818720:01CA732D] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Draft new version: draft-ietf-sipcore-info-events X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 08:59:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA732D.BF309136 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version of the info draft. Hopefully all comments and feedback have now been addressed. The biggest changes are: - Section 4.2: The usage of the Recv-Info header has been clarified, some simple rules have been added, and there were some discussions that since the re-INVITE fallback issue also affects Recv-Info (if you receive a Recv-Info in a 18x to a re-INVITE, and the re-INVITE then fails) and that we need some words about that. The text now says that IF the request contains a Recv-Info header, the response must also contain it. - Section 11.4: Contains new wording about the IANA process for registering info packages, including the expert review etc. - Section 12: Additional examples have been added Please note that I did NOT remove Recv-Info in PRACKs, since there in my opinion was no concensus to do so. The draft can also be found at: http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-info-events-03 .txt Regards, Christer ------_=_NextPart_001_01CA732D.BF309136 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft new version: draft-ietf-sipcore-info-events

Hi,

I've submitted a new version of the = info draft. Hopefully all comments and feedback have now been = addressed.

The biggest changes are:

- Section 4.2: The usage of the = Recv-Info header has been clarified, some simple rules have been added, = and there were some discussions that since the re-INVITE fallback issue = also affects Recv-Info (if you receive a Recv-Info in a 18x to a = re-INVITE, and the re-INVITE then fails) and that we need some words = about that. The text now says that IF the request contains a Recv-Info = header, the response must also contain it.

- Section 11.4: Contains new wording = about the IANA process for registering info packages, including the = expert review etc.

- Section 12: Additional examples have = been added


Please note that I did NOT remove = Recv-Info in PRACKs, since there in my opinion was no concensus to do = so.


The draft can also be found at:

http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-= info-events-03.txt


Regards,

Christer

------_=_NextPart_001_01CA732D.BF309136-- From root@core3.amsl.com Wed Dec 2 01:00:02 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2E3CC3A6A17; Wed, 2 Dec 2009 01:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091202090002.2E3CC3A6A17@core3.amsl.com> Date: Wed, 2 Dec 2009 01:00:02 -0800 (PST) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-info-events-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 09:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Session Initiation Protocol (SIP) INFO Method and Package Framework Author(s) : E. Burger, et al. Filename : draft-ietf-sipcore-info-events-03.txt Pages : 38 Date : 2009-12-02 This document defines a new method, INFO, for the Session Initiation Protocol (SIP) [RFC3261], and an Info Package mechanism. The document obsoletes [RFC2976]. For backward compatibility the document also specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in [RFC2976], referred to as "legacy INFO Usage" in this document. Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The terminology in this document conforms to the Internet Security Glossary [RFC4949]. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 5, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-info-events-03.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-sipcore-info-events-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-02005416.I-D@ietf.org> --NextPart-- From christer.holmberg@ericsson.com Wed Dec 2 01:13:44 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 264E83A6A80 for ; Wed, 2 Dec 2009 01:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 qzL3TR5VBCF0 for ; Wed, 2 Dec 2009 01:13:43 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 388C03A6A7C for ; Wed, 2 Dec 2009 01:13:38 -0800 (PST) X-AuditID: c1b4fb24-b7beeae000003a71-f9-4b162fb45788 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 10.5C.14961.4BF261B4; Wed, 2 Dec 2009 10:13:24 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 10:13:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA732F.B30AF2F6" Date: Wed, 2 Dec 2009 10:13:16 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft new version: draft-ietf-sipcore-199 Thread-Index: AcpzL67TDqfjY2gURQKM1g491HUr+w== From: "Christer Holmberg" To: X-OriginalArrivalTime: 02 Dec 2009 09:13:24.0305 (UTC) FILETIME=[B3585C10:01CA732F] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Draft new version: draft-ietf-sipcore-199 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 09:13:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA732F.B30AF2F6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've posted a new version (-01) of the 199 draft, based on Robert's AD comments. Regards, Christer ------_=_NextPart_001_01CA732F.B30AF2F6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft new version: draft-ietf-sipcore-199

Hi,

I've posted a new version (-01) of the = 199 draft, based on Robert's AD comments.

Regards,

Christer

------_=_NextPart_001_01CA732F.B30AF2F6-- From root@core3.amsl.com Wed Dec 2 01:15:01 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 975C83A6A80; Wed, 2 Dec 2009 01:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091202091501.975C83A6A80@core3.amsl.com> Date: Wed, 2 Dec 2009 01:15:01 -0800 (PST) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-199-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 09:15: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 Initiation Protocol Core Working Group of the IETF. Title : Response Code for Indication of Terminated Dialog Author(s) : C. Holmberg Filename : draft-ietf-sipcore-199-01.txt Pages : 16 Date : 2009-12-02 This specification defines a new SIP response code, 199 Early Dialog Terminated, which a SIP forking proxy and a UAS can use to indicate upstream towards the UAC that an early dialog has been terminated, before a final response is sent towards the UAC. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 5, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-199-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-sipcore-199-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-02011242.I-D@ietf.org> --NextPart-- From pkyzivat@cisco.com Wed Dec 2 06:01:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E5F73A6AC6 for ; Wed, 2 Dec 2009 06:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 CR4AZ9P-zlUW for ; Wed, 2 Dec 2009 06:01:18 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 52B043A6AD0 for ; Wed, 2 Dec 2009 06:01:17 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGkCFkurRN+J/2dsb2JhbAC/UZgOgi6CAwQ X-IronPort-AV: E=Sophos;i="4.47,328,1257120000"; d="scan'208";a="443911510" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 02 Dec 2009 14:01:04 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nB2E13Lk023016; Wed, 2 Dec 2009 14:01:04 GMT Received: from xfe-rtp-211.amer.cisco.com ([64.102.31.113]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 09:01:03 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 09:01:02 -0500 Message-ID: <4B16731E.20000@cisco.com> Date: Wed, 02 Dec 2009 09:01:02 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: R.Jesske@telekom.de References: <4B13C4FC.5050907@sipstation.com><98E67934-70CE-49E4-A2C3-05C3EB42573F@skype.net><10A79C23-41FB-4FF8-AD55-2F83D7017EFC@gmail.com> <057B55FD-2B09-4296-AB60-6FA7E47EDD37@ntt-at.com> <9886E5FCA6D76549A3011068483A4BD40551C3B6@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD40551C3B6@S4DE8PSAAQB.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 02 Dec 2009 14:01:02.0810 (UTC) FILETIME=[E2373BA0:01CA7357] Cc: audet.francois@gmail.com, sipcore@ietf.org Subject: Re: [sipcore] Some comments on draft-barnes-sipcore-rfc4244bis-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 14:01:19 -0000 R.Jesske@telekom.de wrote: > Hi Shida and François, > I have never heard about an implementation that a forwarding service will choose the first entry for voicemail. > Should I see this more in the surrounding of private networks/PBX? > > Seen from the diverting user either I would like to forward my call to an other URI or to an voicemail service. But that is a decision that the diverting user is taking. IMO the diverting user should have the option to attempt a diversion to another number but have the call go to his own voicemail if that diversion fails - preempting subsequent diversion to another's voicemail. But that should *not* depend on on the downstream users using the same VM server. Its a matter of the diverting user entering a preference that the call not go to voicemail downstream. Callerprefs has a mechanism to indicate this, but I have never heard of it being supported for this. This would of course be *policy*. In other cases I might indeed want to delegate full responsibility for the call, including going to voicemail. Unfortunately, making this work requires that the diversion target cooperate. Thanks, Paul > > Best Regards > Roland > > -----Ursprüngliche Nachricht----- > Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im Auftrag von Shida Schubert > Gesendet: Mittwoch, 2. Dezember 2009 06:28 > An: Francois Audet > Cc: sipcore@ietf.org > Betreff: Re: [sipcore] Some comments on draft-barnes-sipcore-rfc4244bis-03 > > > I don't think we need normative text, the whole examples are > in appendix anyways, but I think what people want is to have > explicit text on how one can determine the first versus the > last redirecting target. I am not the one asking for them so > I can't speak for them though.. > > Regards > Shida > > On Dec 2, 2009, at 12:55 PM, Francois Audet wrote: > >> That seems pretty reasonable to me. But... >> >> Perhaps we can clarify a bit more in explaining why a voicemail system would choose the first versus the last redirecting target. This is typically not a "configuration" as described in your example below (although, it is certainly possible). >> >> Typically, a voicemail system will choose the first one IF it is responsible for the mailbox of that target. Obviously, it would be impossible otherwise. In this latter case, the voicemail system would then use the last redirecting number. >> >> This is why I don't think we can put "normative" text, but instead "use case examples" as described above. A implementation could decide to always use the last redirecting number. >> >> On Nov 30, 2009, at 17:39 , Shida Schubert wrote: >> >>> Francois; >>> >>> This was something Cullen asked we add to the draft too. >>> >>> I am assuming what we need is to add an explicit text that aids >>> voicemail server to identify the target of the voicemail box. >>> >>> If a call was initially received at Alice then diverted >>> to Carol, then to Bob which then diverts to voicemail, >>> the question is for which AoR should the voicemail server >>> leave a voicemail? >>> >>> I think the answer depends on the configuration >>> of the voicemail server. But with the "mp" tag and >>> "mp" index we can identify when the mapping >>> (diversion) took place making it much more >>> deterministic to identify the target of the voicemail box. >>> >>> Looking at the example from the draft below; >>> >>> History-Info: ;index=1 >>> History-Info: ;\ >>> index=1.1;rc >>> History-Info: ;index=1.2;mp=1 >>> History-Info: ;index=1.2.1;rc >>> History-Info: ;index=1.3;mp=1.2 >>> History-Info: ;index=1.3.1 >>> >>> If the voicemail server is configured to use the voicemail box >>> of the initial target it can look for the first mp tag and look >>> at the hi-entry that mp index references (bob@example.com). >>> >>> If the voicemail server is configured to use the voicemail box >>> of the last target then it can look for the last mp tag and look >>> at the hi-entry that mp index references (carol@example.com) etc. >>> >>> Regards >>> Shida >>> >>> On Dec 1, 2009, at 7:56 AM, Francois AUDET wrote: >>> >>>> On Nov 30, 2009, at 5:13 , Alan Johnston wrote: >>>> >>>>> Does this document have a good voicemail example? This is the application I am most interested in, so it would be nice to have a very clear example of this. >>>>> >>>> That was the intent of section B.2 (in the appendix). >>>> >>>> Are you saying you'd want a better voicemail example? Or that we add more voicemail examples? What do you have in mind? >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From R.Jesske@telekom.de Wed Dec 2 07:07:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 876983A68D4 for ; Wed, 2 Dec 2009 07:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 73IeeGAuSgyT for ; Wed, 2 Dec 2009 07:07:08 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 66C343A6873 for ; Wed, 2 Dec 2009 07:07:07 -0800 (PST) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 02 Dec 2009 16:02:46 +0100 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 16:02:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Dec 2009 16:02:41 +0100 Message-ID: <9886E5FCA6D76549A3011068483A4BD40551C7A0@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <4B16731E.20000@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Some comments on draft-barnes-sipcore-rfc4244bis-03 thread-index: AcpzWKN85trzCfnbRWqHmEIFahTZqwAB1sRA References: <4B13C4FC.5050907@sipstation.com><98E67934-70CE-49E4-A2C3-05C3EB42573F@skype.net><10A79C23-41FB-4FF8-AD55-2F83D7017EFC@gmail.com> <057B55FD-2B09-4296-AB60-6FA7E47EDD37@ntt-at.com> <9886E5FCA6D76549A3011068483A4BD40551C3B6@S4DE8PSAAQB.mitte.t-com.de> <4B16731E.20000@cisco.com> From: To: X-OriginalArrivalTime: 02 Dec 2009 15:02:46.0202 (UTC) FILETIME=[819C01A0:01CA7360] Cc: audet.francois@gmail.com, sipcore@ietf.org Subject: Re: [sipcore] Some comments on draft-barnes-sipcore-rfc4244bis-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 15:07:09 -0000 The only application I could think about is a company's network where = one call agent has a couple of replacements and if they are not = reachable then the voicemail of the originally called UA is then put in = charge. But As Paul said that is a policy within a private network/PBX and will = never happen for an operator approach. So if such an example will be put = into, then the circumstances should be described explicitly. Thanks you and Best Regards Roland=20 -----Urspr=FCngliche Nachricht----- Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Gesendet: Mittwoch, 2. Dezember 2009 15:01 An: Jesske, Roland Cc: shida@ntt-at.com; audet.francois@gmail.com; sipcore@ietf.org Betreff: Re: [sipcore] Some comments on = draft-barnes-sipcore-rfc4244bis-03 R.Jesske@telekom.de wrote: > Hi Shida and Fran=E7ois, > I have never heard about an implementation that a forwarding service = will choose the first entry for voicemail. > Should I see this more in the surrounding of private networks/PBX? >=20 > Seen from the diverting user either I would like to forward my call to = an other URI or to an voicemail service. But that is a decision that the = diverting user is taking. IMO the diverting user should have the option to attempt a diversion to=20 another number but have the call go to his own voicemail if that=20 diversion fails - preempting subsequent diversion to another's = voicemail. But that should *not* depend on on the downstream users using the same=20 VM server. Its a matter of the diverting user entering a preference that = the call not go to voicemail downstream. Callerprefs has a mechanism to=20 indicate this, but I have never heard of it being supported for this. This would of course be *policy*. In other cases I might indeed want to=20 delegate full responsibility for the call, including going to voicemail. Unfortunately, making this work requires that the diversion target=20 cooperate. Thanks, Paul >=20 > Best Regards > Roland=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im = Auftrag von Shida Schubert > Gesendet: Mittwoch, 2. Dezember 2009 06:28 > An: Francois Audet > Cc: sipcore@ietf.org > Betreff: Re: [sipcore] Some comments on = draft-barnes-sipcore-rfc4244bis-03 >=20 >=20 > I don't think we need normative text, the whole examples are=20 > in appendix anyways, but I think what people want is to have=20 > explicit text on how one can determine the first versus the=20 > last redirecting target. I am not the one asking for them so=20 > I can't speak for them though..=20 >=20 > Regards > Shida >=20 > On Dec 2, 2009, at 12:55 PM, Francois Audet wrote: >=20 >> That seems pretty reasonable to me. But... >> >> Perhaps we can clarify a bit more in explaining why a voicemail = system would choose the first versus the last redirecting target. This = is typically not a "configuration" as described in your example below = (although, it is certainly possible). >> >> Typically, a voicemail system will choose the first one IF it is = responsible for the mailbox of that target. Obviously, it would be = impossible otherwise. In this latter case, the voicemail system would = then use the last redirecting number. >> >> This is why I don't think we can put "normative" text, but instead = "use case examples" as described above. A implementation could decide to = always use the last redirecting number. >> >> On Nov 30, 2009, at 17:39 , Shida Schubert wrote: >> >>> Francois; >>> >>> This was something Cullen asked we add to the draft too. >>> >>> I am assuming what we need is to add an explicit text that aids >>> voicemail server to identify the target of the voicemail box. >>> >>> If a call was initially received at Alice then diverted >>> to Carol, then to Bob which then diverts to voicemail, >>> the question is for which AoR should the voicemail server >>> leave a voicemail? >>> >>> I think the answer depends on the configuration >>> of the voicemail server. But with the "mp" tag and >>> "mp" index we can identify when the mapping >>> (diversion) took place making it much more >>> deterministic to identify the target of the voicemail box. >>> >>> Looking at the example from the draft below; >>> >>> History-Info: ;index=3D1 >>> History-Info: ;\ >>> index=3D1.1;rc >>> History-Info: ;index=3D1.2;mp=3D1 >>> History-Info: ;index=3D1.2.1;rc >>> History-Info: ;index=3D1.3;mp=3D1.2 >>> History-Info: ;index=3D1.3.1 >>> >>> If the voicemail server is configured to use the voicemail box >>> of the initial target it can look for the first mp tag and look >>> at the hi-entry that mp index references (bob@example.com). >>> >>> If the voicemail server is configured to use the voicemail box >>> of the last target then it can look for the last mp tag and look >>> at the hi-entry that mp index references (carol@example.com) etc. >>> >>> Regards >>> Shida >>> >>> On Dec 1, 2009, at 7:56 AM, Francois AUDET wrote: >>> >>>> On Nov 30, 2009, at 5:13 , Alan Johnston wrote: >>>> >>>>> Does this document have a good voicemail example? This is the = application I am most interested in, so it would be nice to have a very = clear example of this. >>>>> >>>> That was the intent of section B.2 (in the appendix). >>>> >>>> Are you saying you'd want a better voicemail example? Or that we = add more voicemail examples? What do you have in mind? >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From audet.francois@gmail.com Wed Dec 2 09:20:18 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C40C3A6ACB for ; Wed, 2 Dec 2009 09:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.437, 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 VDtZPm08G0wY for ; Wed, 2 Dec 2009 09:20:17 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 2198C3A6A3E for ; Wed, 2 Dec 2009 09:20:17 -0800 (PST) Received: by gxk28 with SMTP id 28so352024gxk.9 for ; Wed, 02 Dec 2009 09:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=8Y1a0xT1UDecSqm9z4kmD6ItifM6lHGAWCh3Z3GbXUk=; b=uQaOOCDBDVgiwpI7w8vAc1d/AQM4dhIwlKrSaQ/JFaz+aKxgv1ClNUBwniZSX5u4lb h90YUKx/Wh94S7IG07Js64LNKDF6mUJJFn9lBhkex2stEZXTPOoNSiohJWWBAvskviVO dENWEfeKUkPuwe3vxk44BVTW2zQdg7hl/U1+w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=a0fXYbwUZjD21Ak3PKCfwslNnxFNH3gxDMv8sqjWG7r9s+RG1YBR7PXmDzGM9Tmddg wRYNhFIaONUDEunN1Mdz9NS+pzvmOVOlq76YKMOshdhhvLZe9BMn9iSvVgP1ilWQGmhj XH9YuZhVIN/5VVLkd2Tx/OcHuPvRG1TQkaNWg= Received: by 10.151.18.19 with SMTP id v19mr806154ybi.66.1259774402172; Wed, 02 Dec 2009 09:20:02 -0800 (PST) Received: from ?172.17.1.16? (216.156.83.78.ptr.us.xo.net [216.156.83.78]) by mx.google.com with ESMTPS id 15sm704649gxk.12.2009.12.02.09.20.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Dec 2009 09:20:01 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Francois Audet In-Reply-To: <9886E5FCA6D76549A3011068483A4BD40551C3B6@S4DE8PSAAQB.mitte.t-com.de> Date: Wed, 2 Dec 2009 09:19:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <52DC7475-F576-4397-B1CF-0C6ED6540089@gmail.com> References: <4B13C4FC.5050907@sipstation.com><98E67934-70CE-49E4-A2C3-05C3EB42573F@skype.net><10A79C23-41FB-4FF8-AD55-2F83D7017EFC@gmail.com> <057B55FD-2B09-4296-AB60-6FA7E47EDD37@ntt-at.com> <9886E5FCA6D76549A3011068483A4BD40551C3B6@S4DE8PSAAQB.mitte.t-com.de> To: X-Mailer: Apple Mail (2.1077) Cc: sipcore@ietf.org Subject: Re: [sipcore] Some comments on draft-barnes-sipcore-rfc4244bis-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 17:20:18 -0000 Yeah, PBXs do this. I was told that service providers do this to. When you think about it, it makes sense. If you call me, you would expect to get my voicemail, not somebody = else's. On Dec 2, 2009, at 0:12 , wrote: > Hi Shida and Fran=E7ois, > I have never heard about an implementation that a forwarding service = will choose the first entry for voicemail. > Should I see this more in the surrounding of private networks/PBX? >=20 > Seen from the diverting user either I would like to forward my call to = an other URI or to an voicemail service. But that is a decision that the = diverting user is taking. >=20 >=20 > Best Regards > Roland=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im = Auftrag von Shida Schubert > Gesendet: Mittwoch, 2. Dezember 2009 06:28 > An: Francois Audet > Cc: sipcore@ietf.org > Betreff: Re: [sipcore] Some comments on = draft-barnes-sipcore-rfc4244bis-03 >=20 >=20 > I don't think we need normative text, the whole examples are=20 > in appendix anyways, but I think what people want is to have=20 > explicit text on how one can determine the first versus the=20 > last redirecting target. I am not the one asking for them so=20 > I can't speak for them though..=20 >=20 > Regards > Shida >=20 > On Dec 2, 2009, at 12:55 PM, Francois Audet wrote: >=20 >> That seems pretty reasonable to me. But... >>=20 >> Perhaps we can clarify a bit more in explaining why a voicemail = system would choose the first versus the last redirecting target. This = is typically not a "configuration" as described in your example below = (although, it is certainly possible). >>=20 >> Typically, a voicemail system will choose the first one IF it is = responsible for the mailbox of that target. Obviously, it would be = impossible otherwise. In this latter case, the voicemail system would = then use the last redirecting number. >>=20 >> This is why I don't think we can put "normative" text, but instead = "use case examples" as described above. A implementation could decide to = always use the last redirecting number. >>=20 >> On Nov 30, 2009, at 17:39 , Shida Schubert wrote: >>=20 >>>=20 >>> Francois; >>>=20 >>> This was something Cullen asked we add to the draft too. >>>=20 >>> I am assuming what we need is to add an explicit text that aids >>> voicemail server to identify the target of the voicemail box. >>>=20 >>> If a call was initially received at Alice then diverted >>> to Carol, then to Bob which then diverts to voicemail, >>> the question is for which AoR should the voicemail server >>> leave a voicemail? >>>=20 >>> I think the answer depends on the configuration >>> of the voicemail server. But with the "mp" tag and >>> "mp" index we can identify when the mapping >>> (diversion) took place making it much more >>> deterministic to identify the target of the voicemail box. >>>=20 >>> Looking at the example from the draft below; >>>=20 >>> History-Info: ;index=3D1 >>> History-Info: ;\ >>> index=3D1.1;rc >>> History-Info: ;index=3D1.2;mp=3D1 >>> History-Info: ;index=3D1.2.1;rc >>> History-Info: ;index=3D1.3;mp=3D1.2 >>> History-Info: ;index=3D1.3.1 >>>=20 >>> If the voicemail server is configured to use the voicemail box >>> of the initial target it can look for the first mp tag and look >>> at the hi-entry that mp index references (bob@example.com). >>>=20 >>> If the voicemail server is configured to use the voicemail box >>> of the last target then it can look for the last mp tag and look >>> at the hi-entry that mp index references (carol@example.com) etc. >>>=20 >>> Regards >>> Shida >>>=20 >>> On Dec 1, 2009, at 7:56 AM, Francois AUDET wrote: >>>=20 >>>>=20 >>>> On Nov 30, 2009, at 5:13 , Alan Johnston wrote: >>>>=20 >>>>>=20 >>>>> Does this document have a good voicemail example? This is the = application I am most interested in, so it would be nice to have a very = clear example of this. >>>>>=20 >>>>=20 >>>> That was the intent of section B.2 (in the appendix). >>>>=20 >>>> Are you saying you'd want a better voicemail example? Or that we = add more voicemail examples? What do you have in mind? >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>=20 >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Wed Dec 2 09:25:36 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FE6E3A67EF for ; Wed, 2 Dec 2009 09:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 2aj8GEq2Rlg6 for ; Wed, 2 Dec 2009 09:25:34 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 985643A67C1 for ; Wed, 2 Dec 2009 09:25:34 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcFADMyFktAZnwN/2dsb2JhbACZQaZsl3yCLoIDBA X-IronPort-AV: E=Sophos;i="4.47,329,1257120000"; d="scan'208";a="71550219" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 02 Dec 2009 17:25:26 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nB2HPQ3n013865; Wed, 2 Dec 2009 17:25:26 GMT Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 12:25:26 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 12:25:25 -0500 Message-ID: <4B16A305.5090700@cisco.com> Date: Wed, 02 Dec 2009 12:25:25 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: R.Jesske@telekom.de References: <4B13C4FC.5050907@sipstation.com><98E67934-70CE-49E4-A2C3-05C3EB42573F@skype.net><10A79C23-41FB-4FF8-AD55-2F83D7017EFC@gmail.com> <057B55FD-2B09-4296-AB60-6FA7E47EDD37@ntt-at.com> <9886E5FCA6D76549A3011068483A4BD40551C3B6@S4DE8PSAAQB.mitte.t-com.de> <4B16731E.20000@cisco.com> <9886E5FCA6D76549A3011068483A4BD40551C7A0@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD40551C7A0@S4DE8PSAAQB.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 02 Dec 2009 17:25:25.0863 (UTC) FILETIME=[6F909F70:01CA7374] Cc: audet.francois@gmail.com, sipcore@ietf.org Subject: Re: [sipcore] Some comments on draft-barnes-sipcore-rfc4244bis-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 17:25:36 -0000 R.Jesske@telekom.de wrote: > The only application I could think about is a company's network where one call agent has a couple of replacements and if they are not reachable then the voicemail of the originally called UA is then put in charge. > > But As Paul said that is a policy within a private network/PBX and will never happen for an operator approach. So if such an example will be put into, then the circumstances should be described explicitly. Some cases that are (IMO) very plausible: 1) I want incoming calls to my cellphone to divert to my home phone if I don't answer. But if there is no answer at home either, then I want the call to go to my cellphone voicemail. (Because I'm more likely to check that in a timely way.) 2) I want calls to my office phone to try my personal cell phone if I'm not in the office. But I want any messages left on my office voicemail because it is corporate policy not to have business stuff recorded on VM servers it doesn't control. 3) When I'm at lunch, I want calls to my business line to try the person who backs me up when I'm away. But if that person can't take the call then I want it on my voicemail to deal with after lunch. (Converse to this: When I'm on *vacation*, I want calls to my business line to try the person who backs me up. If they can't answer, then I want messages left on *their* vm, so that they can deal with it later. Don't want callers waiting until I get back from vacation.) Thanks, Paul > Thanks you and Best Regards > > Roland > > -----Ursprüngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Gesendet: Mittwoch, 2. Dezember 2009 15:01 > An: Jesske, Roland > Cc: shida@ntt-at.com; audet.francois@gmail.com; sipcore@ietf.org > Betreff: Re: [sipcore] Some comments on draft-barnes-sipcore-rfc4244bis-03 > > > > R.Jesske@telekom.de wrote: >> Hi Shida and François, >> I have never heard about an implementation that a forwarding service will choose the first entry for voicemail. >> Should I see this more in the surrounding of private networks/PBX? >> >> Seen from the diverting user either I would like to forward my call to an other URI or to an voicemail service. But that is a decision that the diverting user is taking. > > IMO the diverting user should have the option to attempt a diversion to > another number but have the call go to his own voicemail if that > diversion fails - preempting subsequent diversion to another's voicemail. > > But that should *not* depend on on the downstream users using the same > VM server. Its a matter of the diverting user entering a preference that > the call not go to voicemail downstream. Callerprefs has a mechanism to > indicate this, but I have never heard of it being supported for this. > > This would of course be *policy*. In other cases I might indeed want to > delegate full responsibility for the call, including going to voicemail. > > Unfortunately, making this work requires that the diversion target > cooperate. > > Thanks, > Paul > >> Best Regards >> Roland >> >> -----Ursprüngliche Nachricht----- >> Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im Auftrag von Shida Schubert >> Gesendet: Mittwoch, 2. Dezember 2009 06:28 >> An: Francois Audet >> Cc: sipcore@ietf.org >> Betreff: Re: [sipcore] Some comments on draft-barnes-sipcore-rfc4244bis-03 >> >> >> I don't think we need normative text, the whole examples are >> in appendix anyways, but I think what people want is to have >> explicit text on how one can determine the first versus the >> last redirecting target. I am not the one asking for them so >> I can't speak for them though.. >> >> Regards >> Shida >> >> On Dec 2, 2009, at 12:55 PM, Francois Audet wrote: >> >>> That seems pretty reasonable to me. But... >>> >>> Perhaps we can clarify a bit more in explaining why a voicemail system would choose the first versus the last redirecting target. This is typically not a "configuration" as described in your example below (although, it is certainly possible). >>> >>> Typically, a voicemail system will choose the first one IF it is responsible for the mailbox of that target. Obviously, it would be impossible otherwise. In this latter case, the voicemail system would then use the last redirecting number. >>> >>> This is why I don't think we can put "normative" text, but instead "use case examples" as described above. A implementation could decide to always use the last redirecting number. >>> >>> On Nov 30, 2009, at 17:39 , Shida Schubert wrote: >>> >>>> Francois; >>>> >>>> This was something Cullen asked we add to the draft too. >>>> >>>> I am assuming what we need is to add an explicit text that aids >>>> voicemail server to identify the target of the voicemail box. >>>> >>>> If a call was initially received at Alice then diverted >>>> to Carol, then to Bob which then diverts to voicemail, >>>> the question is for which AoR should the voicemail server >>>> leave a voicemail? >>>> >>>> I think the answer depends on the configuration >>>> of the voicemail server. But with the "mp" tag and >>>> "mp" index we can identify when the mapping >>>> (diversion) took place making it much more >>>> deterministic to identify the target of the voicemail box. >>>> >>>> Looking at the example from the draft below; >>>> >>>> History-Info: ;index=1 >>>> History-Info: ;\ >>>> index=1.1;rc >>>> History-Info: ;index=1.2;mp=1 >>>> History-Info: ;index=1.2.1;rc >>>> History-Info: ;index=1.3;mp=1.2 >>>> History-Info: ;index=1.3.1 >>>> >>>> If the voicemail server is configured to use the voicemail box >>>> of the initial target it can look for the first mp tag and look >>>> at the hi-entry that mp index references (bob@example.com). >>>> >>>> If the voicemail server is configured to use the voicemail box >>>> of the last target then it can look for the last mp tag and look >>>> at the hi-entry that mp index references (carol@example.com) etc. >>>> >>>> Regards >>>> Shida >>>> >>>> On Dec 1, 2009, at 7:56 AM, Francois AUDET wrote: >>>> >>>>> On Nov 30, 2009, at 5:13 , Alan Johnston wrote: >>>>> >>>>>> Does this document have a good voicemail example? This is the application I am most interested in, so it would be nice to have a very clear example of this. >>>>>> >>>>> That was the intent of section B.2 (in the appendix). >>>>> >>>>> Are you saying you'd want a better voicemail example? Or that we add more voicemail examples? What do you have in mind? >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > From john.elwell@siemens-enterprise.com Wed Dec 2 12:15:49 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B44E23A694D for ; Wed, 2 Dec 2009 12:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 k5HRgeTPhOyg for ; Wed, 2 Dec 2009 12:15:48 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 8563A3A6964 for ; Wed, 2 Dec 2009 12:15:47 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-186413; Wed, 2 Dec 2009 21:15:36 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 59B8923F01FD; Wed, 2 Dec 2009 21:15:36 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 2 Dec 2009 21:15:36 +0100 From: "Elwell, John" To: Paul Kyzivat , "R.Jesske@telekom.de" Date: Wed, 2 Dec 2009 21:15:34 +0100 Thread-Topic: [sipcore] Some comments on draft-barnes-sipcore-rfc4244bis-03 Thread-Index: AcpzdHJfWkK4TnDgTXW0eDAdd99J2wAFwjtw Message-ID: References: <4B13C4FC.5050907@sipstation.com><98E67934-70CE-49E4-A2C3-05C3EB42573F@skype.net><10A79C23-41FB-4FF8-AD55-2F83D7017EFC@gmail.com> <057B55FD-2B09-4296-AB60-6FA7E47EDD37@ntt-at.com> <9886E5FCA6D76549A3011068483A4BD40551C3B6@S4DE8PSAAQB.mitte.t-com.de> <4B16731E.20000@cisco.com> <9886E5FCA6D76549A3011068483A4BD40551C7A0@S4DE8PSAAQB.mitte.t-com.de> <4B16A305.5090700@cisco.com> In-Reply-To: <4B16A305.5090700@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "audet.francois@gmail.com" , "sipcore@ietf.org" Subject: Re: [sipcore] Some comments on draft-barnes-sipcore-rfc4244bis-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 20:15:49 -0000 I agree with these examples Paul has enumerated, and I personally use the s= econd one. It relies on my domain proxy stepping in and cancelling the call= to my cellphone before it has chance to divert to cellphone (personal) voi= cemail (unless of course I have disabled that capability). As Paul pointed = out earlier, SIP does have a means of doing it using caller preferences, bu= t this doesn't work if the call goes to PSTN. John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 02 December 2009 17:25 > To: R.Jesske@telekom.de > Cc: audet.francois@gmail.com; sipcore@ietf.org > Subject: Re: [sipcore] Some comments on=20 > draft-barnes-sipcore-rfc4244bis-03 >=20 >=20 >=20 > R.Jesske@telekom.de wrote: > > The only application I could think about is a company's=20 > network where one call agent has a couple of replacements and=20 > if they are not reachable then the voicemail of the=20 > originally called UA is then put in charge. > >=20 > > But As Paul said that is a policy within a private=20 > network/PBX and will never happen for an operator approach.=20 > So if such an example will be put into, then the=20 > circumstances should be described explicitly. >=20 > Some cases that are (IMO) very plausible: >=20 > 1) I want incoming calls to my cellphone to divert to my home phone > if I don't answer. But if there is no answer at home either, > then I want the call to go to my cellphone voicemail. (Because > I'm more likely to check that in a timely way.) >=20 > 2) I want calls to my office phone to try my personal cell phone > if I'm not in the office. But I want any messages left on my > office voicemail because it is corporate policy not to have > business stuff recorded on VM servers it doesn't control. >=20 > 3) When I'm at lunch, I want calls to my business line to try > the person who backs me up when I'm away. But if that person > can't take the call then I want it on my voicemail to deal > with after lunch. >=20 > (Converse to this: When I'm on *vacation*, I want calls to my > business line to try the person who backs me up. If they can't > answer, then I want messages left on *their* vm, so that they > can deal with it later. Don't want callers waiting until I get > back from vacation.) >=20 > Thanks, > Paul >=20 > > Thanks you and Best Regards > >=20 > > Roland=20 > >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > > Gesendet: Mittwoch, 2. Dezember 2009 15:01 > > An: Jesske, Roland > > Cc: shida@ntt-at.com; audet.francois@gmail.com; sipcore@ietf.org > > Betreff: Re: [sipcore] Some comments on=20 > draft-barnes-sipcore-rfc4244bis-03 > >=20 > >=20 > >=20 > > R.Jesske@telekom.de wrote: > >> Hi Shida and Fran=E7ois, > >> I have never heard about an implementation that a=20 > forwarding service will choose the first entry for voicemail. > >> Should I see this more in the surrounding of private networks/PBX? > >> > >> Seen from the diverting user either I would like to=20 > forward my call to an other URI or to an voicemail service.=20 > But that is a decision that the diverting user is taking. > >=20 > > IMO the diverting user should have the option to attempt a=20 > diversion to=20 > > another number but have the call go to his own voicemail if that=20 > > diversion fails - preempting subsequent diversion to=20 > another's voicemail. > >=20 > > But that should *not* depend on on the downstream users=20 > using the same=20 > > VM server. Its a matter of the diverting user entering a=20 > preference that=20 > > the call not go to voicemail downstream. Callerprefs has a=20 > mechanism to=20 > > indicate this, but I have never heard of it being supported=20 > for this. > >=20 > > This would of course be *policy*. In other cases I might=20 > indeed want to=20 > > delegate full responsibility for the call, including going=20 > to voicemail. > >=20 > > Unfortunately, making this work requires that the diversion target=20 > > cooperate. > >=20 > > Thanks, > > Paul > >=20 > >> Best Regards > >> Roland=20 > >> > >> -----Urspr=FCngliche Nachricht----- > >> Von: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] Im Auftrag von Shida Schubert > >> Gesendet: Mittwoch, 2. Dezember 2009 06:28 > >> An: Francois Audet > >> Cc: sipcore@ietf.org > >> Betreff: Re: [sipcore] Some comments on=20 > draft-barnes-sipcore-rfc4244bis-03 > >> > >> > >> I don't think we need normative text, the whole examples are=20 > >> in appendix anyways, but I think what people want is to have=20 > >> explicit text on how one can determine the first versus the=20 > >> last redirecting target. I am not the one asking for them so=20 > >> I can't speak for them though..=20 > >> > >> Regards > >> Shida > >> > >> On Dec 2, 2009, at 12:55 PM, Francois Audet wrote: > >> > >>> That seems pretty reasonable to me. But... > >>> > >>> Perhaps we can clarify a bit more in explaining why a=20 > voicemail system would choose the first versus the last=20 > redirecting target. This is typically not a "configuration"=20 > as described in your example below (although, it is certainly=20 > possible). > >>> > >>> Typically, a voicemail system will choose the first one=20 > IF it is responsible for the mailbox of that target.=20 > Obviously, it would be impossible otherwise. In this latter=20 > case, the voicemail system would then use the last redirecting number. > >>> > >>> This is why I don't think we can put "normative" text,=20 > but instead "use case examples" as described above. A=20 > implementation could decide to always use the last redirecting number. > >>> > >>> On Nov 30, 2009, at 17:39 , Shida Schubert wrote: > >>> > >>>> Francois; > >>>> > >>>> This was something Cullen asked we add to the draft too. > >>>> > >>>> I am assuming what we need is to add an explicit text that aids > >>>> voicemail server to identify the target of the voicemail box. > >>>> > >>>> If a call was initially received at Alice then diverted > >>>> to Carol, then to Bob which then diverts to voicemail, > >>>> the question is for which AoR should the voicemail server > >>>> leave a voicemail? > >>>> > >>>> I think the answer depends on the configuration > >>>> of the voicemail server. But with the "mp" tag and > >>>> "mp" index we can identify when the mapping > >>>> (diversion) took place making it much more > >>>> deterministic to identify the target of the voicemail box. > >>>> > >>>> Looking at the example from the draft below; > >>>> > >>>> History-Info: ;index=3D1 > >>>> History-Info: ;\ > >>>> index=3D1.1;rc > >>>> History-Info: ;index=3D1.2;mp=3D1 > >>>> History-Info: ;index=3D1.2.1;rc > >>>> History-Info: ;index=3D1.3;mp=3D1.2 > >>>> History-Info: ;index=3D1.3.1 > >>>> > >>>> If the voicemail server is configured to use the voicemail box > >>>> of the initial target it can look for the first mp tag and look > >>>> at the hi-entry that mp index references (bob@example.com). > >>>> > >>>> If the voicemail server is configured to use the voicemail box > >>>> of the last target then it can look for the last mp tag and look > >>>> at the hi-entry that mp index references (carol@example.com) etc. > >>>> > >>>> Regards > >>>> Shida > >>>> > >>>> On Dec 1, 2009, at 7:56 AM, Francois AUDET wrote: > >>>> > >>>>> On Nov 30, 2009, at 5:13 , Alan Johnston wrote: > >>>>> > >>>>>> Does this document have a good voicemail example? =20 > This is the application I am most interested in, so it would=20 > be nice to have a very clear example of this. > >>>>>> > >>>>> That was the intent of section B.2 (in the appendix). > >>>>> > >>>>> Are you saying you'd want a better voicemail example?=20 > Or that we add more voicemail examples? What do you have in mind? > >>>>> _______________________________________________ > >>>>> sipcore mailing list > >>>>> sipcore@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sipcore > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From adam@estacado.net Fri Dec 4 15:51:08 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA3193A6A6F for ; Fri, 4 Dec 2009 15:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RDNS_DYNAMIC=0.1] 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 DuvSz64OQdSr for ; Fri, 4 Dec 2009 15:51:08 -0800 (PST) Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id 1730E3A6A4A for ; Fri, 4 Dec 2009 15:51:08 -0800 (PST) Received: from [172.16.3.231] (dn3-231.estacado.net [172.16.3.231]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id nB4NnhlQ037928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 4 Dec 2009 17:49:44 -0600 (CST) (envelope-from adam@estacado.net) Message-ID: <4B19A017.1090402@estacado.net> Date: Fri, 04 Dec 2009 17:49:43 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091130 Thunderbird/3.0 MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sipcore] Call for consensus: adopting draft-camarillo-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 23:51:08 -0000 [as chair] Regarding the following milestone on our charter: Invite Transaction Handling Correction to IESG (PS) To fulfill this milestone, there are two potential problems that may need to be addressed. One of them relates to handling of 200-class responses to INVITE messages; the other relates to re-INVITE and target refresh handling. The first problem is addressed by an adopted working group item (draft-ietf-sipcore-invfix). We do not currently have an adopted item for the second problem. The chairs would like to solicit feedback from the group regarding adoption of draft-camarillo-sipcore-reinvite as a working group item to fix the second set of problems. Please comment on the SIPCORE mailing list. If you agree with this adoption, a simple note stating as much is encouraged: we cannot determine consensus without feedback, and silence is not very informative. Thanks! /a From pkyzivat@cisco.com Fri Dec 4 16:26:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28FCB3A679C for ; Fri, 4 Dec 2009 16:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 jqMGAEcY8CIb for ; Fri, 4 Dec 2009 16:26:03 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 60B3B3A65A6 for ; Fri, 4 Dec 2009 16:26:01 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4FAKM3GUtAZnwM/2dsb2JhbACZI6VzlyyEMwQ X-IronPort-AV: E=Sophos;i="4.47,344,1257120000"; d="scan'208";a="72132904" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 05 Dec 2009 00:25:52 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nB50Pq2J020424; Sat, 5 Dec 2009 00:25:52 GMT Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 19:25:52 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 19:25:51 -0500 Message-ID: <4B19A88F.3030008@cisco.com> Date: Fri, 04 Dec 2009 19:25:51 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <4B19A017.1090402@estacado.net> In-Reply-To: <4B19A017.1090402@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Dec 2009 00:25:51.0672 (UTC) FILETIME=[80251B80:01CA7541] Cc: SIPCORE Subject: Re: [sipcore] Call for consensus: adopting draft-camarillo-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 00:26:04 -0000 yes, adopt draft-camarillo-sipcore-reinvite Thanks, Paul Adam Roach wrote: > [as chair] > > Regarding the following milestone on our charter: > > Invite Transaction Handling Correction to IESG (PS) > > To fulfill this milestone, there are two potential problems that may > need to be addressed. One of them relates to handling of 200-class > responses to INVITE messages; the other relates to re-INVITE and target > refresh handling. > > The first problem is addressed by an adopted working group item > (draft-ietf-sipcore-invfix). We do not currently have an adopted item > for the second problem. > > The chairs would like to solicit feedback from the group regarding > adoption of draft-camarillo-sipcore-reinvite as a working group item to > fix the second set of problems. Please comment on the SIPCORE mailing > list. If you agree with this adoption, a simple note stating as much is > encouraged: we cannot determine consensus without feedback, and silence > is not very informative. > > Thanks! > > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From shida@ntt-at.com Fri Dec 4 22:19:15 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8E623A67B1 for ; Fri, 4 Dec 2009 22:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 jsj7mU1aRcOg for ; Fri, 4 Dec 2009 22:19:12 -0800 (PST) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [67.18.71.3]) by core3.amsl.com (Postfix) with SMTP id 0BCD23A6880 for ; Fri, 4 Dec 2009 22:18:56 -0800 (PST) Received: (qmail 24714 invoked from network); 5 Dec 2009 06:32:40 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway12.websitewelcome.com with SMTP; 5 Dec 2009 06:32:40 -0000 Received: from fl1-118-109-66-179.tky.mesh.ad.jp ([118.109.66.179]:61897 helo=[192.168.1.5]) by gator465.hostgator.com with esmtpa (Exim 4.69) (envelope-from ) id 1NGny5-00073g-Jv; Sat, 05 Dec 2009 00:18:10 -0600 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <4B19A88F.3030008@cisco.com> Date: Sat, 5 Dec 2009 15:18:21 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <42553FC9-2239-4ED2-A5A3-7DEFEEF9C0C1@ntt-at.com> References: <4B19A017.1090402@estacado.net> <4B19A88F.3030008@cisco.com> To: Paul Kyzivat X-Mailer: Apple Mail (2.1077) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Cc: Adam Roach , SIPCORE Subject: Re: [sipcore] Call for consensus: adopting draft-camarillo-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 06:19:16 -0000 +1 =20 Regards, Shida On Dec 5, 2009, at 9:25 AM, Paul Kyzivat wrote: > yes, adopt draft-camarillo-sipcore-reinvite >=20 > Thanks, > Paul >=20 > Adam Roach wrote: >> [as chair] >> Regarding the following milestone on our charter: >> Invite Transaction Handling Correction to IESG (PS) >> To fulfill this milestone, there are two potential problems that may = need to be addressed. One of them relates to handling of 200-class = responses to INVITE messages; the other relates to re-INVITE and target = refresh handling. >> The first problem is addressed by an adopted working group item = (draft-ietf-sipcore-invfix). We do not currently have an adopted item = for the second problem. >> The chairs would like to solicit feedback from the group regarding = adoption of draft-camarillo-sipcore-reinvite as a working group item to = fix the second set of problems. Please comment on the SIPCORE mailing = list. If you agree with this adoption, a simple note stating as much is = encouraged: we cannot determine consensus without feedback, and silence = is not very informative. >> Thanks! >> /a >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From brett@broadsoft.com Sat Dec 5 08:46:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20BB23A6930 for ; Sat, 5 Dec 2009 08:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 zOy7FWnZaY07 for ; Sat, 5 Dec 2009 08:46:29 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 569C53A68C5 for ; Sat, 5 Dec 2009 08:46:29 -0800 (PST) Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Sat, 5 Dec 2009 08:46:19 -0800 From: Brett Tate To: Adam Roach , SIPCORE Date: Sat, 5 Dec 2009 08:46:05 -0800 Thread-Topic: [sipcore] Call for consensus: adopting draft-camarillo-sipcore-reinvite Thread-Index: Acp1QYca22m22n6VRf6I63SwYULragAiN8Cw Message-ID: <747A6506A991724FB09B129B79D5FEB61442592A6D@EXMBXCLUS01.citservers.local> References: <4B19A017.1090402@estacado.net> <4B19A88F.3030008@cisco.com> In-Reply-To: <4B19A88F.3030008@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Call for consensus: adopting draft-camarillo-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 16:46:30 -0000 +1 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Friday, December 04, 2009 7:26 PM > To: Adam Roach > Cc: SIPCORE > Subject: Re: [sipcore] Call for consensus: adopting draft-camarillo- > sipcore-reinvite >=20 > yes, adopt draft-camarillo-sipcore-reinvite >=20 > Thanks, > Paul >=20 > Adam Roach wrote: > > [as chair] > > > > Regarding the following milestone on our charter: > > > > Invite Transaction Handling Correction to IESG (PS) > > > > To fulfill this milestone, there are two potential problems that may > > need to be addressed. One of them relates to handling of 200-class > > responses to INVITE messages; the other relates to re-INVITE and > target > > refresh handling. > > > > The first problem is addressed by an adopted working group item > > (draft-ietf-sipcore-invfix). We do not currently have an adopted item > > for the second problem. > > > > The chairs would like to solicit feedback from the group regarding > > adoption of draft-camarillo-sipcore-reinvite as a working group item > to > > fix the second set of problems. Please comment on the SIPCORE mailing > > list. If you agree with this adoption, a simple note stating as much > is > > encouraged: we cannot determine consensus without feedback, and > silence > > is not very informative. > > > > Thanks! > > > > /a > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From gonzalo.camarillo@ericsson.com Sat Dec 5 22:37:58 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B46A28C0D6 for ; Sat, 5 Dec 2009 22:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 O6ymqSow1bh5 for ; Sat, 5 Dec 2009 22:37:51 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 3F4DF3A6895 for ; Sat, 5 Dec 2009 22:37:48 -0800 (PST) X-AuditID: c1b4fb24-b7beeae000003a71-25-4b1b5132c81e Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 5F.93.14961.2315B1B4; Sun, 6 Dec 2009 07:37:38 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 6 Dec 2009 07:37:37 +0100 Received: from [131.160.126.151] ([131.160.126.151]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 6 Dec 2009 07:37:37 +0100 Message-ID: <4B1B5130.1020305@ericsson.com> Date: Sun, 06 Dec 2009 08:37:36 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: gao.yang2@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Dec 2009 06:37:37.0327 (UTC) FILETIME=[99C3B3F0:01CA763E] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , wang.libo@zte.com.cn Subject: Re: [sipcore] Suspending and Resuming modification of session or stream? //New revision of the re-INVITE handling draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 06:37:58 -0000 Hi, [I am resurrecting this old thread because it did not reach a conclusion.] Originally, preconditions were designed with initial INVITE requests in mind. The idea was to keep the UAS from alerting the callee until the media streams with preconditions were ready to be established (e.g., their QoS was in place). That is, if there were some streams that did not have preconditions, they would not be established until the preconditions for the other streams were met. For example, let us assume an initial INVITE with an audio stream without preconditions and a video stream with QoS preconditions. Until the QoS for the video stream is in place, the audio stream will not be established and the callee will not be alerted. In short, when one or more streams within a session have preconditions, the whole session establishment is suspended until those preconditions are met. When we extended the concept of preconditions to re-INVITEs, we wanted to have similar behavior for initial INVITEs and for re-INVITEs. That is why RFC 4032 talks about about *session* establishment being suspended: http://tools.ietf.org/html/rfc4032#section-3.4 Therefore, the idea was that no changes were applied to any stream until all the preconditions were met. So, the above was our original thinking. However, at present we have a better understanding about the problems with long-lived re-INVITE transactions. If we allow the whole session establishment to be suspended, it would be impossible to change the session parameters of any stream while the UAs were working on meeting the preconditions of other streams. On the other hand, we want to be able to make the changes to one stream conditional to the changes on other stream being executed (e.g., use this new audio codec if you accept adding a video stream to the session; otherwise, keep on using the old audio codec). Before we explore this more deeply, I would like to understand if there is interest in resolving this type of issue. Some time ago I put together a draft dealing with a similar issue (media state during preconditions) but we concluded that, at that point, there was not enough interest for me (or anyone else for that matter) to put more energy into it: http://tools.ietf.org/html/draft-camarillo-sipping-precons-00 If people want these issues to be clarified, we should by all means do so. However, if people do not really care about these corner cases, we should prioritize other specs. Thanks, Gonzalo gao.yang2@zte.com.cn wrote: > > Considering a use case, A and B has a audio only session. Then A send a > Re-INVITE for adding vedio stream( with precondition) and changing codec > or address for audio stream( without preconditon). > > If suspending is effective for whole session, then streams without > precondition should use old parameters while in suspending state. > For the use case, A and B should not use new codec or address for audio > before vedio's preconditon is met. > > If suspending is effective for streams with precondition, the then > streams without preconditio can use new parameters after first O/A > during the Re-INVITE. > For the use case, A and B can use new codec or address for audio before > vedio's preconditon is met. > > > I prefer the first one, as; > 1. To delay using of new parameters for stream without precondition may > arose media clip problem. > 2. Behavior of streams without precondition should be independent of > existence of other streams( with precondition). > > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =================================== > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > From gonzalo.camarillo@ericsson.com Sun Dec 6 08:40:07 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 473753A68E2 for ; Sun, 6 Dec 2009 08:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.185 X-Spam-Level: X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 Xbp9yGSYWs-N for ; Sun, 6 Dec 2009 08:40:06 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 54C713A68CB for ; Sun, 6 Dec 2009 08:40:06 -0800 (PST) X-AuditID: c1b4fb3c-b7bd1ae000001924-84-4b1bde5bfdde Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id B7.98.06436.B5EDB1B4; Sun, 6 Dec 2009 17:39:55 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 6 Dec 2009 17:39:55 +0100 Received: from [131.160.126.151] ([131.160.126.151]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 6 Dec 2009 17:39:55 +0100 Message-ID: <4B1BDE5A.1060608@ericsson.com> Date: Sun, 06 Dec 2009 18:39:54 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Francois Audet References: <4B13C4FC.5050907@sipstation.com><98E67934-70CE-49E4-A2C3-05C3EB42573F@skype.net><10A79C23-41FB-4FF8-AD55-2F83D7017EFC@gmail.com> <057B55FD-2B09-4296-AB60-6FA7E47EDD37@ntt-at.com> <9886E5FCA6D76549A3011068483A4BD40551C3B6@S4DE8PSAAQB.mitte.t-com.de> <52DC7475-F576-4397-B1CF-0C6ED6540089@gmail.com> In-Reply-To: <52DC7475-F576-4397-B1CF-0C6ED6540089@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Dec 2009 16:39:55.0190 (UTC) FILETIME=[BD9BFD60:01CA7692] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, R.Jesske@telekom.de Subject: Re: [sipcore] Some comments on draft-barnes-sipcore-rfc4244bis-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 16:40:07 -0000 Hi, > When you think about it, it makes sense. > > If you call me, you would expect to get my voicemail, not somebody else's. yes, Paul's example has been discussed *many* times. So, addressing it in some way would be a good thing. Cheers, Gonzalo From gonzalo.camarillo@ericsson.com Sun Dec 6 09:11:10 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B7B33A691A for ; Sun, 6 Dec 2009 09:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.187 X-Spam-Level: X-Spam-Status: No, score=-6.187 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 F4ISsve0zaS8 for ; Sun, 6 Dec 2009 09:11:09 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A3C833A6909 for ; Sun, 6 Dec 2009 09:11:08 -0800 (PST) X-AuditID: c1b4fb3e-b7bc9ae000005cee-1b-4b1be5a1122e Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id F4.BE.23790.1A5EB1B4; Sun, 6 Dec 2009 18:10:57 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 6 Dec 2009 18:10:57 +0100 Received: from [131.160.126.151] ([131.160.126.151]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 6 Dec 2009 18:10:57 +0100 Message-ID: <4B1BE59E.3040803@ericsson.com> Date: Sun, 06 Dec 2009 19:10:54 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: SIPCORE References: <4AFA3E1A.8060204@ericsson.com> <4B0FD53A.10705@ericsson.com> In-Reply-To: <4B0FD53A.10705@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Dec 2009 17:10:57.0199 (UTC) FILETIME=[137403F0:01CA7697] X-Brightmail-Tracker: AAAAAA== Cc: Brian Hibbard Subject: Re: [sipcore] Reviewing the sec-flows draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 17:11:11 -0000 Folks, as you know, when we restructured the RAI area one of the plans was to avoid working on specifications people were not interested in any longer. Adam and I have had to assign a new editor (with cycles) to this document and have unsuccessfully asked for reviewers *many* times. If we do not see some activity related to this draft in the near future the only conclusion we can draw is that we should abandon it. So, if you think this is important, now it would be a good time for volunteering. Also, if you think we should abandon this draft, let us know as well. Thanks, Gonzalo SIPCORE co-chair Gonzalo Camarillo wrote: > Folks, > > as you may have noticed, Brian has submitted a new revision of this > draft and sent a couple of notes to the list (on November 24th) > describing the topics on which he expects to get feedback. Please, send > your comments to this list. > > Thanks, > > Gonzalo > SIPCORE co-chair > > Gonzalo Camarillo wrote: >> Folks, >> >> as you know, we have asked for volunteers to review the sec-flows >> draft many times. We got a couple of reviews but we would like to get >> at least one dedicated review more. If you want to volunteer, please >> send your review to the list. >> >> Additionally, the reviews we got pointed out at issues that require WG >> consensus (as opposed to the editor simply going off and implementing >> them). >> >> As next steps, the draft's editor (Brian) will be submitting a new >> revision of the draft because the current one has expired. Then, he >> will be sending a set of emails to the list so that we can reach >> consensus on the issues that need discussion. >> >> Thanks, >> >> Gonzalo >> SIPCORE co-chair >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@cisco.com Sun Dec 6 09:52:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 502303A67A8 for ; Sun, 6 Dec 2009 09:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 4xF+fB-uePyQ for ; Sun, 6 Dec 2009 09:52:29 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 3F2DC3A692E for ; Sun, 6 Dec 2009 09:52:29 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQHAEx+G0tAZnwN/2dsb2JhbACZD6YklXiEMwQ X-IronPort-AV: E=Sophos;i="4.47,350,1257120000"; d="scan'208";a="72411862" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 06 Dec 2009 17:52:19 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nB6HqJ0K004512; Sun, 6 Dec 2009 17:52:19 GMT Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 6 Dec 2009 12:52:19 -0500 Received: from [10.86.254.9] ([10.86.254.9]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 6 Dec 2009 12:52:18 -0500 Message-ID: <4B1BEF51.1080805@cisco.com> Date: Sun, 06 Dec 2009 12:52:17 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4B13C4FC.5050907@sipstation.com><98E67934-70CE-49E4-A2C3-05C3EB42573F@skype.net><10A79C23-41FB-4FF8-AD55-2F83D7017EFC@gmail.com> <057B55FD-2B09-4296-AB60-6FA7E47EDD37@ntt-at.com> <9886E5FCA6D76549A3011068483A4BD40551C3B6@S4DE8PSAAQB.mitte.t-com.de> <52DC7475-F576-4397-B1CF-0C6ED6540089@gmail.com> <4B1BDE5A.1060608@ericsson.com> In-Reply-To: <4B1BDE5A.1060608@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Dec 2009 17:52:18.0733 (UTC) FILETIME=[DA900DD0:01CA769C] Cc: Francois Audet , sipcore@ietf.org, R.Jesske@telekom.de Subject: Re: [sipcore] Some comments on draft-barnes-sipcore-rfc4244bis-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 17:52:30 -0000 The main tactic I know of that is currently deployed to address this need is to cancel the forwarded call after a few "rings", hopefully before it is transferred to voicemail there. But of course that doesn't work if you guess wrong about the number of rings, and especially if the call goes direct to voicemail. While there is no way, once I have forwarded a call to you, for me to *prevent* you from handling the call as voicemail, it is typically in the best interests of both of us. Specifically, if I am forwarding the call to you, but asked you *not* to send the call to your voicemail, then honoring that saves you the trouble handling the voicemail, and also keeps you in my good graces. So the key here is to communicate preferences for how the call should be handed, and define the recommended handling of calls in the presence of such a recommendation. The basics to do this have been in callerprefs for a long time. But I don't think they have been considered seriously in this context. I'm not *certain* that is sufficient to address the problem, but it seems like the right starting point. Note that this sort of approach *does not* require looking back in the History-Info to decide which voice mailbox to use. Thanks, Paul Gonzalo Camarillo wrote: > Hi, > >> When you think about it, it makes sense. >> >> If you call me, you would expect to get my voicemail, not somebody >> else's. > > yes, Paul's example has been discussed *many* times. So, addressing it > in some way would be a good thing. > > Cheers, > > Gonzalo > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Sun Dec 6 10:40:02 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FCDD3A6848 for ; Sun, 6 Dec 2009 10:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 dKDc0k7UplYJ for ; Sun, 6 Dec 2009 10:40:01 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 2ABD03A66B4 for ; Sun, 6 Dec 2009 10:40:00 -0800 (PST) X-AuditID: c1b4fb24-b7beeae000003a71-06-4b1bfa768d7d Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id B3.BC.14961.67AFB1B4; Sun, 6 Dec 2009 19:39:50 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 6 Dec 2009 19:39:49 +0100 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: Sun, 6 Dec 2009 19:39:49 +0100 Message-ID: In-Reply-To: <4B19A88F.3030008@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Call for consensus:adopting draft-camarillo-sipcore-reinvite Thread-Index: Acp1QYTHoX43XH3HTFa9qZawZtq/xgBYfQWA References: <4B19A017.1090402@estacado.net> <4B19A88F.3030008@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Adam Roach" X-OriginalArrivalTime: 06 Dec 2009 18:39:49.0934 (UTC) FILETIME=[7E02CCE0:01CA76A3] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Call for consensus:adopting draft-camarillo-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 18:40:02 -0000 + 1=20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 5. joulukuuta 2009 2:26 To: Adam Roach Cc: SIPCORE Subject: Re: [sipcore] Call for consensus:adopting draft-camarillo-sipcore-reinvite yes, adopt draft-camarillo-sipcore-reinvite Thanks, Paul Adam Roach wrote: > [as chair] >=20 > Regarding the following milestone on our charter: >=20 > Invite Transaction Handling Correction to IESG (PS) >=20 > To fulfill this milestone, there are two potential problems that may=20 > need to be addressed. One of them relates to handling of 200-class=20 > responses to INVITE messages; the other relates to re-INVITE and=20 > target refresh handling. >=20 > The first problem is addressed by an adopted working group item=20 > (draft-ietf-sipcore-invfix). We do not currently have an adopted item=20 > for the second problem. >=20 > The chairs would like to solicit feedback from the group regarding=20 > adoption of draft-camarillo-sipcore-reinvite as a working group item=20 > to fix the second set of problems. Please comment on the SIPCORE=20 > mailing list. If you agree with this adoption, a simple note stating=20 > as much is > encouraged: we cannot determine consensus without feedback, and=20 > silence is not very informative. >=20 > Thanks! >=20 > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From gao.yang2@zte.com.cn Sun Dec 6 16:53:55 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C6853A6892; Sun, 6 Dec 2009 16:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.314 X-Spam-Level: X-Spam-Status: No, score=-97.314 tagged_above=-999 required=5 tests=[AWL=-4.524, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] 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 KY76KxHxlP4L; Sun, 6 Dec 2009 16:53:54 -0800 (PST) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 366143A672F; Sun, 6 Dec 2009 16:53:52 -0800 (PST) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 91102001811080; Mon, 7 Dec 2009 08:30:22 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.99] with StormMail ESMTP id 89005.4761360516; Mon, 7 Dec 2009 08:52:38 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id nB70rSm4067007; Mon, 7 Dec 2009 08:53:28 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4B19A88F.3030008@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 7 Dec 2009 08:52:38 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-12-07 08:53:24, Serialize complete at 2009-12-07 08:53:24 Content-Type: multipart/alternative; boundary="=_alternative 0004E33E48257685_=" X-MAIL: mse1.zte.com.cn nB70rSm4067007 Cc: Adam Roach , SIPCORE , sipcore-bounces@ietf.org Subject: [sipcore] =?gb2312?b?tPC4tDogUmU6ICBDYWxsIGZvciBjb25zZW5zdXM6CWFk?= =?gb2312?b?b3B0aW5nCWRyYWZ0LWNhbWFyaWxsby1zaXBjb3JlLXJlaW52aXRl?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 00:53:55 -0000 This is a multipart message in MIME format. --=_alternative 0004E33E48257685_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 KzENCg0KVGhlcmUgdG9waWNzKHNlc3Npb24gc3RhdGUgYW5kIGRpYWxvZyBzdGF0ZSBhZnRlciBS ZS1JTlZJVEUpIGlzIGEgdmVyeSANCmxvbmcgaXNzdWUgZm9yIFNJUC4gQW5kIEkgdGhpbmsgd2Ug bmVlZCB0aGUgV0cgaXRlbS4NCkFzIHRoZXJlIGlzIGludGVyd29ya2luZyBwcm9ibGVtIGZvciB0 aGUgYWJzZW5jZSBvZiB0aGUgbm9ybWF0aXZlIA0KZG9jdW1lbnQsIHRoZSBXRyBpdGVtIHdvdWxk IGJlICJ0aGUgc29vbmVyIHRoZSBiZXR0ZXIiLg0KDQpUaGFua3MsDQoNCkdhbw0KDQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIFppcCAgICA6IDIxMDAxMg0KIFRlbCAgICA6 IDg3MjExDQogVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCiBlX21haWwgOiBnYW8ueWFuZzJA enRlLmNvbS5jbg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQoNClBh dWwgS3l6aXZhdCA8cGt5eml2YXRAY2lzY28uY29tPiANCreivP7IyzogIHNpcGNvcmUtYm91bmNl c0BpZXRmLm9yZw0KMjAwOS0xMi0wNSAwODoyNQ0KDQrK1bz+yMsNCkFkYW0gUm9hY2ggPGFkYW1A ZXN0YWNhZG8ubmV0Pg0Ks63LzQ0KU0lQQ09SRSA8c2lwY29yZUBpZXRmLm9yZz4NCtb3zOINClJl OiBbc2lwY29yZV0gQ2FsbCBmb3IgY29uc2Vuc3VzOiAgICAgICBhZG9wdGluZyANCmRyYWZ0LWNh bWFyaWxsby1zaXBjb3JlLXJlaW52aXRlDQoNCg0KDQoNCg0KDQp5ZXMsIGFkb3B0IGRyYWZ0LWNh bWFyaWxsby1zaXBjb3JlLXJlaW52aXRlDQoNCiAgICAgICAgICAgICAgICAgVGhhbmtzLA0KICAg ICAgICAgICAgICAgICBQYXVsDQoNCkFkYW0gUm9hY2ggd3JvdGU6DQo+IFthcyBjaGFpcl0NCj4g DQo+IFJlZ2FyZGluZyB0aGUgZm9sbG93aW5nIG1pbGVzdG9uZSBvbiBvdXIgY2hhcnRlcjoNCj4g DQo+ICAgSW52aXRlIFRyYW5zYWN0aW9uIEhhbmRsaW5nIENvcnJlY3Rpb24gdG8gSUVTRyAoUFMp DQo+IA0KPiBUbyBmdWxmaWxsIHRoaXMgbWlsZXN0b25lLCB0aGVyZSBhcmUgdHdvIHBvdGVudGlh bCBwcm9ibGVtcyB0aGF0IG1heSANCj4gbmVlZCB0byBiZSBhZGRyZXNzZWQuIE9uZSBvZiB0aGVt IHJlbGF0ZXMgdG8gaGFuZGxpbmcgb2YgMjAwLWNsYXNzIA0KPiByZXNwb25zZXMgdG8gSU5WSVRF IG1lc3NhZ2VzOyB0aGUgb3RoZXIgcmVsYXRlcyB0byByZS1JTlZJVEUgYW5kIHRhcmdldCANCj4g cmVmcmVzaCBoYW5kbGluZy4NCj4gDQo+IFRoZSBmaXJzdCBwcm9ibGVtIGlzIGFkZHJlc3NlZCBi eSBhbiBhZG9wdGVkIHdvcmtpbmcgZ3JvdXAgaXRlbSANCj4gKGRyYWZ0LWlldGYtc2lwY29yZS1p bnZmaXgpLiBXZSBkbyBub3QgY3VycmVudGx5IGhhdmUgYW4gYWRvcHRlZCBpdGVtIA0KPiBmb3Ig dGhlIHNlY29uZCBwcm9ibGVtLg0KPiANCj4gVGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIHNvbGlj aXQgZmVlZGJhY2sgZnJvbSB0aGUgZ3JvdXAgcmVnYXJkaW5nIA0KPiBhZG9wdGlvbiBvZiBkcmFm dC1jYW1hcmlsbG8tc2lwY29yZS1yZWludml0ZSBhcyBhIHdvcmtpbmcgZ3JvdXAgaXRlbSB0byAN Cj4gZml4IHRoZSBzZWNvbmQgc2V0IG9mIHByb2JsZW1zLiBQbGVhc2UgY29tbWVudCBvbiB0aGUg U0lQQ09SRSBtYWlsaW5nIA0KPiBsaXN0LiBJZiB5b3UgYWdyZWUgd2l0aCB0aGlzIGFkb3B0aW9u LCBhIHNpbXBsZSBub3RlIHN0YXRpbmcgYXMgbXVjaCBpcyANCj4gZW5jb3VyYWdlZDogd2UgY2Fu bm90IGRldGVybWluZSBjb25zZW5zdXMgd2l0aG91dCBmZWVkYmFjaywgYW5kIHNpbGVuY2UgDQo+ IGlzIG5vdCB2ZXJ5IGluZm9ybWF0aXZlLg0KPiANCj4gVGhhbmtzIQ0KPiANCj4gL2ENCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2lwY29yZSBt YWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4gDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QNCnNpcGNvcmVAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KDQoNCg0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9y Z2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNp cGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQg YXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVu aWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQg d2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhl IG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBt ZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2Ug aGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5 c3RlbS4NCg== --=_alternative 0004E33E48257685_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPisxPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGVyZSB0b3BpY3Moc2Vzc2lvbiBzdGF0 ZSBhbmQgZGlhbG9nDQpzdGF0ZSBhZnRlciBSZS1JTlZJVEUpIGlzIGEgdmVyeSBsb25nIGlzc3Vl IGZvciBTSVAuIEFuZCBJIHRoaW5rIHdlIG5lZWQNCnRoZSBXRyBpdGVtLjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QXMgdGhlcmUgaXMgaW50ZXJ3b3JraW5nIHBy b2JsZW0gZm9yDQp0aGUgYWJzZW5jZSBvZiB0aGUgbm9ybWF0aXZlIGRvY3VtZW50LCB0aGUgV0cg aXRlbSB3b3VsZCBiZSAmcXVvdDt0aGUgc29vbmVyDQp0aGUgYmV0dGVyJnF1b3Q7LjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzLDwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+R2FvPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj49PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PTxicj4NCiBaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJyPg0KIFRl bCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiBUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUyODc3 MjExPGJyPg0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT08L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUg d2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+PGI+UGF1bCBLeXppdmF0ICZsdDtwa3l6aXZhdEBjaXNjby5jb20m Z3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+ yMs6ICZuYnNwO3NpcGNvcmUtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDA5LTEyLTA1IDA4OjI1PC9mb250Pg0KPHRkIHdpZHRoPTcz JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+ DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPkFkYW0gUm9hY2ggJmx0O2FkYW1A ZXN0YWNhZG8ubmV0Jmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGln bj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4N Cjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+U0lQQ09SRSAmbHQ7c2lwY29yZUBp ZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbc2lwY29yZV0gQ2FsbCBmb3IgY29u c2Vuc3VzOiAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7YWRvcHRpbmcgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ZHJhZnQtY2FtYXJpbGxvLXNpcGNvcmUtcmVpbnZpdGU8L2ZvbnQ+PC90 YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+ DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0PnllcywgYWRv cHQgZHJhZnQtY2FtYXJpbGxvLXNpcGNvcmUtcmVpbnZpdGU8YnI+DQo8YnI+DQogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KVGhhbmtzLDxi cj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQpQYXVsPGJyPg0KPGJyPg0KQWRhbSBSb2FjaCB3cm90ZTo8YnI+DQomZ3Q7IFthcyBjaGFp cl08YnI+DQomZ3Q7IDxicj4NCiZndDsgUmVnYXJkaW5nIHRoZSBmb2xsb3dpbmcgbWlsZXN0b25l IG9uIG91ciBjaGFydGVyOjxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgSW52aXRlIFRyYW5z YWN0aW9uIEhhbmRsaW5nIENvcnJlY3Rpb24gdG8gSUVTRyAoUFMpPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IFRvIGZ1bGZpbGwgdGhpcyBtaWxlc3RvbmUsIHRoZXJlIGFyZSB0d28gcG90ZW50aWFsIHBy b2JsZW1zIHRoYXQgbWF5DQo8YnI+DQomZ3Q7IG5lZWQgdG8gYmUgYWRkcmVzc2VkLiBPbmUgb2Yg dGhlbSByZWxhdGVzIHRvIGhhbmRsaW5nIG9mIDIwMC1jbGFzcw0KPGJyPg0KJmd0OyByZXNwb25z ZXMgdG8gSU5WSVRFIG1lc3NhZ2VzOyB0aGUgb3RoZXIgcmVsYXRlcyB0byByZS1JTlZJVEUgYW5k IHRhcmdldA0KPGJyPg0KJmd0OyByZWZyZXNoIGhhbmRsaW5nLjxicj4NCiZndDsgPGJyPg0KJmd0 OyBUaGUgZmlyc3QgcHJvYmxlbSBpcyBhZGRyZXNzZWQgYnkgYW4gYWRvcHRlZCB3b3JraW5nIGdy b3VwIGl0ZW0gPGJyPg0KJmd0OyAoZHJhZnQtaWV0Zi1zaXBjb3JlLWludmZpeCkuIFdlIGRvIG5v dCBjdXJyZW50bHkgaGF2ZSBhbiBhZG9wdGVkIGl0ZW0NCjxicj4NCiZndDsgZm9yIHRoZSBzZWNv bmQgcHJvYmxlbS48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIGNoYWlycyB3b3VsZCBsaWtlIHRv IHNvbGljaXQgZmVlZGJhY2sgZnJvbSB0aGUgZ3JvdXAgcmVnYXJkaW5nDQo8YnI+DQomZ3Q7IGFk b3B0aW9uIG9mIGRyYWZ0LWNhbWFyaWxsby1zaXBjb3JlLXJlaW52aXRlIGFzIGEgd29ya2luZyBn cm91cCBpdGVtDQp0byA8YnI+DQomZ3Q7IGZpeCB0aGUgc2Vjb25kIHNldCBvZiBwcm9ibGVtcy4g UGxlYXNlIGNvbW1lbnQgb24gdGhlIFNJUENPUkUgbWFpbGluZw0KPGJyPg0KJmd0OyBsaXN0LiBJ ZiB5b3UgYWdyZWUgd2l0aCB0aGlzIGFkb3B0aW9uLCBhIHNpbXBsZSBub3RlIHN0YXRpbmcgYXMg bXVjaA0KaXMgPGJyPg0KJmd0OyBlbmNvdXJhZ2VkOiB3ZSBjYW5ub3QgZGV0ZXJtaW5lIGNvbnNl bnN1cyB3aXRob3V0IGZlZWRiYWNrLCBhbmQgc2lsZW5jZQ0KPGJyPg0KJmd0OyBpcyBub3QgdmVy eSBpbmZvcm1hdGl2ZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmtzITxicj4NCiZndDsgPGJy Pg0KJmd0OyAvYTxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQomZ3Q7IHNpcGNvcmUgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBzaXBj b3JlQGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NpcGNvcmU8YnI+DQomZ3Q7IDxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0Kc2lwY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQpzaXBjb3Jl QGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBj b3JlPGJyPg0KPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJ bmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9y bWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lz Jm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidz Jm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlv biZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZu YnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZu YnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJz cDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3Ro aXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1h aWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0 aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5k ZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZu YnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDto YXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9y Jm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3Nl ZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNw O29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNz YWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2Vz Jm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7 c3lzdGVtLg0KPC9wcmU+ --=_alternative 0004E33E48257685_=-- From gao.yang2@zte.com.cn Sun Dec 6 17:07:15 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64C143A695E; Sun, 6 Dec 2009 17:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.545 X-Spam-Level: X-Spam-Status: No, score=-93.545 tagged_above=-999 required=5 tests=[AWL=-3.769, BAYES_40=-0.185, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] 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 1uUn02z1uCCc; Sun, 6 Dec 2009 17:07:13 -0800 (PST) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 93A473A6951; Sun, 6 Dec 2009 17:07:10 -0800 (PST) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 91102001811080; Mon, 7 Dec 2009 08:43:46 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.99] with StormMail ESMTP id 89005.2001811080; Mon, 7 Dec 2009 09:05:55 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id nB716epY013646; Mon, 7 Dec 2009 09:06:43 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4B1B5130.1020305@ericsson.com> To: Gonzalo Camarillo MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 7 Dec 2009 09:05:43 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-12-07 09:06:38, Serialize complete at 2009-12-07 09:06:38 Content-Type: multipart/alternative; boundary="=_alternative 000615E148257685_=" X-MAIL: mse2.zte.com.cn nB716epY013646 Cc: SIPCORE , wang.libo@zte.com.cn, sipcore-bounces@ietf.org Subject: [sipcore] =?gb2312?b?tPC4tDogUmU6ICBTdXNwZW5kaW5nIGFuZCBSZXN1bWlu?= =?gb2312?b?ZyBtb2RpZmljYXRpb24gb2Ygc2Vzc2lvbiBvciBzdHJlYW0/IC8vTmV3IHJl?= =?gb2312?b?dmlzaW9uIG9mIHRoZSByZS1JTlZJVEUgaGFuZGxpbmcgZHJhZnQ=?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 01:07:15 -0000 This is a multipart message in MIME format. --=_alternative 000615E148257685_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCkJ5IG15c2VsZiwgSSB0aGluayB0aGF0IHRoaXMgaXNzdWUoIlN1c3BlbmRpbmcgYW5k IFJlc3VtaW5nIG1vZGlmaWNhdGlvbiANCm9mIHNlc3Npb24gb3Igc3RyZWFtIikgaXMgbm90IGFz IHVyZ2VudCBhcyB0aGUgInNlc3Npb24gc3RhdGUiIGFuZCAiZGlhbG9nIA0Kc3RhdGUiIGlzc3Vl Lg0KDQpXaGlsZSBJIHByb3Bvc2VkIHRoaXMgdGhyZWFkLCB0aGVyZSBhcmUgbGVzcyBwZW9wbGUg Y2FyZSBhYm91dCBpdC4oSW4gDQpmYWN0LCBJIGhhdmUgaW4gcmVtZW1icmFuY2UgdGhhdCBvbmx5 IFBhdWwgYW5kIENocmlzdGVyIGdhdmUgY29tbWVudHMoaWYgDQp0aGVyZSBhcmUgc29tZW9uZSBl bHNlLCBzb3JyeSBmb3IgaXQpKS4NCg0KQW5kIEkgc3VwcG9ydCB5b3VyIHdheSBhcyAiSWYgcGVv cGxlIHdhbnQgdGhlc2UgaXNzdWVzIHRvIGJlIGNsYXJpZmllZCwgd2UgDQpzaG91bGQgYnkgYWxs IG1lYW5zIGRvIHNvLiBIb3dldmVyLCBpZiBwZW9wbGUgZG8gbm90IHJlYWxseSBjYXJlIGFib3V0 IA0KdGhlc2UgY29ybmVyIGNhc2VzLCB3ZSANCnNob3VsZCBwcmlvcml0aXplIG90aGVyIHNwZWNz LiINCiANCkJUVywgSSB0aGluayBpZiBzb21lZGF5IG1vcmUgcGVvcGxlIHdhbnQgdG8gY2xhcmlm eSB0aGlzIGlzc3VlLCANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhbWFyaWxs by1zaXBwaW5nLXByZWNvbnMtMDAgaXMgYSBuaWNlIA0Kc3RhbmRieSBhbmQgc3RhcnRpbmcuDQoN ClRoYW5rcywNCg0KR2FvDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQog WmlwICAgIDogMjEwMDEyDQogVGVsICAgIDogODcyMTENCiBUZWwyICAgOigrODYpLTAyNS01Mjg3 NzIxMQ0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuDQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KDQoNCg0KR29uemFsbyBDYW1hcmlsbG8gPEdvbnphbG8uQ2FtYXJp bGxvQGVyaWNzc29uLmNvbT4gDQq3orz+yMs6ICBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcNCjIw MDktMTItMDYgMTQ6MzcNCg0KytW8/sjLDQpnYW8ueWFuZzJAenRlLmNvbS5jbg0Ks63LzQ0KU0lQ Q09SRSA8c2lwY29yZUBpZXRmLm9yZz4sIHdhbmcubGlib0B6dGUuY29tLmNuDQrW98ziDQpSZTog W3NpcGNvcmVdIFN1c3BlbmRpbmcgYW5kIFJlc3VtaW5nIG1vZGlmaWNhdGlvbiBvZiBzZXNzaW9u IG9yIHN0cmVhbT8gDQovL05ldyByZXZpc2lvbiBvZiB0aGUgcmUtSU5WSVRFIGhhbmRsaW5nIGRy YWZ0DQoNCg0KDQoNCg0KDQpIaSwNCg0KW0kgYW0gcmVzdXJyZWN0aW5nIHRoaXMgb2xkIHRocmVh ZCBiZWNhdXNlIGl0IGRpZCBub3QgcmVhY2ggYSBjb25jbHVzaW9uLl0NCg0KT3JpZ2luYWxseSwg cHJlY29uZGl0aW9ucyB3ZXJlIGRlc2lnbmVkIHdpdGggaW5pdGlhbCBJTlZJVEUgcmVxdWVzdHMg aW4gDQptaW5kLiBUaGUgaWRlYSB3YXMgdG8ga2VlcCB0aGUgVUFTIGZyb20gYWxlcnRpbmcgdGhl IGNhbGxlZSB1bnRpbCB0aGUgDQptZWRpYSBzdHJlYW1zIHdpdGggcHJlY29uZGl0aW9ucyB3ZXJl IHJlYWR5IHRvIGJlIGVzdGFibGlzaGVkIChlLmcuLCANCnRoZWlyIFFvUyB3YXMgaW4gcGxhY2Up LiBUaGF0IGlzLCBpZiB0aGVyZSB3ZXJlIHNvbWUgc3RyZWFtcyB0aGF0IGRpZCANCm5vdCBoYXZl IHByZWNvbmRpdGlvbnMsIHRoZXkgd291bGQgbm90IGJlIGVzdGFibGlzaGVkIHVudGlsIHRoZSAN CnByZWNvbmRpdGlvbnMgZm9yIHRoZSBvdGhlciBzdHJlYW1zIHdlcmUgbWV0LiBGb3IgZXhhbXBs ZSwgbGV0IHVzIGFzc3VtZSANCmFuIGluaXRpYWwgSU5WSVRFIHdpdGggYW4gYXVkaW8gc3RyZWFt IHdpdGhvdXQgcHJlY29uZGl0aW9ucyBhbmQgYSB2aWRlbyANCnN0cmVhbSB3aXRoIFFvUyBwcmVj b25kaXRpb25zLiBVbnRpbCB0aGUgUW9TIGZvciB0aGUgdmlkZW8gc3RyZWFtIGlzIGluIA0KcGxh Y2UsIHRoZSBhdWRpbyBzdHJlYW0gd2lsbCBub3QgYmUgZXN0YWJsaXNoZWQgYW5kIHRoZSBjYWxs ZWUgd2lsbCBub3QgDQpiZSBhbGVydGVkLiBJbiBzaG9ydCwgd2hlbiBvbmUgb3IgbW9yZSBzdHJl YW1zIHdpdGhpbiBhIHNlc3Npb24gaGF2ZSANCnByZWNvbmRpdGlvbnMsIHRoZSB3aG9sZSBzZXNz aW9uIGVzdGFibGlzaG1lbnQgaXMgc3VzcGVuZGVkIHVudGlsIHRob3NlIA0KcHJlY29uZGl0aW9u cyBhcmUgbWV0Lg0KDQpXaGVuIHdlIGV4dGVuZGVkIHRoZSBjb25jZXB0IG9mIHByZWNvbmRpdGlv bnMgdG8gcmUtSU5WSVRFcywgd2Ugd2FudGVkIA0KdG8gaGF2ZSBzaW1pbGFyIGJlaGF2aW9yIGZv ciBpbml0aWFsIElOVklURXMgYW5kIGZvciByZS1JTlZJVEVzLiBUaGF0IGlzIA0Kd2h5IFJGQyA0 MDMyIHRhbGtzIGFib3V0IGFib3V0ICpzZXNzaW9uKiBlc3RhYmxpc2htZW50IGJlaW5nIHN1c3Bl bmRlZDoNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDAzMiNzZWN0aW9uLTMuNA0K DQpUaGVyZWZvcmUsIHRoZSBpZGVhIHdhcyB0aGF0IG5vIGNoYW5nZXMgd2VyZSBhcHBsaWVkIHRv IGFueSBzdHJlYW0gdW50aWwgDQphbGwgdGhlIHByZWNvbmRpdGlvbnMgd2VyZSBtZXQuDQoNClNv LCB0aGUgYWJvdmUgd2FzIG91ciBvcmlnaW5hbCB0aGlua2luZy4gSG93ZXZlciwgYXQgcHJlc2Vu dCB3ZSBoYXZlIGEgDQpiZXR0ZXIgdW5kZXJzdGFuZGluZyBhYm91dCB0aGUgcHJvYmxlbXMgd2l0 aCBsb25nLWxpdmVkIHJlLUlOVklURSANCnRyYW5zYWN0aW9ucy4gSWYgd2UgYWxsb3cgdGhlIHdo b2xlIHNlc3Npb24gZXN0YWJsaXNobWVudCB0byBiZSANCnN1c3BlbmRlZCwgaXQgd291bGQgYmUg aW1wb3NzaWJsZSB0byBjaGFuZ2UgdGhlIHNlc3Npb24gcGFyYW1ldGVycyBvZiANCmFueSBzdHJl YW0gd2hpbGUgdGhlIFVBcyB3ZXJlIHdvcmtpbmcgb24gbWVldGluZyB0aGUgcHJlY29uZGl0aW9u cyBvZiANCm90aGVyIHN0cmVhbXMuIE9uIHRoZSBvdGhlciBoYW5kLCB3ZSB3YW50IHRvIGJlIGFi bGUgdG8gbWFrZSB0aGUgY2hhbmdlcyANCnRvIG9uZSBzdHJlYW0gY29uZGl0aW9uYWwgdG8gdGhl IGNoYW5nZXMgb24gb3RoZXIgc3RyZWFtIGJlaW5nIGV4ZWN1dGVkIA0KKGUuZy4sIHVzZSB0aGlz IG5ldyBhdWRpbyBjb2RlYyBpZiB5b3UgYWNjZXB0IGFkZGluZyBhIHZpZGVvIHN0cmVhbSB0byAN CnRoZSBzZXNzaW9uOyBvdGhlcndpc2UsIGtlZXAgb24gdXNpbmcgdGhlIG9sZCBhdWRpbyBjb2Rl YykuDQoNCkJlZm9yZSB3ZSBleHBsb3JlIHRoaXMgbW9yZSBkZWVwbHksIEkgd291bGQgbGlrZSB0 byB1bmRlcnN0YW5kIGlmIHRoZXJlIA0KaXMgaW50ZXJlc3QgaW4gcmVzb2x2aW5nIHRoaXMgdHlw ZSBvZiBpc3N1ZS4gU29tZSB0aW1lIGFnbyBJIHB1dCANCnRvZ2V0aGVyIGEgZHJhZnQgZGVhbGlu ZyB3aXRoIGEgc2ltaWxhciBpc3N1ZSAobWVkaWEgc3RhdGUgZHVyaW5nIA0KcHJlY29uZGl0aW9u cykgYnV0IHdlIGNvbmNsdWRlZCB0aGF0LCBhdCB0aGF0IHBvaW50LCB0aGVyZSB3YXMgbm90IA0K ZW5vdWdoIGludGVyZXN0IGZvciBtZSAob3IgYW55b25lIGVsc2UgZm9yIHRoYXQgbWF0dGVyKSB0 byBwdXQgbW9yZSANCmVuZXJneSBpbnRvIGl0Og0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1jYW1hcmlsbG8tc2lwcGluZy1wcmVjb25zLTAwDQoNCklmIHBlb3BsZSB3YW50IHRo ZXNlIGlzc3VlcyB0byBiZSBjbGFyaWZpZWQsIHdlIHNob3VsZCBieSBhbGwgbWVhbnMgZG8gDQpz by4gSG93ZXZlciwgaWYgcGVvcGxlIGRvIG5vdCByZWFsbHkgY2FyZSBhYm91dCB0aGVzZSBjb3Ju ZXIgY2FzZXMsIHdlIA0Kc2hvdWxkIHByaW9yaXRpemUgb3RoZXIgc3BlY3MuDQoNClRoYW5rcywN Cg0KR29uemFsbw0KDQoNCg0KZ2FvLnlhbmcyQHp0ZS5jb20uY24gd3JvdGU6DQo+IA0KPiBDb25z aWRlcmluZyBhIHVzZSBjYXNlLCBBIGFuZCBCIGhhcyBhIGF1ZGlvIG9ubHkgc2Vzc2lvbi4gVGhl biBBIHNlbmQgYSANCj4gUmUtSU5WSVRFIGZvciBhZGRpbmcgdmVkaW8gc3RyZWFtKCB3aXRoIHBy ZWNvbmRpdGlvbikgYW5kIGNoYW5naW5nIGNvZGVjIA0KDQo+IG9yIGFkZHJlc3MgZm9yIGF1ZGlv IHN0cmVhbSggd2l0aG91dCBwcmVjb25kaXRvbikuDQo+IA0KPiBJZiBzdXNwZW5kaW5nIGlzIGVm ZmVjdGl2ZSBmb3Igd2hvbGUgc2Vzc2lvbiwgdGhlbiBzdHJlYW1zIHdpdGhvdXQgDQo+IHByZWNv bmRpdGlvbiBzaG91bGQgdXNlIG9sZCBwYXJhbWV0ZXJzIHdoaWxlIGluIHN1c3BlbmRpbmcgc3Rh dGUuDQo+IEZvciB0aGUgdXNlIGNhc2UsIEEgYW5kIEIgc2hvdWxkIG5vdCB1c2UgbmV3IGNvZGVj IG9yIGFkZHJlc3MgZm9yIGF1ZGlvIA0KPiBiZWZvcmUgdmVkaW8ncyBwcmVjb25kaXRvbiBpcyBt ZXQuDQo+IA0KPiBJZiBzdXNwZW5kaW5nIGlzIGVmZmVjdGl2ZSBmb3Igc3RyZWFtcyB3aXRoIHBy ZWNvbmRpdGlvbiwgdGhlIHRoZW4gDQo+IHN0cmVhbXMgd2l0aG91dCBwcmVjb25kaXRpbyBjYW4g dXNlIG5ldyBwYXJhbWV0ZXJzIGFmdGVyIGZpcnN0IE8vQSANCj4gZHVyaW5nIHRoZSBSZS1JTlZJ VEUuDQo+IEZvciB0aGUgdXNlIGNhc2UsIEEgYW5kIEIgY2FuIHVzZSBuZXcgY29kZWMgb3IgYWRk cmVzcyBmb3IgYXVkaW8gYmVmb3JlIA0KPiB2ZWRpbydzIHByZWNvbmRpdG9uIGlzIG1ldC4NCj4g DQo+IA0KPiBJIHByZWZlciB0aGUgZmlyc3Qgb25lLCBhczsNCj4gMS4gVG8gZGVsYXkgdXNpbmcg b2YgbmV3IHBhcmFtZXRlcnMgZm9yIHN0cmVhbSB3aXRob3V0IHByZWNvbmRpdGlvbiBtYXkgDQo+ IGFyb3NlIG1lZGlhIGNsaXAgcHJvYmxlbS4NCj4gMi4gQmVoYXZpb3Igb2Ygc3RyZWFtcyB3aXRo b3V0IHByZWNvbmRpdGlvbiBzaG91bGQgYmUgaW5kZXBlbmRlbnQgb2YgDQo+IGV4aXN0ZW5jZSBv ZiBvdGhlciBzdHJlYW1zKCB3aXRoIHByZWNvbmRpdGlvbikuDQo+IA0KPiA9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQ0KPiBaaXAgICAgOiAyMTAwMTINCj4gVGVsICAgIDogODcy MTENCj4gVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCj4gZV9tYWlsIDogZ2FvLnlhbmcyQHp0 ZS5jb20uY24NCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gDQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gdGhpcyBtYWlsIA0KaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdh bml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIA0KaXMgY29uZmlkZW50aWFsLiBSZWNp cGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSANCmFu ZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21t dW5pY2F0aW9uIHRvIA0Kb3RoZXJzLg0KPiBUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNt aXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCANCmludGVuZGVkIHNvbGVseSBmb3Ig dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSANCmFk ZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ug bm90aWZ5IHRoZSANCm9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNz ZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSANCm9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4N Cj4gVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkg WlRFIEFudGktU3BhbSANCnN5c3RlbS4NCj4gDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lwY29yZUBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQoNCg0K DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mg b3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJl Y2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFu ZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21t dW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRl ZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVz ZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQu IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0 aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlz IG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2Fn ZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0g c3lzdGVtLg0K --=_alternative 000615E148257685_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QnkgbXlzZWxmLCBJIHRoaW5rIHRoYXQg dGhpcyBpc3N1ZSgmcXVvdDtTdXNwZW5kaW5nDQphbmQgUmVzdW1pbmcgbW9kaWZpY2F0aW9uIG9m IHNlc3Npb24gb3Igc3RyZWFtJnF1b3Q7KSBpcyBub3QgYXMgdXJnZW50DQphcyB0aGUgJnF1b3Q7 c2Vzc2lvbiBzdGF0ZSZxdW90OyBhbmQgJnF1b3Q7ZGlhbG9nIHN0YXRlJnF1b3Q7IGlzc3VlLjwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+V2hpbGUgSSBw cm9wb3NlZCB0aGlzIHRocmVhZCwgdGhlcmUNCmFyZSBsZXNzIHBlb3BsZSBjYXJlIGFib3V0IGl0 LihJbiBmYWN0LCBJIGhhdmUgaW4gcmVtZW1icmFuY2UgdGhhdCBvbmx5DQpQYXVsIGFuZCBDaHJp c3RlciBnYXZlIGNvbW1lbnRzKGlmIHRoZXJlIGFyZSBzb21lb25lIGVsc2UsIHNvcnJ5IGZvciBp dCkpLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QW5k IEkgc3VwcG9ydCB5b3VyIHdheSBhcyA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFj ZT0ic2Fucy1zZXJpZiI+JnF1b3Q7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlPjx0dD5J Zg0KcGVvcGxlIHdhbnQgdGhlc2UgaXNzdWVzIHRvIGJlIGNsYXJpZmllZCwgd2Ugc2hvdWxkIGJ5 IGFsbCBtZWFucyBkbyBzby4NCkhvd2V2ZXIsIGlmIHBlb3BsZSBkbyBub3QgcmVhbGx5IGNhcmUg YWJvdXQgdGhlc2UgY29ybmVyIGNhc2VzLCB3ZSA8YnI+DQpzaG91bGQgcHJpb3JpdGl6ZSBvdGhl ciBzcGVjcy48L3R0PjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNl cmlmIj4mcXVvdDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QlRXLCBJIHRo aW5rIGlmIHNvbWVkYXkgbW9yZSBwZW9wbGUNCndhbnQgdG8gY2xhcmlmeSB0aGlzIGlzc3VlLCA8 L2ZvbnQ+PGZvbnQgc2l6ZT0yPjx0dD5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1j YW1hcmlsbG8tc2lwcGluZy1wcmVjb25zLTAwPC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPg0KaXMgYSBuaWNlIHN0YW5kYnkgYW5kIHN0YXJ0aW5nLjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzLDwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+R2FvPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj49PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PTxicj4NCiBaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJyPg0KIFRlbCAm bmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiBUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUyODc3MjEx PGJyPg0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT08L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+PGI+R29uemFsbyBDYW1hcmlsbG8gJmx0O0dvbnphbG8uQ2FtYXJpbGxv QGVyaWNzc29uLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPreivP7IyzogJm5ic3A7c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0K PHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMDktMTItMDYgMTQ6Mzc8L2ZvbnQ+ DQo8dGQgd2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7I yzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Z2FvLnlh bmcyQHp0ZS5jb20uY248L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249 cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8 dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlNJUENPUkUgJmx0O3NpcGNvcmVAaWV0 Zi5vcmcmZ3Q7LCB3YW5nLmxpYm9AenRlLmNvbS5jbjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM 4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtz aXBjb3JlXSBTdXNwZW5kaW5nIGFuZCBSZXN1bWluZw0KbW9kaWZpY2F0aW9uIG9mIHNlc3Npb24g b3Igc3RyZWFtPyAvL05ldyByZXZpc2lvbiBvZiB0aGUgcmUtSU5WSVRFIGhhbmRsaW5nDQpkcmFm dDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8 dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48 dHQ+SGksPGJyPg0KPGJyPg0KW0kgYW0gcmVzdXJyZWN0aW5nIHRoaXMgb2xkIHRocmVhZCBiZWNh dXNlIGl0IGRpZCBub3QgcmVhY2ggYSBjb25jbHVzaW9uLl08YnI+DQo8YnI+DQpPcmlnaW5hbGx5 LCBwcmVjb25kaXRpb25zIHdlcmUgZGVzaWduZWQgd2l0aCBpbml0aWFsIElOVklURSByZXF1ZXN0 cyBpbg0KPGJyPg0KbWluZC4gVGhlIGlkZWEgd2FzIHRvIGtlZXAgdGhlIFVBUyBmcm9tIGFsZXJ0 aW5nIHRoZSBjYWxsZWUgdW50aWwgdGhlIDxicj4NCm1lZGlhIHN0cmVhbXMgd2l0aCBwcmVjb25k aXRpb25zIHdlcmUgcmVhZHkgdG8gYmUgZXN0YWJsaXNoZWQgKGUuZy4sIDxicj4NCnRoZWlyIFFv UyB3YXMgaW4gcGxhY2UpLiBUaGF0IGlzLCBpZiB0aGVyZSB3ZXJlIHNvbWUgc3RyZWFtcyB0aGF0 IGRpZCA8YnI+DQpub3QgaGF2ZSBwcmVjb25kaXRpb25zLCB0aGV5IHdvdWxkIG5vdCBiZSBlc3Rh Ymxpc2hlZCB1bnRpbCB0aGUgPGJyPg0KcHJlY29uZGl0aW9ucyBmb3IgdGhlIG90aGVyIHN0cmVh bXMgd2VyZSBtZXQuIEZvciBleGFtcGxlLCBsZXQgdXMgYXNzdW1lDQo8YnI+DQphbiBpbml0aWFs IElOVklURSB3aXRoIGFuIGF1ZGlvIHN0cmVhbSB3aXRob3V0IHByZWNvbmRpdGlvbnMgYW5kIGEg dmlkZW8NCjxicj4NCnN0cmVhbSB3aXRoIFFvUyBwcmVjb25kaXRpb25zLiBVbnRpbCB0aGUgUW9T IGZvciB0aGUgdmlkZW8gc3RyZWFtIGlzIGluDQo8YnI+DQpwbGFjZSwgdGhlIGF1ZGlvIHN0cmVh bSB3aWxsIG5vdCBiZSBlc3RhYmxpc2hlZCBhbmQgdGhlIGNhbGxlZSB3aWxsIG5vdA0KPGJyPg0K YmUgYWxlcnRlZC4gSW4gc2hvcnQsIHdoZW4gb25lIG9yIG1vcmUgc3RyZWFtcyB3aXRoaW4gYSBz ZXNzaW9uIGhhdmUgPGJyPg0KcHJlY29uZGl0aW9ucywgdGhlIHdob2xlIHNlc3Npb24gZXN0YWJs aXNobWVudCBpcyBzdXNwZW5kZWQgdW50aWwgdGhvc2UNCjxicj4NCnByZWNvbmRpdGlvbnMgYXJl IG1ldC48YnI+DQo8YnI+DQpXaGVuIHdlIGV4dGVuZGVkIHRoZSBjb25jZXB0IG9mIHByZWNvbmRp dGlvbnMgdG8gcmUtSU5WSVRFcywgd2Ugd2FudGVkDQo8YnI+DQp0byBoYXZlIHNpbWlsYXIgYmVo YXZpb3IgZm9yIGluaXRpYWwgSU5WSVRFcyBhbmQgZm9yIHJlLUlOVklURXMuIFRoYXQgaXMNCjxi cj4NCndoeSBSRkMgNDAzMiB0YWxrcyBhYm91dCBhYm91dCAqc2Vzc2lvbiogZXN0YWJsaXNobWVu dCBiZWluZyBzdXNwZW5kZWQ6PGJyPg0KPGJyPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNDAzMiNzZWN0aW9uLTMuNDxicj4NCjxicj4NClRoZXJlZm9yZSwgdGhlIGlkZWEgd2FzIHRo YXQgbm8gY2hhbmdlcyB3ZXJlIGFwcGxpZWQgdG8gYW55IHN0cmVhbSB1bnRpbA0KPGJyPg0KYWxs IHRoZSBwcmVjb25kaXRpb25zIHdlcmUgbWV0Ljxicj4NCjxicj4NClNvLCB0aGUgYWJvdmUgd2Fz IG91ciBvcmlnaW5hbCB0aGlua2luZy4gSG93ZXZlciwgYXQgcHJlc2VudCB3ZSBoYXZlIGENCjxi cj4NCmJldHRlciB1bmRlcnN0YW5kaW5nIGFib3V0IHRoZSBwcm9ibGVtcyB3aXRoIGxvbmctbGl2 ZWQgcmUtSU5WSVRFIDxicj4NCnRyYW5zYWN0aW9ucy4gSWYgd2UgYWxsb3cgdGhlIHdob2xlIHNl c3Npb24gZXN0YWJsaXNobWVudCB0byBiZSA8YnI+DQpzdXNwZW5kZWQsIGl0IHdvdWxkIGJlIGlt cG9zc2libGUgdG8gY2hhbmdlIHRoZSBzZXNzaW9uIHBhcmFtZXRlcnMgb2YgPGJyPg0KYW55IHN0 cmVhbSB3aGlsZSB0aGUgVUFzIHdlcmUgd29ya2luZyBvbiBtZWV0aW5nIHRoZSBwcmVjb25kaXRp b25zIG9mIDxicj4NCm90aGVyIHN0cmVhbXMuIE9uIHRoZSBvdGhlciBoYW5kLCB3ZSB3YW50IHRv IGJlIGFibGUgdG8gbWFrZSB0aGUgY2hhbmdlcw0KPGJyPg0KdG8gb25lIHN0cmVhbSBjb25kaXRp b25hbCB0byB0aGUgY2hhbmdlcyBvbiBvdGhlciBzdHJlYW0gYmVpbmcgZXhlY3V0ZWQNCjxicj4N CihlLmcuLCB1c2UgdGhpcyBuZXcgYXVkaW8gY29kZWMgaWYgeW91IGFjY2VwdCBhZGRpbmcgYSB2 aWRlbyBzdHJlYW0gdG8NCjxicj4NCnRoZSBzZXNzaW9uOyBvdGhlcndpc2UsIGtlZXAgb24gdXNp bmcgdGhlIG9sZCBhdWRpbyBjb2RlYykuPGJyPg0KPGJyPg0KQmVmb3JlIHdlIGV4cGxvcmUgdGhp cyBtb3JlIGRlZXBseSwgSSB3b3VsZCBsaWtlIHRvIHVuZGVyc3RhbmQgaWYgdGhlcmUNCjxicj4N CmlzIGludGVyZXN0IGluIHJlc29sdmluZyB0aGlzIHR5cGUgb2YgaXNzdWUuIFNvbWUgdGltZSBh Z28gSSBwdXQgPGJyPg0KdG9nZXRoZXIgYSBkcmFmdCBkZWFsaW5nIHdpdGggYSBzaW1pbGFyIGlz c3VlIChtZWRpYSBzdGF0ZSBkdXJpbmcgPGJyPg0KcHJlY29uZGl0aW9ucykgYnV0IHdlIGNvbmNs dWRlZCB0aGF0LCBhdCB0aGF0IHBvaW50LCB0aGVyZSB3YXMgbm90IDxicj4NCmVub3VnaCBpbnRl cmVzdCBmb3IgbWUgKG9yIGFueW9uZSBlbHNlIGZvciB0aGF0IG1hdHRlcikgdG8gcHV0IG1vcmUg PGJyPg0KZW5lcmd5IGludG8gaXQ6PGJyPg0KPGJyPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtY2FtYXJpbGxvLXNpcHBpbmctcHJlY29ucy0wMDxicj4NCjxicj4NCklmIHBlb3Bs ZSB3YW50IHRoZXNlIGlzc3VlcyB0byBiZSBjbGFyaWZpZWQsIHdlIHNob3VsZCBieSBhbGwgbWVh bnMgZG8NCjxicj4NCnNvLiBIb3dldmVyLCBpZiBwZW9wbGUgZG8gbm90IHJlYWxseSBjYXJlIGFi b3V0IHRoZXNlIGNvcm5lciBjYXNlcywgd2UNCjxicj4NCnNob3VsZCBwcmlvcml0aXplIG90aGVy IHNwZWNzLjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQo8YnI+DQpHb256YWxvPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KZ2FvLnlhbmcyQHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQom Z3Q7IENvbnNpZGVyaW5nIGEgdXNlIGNhc2UsIEEgYW5kIEIgaGFzIGEgYXVkaW8gb25seSBzZXNz aW9uLiBUaGVuIEEgc2VuZA0KYSA8YnI+DQomZ3Q7IFJlLUlOVklURSBmb3IgYWRkaW5nIHZlZGlv IHN0cmVhbSggd2l0aCBwcmVjb25kaXRpb24pIGFuZCBjaGFuZ2luZw0KY29kZWMgPGJyPg0KJmd0 OyBvciBhZGRyZXNzIGZvciBhdWRpbyBzdHJlYW0oIHdpdGhvdXQgcHJlY29uZGl0b24pLjxicj4N CiZndDsgPGJyPg0KJmd0OyBJZiBzdXNwZW5kaW5nIGlzIGVmZmVjdGl2ZSBmb3Igd2hvbGUgc2Vz c2lvbiwgdGhlbiBzdHJlYW1zIHdpdGhvdXQNCjxicj4NCiZndDsgcHJlY29uZGl0aW9uIHNob3Vs ZCB1c2Ugb2xkIHBhcmFtZXRlcnMgd2hpbGUgaW4gc3VzcGVuZGluZyBzdGF0ZS48YnI+DQomZ3Q7 IEZvciB0aGUgdXNlIGNhc2UsIEEgYW5kIEIgc2hvdWxkIG5vdCB1c2UgbmV3IGNvZGVjIG9yIGFk ZHJlc3MgZm9yDQphdWRpbyA8YnI+DQomZ3Q7IGJlZm9yZSB2ZWRpbydzIHByZWNvbmRpdG9uIGlz IG1ldC48YnI+DQomZ3Q7IDxicj4NCiZndDsgSWYgc3VzcGVuZGluZyBpcyBlZmZlY3RpdmUgZm9y IHN0cmVhbXMgd2l0aCBwcmVjb25kaXRpb24sIHRoZSB0aGVuDQo8YnI+DQomZ3Q7IHN0cmVhbXMg d2l0aG91dCBwcmVjb25kaXRpbyBjYW4gdXNlIG5ldyBwYXJhbWV0ZXJzIGFmdGVyIGZpcnN0IE8v QQ0KPGJyPg0KJmd0OyBkdXJpbmcgdGhlIFJlLUlOVklURS48YnI+DQomZ3Q7IEZvciB0aGUgdXNl IGNhc2UsIEEgYW5kIEIgY2FuIHVzZSBuZXcgY29kZWMgb3IgYWRkcmVzcyBmb3IgYXVkaW8gYmVm b3JlDQo8YnI+DQomZ3Q7IHZlZGlvJ3MgcHJlY29uZGl0b24gaXMgbWV0Ljxicj4NCiZndDsgPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IEkgcHJlZmVyIHRoZSBmaXJzdCBvbmUsIGFzOzxicj4NCiZndDsg MS4gVG8gZGVsYXkgdXNpbmcgb2YgbmV3IHBhcmFtZXRlcnMgZm9yIHN0cmVhbSB3aXRob3V0IHBy ZWNvbmRpdGlvbg0KbWF5IDxicj4NCiZndDsgYXJvc2UgbWVkaWEgY2xpcCBwcm9ibGVtLjxicj4N CiZndDsgMi4gQmVoYXZpb3Igb2Ygc3RyZWFtcyB3aXRob3V0IHByZWNvbmRpdGlvbiBzaG91bGQg YmUgaW5kZXBlbmRlbnQNCm9mIDxicj4NCiZndDsgZXhpc3RlbmNlIG9mIG90aGVyIHN0cmVhbXMo IHdpdGggcHJlY29uZGl0aW9uKS48YnI+DQomZ3Q7IDxicj4NCiZndDsgPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT08YnI+DQomZ3Q7IFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8 YnI+DQomZ3Q7IFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiZndDsgVGVsMiAmbmJzcDsg OigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiZndDsgZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20u Y248YnI+DQomZ3Q7ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBU aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMNCm1haWwgaXMgc29sZWx5IHByb3BlcnR5 IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uDQpp cyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBt YWludGFpbiBzZWNyZWN5DQphbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNv bnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0bw0Kb3RoZXJzLjxicj4NCiZndDsgVGhpcyBl bWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBh bmQNCmludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRp dHkgdG8gd2hvbSB0aGV5IGFyZQ0KYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3INCm9mIHRoZSBtZXNz YWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhl IGluZGl2aWR1YWwNCnNlbmRlci48YnI+DQomZ3Q7IFRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2Fu bmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0NCnN5c3RlbS48YnI+DQom Z3Q7IDxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0Kc2lwY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQpzaXBjb3JlQGlldGYub3JnPGJy Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlPGJyPg0KPGJy Pg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZu YnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7 Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5 Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5p emF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5i c3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5i c3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3km bmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rp c2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21t dW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQm bmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5i c3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xl bHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2 aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJz cDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVj ZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNl Jm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5i c3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5i c3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhl Jm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFz Jm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5i c3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9w cmU+ --=_alternative 000615E148257685_=-- From vkg@bell-labs.com Sun Dec 6 18:41:22 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54E0B3A69F7 for ; Sun, 6 Dec 2009 18:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Vkdgi2I35WYW for ; Sun, 6 Dec 2009 18:41:21 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 2D45C3A69F4 for ; Sun, 6 Dec 2009 18:41:21 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id nB72fBMj018061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 6 Dec 2009 20:41:11 -0600 (CST) Received: from shoonya.ih.lucent.com (guard.research.bell-labs.com [135.104.2.10]) by umail.lucent.com (8.13.8/TPES) with ESMTP id nB72fA6L006681 for ; Sun, 6 Dec 2009 20:41:10 -0600 (CST) Message-ID: <4B1C6B6E.8070801@bell-labs.com> Date: Sun, 06 Dec 2009 20:41:50 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: sipcore@ietf.org References: <4AFA3E1A.8060204@ericsson.com> <4B0FD53A.10705@ericsson.com> <4B1BE59E.3040803@ericsson.com> In-Reply-To: <4B1BE59E.3040803@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Mailman-Approved-At: Sun, 06 Dec 2009 18:43:00 -0800 Subject: Re: [sipcore] Reviewing the sec-flows draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 02:41:22 -0000 On 12/06/2009 11:10 AM, Gonzalo Camarillo wrote: > Folks, > > as you know, when we restructured the RAI area one of the plans was to > avoid working on specifications people were not interested in any > longer. Adam and I have had to assign a new editor (with cycles) to this > document and have unsuccessfully asked for reviewers *many* times. If we > do not see some activity related to this draft in the near future the > only conclusion we can draw is that we should abandon it. > > So, if you think this is important, now it would be a good time for > volunteering. Also, if you think we should abandon this draft, let us > know as well. We should NOT abandon it; the draft has some good information. I had promised Brian a review of some sections after Thanksgiving, but have been tied up last week. I intend to send out comments this week (i.e., Dec. 7). Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From salvatore.loreto@ericsson.com Mon Dec 7 00:43:12 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F33A528C137 for ; Mon, 7 Dec 2009 00:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 ksNclMLhOd8B for ; Mon, 7 Dec 2009 00:43:11 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A759E28C138 for ; Mon, 7 Dec 2009 00:43:10 -0800 (PST) X-AuditID: c1b4fb3c-b7bd1ae000001924-f9-4b1cc012f315 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id E2.19.06436.210CC1B4; Mon, 7 Dec 2009 09:42:58 +0100 (CET) To: undisclosed-recipients:; Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 09:41:10 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 09:41:10 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4457C2505; Mon, 7 Dec 2009 10:41:10 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0FAE821A31; Mon, 7 Dec 2009 10:41:10 +0200 (EET) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 92AA2219B5; Mon, 7 Dec 2009 10:41:09 +0200 (EET) Message-ID: <4B1CBFA5.7020300@ericsson.com> Date: Mon, 07 Dec 2009 10:41:09 +0200 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 References: <4B19A017.1090402@estacado.net> <4B19A88F.3030008@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 07 Dec 2009 08:41:10.0473 (UTC) FILETIME=[06C1C390:01CA7719] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , SIPCORE Subject: Re: [sipcore] Call for consensus:adopting draft-camarillo-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 08:43:12 -0000 +1 I think we need the WG item /Sal > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 5. joulukuuta 2009 2:26 > To: Adam Roach > Cc: SIPCORE > Subject: Re: [sipcore] Call for consensus:adopting > draft-camarillo-sipcore-reinvite > > yes, adopt draft-camarillo-sipcore-reinvite > > Thanks, > Paul > > Adam Roach wrote: > >> [as chair] >> >> Regarding the following milestone on our charter: >> >> Invite Transaction Handling Correction to IESG (PS) >> >> To fulfill this milestone, there are two potential problems that may >> need to be addressed. One of them relates to handling of 200-class >> responses to INVITE messages; the other relates to re-INVITE and >> target refresh handling. >> >> The first problem is addressed by an adopted working group item >> (draft-ietf-sipcore-invfix). We do not currently have an adopted item >> for the second problem. >> >> The chairs would like to solicit feedback from the group regarding >> adoption of draft-camarillo-sipcore-reinvite as a working group item >> to fix the second set of problems. Please comment on the SIPCORE >> mailing list. If you agree with this adoption, a simple note stating >> as much is >> encouraged: we cannot determine consensus without feedback, and >> silence is not very informative. >> >> Thanks! >> >> /a >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From rjsparks@nostrum.com Mon Dec 7 11:32:50 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BAEF3A6817 for ; Mon, 7 Dec 2009 11:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, SPF_PASS=-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 GFoKgueW1b5A for ; Mon, 7 Dec 2009 11:32:49 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 235473A68CB for ; Mon, 7 Dec 2009 11:32:48 -0800 (PST) Received: from dn3-232.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nB7JWYrm002848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Dec 2009 13:32:34 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 7 Dec 2009 13:32:34 -0600 References: <70463F72-4486-4384-B294-078EA191CC9B@nostrum.com> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: draft-ietf-sipcore-199@tools.ietf.org, sipcore@ietf.org, sipcore-chairs@tools.ietf.org Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 19:32:50 -0000 On Oct 14, 2009, at 1:20 PM, Christer Holmberg wrote: > > Hi Robert, > > Comments inline. > > ------------------- > >> In preparing this document for IETF last call, I found a few points >> we > should discuss before moving forward. >> >> Major Comments >> >> I don't understand the sentence in section 4.1 that talks about > RFC5009. There is not enough here to inform an >> implementor and don't think 5009 is required reading to understand or > implement this document (hence, I don't agree that >> 5009 should be a normative reference). The sentence has been there >> for > a long time, but I think other things have pulled >> reviewer's eyes away from it. > > I can change 5009 into an informative reference. > You didn't do this in -01? RjS From rjsparks@nostrum.com Mon Dec 7 11:37:54 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70F1C3A696B for ; Mon, 7 Dec 2009 11:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, SPF_PASS=-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 Y3OsO8reM1gQ for ; Mon, 7 Dec 2009 11:37:53 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 3162E3A6817 for ; Mon, 7 Dec 2009 11:37:52 -0800 (PST) Received: from dn3-232.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nB7JbdQ1003272 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Dec 2009 13:37:39 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: <58E966D3-5D25-4171-AD5B-0D4CC3A3A3D4@nostrum.com> From: Robert Sparks To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 7 Dec 2009 13:37:38 -0600 References: <70463F72-4486-4384-B294-078EA191CC9B@nostrum.com> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: draft-ietf-sipcore-199@tools.ietf.org, sipcore@ietf.org, sipcore-chairs@tools.ietf.org Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 19:37:54 -0000 On Oct 14, 2009, at 1:20 PM, Christer Holmberg wrote: ... > > >> In Sections 5 and 9, the document says to include SDP in a 199 if >> RFC3263 requires it. I would like to see some additional discussion > around whether this is the right way to deal with >> this edge case. If it is, then this document needs to explain how a >> UA > should handle receiving an offer in a 199. A >> different path out is to say that such a 199 MUST NOT be sent >> reliably. > (More explanation of why we allow 199 to be sent >> reliably at all (why this is SHOULD not MUST) would also help). > > I wouldn't like to generally disallow to send 199 reliably, in case > there is some future use-case which would need it. That's the reason > for > the SHOULD: don't send it reliably unless you have a good reason to do > so. > > Regarding the specific must-include-SDP-offer case (which will be very > rare, in my opinion) I see two alternatives: > > 1. We disallow reliable 199 in such cases > 2. We say that the UAS must include e.g. an SDP offer without any m- > lines. > > My proposal is to describe both alternatives, and say that the UAS > MUST > use of them. > I'm not seeing any changes in -01 addressing this comment? RjS From rjsparks@nostrum.com Mon Dec 7 11:41:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 065193A6403 for ; Mon, 7 Dec 2009 11:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-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 B0qMm8zt6RBP for ; Mon, 7 Dec 2009 11:41:23 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id CE3C43A67AE for ; Mon, 7 Dec 2009 11:41:22 -0800 (PST) Received: from dn3-232.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nB7Jf8Xo006262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Dec 2009 13:41:09 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: Christer Holmberg In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-34-587310858 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 7 Dec 2009 13:41:08 -0600 References: <70463F72-4486-4384-B294-078EA191CC9B@nostrum.com> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: draft-ietf-sipcore-199@tools.ietf.org, sipcore@ietf.org, sipcore-chairs@tools.ietf.org Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 19:41:24 -0000 --Apple-Mail-34-587310858 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Oct 14, 2009, at 1:20 PM, Christer Holmberg wrote: ... > >> Last sentence on page 8: This paragraph is talking about the proxy > generating a 199 itself. It would be terribly >> misleading from a diagnostics point of view for the proxy to put the > Record-Route and contact from some UA (it would then >> look like the 199 came from the remote endpoint - is that what you >> are > trying to accomplish?). Why is having these bits >> in the message useful at all? > > The intention is NOT to make the 199 look like it came from the > endpoint, but someone commented that the UA could be confused if the > bits aren't included. > > Personally I would bo ok to remove the text, since the proxy is not > allowed to send a 199 reliably (there will be no PRACK etc, for which > the bits would b needed) The document shows no change from -00 addressing this comment either? RjS --Apple-Mail-34-587310858 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Oct 14, 2009, = at 1:20 PM, Christer Holmberg = wrote:
...


Last sentence on = page 8: This paragraph is talking about the = proxy
generating a 199 itself. It would be terribly =
misleading from a diagnostics point of = view for the proxy to put the
Record-Route and contact = from some UA (it would then
look like the = 199 came from the remote endpoint - is that what you = are
trying to accomplish?). Why is having these bits =
in the message useful at = all?

The intention is NOT to make the 199 look like = it came from the
endpoint, but someone commented that the UA could be = confused if the
bits aren't included.

Personally I would bo ok = to remove the text, since the proxy is not
allowed to send a 199 = reliably (there will be no PRACK etc, for which
the bits would b = needed)

The document shows no = change from -00 addressing this comment = either?

RjS

= --Apple-Mail-34-587310858-- From rjsparks@nostrum.com Mon Dec 7 11:43:45 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 613583A67B2 for ; Mon, 7 Dec 2009 11:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, SPF_PASS=-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 iXOfdp08-gdh for ; Mon, 7 Dec 2009 11:43:44 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 3356D3A6403 for ; Mon, 7 Dec 2009 11:43:43 -0800 (PST) Received: from dn3-232.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nB7JhUmc006436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Dec 2009 13:43:30 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: <3E7D74BA-84DB-4906-BB66-C30080071F5A@nostrum.com> From: Robert Sparks To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 7 Dec 2009 13:43:29 -0600 References: <70463F72-4486-4384-B294-078EA191CC9B@nostrum.com> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: draft-ietf-sipcore-199@tools.ietf.org, sipcore@ietf.org, sipcore-chairs@tools.ietf.org Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 - 199 after final response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 19:43:45 -0000 I still can't find where in the document this is answered. Can you point to the sentence(s) that you think covers these. RjS On Oct 16, 2009, at 1:29 PM, Christer Holmberg wrote: > > Hi, > >>> I don't think the document currently provides a solid answer to this >>> question (maybe I'm missing it): If a proxy has >>> multiple branches outstanding and receives a 200 OK on one of >>> them, it >>> forwards it immediately. As the other branches >>> complete, should the proxy send 199s for them (assuming they didn't >>> complete with additional 200s)? >> >> The intention is that NO 199s are sent after 200 OK has been >> forwarded > on a branch, and the proxy sends CANCEL on the other branches. >> >> I DO agree that it is not clear in the spec, and that we can add some > text about that. > > Actually, when taking a closer look at the text, I think this is > already > covered. The text says that when the proxy receives a non-2xx final > response, it sends 199 if the forking proxy has not already sent a > final > resposne for any of the early dialogs. So, if a final response (2xx or > non-2xx) response has been sent, additional non-2xx responses will not > trigger 199. > > Regards, > > Christer > From rjsparks@nostrum.com Mon Dec 7 11:51:01 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D3A428C123 for ; Mon, 7 Dec 2009 11:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-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 E6zgYSw85e1Q for ; Mon, 7 Dec 2009 11:51:00 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id C8C3D3A689C for ; Mon, 7 Dec 2009 11:50:59 -0800 (PST) Received: from dn3-232.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nB7Joj2N007028 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Dec 2009 13:50:45 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: <78389296-61C0-4B3B-A1AC-0C0C60804EDA@nostrum.com> From: Robert Sparks To: Christer Holmberg In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-35-587887565 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 7 Dec 2009 13:50:45 -0600 References: <70463F72-4486-4384-B294-078EA191CC9B@nostrum.com> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: draft-ietf-sipcore-199@tools.ietf.org, sipcore@ietf.org, sipcore-chairs@tools.ietf.org Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 19:51:01 -0000 --Apple-Mail-35-587887565 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit While these were less important, I'm not seeing any changes at all addressing them, even for those you indicated you would make changes. At this point, I'd like to double-check that you submitted what you meant to submit as -01? RjS On Oct 14, 2009, at 1:20 PM, Christer Holmberg wrote: > >> Minor Comments >> >> Bottom of page 3, next to last paragraph, last sentence: This assumes > the response can't be recovered from, precluding >> responding to authentication challenges, extension negotiation, etc. > > Again, I am not sure I understand the comment. > > ------------------- > >> Page 6 - NOTE in section 4.1: Why isn't this calling out DTLS/SRTP? > > I can add it. How would you like to change to look like? > > ------------------- > >> Section 8 is completely redundant. It adds no value to the draft. I > suggest deleting it. > > I based this on other drafts, but I can remove it. > > ------------------- > >> Nits >> >> The 2119 language (two instances of MAY unless I missed more) >> appearing > in the introduction are inappropriate in an >> introduction. > > I propose to change "MAY" to "can" (in the introduction). > > ------------------- > >> Page 5, second paragraph : is "shall not" meant to be normative? > > Yes. I'll change it to uppercase. > > ------------------- > >> Page 8 Section 6 first paragraph: Suggest dropping "on an early >> dialog" > from the first sentence. Does it add anything? >> This would help avoid the problem the current text has about assuming > proxies know about dialogs. > > I can drop it from the first sentence. > > ------------------- > > Thanks for your comments! > > Regards, > > Christer --Apple-Mail-35-587887565 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
While these were less = important, I'm not seeing any changes at all addressing them, even for = those you indicated you would make changes.

At = this point, I'd like to double-check that you submitted what you meant = to submit as = -01?

RjS

On Oct = 14, 2009, at 1:20 PM, Christer Holmberg wrote:

Minor = Comments

Bottom of page = 3, next to last paragraph, last sentence: This = assumes
the response can't be recovered from, precluding =
responding to authentication challenges, = extension negotiation, etc.

Again, I am not sure I = understand the comment.

-------------------

Page 6 - NOTE in section 4.1: Why isn't this calling out = DTLS/SRTP?

I can add it. How would you like to = change to look like?

-------------------

Section 8 is completely redundant. It adds no value to the = draft. I
suggest deleting it.

I based this on = other drafts, but I can remove = it.

-------------------

Nits

The 2119 = language (two instances of MAY unless I missed more) = appearing
in the introduction are inappropriate in an =
introduction.

I = propose to change "MAY" to "can" (in the = introduction).

-------------------

Page 5, second paragraph : is "shall not" meant to be = normative?

Yes. I'll change it to = uppercase.

-------------------

Page 8 Section 6 first paragraph: Suggest dropping "on an = early dialog"
from the first sentence. Does it add = anything?
This would help avoid the = problem the current text has about assuming
proxies know = about dialogs.

I can drop it from the first = sentence.

-------------------

Thanks for your = comments!

Regards,

Christer

= = --Apple-Mail-35-587887565-- From christer.holmberg@ericsson.com Tue Dec 8 11:56:44 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 441253A692E for ; Tue, 8 Dec 2009 11:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 StMW00hb-kBx for ; Tue, 8 Dec 2009 11:56:43 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 44AF13A6A17 for ; Tue, 8 Dec 2009 11:56:43 -0800 (PST) X-AuditID: c1b4fb3e-b7b17ae0000045b9-c6-4b1eaf6f113a Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 23.8A.17849.F6FAE1B4; Tue, 8 Dec 2009 20:56:31 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 20:56:05 +0100 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: Tue, 8 Dec 2009 20:56:05 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] AD review draft-ietf-sipcore-199-00 - 5009 reference Thread-Index: Acp3dAh7wI8QlqOmSLmWPjEuTFiN6QAy5qUQ References: <70463F72-4486-4384-B294-078EA191CC9B@nostrum.com> From: "Christer Holmberg" To: "Robert Sparks" X-OriginalArrivalTime: 08 Dec 2009 19:56:05.0994 (UTC) FILETIME=[7A61A4A0:01CA7840] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-sipcore-199@tools.ietf.org, sipcore@ietf.org, sipcore-chairs@tools.ietf.org Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 - 5009 reference X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 19:56:44 -0000 =20 Hi Robert, It seems like I did some of the changes in another XML file than the one I used to produce the -01 draft - sorry for that :( >>>I don't understand the sentence in section 4.1 that talks about >>>RFC5009. There is not enough here to inform an >>>implementor and don't think 5009 is required reading to understand or >>>implement this document (hence, I don't agree that >>>5009 should be a normative reference). The sentence has been there=20 >>>for a long time, but I think other things have pulled >>>reviewer's eyes away from it. >> >>I can change 5009 into an informative reference. > >You didn't do this in -01? It is now in the correct XML file, so it will be done in -02. Regards, Christer From christer.holmberg@ericsson.com Tue Dec 8 12:46:11 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3E533A6808 for ; Tue, 8 Dec 2009 12:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 gSAE5rLHxoOU for ; Tue, 8 Dec 2009 12:46:11 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6FEA53A684E for ; Tue, 8 Dec 2009 12:46:10 -0800 (PST) X-AuditID: c1b4fb3c-b7b8dae0000047e9-ce-4b1ebb06e829 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id BB.9C.18409.60BBE1B4; Tue, 8 Dec 2009 21:45:58 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 21:45:16 +0100 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: Tue, 8 Dec 2009 21:45:16 +0100 Message-ID: In-Reply-To: <78389296-61C0-4B3B-A1AC-0C0C60804EDA@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] AD review draft-ietf-sipcore-199-00 Thread-Index: Acp3dpKoHOpVGNy5T6WQ0P+FVqf0ugAzRfhg References: <70463F72-4486-4384-B294-078EA191CC9B@nostrum.com> <78389296-61C0-4B3B-A1AC-0C0C60804EDA@nostrum.com> From: "Christer Holmberg" To: "Robert Sparks" X-OriginalArrivalTime: 08 Dec 2009 20:45:16.0809 (UTC) FILETIME=[59344790:01CA7847] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-sipcore-199@tools.ietf.org, sipcore@ietf.org, sipcore-chairs@tools.ietf.org Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 20:46:11 -0000 Hi, =20 >While these were less important, I'm not seeing any changes at all addressing them, even for those you indicated you would make changes. > > >At this point, I'd like to double-check that you submitted what you meant to submit as -01? Again, most changes were done (note the DTLS/SRTP issue, though), but in the wrong xml file. "Change done now" means that the changes will be in version -02. ------------------- >>Bottom of page 3, next to last paragraph, last sentence: This assumes >>the response can't be recovered from, precluding responding to authentication challenges, extension negotiation, etc. > =09 >Again, I am not sure I understand the comment. The sentence tries to describe current behavior. I added ", or retry," to the text, in order to clarify that the UAC may retry the session setup. "When SIP entities upstream receive the non-2xx final response they will release resources associated with the session, and the UAC will terminate, or retry, the session setup." =09 ------------------- =09 >>Page 6 - NOTE in section 4.1: Why isn't this calling out DTLS/SRTP? > =09 >I can add it. How would you like to change to look like? On this topic I did send out an e-mail (RE: [sipcore] AD review draft-ietf-sipcore-199-00 - DTLS/SRTP), where I said: "I would need some clarification on why DTLS would have to be added here. The issue is not related to a specific key management mechanism used, but with the fact that the media is encrypted in general. Of course different key management mechanisms may have different impacts on the needed resources etc, but I still don't see why this would be an issue specific to DTLS." =09 ------------------- =09 >>Section 8 is completely redundant. It adds no value to the draft. I suggest deleting it. > >I based this on other drafts, but I can remove it. Change done now. =09 ------------------- =09 >>The 2119 language (two instances of MAY unless I missed more) appearing >>in the introduction are inappropriate in an introduction. > =09 >I propose to change "MAY" to "can" (in the introduction). Change done now. =09 ------------------- =09 =09 >>Page 5, second paragraph : is "shall not" meant to be normative? > =09 >Yes. I'll change it to uppercase. =09 Change done now. ------------------- =09 =09 >>Page 8 Section 6 first paragraph: Suggest dropping "on an early dialog" >>from the first sentence. Does it add anything?=20 >>This would help avoid the problem the current text has about assuming >>proxies know about dialogs. >=09 >I can drop it from the first sentence. Change done now. =09 ------------------- Again, sorry for the mess. =09 =09 Regards, =09 Christer =09 From christer.holmberg@ericsson.com Tue Dec 8 12:50:52 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6284F3A692C for ; Tue, 8 Dec 2009 12:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 GB8JBxAtFDCb for ; Tue, 8 Dec 2009 12:50:51 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id E79983A691C for ; Tue, 8 Dec 2009 12:50:50 -0800 (PST) X-AuditID: c1b4fb24-b7beeae000003a71-e8-4b1ebc1e5053 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 9A.FA.14961.E1CBE1B4; Tue, 8 Dec 2009 21:50:39 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 21:49:16 +0100 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: Tue, 8 Dec 2009 21:49:15 +0100 Message-ID: In-Reply-To: <3E7D74BA-84DB-4906-BB66-C30080071F5A@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] AD review draft-ietf-sipcore-199-00 - 199 after final response Thread-Index: Acp3dY75NL/eDXRgSpGr+511af3suwA0d0vw References: <70463F72-4486-4384-B294-078EA191CC9B@nostrum.com> <3E7D74BA-84DB-4906-BB66-C30080071F5A@nostrum.com> From: "Christer Holmberg" To: "Robert Sparks" X-OriginalArrivalTime: 08 Dec 2009 20:49:16.0233 (UTC) FILETIME=[E7E97B90:01CA7847] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-sipcore-199@tools.ietf.org, sipcore@ietf.org, sipcore-chairs@tools.ietf.org Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 - 199 after final response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 20:50:52 -0000 Hi,=20 >I still can't find where in the document this is answered. Can you point to the sentence(s) that you think covers these. Section 6 says: "When a forking proxy receives a non-2xx final response that it recognizes as terminating one or more early dialogs, it SHOULD generate and send a 199 response upstream for each of the terminated early dialogs that satisfy each of the following conditions: - the forking proxy does not intend to forward the final response immediately (in accordance with rules for a forking proxy) - the UAC has indicated support (using the 199 option tag) for the 199 response code - the forking proxy has not already received and forwarded a 199 response for that early dialog - the forking proxy has not already sent a final response for any of the early dialogs" I think the fourth condition addresses your issue. Regards, Christer On Oct 16, 2009, at 1:29 PM, Christer Holmberg wrote: > > Hi, > >>> I don't think the document currently provides a solid answer to this >>> question (maybe I'm missing it): If a proxy has multiple branches=20 >>> outstanding and receives a 200 OK on one of them, it forwards it=20 >>> immediately. As the other branches complete, should the proxy send=20 >>> 199s for them (assuming they didn't complete with additional 200s)? >> >> The intention is that NO 199s are sent after 200 OK has been=20 >> forwarded > on a branch, and the proxy sends CANCEL on the other branches. >> >> I DO agree that it is not clear in the spec, and that we can add some > text about that. > > Actually, when taking a closer look at the text, I think this is=20 > already covered. The text says that when the proxy receives a non-2xx=20 > final response, it sends 199 if the forking proxy has not already sent > a final resposne for any of the early dialogs. So, if a final response > (2xx or > non-2xx) response has been sent, additional non-2xx responses will not > trigger 199. > > Regards, > > Christer > From christer.holmberg@ericsson.com Tue Dec 8 12:55:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A87A83A6A6D for ; Tue, 8 Dec 2009 12:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 3QQOiuGKF0kB for ; Tue, 8 Dec 2009 12:55:18 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id DE35E3A6A68 for ; Tue, 8 Dec 2009 12:55:17 -0800 (PST) X-AuditID: c1b4fb3c-b7b8dae0000047e9-38-4b1ebd293316 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id DD.DC.18409.92DBE1B4; Tue, 8 Dec 2009 21:55:06 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 21:55:05 +0100 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: Tue, 8 Dec 2009 21:55:04 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] AD review draft-ietf-sipcore-199-00 - Contact/Record-Route Thread-Index: Acp3dTq1g/8idqFdQn66gHHYJRidiwA0um7w References: <70463F72-4486-4384-B294-078EA191CC9B@nostrum.com> From: "Christer Holmberg" To: "Robert Sparks" X-OriginalArrivalTime: 08 Dec 2009 20:55:05.0861 (UTC) FILETIME=[B84E7B50:01CA7848] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-sipcore-199@tools.ietf.org, sipcore@ietf.org, sipcore-chairs@tools.ietf.org Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 - Contact/Record-Route X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 20:55:19 -0000 Hi, >>Last sentence on page 8: This paragraph is talking about the proxy >>generating a 199 itself. It would be terribly=20 >>misleading from a diagnostics point of view for the proxy to put the >>Record-Route and contact from some UA (it would then look like the 199 came=20 >>from the remote endpoint - is that what you are trying to accomplish?).=20 >>Why is having these bits in the message useful at all? > =09 >The intention is NOT to make the 199 look like it came from the >endpoint, but someone commented that the UA could be confused if the >bits aren't included. >=09 >Personally I would bo ok to remove the text, since the proxy is not >allowed to send a 199 reliably (there will be no PRACK etc, for which >the bits would b needed) >=09 >The document shows no change from -00 addressing this comment either? In version -02 the last sentence, talking about Contact and Record-Route, will be removed. Regards, Christer From rjsparks@nostrum.com Tue Dec 8 13:03:44 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FFA63A6967 for ; Tue, 8 Dec 2009 13:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.725 X-Spam-Level: X-Spam-Status: No, score=-2.725 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, SPF_PASS=-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 EnfebrfmUFql for ; Tue, 8 Dec 2009 13:03:43 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id A2A613A677D for ; Tue, 8 Dec 2009 13:03:39 -0800 (PST) Received: from [192.168.2.2] (pool-173-57-98-31.dllstx.fios.verizon.net [173.57.98.31]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nB8L3Psj027328 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 Dec 2009 15:03:25 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: <06662B84-BB4C-49F1-A3D4-738A60712247@nostrum.com> From: Robert Sparks To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 8 Dec 2009 15:03:25 -0600 References: <70463F72-4486-4384-B294-078EA191CC9B@nostrum.com> <3E7D74BA-84DB-4906-BB66-C30080071F5A@nostrum.com> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 173.57.98.31 is authenticated by a trusted mechanism) Cc: draft-ietf-sipcore-199@tools.ietf.org, sipcore@ietf.org, sipcore-chairs@tools.ietf.org Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 - 199 after final response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 21:03:44 -0000 Ok - I can see how you are reading the text. I think the opportunity for mis-interpretation is very high here though, and encourage adding a sentence after this saying something like: "As a consequence, once a final response to the INVITE has been issued by the proxy, no further 199 messages corresponding to the INVITE will be generated or forwarded by the proxy" RjS On Dec 8, 2009, at 2:49 PM, Christer Holmberg wrote: > > Hi, > >> I still can't find where in the document this is answered. Can you > point to the sentence(s) that you think covers these. > > Section 6 says: > > "When a forking proxy receives a non-2xx final response that it > recognizes as terminating one or more early dialogs, it SHOULD > generate and send a 199 response upstream for each of the terminated > early dialogs that satisfy each of the following conditions: > > - the forking proxy does not intend to forward the final response > immediately (in accordance with rules for a forking proxy) > > - the UAC has indicated support (using the 199 option tag) for the > 199 response code > > - the forking proxy has not already received and forwarded a 199 > response for that early dialog > > - the forking proxy has not already sent a final response for any of > the early dialogs" > > I think the fourth condition addresses your issue. > > Regards, > > Christer > > > > > On Oct 16, 2009, at 1:29 PM, Christer Holmberg wrote: > >> >> Hi, >> >>>> I don't think the document currently provides a solid answer to >>>> this > >>>> question (maybe I'm missing it): If a proxy has multiple branches >>>> outstanding and receives a 200 OK on one of them, it forwards it >>>> immediately. As the other branches complete, should the proxy send >>>> 199s for them (assuming they didn't complete with additional 200s)? >>> >>> The intention is that NO 199s are sent after 200 OK has been >>> forwarded >> on a branch, and the proxy sends CANCEL on the other branches. >>> >>> I DO agree that it is not clear in the spec, and that we can add >>> some >> text about that. >> >> Actually, when taking a closer look at the text, I think this is >> already covered. The text says that when the proxy receives a non-2xx >> final response, it sends 199 if the forking proxy has not already >> sent > >> a final resposne for any of the early dialogs. So, if a final >> response > >> (2xx or >> non-2xx) response has been sent, additional non-2xx responses will >> not > >> trigger 199. >> >> Regards, >> >> Christer >> > From christer.holmberg@ericsson.com Tue Dec 8 13:06:22 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48A5F3A6A49 for ; Tue, 8 Dec 2009 13:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 X5LE337DjDLd for ; Tue, 8 Dec 2009 13:06:21 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E8AE13A67A5 for ; Tue, 8 Dec 2009 13:06:20 -0800 (PST) X-AuditID: c1b4fb3e-b7b17ae0000045b9-38-4b1ebfc0cc43 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id BC.2C.17849.0CFBE1B4; Tue, 8 Dec 2009 22:06:08 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 22:04:59 +0100 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: Tue, 8 Dec 2009 22:04:59 +0100 Message-ID: In-Reply-To: <58E966D3-5D25-4171-AD5B-0D4CC3A3A3D4@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] AD review draft-ietf-sipcore-199-00 - offer/answer Thread-Index: Acp3dL2+zItDSu37TKamxQMDC1Yr2wAzkFrA References: <70463F72-4486-4384-B294-078EA191CC9B@nostrum.com> <58E966D3-5D25-4171-AD5B-0D4CC3A3A3D4@nostrum.com> From: "Christer Holmberg" To: "Robert Sparks" X-OriginalArrivalTime: 08 Dec 2009 21:04:59.0582 (UTC) FILETIME=[1A311DE0:01CA784A] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-sipcore-199@tools.ietf.org, sipcore@ietf.org, sipcore-chairs@tools.ietf.org Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 - offer/answer X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 21:06:22 -0000 =20 Hi, >>In Sections 5 and 9, the document says to include SDP in a 199 if >>RFC3263 requires it. I would like to see some additional discussion >>around whether this is the right way to deal with >>this edge case. If it is, then this document needs to explain how a=20 >>UA should handle receiving an offer in a 199. A >>different path out is to say that such a 199 MUST NOT be sent=20 >>reliably. >>(More explanation of why we allow 199 to be sent >>reliably at all (why this is SHOULD not MUST) would also help). >> >>I wouldn't like to generally disallow to send 199 reliably, in case=20 >>there is some future use-case which would need it. That's the reason=20 >>for the SHOULD: don't send it reliably unless you have a good reason=20 >>to do so. >> >>Regarding the specific must-include-SDP-offer case (which will be very >>rare, in my opinion) I see two alternatives: >> >>1. We disallow reliable 199 in such cases 2. We say that the UAS=20 >>must include e.g. an SDP offer without any m- lines. >> >>My proposal is to describe both alternatives, and say that the UAS=20 >>MUST use of them. > > >I'm not seeing any changes in -01 addressing this comment? I changed and extended (will be seen in -02) the note into normative text: "A 199 Early Dialog Terminated provisional response SHOULD NOT contain an SDP offer/answer message body, unless required by the rules in [RFC3264]. If the INVITE request did not contain an SDP offer, and the 199 response is the first reliably sent response, the 199 response is required to contain an SDP offer. In this case the UAS SHOULD send the 199 response unreliable, or include an SDP offer with no m- lines=20 in the reliable 199 response." Regards, Christer From christer.holmberg@ericsson.com Tue Dec 8 13:15:23 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA3B43A6A83 for ; Tue, 8 Dec 2009 13:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 KvEPquc2XJFc for ; Tue, 8 Dec 2009 13:15:17 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 698993A6A97 for ; Tue, 8 Dec 2009 13:14:27 -0800 (PST) X-AuditID: c1b4fb24-b7beeae000003a71-a0-4b1ec19c3cfc Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 4E.5B.14961.C91CE1B4; Tue, 8 Dec 2009 22:14:04 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 22:14:04 +0100 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: Tue, 8 Dec 2009 22:14:03 +0100 Message-ID: In-Reply-To: <06662B84-BB4C-49F1-A3D4-738A60712247@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] AD review draft-ietf-sipcore-199-00 - 199 after final response Thread-Index: Acp4SeN+dtc2SX9TRo6CAVZwyvQ7JwAAWDWQ References: <70463F72-4486-4384-B294-078EA191CC9B@nostrum.com> <3E7D74BA-84DB-4906-BB66-C30080071F5A@nostrum.com> <06662B84-BB4C-49F1-A3D4-738A60712247@nostrum.com> From: "Christer Holmberg" To: "Robert Sparks" X-OriginalArrivalTime: 08 Dec 2009 21:14:04.0127 (UTC) FILETIME=[5EC416F0:01CA784B] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-sipcore-199@tools.ietf.org, sipcore@ietf.org, sipcore-chairs@tools.ietf.org Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 - 199 after final response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 21:15:23 -0000 Hi,=20 >Ok - I can see how you are reading the text. > >I think the opportunity for mis-interpretation is very high here though, and encourage adding a sentence after this saying something like: > >"As a consequence, once a final response to the INVITE has been issued by >the proxy, no further 199 messages corresponding to the INVITE will be >generated or forwarded by the proxy" I can do that. I will add the text below the conditions. Regards, Christer On Dec 8, 2009, at 2:49 PM, Christer Holmberg wrote: > > Hi, > >> I still can't find where in the document this is answered. Can you > point to the sentence(s) that you think covers these. > > Section 6 says: > > "When a forking proxy receives a non-2xx final response that it=20 > recognizes as terminating one or more early dialogs, it SHOULD=20 > generate and send a 199 response upstream for each of the terminated=20 > early dialogs that satisfy each of the following conditions: > > - the forking proxy does not intend to forward the final response=20 > immediately (in accordance with rules for a forking proxy) > > - the UAC has indicated support (using the 199 option tag) for the > 199 response code > > - the forking proxy has not already received and forwarded a 199=20 > response for that early dialog > > - the forking proxy has not already sent a final response for any of=20 > the early dialogs" > > I think the fourth condition addresses your issue. > > Regards, > > Christer > > > > > On Oct 16, 2009, at 1:29 PM, Christer Holmberg wrote: > >> >> Hi, >> >>>> I don't think the document currently provides a solid answer to=20 >>>> this > >>>> question (maybe I'm missing it): If a proxy has multiple branches=20 >>>> outstanding and receives a 200 OK on one of them, it forwards it=20 >>>> immediately. As the other branches complete, should the proxy send=20 >>>> 199s for them (assuming they didn't complete with additional 200s)? >>> >>> The intention is that NO 199s are sent after 200 OK has been=20 >>> forwarded >> on a branch, and the proxy sends CANCEL on the other branches. >>> >>> I DO agree that it is not clear in the spec, and that we can add=20 >>> some >> text about that. >> >> Actually, when taking a closer look at the text, I think this is=20 >> already covered. The text says that when the proxy receives a non-2xx >> final response, it sends 199 if the forking proxy has not already=20 >> sent > >> a final resposne for any of the early dialogs. So, if a final=20 >> response > >> (2xx or >> non-2xx) response has been sent, additional non-2xx responses will=20 >> not > >> trigger 199. >> >> Regards, >> >> Christer >> > From gonzalo.camarillo@ericsson.com Wed Dec 9 07:03:55 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDACF28C12C for ; Wed, 9 Dec 2009 07:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.236 X-Spam-Level: X-Spam-Status: No, score=-6.236 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 F+Pw9gLPtzrG for ; Wed, 9 Dec 2009 07:03:55 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 6C7E928C133 for ; Wed, 9 Dec 2009 07:03:54 -0800 (PST) X-AuditID: c1b4fb3e-b7b0bae000006a3b-12-4b1fbc4d5097 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id E6.EB.27195.D4CBF1B4; Wed, 9 Dec 2009 16:03:42 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 16:03:41 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 16:03:41 +0100 Message-ID: <4B1FBC4C.3010608@ericsson.com> Date: Wed, 09 Dec 2009 17:03:40 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <70463F72-4486-4384-B294-078EA191CC9B@nostrum.com> <78389296-61C0-4B3B-A1AC-0C0C60804EDA@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Dec 2009 15:03:41.0117 (UTC) FILETIME=[CB3B9ED0:01CA78E0] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-sipcore-199@tools.ietf.org, sipcore@ietf.org, sipcore-chairs@tools.ietf.org Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 15:03:56 -0000 Hi Christer, > Again, most changes were done (note the DTLS/SRTP issue, though), but in > the wrong xml file. "Change done now" means that the changes will be in > version -02. why don't you submit 02 now so that people can follow the discussions more clearly? You can submit 03 later if more changes are needed. Thanks, Gonzalo From rjsparks@nostrum.com Wed Dec 9 08:07:33 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6826128C194; Wed, 9 Dec 2009 08:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-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 HjpzcNHm7skw; Wed, 9 Dec 2009 08:07:32 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id A5D4328C14A; Wed, 9 Dec 2009 08:07:31 -0800 (PST) Received: from dn3-232.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nB9G7ITt021508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Dec 2009 10:07:18 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: <3EE30ED1-391F-425A-B896-95897FA58A9E@nostrum.com> From: Robert Sparks To: rai@ietf.org, SIPCORE Content-Type: multipart/alternative; boundary=Apple-Mail-40-747280223 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 9 Dec 2009 10:07:17 -0600 References: <20091208214444.D5C643A68E1@core3.amsl.com> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] Fwd: [Sipping] Last Call: draft-ietf-sipping-config-framework (A Framework for Session Initiation Protocol User Agent Profile Delivery) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 16:07:33 -0000 --Apple-Mail-40-747280223 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Forwarding in case you're not watching the SIPPING list closely: Begin forwarded message: > From: The IESG > Date: December 8, 2009 3:44:44 PM CST > To: IETF-Announce > Cc: sipping@ietf.org > Subject: [Sipping] Last Call: draft-ietf-sipping-config-framework (A > Framework for Session Initiation Protocol User Agent Profile > Delivery) to Proposed Standard > Reply-To: ietf@ietf.org > > The IESG has received a request from the Session Initiation Proposal > Investigation WG (sipping) to consider the following document: > > - 'A Framework for Session Initiation Protocol User Agent Profile > Delivery ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to > the > ietf@ietf.org mailing lists by 2009-12-22. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The IPR disclosure at > https://datatracker.ietf.org/ipr/search/?option=document_search&id_document_tag=10128 > was received after the working group requested publication. Please > consider that > disclosure when preparing comments. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-16.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=10128&rfc_flag=0 > > _______________________________________________ > Sipping mailing list https://www.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 --Apple-Mail-40-747280223 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Forwarding in case you're = not watching the SIPPING list = closely:


Begin forwarded = message:

From: The IESG <iesg-secretary@ietf.org>
Date: December 8, 2009 3:44:44 PM = CST
To: IETF-Announce <ietf-announce@ietf.org>
Subject: = [Sipping] Last Call: draft-ietf-sipping-config-framework = (A Framework for Session Initiation Protocol User Agent Profile = Delivery) to Proposed Standard
Reply-To: ietf@ietf.org

The IESG has = received a request from the Session Initiation Proposal =
Investigation WG (sipping) to consider the following = document:

- 'A Framework for Session Initiation Protocol User = Agent Profile
  Delivery '
=   <draft-ietf-sipping-config-framework-16.txt> as a = Proposed Standard

The IESG plans to make a decision in the next = few weeks, and solicits
final comments on this action.  Please = send substantive comments to the
ietf@ietf.org mailing lists by = 2009-12-22. Exceptionally,
comments may be sent to iesg@ietf.org instead. In either case, = please
retain the beginning of the Subject line to allow automated = sorting.

The IPR disclosure at
https://datatracker.ietf.org/ipr/search/?opti= on=3Ddocument_search&id_document_tag=3D10128
was received = after the working group requested publication. Please consider = that
disclosure when preparing comments.

The file can be = obtained = via
http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-frame= work-16.txt


IESG discussion can be tracked = via
https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_i= d&dTag=3D10128&rfc_flag=3D0

_______________________________= ________________
Sipping mailing list =  https://www.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

= --Apple-Mail-40-747280223-- From rjsparks@nostrum.com Wed Dec 9 11:27:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6738D3A6A44 for ; Wed, 9 Dec 2009 11:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, SPF_PASS=-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 mJha+6eWS7qY for ; Wed, 9 Dec 2009 11:27:39 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 275ED28C1BB for ; Wed, 9 Dec 2009 11:27:35 -0800 (PST) Received: from dn3-232.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nB9JREgd037764 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Dec 2009 13:27:14 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: <87933A2E-8DE8-4EA0-8A95-F98ACFB6AFAC@nostrum.com> From: Robert Sparks To: Brian Hibbard In-Reply-To: <4656101B-A8F8-4EC3-B9D7-D2B01FD824B0@estacado.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 9 Dec 2009 13:27:14 -0600 References: <4656101B-A8F8-4EC3-B9D7-D2B01FD824B0@estacado.net> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE , Kumiko Ono Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: document scope and intent X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 19:27:40 -0000 On Nov 24, 2009, at 3:25 PM, Brian Hibbard wrote: > A new version of the SIP Sec Flows draft is now available at http://www.ietf.org/internet-drafts/draft-ietf-sipcore-sec-flows-01.txt > . > > > The feedback on the draft so far raises some interesting points > about the scope of the Sec Flows draft. There are some basic issues > that need to be resolved for the draft to proceed. Responses to > some of these issues may indicate the need for additional > document(s) or a change in scope of the draft. > > > == Informative vs Normative == > > The draft states in the first line of the introduction that it is > not normative for SIP. That raises the question as to whether this > should be on the standards track. Should this be informational or > BCP? I don't remember why this was PS. Informational seems right. BCP is not. > > > == Tutorial or Reference == > > Is the draft intended to be a hitchhikers' guide to security for SIP > implementers? I don't believe so - it was a set of examples. > > Does the draft intend to be a training tool to educate implementers > in PKI? No. > How far do we want to go in teaching developers how to generate and > manage certificates? Only to the point that it's needed in order to explain what's happening in the examples. > For example, are we trying to teach how to administer a Certificate > Authority and want to deal with how certs are generated in the real > world? Very much no. Is something in the draft looking like it does that to you now? > Or are we only concerned with the cryptography of the messages, and > we are only providing certificates and > > Are we only trying to provide specific reference examples for > helping verify implementations? The last. > > If so, should we be providing test vectors instead? I think you're focusing only on the crypto generation part of the draft (it is the hard part you jumped in to help with), but the examples frame when what type of security mechanisms get used. > Is the document intending to recommend how things should be done, > how they might be done, or how they must be done? The document provides some example flows. It is not intended to be comprehensive. In some cases it shows the only way to do a certain thing. In others, it chooses from a range of options. > > == Document Title == > > Depending on the resolution of the above, we may need to consider > changing the document's title. I don't think we should be changing the document's scope to that degree at this time. From fluffy@cisco.com Wed Dec 9 11:55:33 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D93A13A6A4F for ; Wed, 9 Dec 2009 11:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.579 X-Spam-Level: X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 gOT9j7FBqVf3 for ; Wed, 9 Dec 2009 11:55:33 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 133D53A686B for ; Wed, 9 Dec 2009 11:55:33 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACaPH0urR7Hu/2dsb2JhbADAO5cigiOCCQQ X-IronPort-AV: E=Sophos;i="4.47,370,1257120000"; d="scan'208";a="278564005" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 09 Dec 2009 19:55:22 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nB9JtKwk027626; Wed, 9 Dec 2009 19:55:20 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <4B1BE59E.3040803@ericsson.com> Date: Wed, 9 Dec 2009 12:55:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8E44F059-8FF1-4922-A5BF-C0628F25F17D@cisco.com> References: <4AFA3E1A.8060204@ericsson.com> <4B0FD53A.10705@ericsson.com> <4B1BE59E.3040803@ericsson.com> To: Gonzalo Camarillo X-Mailer: Apple Mail (2.1077) Cc: SIPCORE , Brian Hibbard Subject: Re: [sipcore] Reviewing the sec-flows draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 19:55:33 -0000 I get many emails from implementors that use this draft. I'm really = would not wan to abandon it. The reason no one is very excited to work = on it is that it has been pretty much done for many years now. I'm not = even sure when I should bother to read it and I'm an author. If we are = going to actually finish it, I'm glad to to get people to read it but = the current process seems to just leave it in zombie land where no one = does anything because there is no commitment one way or the other to do = anything with it. Cullen On Dec 6, 2009, at 10:10 AM, Gonzalo Camarillo wrote: > Folks, >=20 > as you know, when we restructured the RAI area one of the plans was to = avoid working on specifications people were not interested in any = longer. Adam and I have had to assign a new editor (with cycles) to this = document and have unsuccessfully asked for reviewers *many* times. If we = do not see some activity related to this draft in the near future the = only conclusion we can draw is that we should abandon it. >=20 > So, if you think this is important, now it would be a good time for = volunteering. Also, if you think we should abandon this draft, let us = know as well. >=20 > Thanks, >=20 > Gonzalo > SIPCORE co-chair >=20 >=20 > Gonzalo Camarillo wrote: >> Folks, >> as you may have noticed, Brian has submitted a new revision of this = draft and sent a couple of notes to the list (on November 24th) = describing the topics on which he expects to get feedback. Please, send = your comments to this list. >> Thanks, >> Gonzalo >> SIPCORE co-chair >> Gonzalo Camarillo wrote: >>> Folks, >>>=20 >>> as you know, we have asked for volunteers to review the sec-flows = draft many times. We got a couple of reviews but we would like to get at = least one dedicated review more. If you want to volunteer, please send = your review to the list. >>>=20 >>> Additionally, the reviews we got pointed out at issues that require = WG consensus (as opposed to the editor simply going off and implementing = them). >>>=20 >>> As next steps, the draft's editor (Brian) will be submitting a new = revision of the draft because the current one has expired. Then, he will = be sending a set of emails to the list so that we can reach consensus on = the issues that need discussion. >>>=20 >>> Thanks, >>>=20 >>> Gonzalo >>> SIPCORE co-chair >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Wed Dec 9 12:35:43 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D1683A67F7 for ; Wed, 9 Dec 2009 12:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 7sTgMBnSzb1w for ; Wed, 9 Dec 2009 12:35:42 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8D3243A67AE for ; Wed, 9 Dec 2009 12:35:42 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAGAHeZH0tAZnwM/2dsb2JhbACZCKcllyKCO4FxBA X-IronPort-AV: E=Sophos;i="4.47,370,1257120000"; d="scan'208";a="73144940" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 09 Dec 2009 20:35:19 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nB9KZJSn001909; Wed, 9 Dec 2009 20:35:19 GMT Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 15:35:19 -0500 Received: from [10.86.251.110] ([10.86.251.110]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 15:35:18 -0500 Message-ID: <4B200A05.9020200@cisco.com> Date: Wed, 09 Dec 2009 15:35:17 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Cullen Jennings References: <4AFA3E1A.8060204@ericsson.com> <4B0FD53A.10705@ericsson.com> <4B1BE59E.3040803@ericsson.com> <8E44F059-8FF1-4922-A5BF-C0628F25F17D@cisco.com> In-Reply-To: <8E44F059-8FF1-4922-A5BF-C0628F25F17D@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Dec 2009 20:35:18.0797 (UTC) FILETIME=[1F2CA3D0:01CA790F] Cc: SIPCORE , Brian Hibbard Subject: Re: [sipcore] Reviewing the sec-flows draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 20:35:43 -0000 Cullen Jennings wrote: > I get many emails from implementors that use this draft. Are those people using it to help them understand the specs? Or in lieu of bothering to understand the specs? Unfortunately I have the impression that there are a significant number of developers that implement from call flow documents and/or call traces of existing implementations rather than trying to understand the specs. That is almost enough to motivate a "call flows considered harmful" paper. I personally find call flows most useful: 1) by the writers of specs, to verify that the specs "work", 2) as a design output from implementors for review of the design prior to implementation 3) as use cases for planned new work Thanks, Paul From christer.holmberg@ericsson.com Wed Dec 9 12:57:15 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEF1A3A6980 for ; Wed, 9 Dec 2009 12:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 tEQfCi4jm3ys for ; Wed, 9 Dec 2009 12:57:15 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id B4CC33A68E7 for ; Wed, 9 Dec 2009 12:57:14 -0800 (PST) X-AuditID: c1b4fb3c-b7b8dae0000047e9-74-4b200f1e61be Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 40.70.18409.E1F002B4; Wed, 9 Dec 2009 21:57:02 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 21:56:29 +0100 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, 9 Dec 2009 21:56:28 +0100 Message-ID: In-Reply-To: <4B1FBC4C.3010608@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] AD review draft-ietf-sipcore-199-00 Thread-Index: Acp44Mvb4y+yfw5xRuSsZg9iN47+ZAAMTdrw References: <4B1FBC4C.3010608@ericsson.com> From: "Christer Holmberg" To: "Gonzalo Camarillo" X-OriginalArrivalTime: 09 Dec 2009 20:56:29.0580 (UTC) FILETIME=[149EBCC0:01CA7912] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-sipcore-199@tools.ietf.org, sipcore@ietf.org, sipcore-chairs@tools.ietf.org Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 20:57:16 -0000 Hi, I have now submitted version -02. Regards, Christer =20 -----Original Message----- From: Gonzalo Camarillo=20 Sent: 9. joulukuuta 2009 17:04 To: Christer Holmberg Cc: Robert Sparks; sipcore@ietf.org; draft-ietf-sipcore-199@tools.ietf.org; sipcore-chairs@tools.ietf.org Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 Hi Christer, > Again, most changes were done (note the DTLS/SRTP issue, though), but=20 > in the wrong xml file. "Change done now" means that the changes will=20 > be in version -02. why don't you submit 02 now so that people can follow the discussions more clearly? You can submit 03 later if more changes are needed. Thanks, Gonzalo From root@core3.amsl.com Wed Dec 9 13:00:02 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 348C93A6980; Wed, 9 Dec 2009 13:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091209210002.348C93A6980@core3.amsl.com> Date: Wed, 9 Dec 2009 13:00:02 -0800 (PST) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-199-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 21:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Response Code for Indication of Terminated Dialog Author(s) : C. Holmberg Filename : draft-ietf-sipcore-199-02.txt Pages : 16 Date : 2009-12-09 This specification defines a new SIP response code, 199 Early Dialog Terminated, which a SIP forking proxy and a UAS can use to indicate upstream towards the UAC that an early dialog has been terminated, before a final response is sent towards the UAC. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 12, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-199-02.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-sipcore-199-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-09125530.I-D@ietf.org> --NextPart-- From fluffy@cisco.com Wed Dec 9 22:04:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE9693A68B8 for ; Wed, 9 Dec 2009 22:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.584 X-Spam-Level: X-Spam-Status: No, score=-106.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 zfGXgb0HX1gF for ; Wed, 9 Dec 2009 22:04:51 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B844D3A6859 for ; Wed, 9 Dec 2009 22:04:50 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.47,373,1257120000"; d="scan'208";a="447480475" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 10 Dec 2009 06:04:40 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nBA64csV015201; Thu, 10 Dec 2009 06:04:39 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <4B200A05.9020200@cisco.com> Date: Wed, 9 Dec 2009 23:04:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <85343038-B65D-47E1-BB06-40DDC31F4083@cisco.com> References: <4AFA3E1A.8060204@ericsson.com> <4B0FD53A.10705@ericsson.com> <4B1BE59E.3040803@ericsson.com> <8E44F059-8FF1-4922-A5BF-C0628F25F17D@cisco.com> <4B200A05.9020200@cisco.com> To: Paul Kyzivat X-Mailer: Apple Mail (2.1077) Cc: SIPCORE , Brian Hibbard Subject: Re: [sipcore] Reviewing the sec-flows draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 06:04:52 -0000 On Dec 9, 2009, at 1:35 PM, Paul Kyzivat wrote: >=20 >=20 > Cullen Jennings wrote: >> I get many emails from implementors that use this draft. >=20 > Are those people using it to help them understand the specs? > Or in lieu of bothering to understand the specs? Ouch, that is brutal. But uh, yah, some probably only read this spec = because they could not find a wireshark capture that they could use to = go implement from. But others are trying to use the stuff in here to = test and to see at what stage their implementation went wrong.=20 >=20 > Unfortunately I have the impression that there are a significant = number of developers that implement from call flow documents and/or call = traces of existing implementations rather than trying to understand the = specs. uh yah, I see some call flows that certainly make me think some people = do it that way >=20 > That is almost enough to motivate a "call flows considered harmful" = paper. >=20 > I personally find call flows most useful: > 1) by the writers of specs, to verify that the specs "work", > 2) as a design output from implementors for review > of the design prior to implementation > 3) as use cases for planned new work Generally agree but in case of TLS or S/MIME, when you are implementing, = it is really hard to figure out what went wrong. You just get a = "security failed" error from underlying libraries and it is really nice = to be able to compare your call flow to a "known good" one or even use = some test vectors from it for testing. Kumiko and I both did separate = implementations of all this stuff then did messages between them in = working on this draft. >=20 > Thanks, > Paul From fluffy@cisco.com Wed Dec 9 22:14:33 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA6863A6859 for ; Wed, 9 Dec 2009 22:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 QUg39OkaWOwI for ; Wed, 9 Dec 2009 22:14:27 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id E9DA13A69D4 for ; Wed, 9 Dec 2009 22:14:23 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEggIEurR7Ht/2dsb2JhbAC9R5cRhCwE X-IronPort-AV: E=Sophos;i="4.47,373,1257120000"; d="scan'208";a="228087289" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 10 Dec 2009 06:14:13 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nBA6ECZC021021; Thu, 10 Dec 2009 06:14:12 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <4656101B-A8F8-4EC3-B9D7-D2B01FD824B0@estacado.net> Date: Wed, 9 Dec 2009 23:14:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4656101B-A8F8-4EC3-B9D7-D2B01FD824B0@estacado.net> To: Brian Hibbard X-Mailer: Apple Mail (2.1077) Cc: SIPCORE , Kumiko Ono Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: document scope and intent X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 06:14:33 -0000 On Nov 24, 2009, at 2:25 PM, Brian Hibbard wrote: > The draft states in the first line of the introduction that it is not = normative for SIP. That raises the question as to whether this should = be on the standards track. Should this be informational or BCP? I think we decided it need to be standards track when we added the = normative statements about binary a long time ago. (I note that the = "should" should be a "SHOULD". =20= From fluffy@cisco.com Wed Dec 9 22:28:22 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C4D73A6967 for ; Wed, 9 Dec 2009 22:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.538 X-Spam-Level: X-Spam-Status: No, score=-106.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 xNFiUcQ5tR7f for ; Wed, 9 Dec 2009 22:28:14 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CC2C03A680A for ; Wed, 9 Dec 2009 22:28:13 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAUkIEurRN+K/2dsb2JhbAC9SJcPhCwE X-IronPort-AV: E=Sophos;i="4.47,373,1257120000"; d="scan'208";a="447493926" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 10 Dec 2009 06:28:02 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nBA6S1Ha000548; Thu, 10 Dec 2009 06:28:02 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> Date: Wed, 9 Dec 2009 23:28:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <72938436-8DE4-4A1C-BE69-4453421C4CC7@cisco.com> References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> To: Brian Hibbard X-Mailer: Apple Mail (2.1077) Cc: SIPCORE , Kumiko Ono Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 06:28:22 -0000 On Nov 24, 2009, at 2:26 PM, Brian Hibbard wrote: > Add a few lines about RFC 3263. Add a few lines about how the UA = decides to create a new TLS session or use an existing one (but not = "connection-reuse" draft level of reuse complexity). Any volunteers for = writing this? I can write that if you don't fine some else to do it. How about: When a UA goes to send a message to example.com, the UA can see if it = already has a TLS connection to example.com and if it does, it MAY send = the message over this connection. A UA SHOULD have some scheme for = reusing connections as opening a new TLS connection for every message = results in awful performance. Implementers are encouraged to read { add = appropriate connection reuse refs here }.=20 Cullen (All my post on this draft are in my role as an individual = contributor) From fluffy@cisco.com Wed Dec 9 22:34:22 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBDB328C0DB for ; Wed, 9 Dec 2009 22:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.586 X-Spam-Level: X-Spam-Status: No, score=-106.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 nI1x5F2sHGfX for ; Wed, 9 Dec 2009 22:34:22 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id EC28A3A6974 for ; Wed, 9 Dec 2009 22:34:21 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPokIEurR7Ht/2dsb2JhbAC9UZcOhCwE X-IronPort-AV: E=Sophos;i="4.47,373,1257120000"; d="scan'208";a="228090583" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 10 Dec 2009 06:34:11 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nBA6YAuY002344; Thu, 10 Dec 2009 06:34:10 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> Date: Wed, 9 Dec 2009 23:34:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2A6E36E2-6AF8-4196-B492-C1B1E94E3DB8@cisco.com> References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> To: Brian Hibbard X-Mailer: Apple Mail (2.1077) Cc: SIPCORE , Kumiko Ono Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 06:34:22 -0000 On Nov 24, 2009, at 2:26 PM, Brian Hibbard wrote: > =3D=3D Observed Interoperability Issues in section 6=3D=3D > Who observed them? Is this experience from SIPits, etc? I think it = would strengthen the idea that these are real-world, = observed-in-the-wild issues to give sources. Kumiko and I at SIPits are the main ref but this is all pretty uh = fluffy, it's not like we have enough observation for any significant = statistical sample. I have also seen S/MIME flows in operational = networks but no one that uses those is going to be very interested in = talking about them so I doubt we are going to get more input on this. = I'm not wiling to put in an RFC names of vendors or product that had = problems with their S/MIME flows - among other things that seems like it = would violate the NDA and spirit of SIPit testing. Perhaps the best = thing would be to remove the "problems observed" type text and just = leave it at the "If you are writing some code, make sure it does not = have these problems" type text.=20 From fluffy@cisco.com Wed Dec 9 22:37:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A2693A6A11 for ; Wed, 9 Dec 2009 22:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.587 X-Spam-Level: X-Spam-Status: No, score=-106.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 gknt52GJ-q4W for ; Wed, 9 Dec 2009 22:37:28 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 5C85A3A6999 for ; Wed, 9 Dec 2009 22:37:28 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABgmIEurR7H+/2dsb2JhbAC9VpcPhCwE X-IronPort-AV: E=Sophos;i="4.47,373,1257120000"; d="scan'208";a="228091323" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 10 Dec 2009 06:37:17 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nBA6bGsq008658; Thu, 10 Dec 2009 06:37:16 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> Date: Wed, 9 Dec 2009 23:37:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1344C8F4-89A6-4C26-9D94-41CCF2310379@cisco.com> References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> To: Brian Hibbard X-Mailer: Apple Mail (2.1077) Cc: SIPCORE , Kumiko Ono Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 06:37:29 -0000 On Nov 24, 2009, at 2:26 PM, Brian Hibbard wrote: > There's some implicit stuff here that should be explicit. Do you mean = to recommend never attaching certs? It's probably worth mentioning the = message size limit issue. What do we mean by "it cannot be relied = upon"--that we can't rely on the peer sending it, or it is unreliable = when the peer does send it? The first thing not the second. There is no guarantee that the peer will = attach a cert to every message that would use it so you have to have = some way to cache or get certs.= From fluffy@cisco.com Wed Dec 9 22:39:59 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9D6A3A69D4 for ; Wed, 9 Dec 2009 22:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 fXbtPpob4v6b for ; Wed, 9 Dec 2009 22:39:58 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E01DC3A6868 for ; Wed, 9 Dec 2009 22:39:58 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAI4mIEurRN+J/2dsb2JhbAC9UpcPhCwE X-IronPort-AV: E=Sophos;i="4.47,373,1257120000"; d="scan'208";a="117199262" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 10 Dec 2009 06:39:47 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nBA6dkR4016498; Thu, 10 Dec 2009 06:39:46 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> Date: Wed, 9 Dec 2009 23:39:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7F45E9F5-ADFF-42D4-9505-882A5A19E198@cisco.com> References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> To: Brian Hibbard X-Mailer: Apple Mail (2.1077) Cc: SIPCORE , Kumiko Ono Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 06:40:00 -0000 On Nov 24, 2009, at 2:26 PM, Brian Hibbard wrote: > =46rom second bullet: What if all you've got is an IP address? Do we = disallow IPAddress entries in SubjectAltName? Good point - IPAddress are allowed in SubjectAltName AFAIC. I imagine = that many people did not test this case and may have problems with it.=20= From fluffy@cisco.com Wed Dec 9 22:44:33 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 828D53A69D4 for ; Wed, 9 Dec 2009 22:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.54 X-Spam-Level: X-Spam-Status: No, score=-106.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 nOTjMrg5Vnrn for ; Wed, 9 Dec 2009 22:44:32 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id C574B3A6868 for ; Wed, 9 Dec 2009 22:44:32 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADIoIEurRN+J/2dsb2JhbAC9V5cPhCwE X-IronPort-AV: E=Sophos;i="4.47,373,1257120000"; d="scan'208";a="60537646" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 10 Dec 2009 06:44:09 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nBA6i8ku018437; Thu, 10 Dec 2009 06:44:09 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> Date: Wed, 9 Dec 2009 23:44:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <85C804CE-610E-42E9-86FD-F8FED9620E29@cisco.com> References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> To: Brian Hibbard X-Mailer: Apple Mail (2.1077) Cc: SIPCORE , Kumiko Ono Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 06:44:33 -0000 On Nov 24, 2009, at 2:26 PM, Brian Hibbard wrote: > We should probably say something about CRLs. We need to get consensus = on whether we want to recommend a method for retrieving CRLs.=20 I predict we will never get consensus on which way one should check CRLs = thus I favor avoiding the CRL discussion but if others feel differently = I don't care one way or the other.=20 From krisztian.kiss@nokia.com Thu Dec 10 01:09:34 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 446CE3A6A8F for ; Thu, 10 Dec 2009 01:09:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 7mbONpPSlj-a for ; Thu, 10 Dec 2009 01:09:33 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 57D153A6972 for ; Thu, 10 Dec 2009 01:09:32 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nBA99CGl028303; Thu, 10 Dec 2009 11:09:15 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 11:08:46 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 11:08:46 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Thu, 10 Dec 2009 10:08:44 +0100 From: To: , Date: Thu, 10 Dec 2009 10:08:36 +0100 Thread-Topic: [sipcore] Event rate control and GEOPRIV requirements Thread-Index: AcphAGYaGdq7Oj2RSviJrBA5EKKkdAAAvIGwAAGE3IAGG4C6sA== Message-ID: References: <8B0A9FCBB9832F43971E38010638454F0F2E4DDB@SISPE7MB1.commscope.com> <4AF7A7B7.8050806@ericsson.com> <8B0A9FCBB9832F43971E38010638454F0F2E4E3D@SISPE7MB1.commscope.com> <4AF7AD5A.3010305@ericsson.com> <8B0A9FCBB9832F43971E38010638454F0F2E4E97@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0F2E4E97@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Dec 2009 09:08:46.0543 (UTC) FILETIME=[61173DF0:01CA7978] X-Nokia-AV: Clean Cc: sipcore@ietf.org Subject: Re: [sipcore] Event rate control and GEOPRIV requirements X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 09:09:34 -0000 Hi Martin, I will issue an updated version of the draft within the next couple of week= s and adopt your preference making the Event header field optional for 2xx = to NOTIFY (in order to cover the case when someone doesn't need this parti= cular feature but otherwise implementing the max-interval functionality). Cheers, Krisztian -----Original Message----- From: ext Thomson, Martin [mailto:Martin.Thomson@andrew.com]=20 Sent: Sunday, November 08, 2009 10:59 PM To: Kiss Krisztian (Nokia-CIC/MtView); salvatore.loreto@ericsson.com Cc: sipcore@ietf.org Subject: RE: [sipcore] Event rate control and GEOPRIV requirements I don't think that there is a conflict. If the subscriber wishes to change details, then they can provide the heade= r. If they do not provide the header - as is the existing behaviour - the = values do not change. Of course, if the _header_ is present, then the parameter must be, but that= is not what the text in the document says. Making this mandatory also makes it mandatory for those who implement this = feature but don't intend to use it. Let's not break existing event package= implementations. --Martin > -----Original Message----- > From: krisztian.kiss@nokia.com [mailto:krisztian.kiss@nokia.com] > Sent: Monday, 9 November 2009 3:50 PM > To: salvatore.loreto@ericsson.com; Thomson, Martin > Cc: sipcore@ietf.org > Subject: RE: [sipcore] Event rate control and GEOPRIV requirements >=20 > Hi, >=20 > Making it optional may create a conflict with the following statement: >=20 > A subscriber that wishes to remove the minimum rate control from > notifications MUST indicate so by not including a "max-interval" > Event header field parameter in a subsequent SUBSCRIBE request or a > 200-class response to the NOTIFY request. >=20 > An Event header field without the "max-interval" parameter means that=20 > the subscriber is deleting the "max-interval" feature from=20 > notifications. Should we now allocate a special meaning for the case=20 > when no Event header field exists in the 2xx response to the NOTIFY? > Does that mean the "max-interval" parameter is not touched from the=20 > previous value? Or something else? I'd prefer the same behavior as for=20 > the SUBSCRIBE request, i.e. the "max-interval" parameter is always=20 > present reflecting the current value and the lack of the parameter=20 > means that the feature is deleted from notifications. >=20 > Existing implementations do not support Event header field in the 2xx=20 > responses to NOTIFY, however new implementations adding the rate-=20 > control feature to notifications will support adding the rate control=20 > parameters to the Event header field in SUBSCRIBE and 2xx to NOTIFY as=20 > well as the Subscription-State header field in NOTIFYs. As RFC 3265=20 > did not define the Event header field to 2xx to NOTIFY,=20 > draft-ietf-sipcore- event-rate-control has to do this in order to have=20 > a placeholder for the new parameter. >=20 > Cheers, > Krisztian >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > Behalf Of ext Salvatore Loreto > Sent: Sunday, November 08, 2009 9:49 PM > To: Thomson, Martin > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Event rate control and GEOPRIV requirements >=20 > Hi Martin, >=20 > good point, I think we can relax it to optional . >=20 > /Sal >=20 > Thomson, Martin wrote: > > Hi Sal, > > > > Thanks for the pointer. > > > > Regarding section 8.3, which addresses the requirement in question: > > > > I'm not sure why you would make the Event header mandatory in the=20 > > 2xx > responses. Optional seems to make more sense to me. Existing=20 > implementations don't do this, after all. > > > > > >> -----Original Message----- > >> From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com] > >> Sent: Monday, 9 November 2009 2:25 PM > >> To: Thomson, Martin > >> Cc: sipcore@ietf.org > >> Subject: Re: [sipcore] Event rate control and GEOPRIV requirements > >> > >> Hi Martin, > >> > >> an updated version of the event-rate-control draft was submitted=20 > >> two days after the IETF76 deadline, for this reason it is not yet=20 > >> on the I-D repository, however it will be available soon > >> > >> for the time being you can fetch a copy from > >> http://krkiss.letolt.info/draft-ietf-sipcore-event-rate-control- > 01.tx > >> t > >> > >> /Sal > >> > >> Thomson, Martin wrote: > >> > >>> Is the -00 version the latest issue of this draft? I expected a - > 01 > >>> > >> and so was under the impression that we were discussion changes=20 > >> already made. > >> > >>> The following two minor changes were requested out of the GEOPRIV=20 > >>> use > >>> > >> cases: > >> > >>> - note that the rate control parameters can be updated in=20 > >>> response > >>> > >> messages (i.e. the 200 response to an initial NOTIFY); the notifier=20 > >> then indicates the agreed (and possibility modified) values in=20 > >> subsequent NOTIFYs > >> > >>> - note that rate control parameters can be changed at any time by > >>> > >> the notifier, based on policy- or implementation-determined=20 > >> constraints > >> > >>> This is what we discussed in the meeting. > >>> > >>> I think that the second one is OK in the version -00 draft. I > could > >>> > >> not find anywhere that mentioned updating event parameters in a=20 > >> response message. > >> > >>> --Martin > >>> > >>> _______________________________________________ > >>> sipcore mailing list > >>> sipcore@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipcore > >>> > >>> > > > > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From gonzalo.camarillo@ericsson.com Thu Dec 10 03:39:21 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 650F03A67AB for ; Thu, 10 Dec 2009 03:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.236 X-Spam-Level: X-Spam-Status: No, score=-6.236 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 MBFaR-40P3tS for ; Thu, 10 Dec 2009 03:39:20 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id BE5FA3A67A6 for ; Thu, 10 Dec 2009 03:39:18 -0800 (PST) X-AuditID: c1b4fb24-b7beeae000003a71-c4-4b20dddae4b8 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id FF.CB.14961.ADDD02B4; Thu, 10 Dec 2009 12:39:06 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 12:38:56 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 12:38:56 +0100 Message-ID: <4B20DDCF.9000409@ericsson.com> Date: Thu, 10 Dec 2009 13:38:55 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: SIPCORE Content-Type: multipart/mixed; boundary="------------050406030501020207060201" X-OriginalArrivalTime: 10 Dec 2009 11:38:56.0118 (UTC) FILETIME=[5B374960:01CA798D] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] WGLC draft-ietf-sipcore-info-events-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 11:39:21 -0000 This is a multi-part message in MIME format. --------------050406030501020207060201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks, Christer has submitted a new version of the INFO Events draft (see email below) that is supposed to address all the comments received so far. Since there have been extensive discussions on this topic since the last time we WGLCed this draft, we are going to WGLC it again. http://tools.ietf.org/html/draft-ietf-sipcore-info-events-03 So, please, have a look at this new version and let us know whether or not you also think all comments have been addressed. Of course, you are also welcome to submit new comments should you have some. This WGLC will end on December 24th. Thanks, Gonzalo SIPCORE co-chair -------- Original Message -------- Subject: [sipcore] Draft new version: draft-ietf-sipcore-info-events Date: Wed, 2 Dec 2009 09:59:24 +0100 From: Christer Holmberg To: Hi, I've submitted a new version of the info draft. Hopefully all comments and feedback have now been addressed. The biggest changes are: - Section 4.2: The usage of the Recv-Info header has been clarified, some simple rules have been added, and there were some discussions that since the re-INVITE fallback issue also affects Recv-Info (if you receive a Recv-Info in a 18x to a re-INVITE, and the re-INVITE then fails) and that we need some words about that. The text now says that IF the request contains a Recv-Info header, the response must also contain it. - Section 11.4: Contains new wording about the IANA process for registering info packages, including the expert review etc. - Section 12: Additional examples have been added Please note that I did NOT remove Recv-Info in PRACKs, since there in my opinion was no concensus to do so. The draft can also be found at: _http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-info-events-03.txt_ Regards, Christer --------------050406030501020207060201 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message Part" _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --------------050406030501020207060201-- From gonzalo.camarillo@ericsson.com Thu Dec 10 03:40:53 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EADC3A690B for ; Thu, 10 Dec 2009 03:40:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.236 X-Spam-Level: X-Spam-Status: No, score=-6.236 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 ek5cxok+6tKn for ; Thu, 10 Dec 2009 03:40:52 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E45D73A67AB for ; Thu, 10 Dec 2009 03:40:51 -0800 (PST) X-AuditID: c1b4fb3c-b7b8dae0000047e9-1f-4b20dadd44c7 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 39.C9.18409.DDAD02B4; Thu, 10 Dec 2009 12:26:22 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 12:25:25 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 12:25:25 +0100 Message-ID: <4B20DAA5.6060109@ericsson.com> Date: Thu, 10 Dec 2009 13:25:25 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: SIPCORE References: <4AFA3E1A.8060204@ericsson.com> <4B0FD53A.10705@ericsson.com> <4B1BE59E.3040803@ericsson.com> In-Reply-To: <4B1BE59E.3040803@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Dec 2009 11:25:25.0755 (UTC) FILETIME=[7833B4B0:01CA798B] X-Brightmail-Tracker: AAAAAA== Cc: Brian Hibbard Subject: Re: [sipcore] Reviewing the sec-flows draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 11:40:53 -0000 Hi, thanks all of you who replied showing interest in this work and, more importantly, started responding to the questions Brian sent some time ago. Let's make sure we keep the ball rolling now. Thanks, Gonzalo Gonzalo Camarillo wrote: > Folks, > > as you know, when we restructured the RAI area one of the plans was to > avoid working on specifications people were not interested in any > longer. Adam and I have had to assign a new editor (with cycles) to this > document and have unsuccessfully asked for reviewers *many* times. If we > do not see some activity related to this draft in the near future the > only conclusion we can draw is that we should abandon it. > > So, if you think this is important, now it would be a good time for > volunteering. Also, if you think we should abandon this draft, let us > know as well. > > Thanks, > > Gonzalo > SIPCORE co-chair > > > Gonzalo Camarillo wrote: >> Folks, >> >> as you may have noticed, Brian has submitted a new revision of this >> draft and sent a couple of notes to the list (on November 24th) >> describing the topics on which he expects to get feedback. Please, >> send your comments to this list. >> >> Thanks, >> >> Gonzalo >> SIPCORE co-chair >> >> Gonzalo Camarillo wrote: >>> Folks, >>> >>> as you know, we have asked for volunteers to review the sec-flows >>> draft many times. We got a couple of reviews but we would like to get >>> at least one dedicated review more. If you want to volunteer, please >>> send your review to the list. >>> >>> Additionally, the reviews we got pointed out at issues that require >>> WG consensus (as opposed to the editor simply going off and >>> implementing them). >>> >>> As next steps, the draft's editor (Brian) will be submitting a new >>> revision of the draft because the current one has expired. Then, he >>> will be sending a set of emails to the list so that we can reach >>> consensus on the issues that need discussion. >>> >>> Thanks, >>> >>> Gonzalo >>> SIPCORE co-chair >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From vkg@alcatel-lucent.com Thu Dec 10 06:52:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1F713A67EE for ; Thu, 10 Dec 2009 06:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 SqdWTUUATOQi for ; Thu, 10 Dec 2009 06:52:29 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 9AB3E3A68B0 for ; Thu, 10 Dec 2009 06:52:29 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id nBAEqEKI011945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 08:52:15 -0600 (CST) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id nBAEqEhe007773; Thu, 10 Dec 2009 08:52:14 -0600 (CST) Message-ID: <4B210B1E.3080202@alcatel-lucent.com> Date: Thu, 10 Dec 2009 08:52:14 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cullen Jennings References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <72938436-8DE4-4A1C-BE69-4453421C4CC7@cisco.com> In-Reply-To: <72938436-8DE4-4A1C-BE69-4453421C4CC7@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 14:52:30 -0000 Cullen Jennings wrote: > On Nov 24, 2009, at 2:26 PM, Brian Hibbard wrote: > >> Add a few lines about RFC 3263. Add a few lines about how the UA >> decides to create a new TLS session or use an existing one (but not >> "connection-reuse" draft level of reuse complexity). Any volunteers >> for writing this? > > I can write that if you don't fine some else to do it. How about: > > When a UA goes to send a message to example.com, the UA can see if it > already has a TLS connection to example.com and if it does, it MAY > send the message over this connection. A UA SHOULD have some scheme > for reusing connections as opening a new TLS connection for every > message results in awful performance. Implementers are encouraged to > read { add appropriate connection reuse refs here }. This is exactly what connect-reuse says, except of course, in much more detail about how the UA goes on to determine "if it already has a TLS connection to example.com". I don't mind putting a capsule summary of the above form in sec-flows, but we should follow it up with a reference to connect-reuse. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From vkg@alcatel-lucent.com Thu Dec 10 07:03:21 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA2313A683B for ; Thu, 10 Dec 2009 07:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Y+4LxDiuFMmO for ; Thu, 10 Dec 2009 07:03:19 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 8F27D3A697A for ; Thu, 10 Dec 2009 07:03:19 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id nBAF35jC021506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 09:03:05 -0600 (CST) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id nBAF35sc017843; Thu, 10 Dec 2009 09:03:05 -0600 (CST) Message-ID: <4B210DA9.90501@alcatel-lucent.com> Date: Thu, 10 Dec 2009 09:03:05 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cullen Jennings References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <7F45E9F5-ADFF-42D4-9505-882A5A19E198@cisco.com> In-Reply-To: <7F45E9F5-ADFF-42D4-9505-882A5A19E198@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 15:03:21 -0000 Cullen Jennings wrote: > On Nov 24, 2009, at 2:26 PM, Brian Hibbard wrote: > >> From second bullet: What if all you've got is an IP address? Do we >> disallow IPAddress entries in SubjectAltName? > > Good point - IPAddress are allowed in SubjectAltName AFAIC. I imagine > that many people did not test this case and may have problems with > it. We can add it as a test case in Section 8. Something along the lines of: 12. TLS : Good peer certificate (CN of Subject empty, and subjectAltName extension contains an iPAddress stored in the octet string in network byte order form as specified in [RFC791].) Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From adam@nostrum.com Thu Dec 10 07:38:23 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D3C83A69E6 for ; Thu, 10 Dec 2009 07:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.838 X-Spam-Level: X-Spam-Status: No, score=-2.838 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, SPF_PASS=-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 L+sPURWk+HMF for ; Thu, 10 Dec 2009 07:38:22 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id C0A9E3A6A00 for ; Thu, 10 Dec 2009 07:38:21 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nBAFbqxl010236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 09:37:52 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B2115CF.6000605@nostrum.com> Date: Thu, 10 Dec 2009 09:37:51 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091130 Thunderbird/3.0 MIME-Version: 1.0 To: Adam Roach References: <4B19A017.1090402@estacado.net> In-Reply-To: <4B19A017.1090402@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] Call for consensus: adopting draft-camarillo-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 15:38:23 -0000 [as chair] Hearing significant support, and no objections, I declare consensus in favor of adopting this document. I have instructed the authors to submit a new version as draft-ietf-sipcore-reinvite. Thank you. /a On 12/4/09 5:49 PM, Adam Roach wrote: > [as chair] > > Regarding the following milestone on our charter: > > Invite Transaction Handling Correction to IESG (PS) > > To fulfill this milestone, there are two potential problems that may > need to be addressed. One of them relates to handling of 200-class > responses to INVITE messages; the other relates to re-INVITE and > target refresh handling. > > The first problem is addressed by an adopted working group item > (draft-ietf-sipcore-invfix). We do not currently have an adopted item > for the second problem. > > The chairs would like to solicit feedback from the group regarding > adoption of draft-camarillo-sipcore-reinvite as a working group item > to fix the second set of problems. Please comment on the SIPCORE > mailing list. If you agree with this adoption, a simple note stating > as much is encouraged: we cannot determine consensus without feedback, > and silence is not very informative. > > Thanks! > > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From gonzalo.camarillo@ericsson.com Thu Dec 10 12:57:02 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB3CB3A6B20 for ; Thu, 10 Dec 2009 12:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.237 X-Spam-Level: X-Spam-Status: No, score=-6.237 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 1q-Eg4ARJtSJ for ; Thu, 10 Dec 2009 12:57:01 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id DBD8E3A6ADD for ; Thu, 10 Dec 2009 12:57:00 -0800 (PST) X-AuditID: c1b4fb24-b7beeae000003a71-bf-4b2160903092 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 91.08.14961.090612B4; Thu, 10 Dec 2009 21:56:48 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 21:56:48 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 21:56:47 +0100 Received: from [131.160.126.231] (rvi2-126-231.lmf.ericsson.se [131.160.126.231]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9F9B32465; Thu, 10 Dec 2009 22:56:47 +0200 (EET) Message-ID: <4B21608F.1060700@ericsson.com> Date: Thu, 10 Dec 2009 22:56:47 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <4B19A017.1090402@estacado.net> <4B2115CF.6000605@nostrum.com> In-Reply-To: <4B2115CF.6000605@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Dec 2009 20:56:47.0898 (UTC) FILETIME=[49F397A0:01CA79DB] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Call for consensus: adopting draft-camarillo-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 20:57:02 -0000 Hi, I have just submitted the draft: http://www.ietf.org/id/draft-ietf-sipcore-reinvite-00.txt The only thing I have changed in this revision is the file name. Cheers, Gonzalo Adam Roach wrote: > [as chair] > > Hearing significant support, and no objections, I declare consensus in > favor of adopting this document. I have instructed the authors to submit > a new version as draft-ietf-sipcore-reinvite. > > Thank you. > > /a > > On 12/4/09 5:49 PM, Adam Roach wrote: >> [as chair] >> >> Regarding the following milestone on our charter: >> >> Invite Transaction Handling Correction to IESG (PS) >> >> To fulfill this milestone, there are two potential problems that may >> need to be addressed. One of them relates to handling of 200-class >> responses to INVITE messages; the other relates to re-INVITE and >> target refresh handling. >> >> The first problem is addressed by an adopted working group item >> (draft-ietf-sipcore-invfix). We do not currently have an adopted item >> for the second problem. >> >> The chairs would like to solicit feedback from the group regarding >> adoption of draft-camarillo-sipcore-reinvite as a working group item >> to fix the second set of problems. Please comment on the SIPCORE >> mailing list. If you agree with this adoption, a simple note stating >> as much is encouraged: we cannot determine consensus without feedback, >> and silence is not very informative. >> >> Thanks! >> >> /a >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From root@core3.amsl.com Thu Dec 10 13:00:02 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 79D2728C0EB; Thu, 10 Dec 2009 13:00:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091210210002.79D2728C0EB@core3.amsl.com> Date: Thu, 10 Dec 2009 13:00:02 -0800 (PST) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 21:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) Author(s) : G. Camarillo, et al. Filename : draft-ietf-sipcore-reinvite-00.txt Pages : 22 Date : 2009-12-10 In this document, we clarify the handling of re-INVITEs in SIP. We clarify in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE. Additionally, we clarify issues related to target-refresh requests. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-reinvite-00.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-sipcore-reinvite-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-10125305.I-D@ietf.org> --NextPart-- From Martin.Thomson@andrew.com Thu Dec 10 13:56:34 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEDD93A6B52 for ; Thu, 10 Dec 2009 13:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 GuZKWMozQ4GZ for ; Thu, 10 Dec 2009 13:56:33 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 9D3D23A68B7 for ; Thu, 10 Dec 2009 13:56:32 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:53424 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S102969AbZLJV4U (ORCPT ); Thu, 10 Dec 2009 15:56:20 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 10 Dec 2009 15:56:20 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 11 Dec 2009 05:56:16 +0800 From: "Thomson, Martin" To: "krisztian.kiss@nokia.com" , "salvatore.loreto@ericsson.com" Date: Fri, 11 Dec 2009 05:57:00 +0800 Thread-Topic: [sipcore] Event rate control and GEOPRIV requirements Thread-Index: AcphAGYaGdq7Oj2RSviJrBA5EKKkdAAAvIGwAAGE3IAGG4C6sAAamVEQ Message-ID: <8B0A9FCBB9832F43971E38010638454F01D65BEA51@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F0F2E4DDB@SISPE7MB1.commscope.com> <4AF7A7B7.8050806@ericsson.com> <8B0A9FCBB9832F43971E38010638454F0F2E4E3D@SISPE7MB1.commscope.com> <4AF7AD5A.3010305@ericsson.com> <8B0A9FCBB9832F43971E38010638454F0F2E4E97@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Event rate control and GEOPRIV requirements X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 21:56:34 -0000 SSB0aGluayB0aGF0IHdlJ3ZlIG1pc3VuZGVyc3Rvb2QgZWFjaCBvdGhlci4NCg0KVGhlIEV2ZW50 IGhlYWRlciBfcGFyYW1ldGVyXyBjYW4gYmUgbWFkZSBtYW5kYXRvcnkuICBJIHRoaW5rIHRoYXQg aXQgc2hvdWxkIGJlIG1hbmRhdG9yeSBpZiB0aGUgbm90aWZpZXIgaXMgYXBwbHlpbmcgcmF0ZSBj b250cm9sLg0KDQpUaGUgdGFibGUgaW4gdGhlIGRyYWZ0IGN1cnJlbnRseSBzdGF0ZXMgdGhhdCB0 aGUgRXZlbnQgX2hlYWRlcl8gaXMgbWFuZGF0b3J5LiAgVGhhdCB3YXMgd2hhdCBJIG9iamVjdGVk IHRvLg0KDQpOb3csIHlvdSBjYW4gbWFkZSB0aGUgaGVhZGVyIG1hbmRhdG9yeSBhcyBsb25nIGFz IHlvdSBxdWFsaWZ5IGl0IHN1ZmZpY2llbnRseS4gIEkgYWN0dWFsbHkgdGhpbmsgdGhhdCB0aGUg dGV4dCBpbiBTZWN0aW9uIDguMyBpcyBhIGxpdHRsZSBzdHJvbmcuICBJJ2QgcHJlZmVyIHRvIHVz ZSBNQVkgaW5zdGVhZCBvZiBNVVNULiAgQWZ0ZXIgYWxsLCB3ZSBkb24ndCB3YW50IHRvIGRpdmVy Z2UgZnJvbSBleGlzdGluZyBiZWhhdmlvdXIgdG9vIG11Y2g6IG5vIHN1YnNjcmliZXIgaW5jbHVk ZXMgdGhlIEV2ZW50IGhlYWRlciBpbiBhIDJ4eCByZXNwb25zZSBjdXJyZW50bHkgYW5kIHRoZXkg bWFuYWdlLg0KDQo+Pg0KOC4zLiBFdmVudCBoZWFkZXIgZmllbGQgdXNhZ2UgaW4gcmVzcG9uc2Vz IHRvIHRoZSBOT1RJRlkgcmVxdWVzdA0KDQogICBJbXBsZW1lbnRhdGlvbnMgdXNpbmcgdGhlIGV4 dGVuc2lvbnMgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgKk1BWSoNCiAgIGluY2x1ZGUgYW4g RXZlbnQgaGVhZGVyIGZpZWxkIGluIGFueSAyMDAtY2xhc3MgcmVzcG9uc2VzIHRvIE5PVElGWQ0K ICAgcmVxdWVzdHMuDQoNCiAgIFRoZSBmb2xsb3dpbmcgdGFibGUgZXhwYW5kcyB0aGUgdGFibGUg ZGVzY3JpYmVkIGluIFNlY3Rpb24gNy4yIG9mDQogICBTSVAgRXZlbnRzIFtSRkMzMjY1XSBhbGxv d2luZyB0aGUgRXZlbnQgaGVhZGVyIGZpZWxkIHRvIGFwcGVhciBpbiBhDQogICAyMDAtY2xhc3Mg cmVzcG9uc2UgdG8gYSBOT1RJRlkgcmVxdWVzdC4NCg0KICAgICAgSGVhZGVyIGZpZWxkICAgICAg d2hlcmUgcHJveHkgQUNLIEJZRSBDQU4gSU5WIE9QVCBSRUcgUFJBIFNVQiBOT1QNCiAgICAgIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQogICAgICBFdmVudCAgICAgICAgICAgICAyeHggICAgICAgICAgLSAgIC0gICAtICAg LSAgIC0gICAtICAgLSAgIC0gICAqbyoNCjw8DQoNCg0KLS1NYXJ0aW4NCg0KDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbToga3Jpc3p0aWFuLmtpc3NAbm9raWEuY29tIFtt YWlsdG86a3Jpc3p0aWFuLmtpc3NAbm9raWEuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgMTAgRGVj ZW1iZXIgMjAwOSA4OjA5IFBNDQo+IFRvOiBUaG9tc29uLCBNYXJ0aW47IHNhbHZhdG9yZS5sb3Jl dG9AZXJpY3Nzb24uY29tDQo+IENjOiBzaXBjb3JlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBb c2lwY29yZV0gRXZlbnQgcmF0ZSBjb250cm9sIGFuZCBHRU9QUklWIHJlcXVpcmVtZW50cw0KPiAN Cj4gSGkgTWFydGluLA0KPiANCj4gSSB3aWxsIGlzc3VlIGFuIHVwZGF0ZWQgdmVyc2lvbiBvZiB0 aGUgZHJhZnQgd2l0aGluIHRoZSBuZXh0IGNvdXBsZSBvZg0KPiB3ZWVrcyBhbmQgYWRvcHQgeW91 ciBwcmVmZXJlbmNlIG1ha2luZyB0aGUgRXZlbnQgaGVhZGVyIGZpZWxkIG9wdGlvbmFsDQo+IGZv ciAyeHggdG8gTk9USUZZIChpbiBvcmRlciB0byBjb3ZlciB0aGUgY2FzZSB3aGVuIHNvbWVvbmUg IGRvZXNuJ3QNCj4gbmVlZCB0aGlzIHBhcnRpY3VsYXIgZmVhdHVyZSBidXQgb3RoZXJ3aXNlIGlt cGxlbWVudGluZyB0aGUgbWF4LQ0KPiBpbnRlcnZhbCBmdW5jdGlvbmFsaXR5KS4NCj4gDQo+IENo ZWVycywNCj4gS3Jpc3p0aWFuDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBleHQgVGhvbXNvbiwgTWFydGluIFttYWlsdG86TWFydGluLlRob21zb25AYW5kcmV3LmNv bV0NCj4gU2VudDogU3VuZGF5LCBOb3ZlbWJlciAwOCwgMjAwOSAxMDo1OSBQTQ0KPiBUbzogS2lz cyBLcmlzenRpYW4gKE5va2lhLUNJQy9NdFZpZXcpOyBzYWx2YXRvcmUubG9yZXRvQGVyaWNzc29u LmNvbQ0KPiBDYzogc2lwY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW3NpcGNvcmVdIEV2 ZW50IHJhdGUgY29udHJvbCBhbmQgR0VPUFJJViByZXF1aXJlbWVudHMNCj4gDQo+IEkgZG9uJ3Qg dGhpbmsgdGhhdCB0aGVyZSBpcyBhIGNvbmZsaWN0Lg0KPiANCj4gSWYgdGhlIHN1YnNjcmliZXIg d2lzaGVzIHRvIGNoYW5nZSBkZXRhaWxzLCB0aGVuIHRoZXkgY2FuIHByb3ZpZGUgdGhlDQo+IGhl YWRlci4gIElmIHRoZXkgZG8gbm90IHByb3ZpZGUgdGhlIGhlYWRlciAtIGFzIGlzIHRoZSBleGlz dGluZw0KPiBiZWhhdmlvdXIgLSB0aGUgdmFsdWVzIGRvIG5vdCBjaGFuZ2UuDQo+IA0KPiBPZiBj b3Vyc2UsIGlmIHRoZSBfaGVhZGVyXyBpcyBwcmVzZW50LCB0aGVuIHRoZSBwYXJhbWV0ZXIgbXVz dCBiZSwgYnV0DQo+IHRoYXQgaXMgbm90IHdoYXQgdGhlIHRleHQgaW4gdGhlIGRvY3VtZW50IHNh eXMuDQo+IA0KPiBNYWtpbmcgdGhpcyBtYW5kYXRvcnkgYWxzbyBtYWtlcyBpdCBtYW5kYXRvcnkg Zm9yIHRob3NlIHdobyBpbXBsZW1lbnQNCj4gdGhpcyBmZWF0dXJlIGJ1dCBkb24ndCBpbnRlbmQg dG8gdXNlIGl0LiAgTGV0J3Mgbm90IGJyZWFrIGV4aXN0aW5nDQo+IGV2ZW50IHBhY2thZ2UgaW1w bGVtZW50YXRpb25zLg0KPiANCj4gLS1NYXJ0aW4NCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPiBGcm9tOiBrcmlzenRpYW4ua2lzc0Bub2tpYS5jb20gW21haWx0bzprcmlz enRpYW4ua2lzc0Bub2tpYS5jb21dDQo+ID4gU2VudDogTW9uZGF5LCA5IE5vdmVtYmVyIDIwMDkg Mzo1MCBQTQ0KPiA+IFRvOiBzYWx2YXRvcmUubG9yZXRvQGVyaWNzc29uLmNvbTsgVGhvbXNvbiwg TWFydGluDQo+ID4gQ2M6IHNpcGNvcmVAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSRTogW3NpcGNv cmVdIEV2ZW50IHJhdGUgY29udHJvbCBhbmQgR0VPUFJJViByZXF1aXJlbWVudHMNCj4gPg0KPiA+ IEhpLA0KPiA+DQo+ID4gTWFraW5nIGl0IG9wdGlvbmFsIG1heSBjcmVhdGUgYSBjb25mbGljdCB3 aXRoIHRoZSBmb2xsb3dpbmcNCj4gc3RhdGVtZW50Og0KPiA+DQo+ID4gICAgQSBzdWJzY3JpYmVy IHRoYXQgd2lzaGVzIHRvIHJlbW92ZSB0aGUgbWluaW11bSByYXRlIGNvbnRyb2wgZnJvbQ0KPiA+ ICAgIG5vdGlmaWNhdGlvbnMgTVVTVCBpbmRpY2F0ZSBzbyBieSBub3QgaW5jbHVkaW5nIGEgIm1h eC1pbnRlcnZhbCINCj4gPiAgICBFdmVudCBoZWFkZXIgZmllbGQgcGFyYW1ldGVyIGluIGEgc3Vi c2VxdWVudCBTVUJTQ1JJQkUgcmVxdWVzdCBvcg0KPiBhDQo+ID4gICAgMjAwLWNsYXNzIHJlc3Bv bnNlIHRvIHRoZSBOT1RJRlkgcmVxdWVzdC4NCj4gPg0KPiA+IEFuIEV2ZW50IGhlYWRlciBmaWVs ZCB3aXRob3V0IHRoZSAibWF4LWludGVydmFsIiBwYXJhbWV0ZXIgbWVhbnMgdGhhdA0KPiA+IHRo ZSBzdWJzY3JpYmVyIGlzIGRlbGV0aW5nIHRoZSAibWF4LWludGVydmFsIiBmZWF0dXJlIGZyb20N Cj4gPiBub3RpZmljYXRpb25zLiBTaG91bGQgd2Ugbm93IGFsbG9jYXRlIGEgc3BlY2lhbCBtZWFu aW5nIGZvciB0aGUgY2FzZQ0KPiA+IHdoZW4gbm8gRXZlbnQgaGVhZGVyIGZpZWxkIGV4aXN0cyBp biB0aGUgMnh4IHJlc3BvbnNlIHRvIHRoZSBOT1RJRlk/DQo+ID4gRG9lcyB0aGF0IG1lYW4gdGhl ICJtYXgtaW50ZXJ2YWwiIHBhcmFtZXRlciBpcyBub3QgdG91Y2hlZCBmcm9tIHRoZQ0KPiA+IHBy ZXZpb3VzIHZhbHVlPyBPciBzb21ldGhpbmcgZWxzZT8gSSdkIHByZWZlciB0aGUgc2FtZSBiZWhh dmlvciBhcw0KPiBmb3INCj4gPiB0aGUgU1VCU0NSSUJFIHJlcXVlc3QsIGkuZS4gdGhlICJtYXgt aW50ZXJ2YWwiIHBhcmFtZXRlciBpcyBhbHdheXMNCj4gPiBwcmVzZW50IHJlZmxlY3RpbmcgdGhl IGN1cnJlbnQgdmFsdWUgYW5kIHRoZSBsYWNrIG9mIHRoZSBwYXJhbWV0ZXINCj4gPiBtZWFucyB0 aGF0IHRoZSBmZWF0dXJlIGlzIGRlbGV0ZWQgZnJvbSBub3RpZmljYXRpb25zLg0KPiA+DQo+ID4g RXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIGRvIG5vdCBzdXBwb3J0IEV2ZW50IGhlYWRlciBmaWVs ZCBpbiB0aGUgMnh4DQo+ID4gcmVzcG9uc2VzIHRvIE5PVElGWSwgaG93ZXZlciBuZXcgaW1wbGVt ZW50YXRpb25zIGFkZGluZyB0aGUgcmF0ZS0NCj4gPiBjb250cm9sIGZlYXR1cmUgdG8gbm90aWZp Y2F0aW9ucyB3aWxsIHN1cHBvcnQgYWRkaW5nIHRoZSByYXRlIGNvbnRyb2wNCj4gPiBwYXJhbWV0 ZXJzIHRvIHRoZSBFdmVudCBoZWFkZXIgZmllbGQgaW4gU1VCU0NSSUJFIGFuZCAyeHggdG8gTk9U SUZZDQo+IGFzDQo+ID4gd2VsbCBhcyB0aGUgU3Vic2NyaXB0aW9uLVN0YXRlIGhlYWRlciBmaWVs ZCBpbiBOT1RJRllzLiBBcyBSRkMgMzI2NQ0KPiA+IGRpZCBub3QgZGVmaW5lIHRoZSBFdmVudCBo ZWFkZXIgZmllbGQgdG8gMnh4IHRvIE5PVElGWSwNCj4gPiBkcmFmdC1pZXRmLXNpcGNvcmUtIGV2 ZW50LXJhdGUtY29udHJvbCBoYXMgdG8gZG8gdGhpcyBpbiBvcmRlciB0bw0KPiBoYXZlDQo+ID4g YSBwbGFjZWhvbGRlciBmb3IgdGhlIG5ldyBwYXJhbWV0ZXIuDQo+ID4NCj4gPiBDaGVlcnMsDQo+ ID4gS3Jpc3p0aWFuDQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZy b206IHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRm Lm9yZ10gT24NCj4gPiBCZWhhbGYgT2YgZXh0IFNhbHZhdG9yZSBMb3JldG8NCj4gPiBTZW50OiBT dW5kYXksIE5vdmVtYmVyIDA4LCAyMDA5IDk6NDkgUE0NCj4gPiBUbzogVGhvbXNvbiwgTWFydGlu DQo+ID4gQ2M6IHNpcGNvcmVAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIEV2 ZW50IHJhdGUgY29udHJvbCBhbmQgR0VPUFJJViByZXF1aXJlbWVudHMNCj4gPg0KPiA+IEhpIE1h cnRpbiwNCj4gPg0KPiA+IGdvb2QgcG9pbnQsIEkgdGhpbmsgd2UgY2FuIHJlbGF4IGl0IHRvIG9w dGlvbmFsIC4NCj4gPg0KPiA+IC9TYWwNCj4gPg0KPiA+IFRob21zb24sIE1hcnRpbiB3cm90ZToN Cj4gPiA+IEhpIFNhbCwNCj4gPiA+DQo+ID4gPiBUaGFua3MgZm9yIHRoZSBwb2ludGVyLg0KPiA+ ID4NCj4gPiA+IFJlZ2FyZGluZyBzZWN0aW9uIDguMywgd2hpY2ggYWRkcmVzc2VzIHRoZSByZXF1 aXJlbWVudCBpbiBxdWVzdGlvbjoNCj4gPiA+DQo+ID4gPiBJJ20gbm90IHN1cmUgd2h5IHlvdSB3 b3VsZCBtYWtlIHRoZSBFdmVudCBoZWFkZXIgbWFuZGF0b3J5IGluIHRoZQ0KPiA+ID4gMnh4DQo+ ID4gcmVzcG9uc2VzLiAgT3B0aW9uYWwgc2VlbXMgdG8gbWFrZSBtb3JlIHNlbnNlIHRvIG1lLiAg RXhpc3RpbmcNCj4gPiBpbXBsZW1lbnRhdGlvbnMgZG9uJ3QgZG8gdGhpcywgYWZ0ZXIgYWxsLg0K PiA+ID4NCj4gPiA+DQo+ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+PiBG cm9tOiBTYWx2YXRvcmUgTG9yZXRvIFttYWlsdG86c2FsdmF0b3JlLmxvcmV0b0Blcmljc3Nvbi5j b21dDQo+ID4gPj4gU2VudDogTW9uZGF5LCA5IE5vdmVtYmVyIDIwMDkgMjoyNSBQTQ0KPiA+ID4+ IFRvOiBUaG9tc29uLCBNYXJ0aW4NCj4gPiA+PiBDYzogc2lwY29yZUBpZXRmLm9yZw0KPiA+ID4+ IFN1YmplY3Q6IFJlOiBbc2lwY29yZV0gRXZlbnQgcmF0ZSBjb250cm9sIGFuZCBHRU9QUklWIHJl cXVpcmVtZW50cw0KPiA+ID4+DQo+ID4gPj4gSGkgTWFydGluLA0KPiA+ID4+DQo+ID4gPj4gYW4g dXBkYXRlZCB2ZXJzaW9uIG9mIHRoZSBldmVudC1yYXRlLWNvbnRyb2wgZHJhZnQgd2FzIHN1Ym1p dHRlZA0KPiA+ID4+IHR3byBkYXlzIGFmdGVyIHRoZSBJRVRGNzYgZGVhZGxpbmUsIGZvciB0aGlz IHJlYXNvbiBpdCBpcyBub3QgeWV0DQo+ID4gPj4gb24gdGhlIEktRCByZXBvc2l0b3J5LCBob3dl dmVyIGl0IHdpbGwgYmUgYXZhaWxhYmxlIHNvb24NCj4gPiA+Pg0KPiA+ID4+IGZvciB0aGUgdGlt ZSBiZWluZyB5b3UgY2FuIGZldGNoIGEgY29weSBmcm9tDQo+ID4gPj4gaHR0cDovL2tya2lzcy5s ZXRvbHQuaW5mby9kcmFmdC1pZXRmLXNpcGNvcmUtZXZlbnQtcmF0ZS1jb250cm9sLQ0KPiA+IDAx LnR4DQo+ID4gPj4gdA0KPiA+ID4+DQo+ID4gPj4gL1NhbA0KPiA+ID4+DQo+ID4gPj4gVGhvbXNv biwgTWFydGluIHdyb3RlOg0KPiA+ID4+DQo+ID4gPj4+IElzIHRoZSAtMDAgdmVyc2lvbiB0aGUg bGF0ZXN0IGlzc3VlIG9mIHRoaXMgZHJhZnQ/ICBJIGV4cGVjdGVkIGENCj4gLQ0KPiA+IDAxDQo+ ID4gPj4+DQo+ID4gPj4gYW5kIHNvIHdhcyB1bmRlciB0aGUgaW1wcmVzc2lvbiB0aGF0IHdlIHdl cmUgZGlzY3Vzc2lvbiBjaGFuZ2VzDQo+ID4gPj4gYWxyZWFkeSBtYWRlLg0KPiA+ID4+DQo+ID4g Pj4+IFRoZSBmb2xsb3dpbmcgdHdvIG1pbm9yIGNoYW5nZXMgd2VyZSByZXF1ZXN0ZWQgb3V0IG9m IHRoZSBHRU9QUklWDQo+ID4gPj4+IHVzZQ0KPiA+ID4+Pg0KPiA+ID4+IGNhc2VzOg0KPiA+ID4+ DQo+ID4gPj4+ICAtIG5vdGUgdGhhdCB0aGUgcmF0ZSBjb250cm9sIHBhcmFtZXRlcnMgY2FuIGJl IHVwZGF0ZWQgaW4NCj4gPiA+Pj4gcmVzcG9uc2UNCj4gPiA+Pj4NCj4gPiA+PiBtZXNzYWdlcyAo aS5lLiB0aGUgMjAwIHJlc3BvbnNlIHRvIGFuIGluaXRpYWwgTk9USUZZKTsgdGhlDQo+IG5vdGlm aWVyDQo+ID4gPj4gdGhlbiBpbmRpY2F0ZXMgdGhlIGFncmVlZCAoYW5kIHBvc3NpYmlsaXR5IG1v ZGlmaWVkKSB2YWx1ZXMgaW4NCj4gPiA+PiBzdWJzZXF1ZW50IE5PVElGWXMNCj4gPiA+Pg0KPiA+ ID4+PiAgLSBub3RlIHRoYXQgcmF0ZSBjb250cm9sIHBhcmFtZXRlcnMgY2FuIGJlIGNoYW5nZWQg YXQgYW55IHRpbWUNCj4gYnkNCj4gPiA+Pj4NCj4gPiA+PiB0aGUgbm90aWZpZXIsIGJhc2VkIG9u IHBvbGljeS0gb3IgaW1wbGVtZW50YXRpb24tZGV0ZXJtaW5lZA0KPiA+ID4+IGNvbnN0cmFpbnRz DQo+ID4gPj4NCj4gPiA+Pj4gVGhpcyBpcyB3aGF0IHdlIGRpc2N1c3NlZCBpbiB0aGUgbWVldGlu Zy4NCj4gPiA+Pj4NCj4gPiA+Pj4gSSB0aGluayB0aGF0IHRoZSBzZWNvbmQgb25lIGlzIE9LIGlu IHRoZSB2ZXJzaW9uIC0wMCBkcmFmdC4gIEkNCj4gPiBjb3VsZA0KPiA+ID4+Pg0KPiA+ID4+IG5v dCBmaW5kIGFueXdoZXJlIHRoYXQgbWVudGlvbmVkIHVwZGF0aW5nIGV2ZW50IHBhcmFtZXRlcnMg aW4gYQ0KPiA+ID4+IHJlc3BvbnNlIG1lc3NhZ2UuDQo+ID4gPj4NCj4gPiA+Pj4gLS1NYXJ0aW4N Cj4gPiA+Pj4NCj4gPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPiA+Pj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gPiA+Pj4gc2lwY29yZUBp ZXRmLm9yZw0KPiA+ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Np cGNvcmUNCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+DQo+ID4gPg0KPiA+DQo+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBzaXBjb3JlIG1haWxp bmcgbGlzdA0KPiA+IHNpcGNvcmVAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg0K From fluffy@cisco.com Thu Dec 10 20:05:12 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF0903A6949 for ; Thu, 10 Dec 2009 20:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.59 X-Spam-Level: X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 PAj3Vjjb8Nmj for ; Thu, 10 Dec 2009 20:05:12 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E84283A6861 for ; Thu, 10 Dec 2009 20:05:11 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAH9TIUurR7Hu/2dsb2JhbADAHZcchCsE X-IronPort-AV: E=Sophos;i="4.47,379,1257120000"; d="scan'208";a="447956407" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 11 Dec 2009 04:04:57 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nBB44v0N000912; Fri, 11 Dec 2009 04:04:57 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Thu, 10 Dec 2009 21:04:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Harhit Tam X-Mailer: Apple Mail (2.1077) Cc: sipcore@ietf.org Subject: Re: [sipcore] e2e sip question X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 04:05:12 -0000 Yes you can. People sometimes set up SIP PSTN gateways bewtween a few = PBX more or less like this. It's also pretty common between a PBX and = voicemail system or conferencing server.=20 On Nov 20, 2009, at 8:04 AM, Harhit Tam wrote: > Hi all,=20 >=20 > Can we use e2e SIP (without proxies) using only the destination's DNS = name? >=20 > That is Bob's phone has a DNS name bob.domain.org, and Alice would = like > to make a call to that DNS name directly without using a SIP URI in = the form > of an e-mail address. >=20 > How can we use SIP in this way? >=20 > Thank you in advance.=20 >=20 > Regards. >=20 > Harhit >=20 > =20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From drage@alcatel-lucent.com Fri Dec 11 06:08:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C1463A6881 for ; Fri, 11 Dec 2009 06:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.843 X-Spam-Level: X-Spam-Status: No, score=-3.843 tagged_above=-999 required=5 tests=[AWL=-1.594, BAYES_00=-2.599, HELO_EQ_FR=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 e3TQbKWPB0Bx for ; Fri, 11 Dec 2009 06:08:28 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 3EF893A689A for ; Fri, 11 Dec 2009 06:08:27 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nBBE7ioj026212 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 11 Dec 2009 15:07:45 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 11 Dec 2009 15:07:44 +0100 From: "DRAGE, Keith (Keith)" To: Cullen Jennings , Brian Hibbard Date: Fri, 11 Dec 2009 15:07:43 +0100 Thread-Topic: [sipcore] draft-ietf-sipcore-sec-flows-01: document scope and intent Thread-Index: Acp5YAfeWeI7DsjTT/yY9Xt0X/8/KABBlqVw Message-ID: References: <4656101B-A8F8-4EC3-B9D7-D2B01FD824B0@estacado.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: SIPCORE , Kumiko Ono Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: document scope and intent X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 14:08:29 -0000 If so, you arbitrarily decided to change it because as far as I know it was= informational during its complete lifetime in the SIP group, and I remembe= r no discussion in the transfer to SIPCORE that made it standards track. Ce= rtainly my final SIP status slides (and the ones before and the ones before= that ...) also say "Candidate: Informational". The first version that carr= ies an "intended status" line is the 1st sipcore version, and this is at va= riance with the charter pages. The last SIP charter pages clearly say: Mar 2009 Example security flows to WGLC (Informational)=20 Jul 2009 Example security flows to IESG (Informational) =20 And the SIPCORE charter pages state: Oct 2009 Example security flows to IESG (Informational)=20 And from my own perspective this should still be informational. If you feel= there is standards track information in here, then pull it out and submit = it as a separate draft, and then the WG can decide whether they want to pro= ceed with such a standards track document. I'd also note to all authors that if you receive private messages of intere= st, then at least please let the WG chairs know that you have had those exp= ressions of interest. If you received any of those messages on sec-flows du= ring its SIP lifetime, the ex SIP WG chairs certainly have no evidence of t= hem ever having been received - and that is essential information to the PR= OTO writeups. I assume the SIPCORE chairs are now in the same boat, having = no email evidence because a small set of exchanges in the past on SIP and S= IPCORE that anyone is even interested in this document. regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: Thursday, December 10, 2009 6:14 AM > To: Brian Hibbard > Cc: SIPCORE; Kumiko Ono > Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01:=20 > document scope and intent >=20 >=20 > On Nov 24, 2009, at 2:25 PM, Brian Hibbard wrote: >=20 > > The draft states in the first line of the introduction that=20 > it is not normative for SIP. That raises the question as to=20 > whether this should be on the standards track. Should this be=20 > informational or BCP? >=20 > I think we decided it need to be standards track when we=20 > added the normative statements about binary a long time ago.=20 > (I note that the "should" should be a "SHOULD". > =20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From drage@alcatel-lucent.com Fri Dec 11 06:09:17 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3F0F3A692D for ; Fri, 11 Dec 2009 06:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.76 X-Spam-Level: X-Spam-Status: No, score=-5.76 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 zvJvYQNsye7I for ; Fri, 11 Dec 2009 06:09:17 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id D640F3A6881 for ; Fri, 11 Dec 2009 06:09:16 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nBBE7uiW002324 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 11 Dec 2009 15:07:56 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 11 Dec 2009 15:07:56 +0100 From: "DRAGE, Keith (Keith)" To: Cullen Jennings , Brian Hibbard Date: Fri, 11 Dec 2009 15:07:55 +0100 Thread-Topic: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues Thread-Index: Acp5YfkvwAjTvi1oR6OmBIRgCrASVgBB2TTw Message-ID: References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <72938436-8DE4-4A1C-BE69-4453421C4CC7@cisco.com> In-Reply-To: <72938436-8DE4-4A1C-BE69-4453421C4CC7@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: SIPCORE , Kumiko Ono Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 14:09:18 -0000 NO. In my view this is an informational document. Description only in the text. See previous message.=20 Keith > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: Thursday, December 10, 2009 6:28 AM > To: Brian Hibbard > Cc: SIPCORE; Kumiko Ono > Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01:=20 > technical issues >=20 >=20 > On Nov 24, 2009, at 2:26 PM, Brian Hibbard wrote: >=20 > > Add a few lines about RFC 3263. Add a few lines about how=20 > the UA decides to create a new TLS session or use an existing=20 > one (but not "connection-reuse" draft level of reuse=20 > complexity). Any volunteers for writing this? >=20 > I can write that if you don't fine some else to do it. How about: >=20 > When a UA goes to send a message to example.com, the UA can=20 > see if it already has a TLS connection to example.com and if=20 > it does, it MAY send the message over this connection. A UA=20 > SHOULD have some scheme for reusing connections as opening a=20 > new TLS connection for every message results in awful=20 > performance. Implementers are encouraged to read { add=20 > appropriate connection reuse refs here }.=20 >=20 > Cullen (All my post on this draft are in my role as an=20 > individual contributor) >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From ben@nostrum.com Fri Dec 11 09:06:00 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A4EA3A69A0 for ; Fri, 11 Dec 2009 09:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-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 tpq1Dqo5NcN9 for ; Fri, 11 Dec 2009 09:05:59 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id B8ED93A687B for ; Fri, 11 Dec 2009 09:05:58 -0800 (PST) Received: from [10.0.1.8] (adsl-68-94-28-128.dsl.rcsntx.swbell.net [68.94.28.128]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nBBH5YUN067915 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Dec 2009 11:05:34 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: Date: Fri, 11 Dec 2009 11:05:29 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <72938436-8DE4-4A1C-BE69-4453421C4CC7@cisco.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1077) Received-SPF: pass (nostrum.com: 68.94.28.128 is authenticated by a trusted mechanism) Cc: SIPCORE , Kumiko Ono , Brian Hibbard Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 17:06:00 -0000 On reflection, I agree this draft should not contain normative = statements for this sort of thing. If we run across a real need for = such language in this draft, perhaps it means we have other standards = work to do. In this case, is there nothing in RAI's entire body of work that talks = about this normatively? On Dec 11, 2009, at 8:07 AM, DRAGE, Keith (Keith) wrote: > NO. >=20 > In my view this is an informational document. Description only in the = text. >=20 > See previous message.=20 >=20 > Keith >=20 >> -----Original Message----- >> From: sipcore-bounces@ietf.org=20 >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Cullen Jennings >> Sent: Thursday, December 10, 2009 6:28 AM >> To: Brian Hibbard >> Cc: SIPCORE; Kumiko Ono >> Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01:=20 >> technical issues >>=20 >>=20 >> On Nov 24, 2009, at 2:26 PM, Brian Hibbard wrote: >>=20 >>> Add a few lines about RFC 3263. Add a few lines about how=20 >> the UA decides to create a new TLS session or use an existing=20 >> one (but not "connection-reuse" draft level of reuse=20 >> complexity). Any volunteers for writing this? >>=20 >> I can write that if you don't fine some else to do it. How about: >>=20 >> When a UA goes to send a message to example.com, the UA can=20 >> see if it already has a TLS connection to example.com and if=20 >> it does, it MAY send the message over this connection. A UA=20 >> SHOULD have some scheme for reusing connections as opening a=20 >> new TLS connection for every message results in awful=20 >> performance. Implementers are encouraged to read { add=20 >> appropriate connection reuse refs here }.=20 >>=20 >> Cullen (All my post on this draft are in my role as an=20 >> individual contributor) >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >>=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From RIFATYU@nortel.com Sat Dec 12 10:54:36 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19DEE3A6967 for ; Sat, 12 Dec 2009 10:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 PkisAiXYOQSy for ; Sat, 12 Dec 2009 10:54:35 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id A23283A6929 for ; Sat, 12 Dec 2009 10:54:34 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nBCIsGu13008; Sat, 12 Dec 2009 18:54:16 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA7B5C.77FDC088" Date: Sat, 12 Dec 2009 13:53:59 -0500 Message-ID: <90243C8A881F8D419D855264D9636F3A02C5B40C@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Draft new version: keep Thread-Index: Acpyd/zn41lehazHToWSzx4xIiXFqQI4Ck8Q References: From: "Rifaat Shekh-Yusef" To: "Christer Holmberg" , Subject: Re: [sipcore] Draft new version: keep X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2009 18:54:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA7B5C.77FDC088 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Christer, =20 I read your document (sipcore-keep-01) and I have the following questions (I am sorry if these questions were asked before): =20 RFC 5626 recommends the STUN Keep-Alive technique with connection-less transports and CRLF Keep-Alive technique with connection-oriented transports. Is this document recommending the client should use STUN Keep-Alive technique for both connection-oriented and connection-less transports? Why did you choose STUN over CRLF? =20 The header of Section 8 implies that there is an overlap between this document and the connect-reuse draft, but when you read the section you realize that this is not the case. Why do you think that this section is needed? Does it matter if the connection between the UA and the proxy uses one TCP connection or two TCP connections? =20 Thanks, Rifaat =20 ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Tuesday, December 01, 2009 6:18 AM To: sipcore@ietf.org Subject: [sipcore] Draft new version: keep Hi,=20 I've submitted a new version of the keep draft. There are no changes from the previous version, but it had expired.=20 I will produce a new version, with new content, once we get the info issues resolved - it has really taken more time than expected...=20 A new version of the info draft will be submitted tomorrow.=20 Regards,=20 Christer=20 ------_=_NextPart_001_01CA7B5C.77FDC088 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft new version: keep
Hi=20 Christer,
 
I read=20 your document (sipcore-keep-01) and I have the following questions = (I am=20 sorry if these questions were asked before):
 
RFC=20 5626 recommends the STUN Keep-Alive technique with connection-less = transports=20 and CRLF Keep-Alive technique with connection-oriented=20 transports.
Is=20 this document recommending the client should use STUN Keep-Alive = technique=20 for both connection-oriented and connection-less = transports?
Why=20 did you choose STUN over CRLF?
 
The=20 header of Section 8 implies that there is an overlap between this = document and=20 the connect-reuse draft, but when you read the section you realize that = this is=20 not the case.
Why do=20 you think that this section is needed? Does it matter if the = connection=20 between the UA and the proxy uses one TCP connection or two = TCP=20 connections?
 
Thanks,
 Rifaat
 

From: sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer=20 Holmberg
Sent: Tuesday, December 01, 2009 6:18 = AM
To:=20 sipcore@ietf.org
Subject: [sipcore] Draft new version:=20 keep


Hi,

I've submitted a new version of the keep = draft. There=20 are no changes from the previous version, but it had expired. =

I will produce a new version, with new = content, once=20 we get the info issues resolved - it has really taken more time than = expected...=20

A new version of the info draft will be = submitted=20 tomorrow.

Regards,

Christer

------_=_NextPart_001_01CA7B5C.77FDC088-- From gunnar.hellstrom@omnitor.se Sat Dec 12 14:35:49 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E13E43A67FE for ; Sat, 12 Dec 2009 14:35:49 -0800 (PST) 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 eCiWdevnTPix for ; Sat, 12 Dec 2009 14:35:49 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id 0A6903A659A for ; Sat, 12 Dec 2009 14:35:49 -0800 (PST) Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id D9B3C63EE for ; Sat, 12 Dec 2009 23:34:38 +0100 (CET) Received: (qmail 37701 invoked from network); 12 Dec 2009 22:34:30 -0000 Received: from h16n1fls34o265.telia.com (HELO GunnarH) (gunnar.hellstrom@omnitor.se@[213.64.232.16]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with SMTP for ; 12 Dec 2009 22:34:30 -0000 From: "Gunnar Hellstrom" To: References: <20090714001501.35E4928C0FE@core3.amsl.com> Date: Sat, 12 Dec 2009 23:34:38 +0100 Message-ID: <003401ca7b7b$4a2234b0$211ea8c0@GunnarH> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoEGP/AbrMQtj3JRXClGPVSXz0QHR3YHVvQ In-Reply-To: <20090714001501.35E4928C0FE@core3.amsl.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Subject: Re: [sipcore] I-D ACTION:draft-ietf-sipcore-location-conveyance-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2009 22:35:50 -0000 I think it would be useful if draft-ietf-sipcore-location-conveyance moved on in status. /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: Tuesday, July 14, 2009 2:15 AM To: i-d-announce@ietf.org Cc: sipcore@ietf.org Subject: I-D ACTION:draft-ietf-sipcore-location-conveyance-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Location Conveyance for the Session Initiation Protocol Author(s) : J. Polk, B. Rosen Filename : draft-ietf-sipcore-location-conveyance-01.txt Pages : 48 Date : 2009-7-13 This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The extension covers end-to-end conveyance as well as location-based routing, where SIP servers make routing decisions based on the location of the user agent client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-0 1.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 christer.holmberg@ericsson.com Sun Dec 13 23:19:52 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75CD13A69BC for ; Sun, 13 Dec 2009 23:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 vY2izOD263vK for ; Sun, 13 Dec 2009 23:19:48 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id CF9FE3A69B8 for ; Sun, 13 Dec 2009 23:19:37 -0800 (PST) X-AuditID: c1b4fb3e-b7bb6ae000001492-12-4b25e6f2726a Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 39.22.05266.2F6E52B4; Mon, 14 Dec 2009 08:19:15 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.22]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Mon, 14 Dec 2009 08:18:16 +0100 From: Christer Holmberg To: 'Rifaat Shekh-Yusef' , "sipcore@ietf.org" Date: Mon, 14 Dec 2009 08:18:15 +0100 Thread-Topic: [sipcore] Draft new version: keep Thread-Index: Acpyd/zn41lehazHToWSzx4xIiXFqQI4Ck8QAE1FmNA= Message-ID: References: <90243C8A881F8D419D855264D9636F3A02C5B40C@zcarhxm2.corp.nortel.com> In-Reply-To: <90243C8A881F8D419D855264D9636F3A02C5B40C@zcarhxm2.corp.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Draft new version: keep X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 07:19:52 -0000 Hi, =20 >I read your document (sipcore-keep-01) and I have the following questions = (I am sorry if these questions were asked before): >=20 >RFC 5626 recommends the STUN Keep-Alive technique with connection-less tra= nsports and CRLF Keep-Alive technique with connection-oriented transports. >Is this document recommending the client should use STUN Keep-Alive techni= que for both connection-oriented and connection-less transports? No. The idea is to use the keep-alive mechanism defined in RFC 5626. The purpose of the draft is only to allow entities to negotiate the usage o= f keep-alive, if they don't support outbound. >Why did you choose STUN over CRLF? > >The header of Section 8 implies that there is an overlap between this docu= ment and the connect-reuse draft, but when you read the section you realize= =20 >that this is not the case. >Why do you think that this section is needed? Does it matter if the connec= tion between the UA and the proxy uses one TCP connection or two TCP=20 >connections? At one point I was asked to add that section, just to point out the differe= nces between keep-alive and connect-reuse. Regards, Christer =20 ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Christer Holmberg Sent: Tuesday, December 01, 2009 6:18 AM To: sipcore@ietf.org Subject: [sipcore] Draft new version: keep Hi,=20 I've submitted a new version of the keep draft. There are no changes from t= he previous version, but it had expired.=20 I will produce a new version, with new content, once we get the info issues= resolved - it has really taken more time than expected...=20 A new version of the info draft will be submitted tomorrow.=20 Regards,=20 Christer=20 From RIFATYU@nortel.com Mon Dec 14 07:48:11 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41AA73A686E for ; Mon, 14 Dec 2009 07:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.293 X-Spam-Level: X-Spam-Status: No, score=-6.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 3GFomK-a6RKH for ; Mon, 14 Dec 2009 07:48:10 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 1DBA53A6956 for ; Mon, 14 Dec 2009 07:48:10 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id nBEFlq225968; Mon, 14 Dec 2009 15:47:52 GMT 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, 14 Dec 2009 10:47:51 -0500 Message-ID: <90243C8A881F8D419D855264D9636F3A02CBC11A@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Draft new version: keep Thread-Index: Acpyd/zn41lehazHToWSzx4xIiXFqQI4Ck8QAE1FmNAAESabkA== References: <90243C8A881F8D419D855264D9636F3A02C5B40C@zcarhxm2.corp.nortel.com> From: "Rifaat Shekh-Yusef" To: "Christer Holmberg" , Subject: Re: [sipcore] Draft new version: keep X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 15:48:11 -0000 > =20 >>I read your document (sipcore-keep-01) and I have the following questions (I am sorry if these questions were asked before): >>=20 >>RFC 5626 recommends the STUN Keep-Alive technique with connection-less transports and CRLF Keep-Alive technique with connection-oriented transports. >>Is this document recommending the client should use STUN Keep-Alive technique for both connection-oriented and connection-less transports? > >No. > >The idea is to use the keep-alive mechanism defined in RFC 5626. > >The purpose of the draft is only to allow entities to negotiate the usage of keep-alive, if they don't support outbound. Then section 5 should be clarified to reflect this, as this is not clear from the current text. >>Why did you choose STUN over CRLF? >> >>The header of Section 8 implies that there is an overlap between this=20 >>document and the connect-reuse draft, but when you read the section you realize that this is not the case. >>Why do you think that this section is needed? Does it matter if the=20 >>connection between the UA and the proxy uses one TCP connection or two TCP connections? > >At one point I was asked to add that section, just to point out the differences between keep-alive and connect-reuse. This section does not seem to add any value to this document. Regards, Rifaat =20 ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Tuesday, December 01, 2009 6:18 AM To: sipcore@ietf.org Subject: [sipcore] Draft new version: keep Hi,=20 I've submitted a new version of the keep draft. There are no changes from the previous version, but it had expired.=20 I will produce a new version, with new content, once we get the info issues resolved - it has really taken more time than expected...=20 A new version of the info draft will be submitted tomorrow.=20 Regards,=20 Christer=20 From christer.holmberg@ericsson.com Mon Dec 14 23:05:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 818C33A6942 for ; Mon, 14 Dec 2009 23:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.236 X-Spam-Level: X-Spam-Status: No, score=-6.236 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 hHwXByeQSQ7i for ; Mon, 14 Dec 2009 23:05:18 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 421EA3A672E for ; Mon, 14 Dec 2009 23:05:18 -0800 (PST) X-AuditID: c1b4fb3c-b7b57ae0000005bb-95-4b27351f4e43 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id F8.E4.01467.F15372B4; Tue, 15 Dec 2009 08:05:03 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.22]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 15 Dec 2009 08:05:03 +0100 From: Christer Holmberg To: 'Rifaat Shekh-Yusef' , "sipcore@ietf.org" Date: Tue, 15 Dec 2009 08:05:02 +0100 Thread-Topic: [sipcore] Draft new version: keep Thread-Index: Acpyd/zn41lehazHToWSzx4xIiXFqQI4Ck8QAE1FmNAAESabkAAgoVsA Message-ID: References: <90243C8A881F8D419D855264D9636F3A02C5B40C@zcarhxm2.corp.nortel.com> <90243C8A881F8D419D855264D9636F3A02CBC11A@zcarhxm2.corp.nortel.com> In-Reply-To: <90243C8A881F8D419D855264D9636F3A02CBC11A@zcarhxm2.corp.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Draft new version: keep X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 07:05:19 -0000 Hi,=20 >>>I read your document (sipcore-keep-01) and I have the following >>>questions (I am sorry if these questions were asked before): >>>RFC 5626 recommends the STUN Keep-Alive technique with connection-less >>>transports and CRLF Keep-Alive technique with connection-oriented transp= orts. >>>Is this document recommending the client should use STUN Keep-Alive >>>technique for both connection-oriented and connection-less transports? >> >>No. >> >>The idea is to use the keep-alive mechanism defined in RFC 5626. >> >>The purpose of the draft is only to allow entities to negotiate the >>usage of keep-alive, if they don't support outbound. > >Then section 5 should be clarified to reflect this, as this is not clear f= rom the current text. Section 1 says: "This specification defines a new SIP Via header parameter, "keep",which ca= n be used by a UA to indicate support of the keep-alive techniques defined in [I-D.ietf-sip-outbound]." Section 5 also mentions, in a number of places, "keep-alive techniques defi= ned in outbound", but I will take a look whether it can be more clear. >>>Why did you choose STUN over CRLF? >>> >>>The header of Section 8 implies that there is an overlap between this=20 >>>document and the connect-reuse draft, but when you read the section >>>you realize that this is not the case. >>>Why do you think that this section is needed? Does it matter if the=20 >>>connection between the UA and the proxy uses one TCP connection or two T= CP connections? >> >>At one point I was asked to add that section, just to point out the diffe= rences between keep-alive and connect-reuse. > >This section does not seem to add any value to this document. I would have to check the archieves for the discussions about it, but in ge= neral I would not like to remove chapters which we have agreed to add. I guess the people who wanted to chapter (Vijay?) could comment. Regards, Christer= From RIFATYU@nortel.com Tue Dec 15 06:22:54 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62CE13A6A51 for ; Tue, 15 Dec 2009 06:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.327 X-Spam-Level: X-Spam-Status: No, score=-6.327 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 DrR4Of2iTnog for ; Tue, 15 Dec 2009 06:22:53 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 302993A6A4E for ; Tue, 15 Dec 2009 06:22:53 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nBFEMXK03279; Tue, 15 Dec 2009 14:22:34 GMT 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: Tue, 15 Dec 2009 09:21:22 -0500 Message-ID: <90243C8A881F8D419D855264D9636F3A02D0AC88@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Draft new version: keep Thread-Index: Acpyd/zn41lehazHToWSzx4xIiXFqQI4Ck8QAE1FmNAAESabkAAgoVsAAA65qzA= References: <90243C8A881F8D419D855264D9636F3A02C5B40C@zcarhxm2.corp.nortel.com> <90243C8A881F8D419D855264D9636F3A02CBC11A@zcarhxm2.corp.nortel.com> From: "Rifaat Shekh-Yusef" To: "Christer Holmberg" , Subject: Re: [sipcore] Draft new version: keep X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 14:22:54 -0000 Hi Christer, >>>>I read your document (sipcore-keep-01) and I have the following=20 >>>>questions (I am sorry if these questions were asked before): >>>>RFC 5626 recommends the STUN Keep-Alive technique with=20 >>>>connection-less transports and CRLF Keep-Alive technique with connection-oriented transports. >>>>Is this document recommending the client should use STUN Keep-Alive=20 >>>>technique for both connection-oriented and connection-less transports? >>> >>>No. >>> >>>The idea is to use the keep-alive mechanism defined in RFC 5626. >>> >>>The purpose of the draft is only to allow entities to negotiate the=20 >>>usage of keep-alive, if they don't support outbound. >> >>Then section 5 should be clarified to reflect this, as this is not clear from the current text. > >Section 1 says: > >"This specification defines a new SIP Via header parameter, "keep",which can be used by a UA to indicate support of the keep-alive techniques defined in >[I-D.ietf-sip-outbound]." > >Section 5 also mentions, in a number of places, "keep-alive techniques defined in outbound", but I will take a look whether it can be more clear. The very first paragraph in section 5 says the following: "A SIP entity aciting as a UAC which supports the method defined in this specification MUST act as a STUN client [I-D.ietf-behave-rfc3489bis], and MUST support the amount of STUN which is required to apply the STUN keep-alive technique [I-D.ietf-sip-outbound]." The way I understand this paragraph and the use of "MUST" is that you are mandating STUN, period. Regards, Rifaat From gonzalo.camarillo@ericsson.com Thu Dec 17 06:55:33 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DACA93A6AD2 for ; Thu, 17 Dec 2009 06:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.238 X-Spam-Level: X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 ujvPj08QK+Kk for ; Thu, 17 Dec 2009 06:55:33 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 831983A6405 for ; Thu, 17 Dec 2009 06:55:32 -0800 (PST) X-AuditID: c1b4fb24-b7beeae000003a71-4b-4b2a4655674a Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 15.DF.14961.5564A2B4; Thu, 17 Dec 2009 15:55:17 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 15:55:16 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 15:55:16 +0100 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 40497233F; Thu, 17 Dec 2009 16:55:16 +0200 (EET) Message-ID: <4B2A4654.6010902@ericsson.com> Date: Thu, 17 Dec 2009 16:55:16 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Gunnar Hellstrom References: <20090714001501.35E4928C0FE@core3.amsl.com> <003401ca7b7b$4a2234b0$211ea8c0@GunnarH> In-Reply-To: <003401ca7b7b$4a2234b0$211ea8c0@GunnarH> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Dec 2009 14:55:16.0452 (UTC) FILETIME=[F1BBDA40:01CA7F28] X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] I-D ACTION:draft-ietf-sipcore-location-conveyance-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 14:55:33 -0000 Hi, note that Keith is the shepherd of this draft. The authors tell me that they will submit a new revision of this draft shortly. Cheers, Gonzalo Gunnar Hellstrom wrote: > I think it would be useful if draft-ietf-sipcore-location-conveyance moved > on in status. > > /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: Tuesday, July 14, 2009 2:15 AM > To: i-d-announce@ietf.org > Cc: sipcore@ietf.org > Subject: I-D ACTION:draft-ietf-sipcore-location-conveyance-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session Initiation Protocol Core Working > Group of the IETF. > > Title : Location Conveyance for the Session Initiation > Protocol > Author(s) : J. Polk, B. Rosen > Filename : draft-ietf-sipcore-location-conveyance-01.txt > Pages : 48 > Date : 2009-7-13 > > This document defines an extension to the Session Initiation > Protocol (SIP) to convey geographic location information from one > SIP entity to another SIP entity. The extension covers end-to-end > conveyance as well as location-based routing, where SIP servers > make routing decisions based on the location of the user agent > client. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-0 > 1.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. > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From gonzalo.camarillo@ericsson.com Thu Dec 17 08:08:55 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 745753A68B4 for ; Thu, 17 Dec 2009 08:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.238 X-Spam-Level: X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 m++PXlyxaf25 for ; Thu, 17 Dec 2009 08:08:54 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id EBE403A63EB for ; Thu, 17 Dec 2009 08:08:53 -0800 (PST) X-AuditID: c1b4fb3e-b7bc3ae000002f8e-e8-4b2a4718febb Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id BC.19.12174.8174A2B4; Thu, 17 Dec 2009 15:58:32 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 15:58:32 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 15:58:31 +0100 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id DCF28233F for ; Thu, 17 Dec 2009 16:58:31 +0200 (EET) Message-ID: <4B2A4717.5090100@ericsson.com> Date: Thu, 17 Dec 2009 16:58:31 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: SIPCORE References: <4B20DDCF.9000409@ericsson.com> In-Reply-To: <4B20DDCF.9000409@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Dec 2009 14:58:32.0078 (UTC) FILETIME=[665602E0:01CA7F29] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] WGLC draft-ietf-sipcore-info-events-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 16:08:55 -0000 Hi, we are half-way through this WGLC and no comments have been received. You need to fire up! ;o) Cheers, Gonzalo Gonzalo Camarillo wrote: > Folks, > > Christer has submitted a new version of the INFO Events draft (see email > below) that is supposed to address all the comments received so far. > Since there have been extensive discussions on this topic since the last > time we WGLCed this draft, we are going to WGLC it again. > > http://tools.ietf.org/html/draft-ietf-sipcore-info-events-03 > > So, please, have a look at this new version and let us know whether or > not you also think all comments have been addressed. Of course, you are > also welcome to submit new comments should you have some. This WGLC will > end on December 24th. > > Thanks, > > Gonzalo > SIPCORE co-chair > > -------- Original Message -------- > Subject: [sipcore] Draft new version: draft-ietf-sipcore-info-events > Date: Wed, 2 Dec 2009 09:59:24 +0100 > From: Christer Holmberg > To: > > > > > Hi, > > I've submitted a new version of the info draft. Hopefully all comments > and feedback have now been addressed. > > The biggest changes are: > > - Section 4.2: The usage of the Recv-Info header has been clarified, > some simple rules have been added, and there were some discussions that > since the re-INVITE fallback issue also affects Recv-Info (if you > receive a Recv-Info in a 18x to a re-INVITE, and the re-INVITE then > fails) and that we need some words about that. The text now says that IF > the request contains a Recv-Info header, the response must also contain it. > > - Section 11.4: Contains new wording about the IANA process for > registering info packages, including the expert review etc. > > - Section 12: Additional examples have been added > > > Please note that I did NOT remove Recv-Info in PRACKs, since there in my > opinion was no concensus to do so. > > > The draft can also be found at: > > _http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-info-events-03.txt_ > > > > > Regards, > > Christer > > > > ------------------------------------------------------------------------ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From vkg@alcatel-lucent.com Tue Dec 22 09:45:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A77C228B23E for ; Tue, 22 Dec 2009 09:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 KrboL5qN0X7u for ; Tue, 22 Dec 2009 09:45:08 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id E05BB3A67D9 for ; Tue, 22 Dec 2009 09:45:07 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id nBMHiohJ026131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Dec 2009 11:44:50 -0600 (CST) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id nBMHiofU011871; Tue, 22 Dec 2009 11:44:50 -0600 (CST) Message-ID: <4B310591.7070808@alcatel-lucent.com> Date: Tue, 22 Dec 2009 11:44:49 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cullen Jennings References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <7F45E9F5-ADFF-42D4-9505-882A5A19E198@cisco.com> In-Reply-To: <7F45E9F5-ADFF-42D4-9505-882A5A19E198@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 17:45:09 -0000 Cullen Jennings wrote: > On Nov 24, 2009, at 2:26 PM, Brian Hibbard wrote: >> == Observed Interoperability Issues in section 6== Who observed >> them? Is this experience from SIPits, etc? I think it would >> strengthen the idea that these are real-world, observed-in-the-wild >> issues to give sources. > > Kumiko and I at SIPits are the main ref but this is all pretty uh > fluffy, it's not like we have enough observation for any significant > statistical sample. [...] Here is a table that contains the number of TLS implementations since SIPit 16: SIPit Unique Number of TLS No. Implementations implementations Percentage ---------------------------------------------------- 16 57 25 44% 18 73 30 41% 19 90 41 45% 20 90 42 46% 21 70 34 49% 22 80 50 63% 23 50 24 48% 24 43 22 52% 25 42 16 38% Note: (1) 16th SIPit was held in April 2005, 23 SIPit was held in October 2008. (2) Data for 16th SIPit is form my private archive and is not reflected in [1]. (3) I don't have data for 17th SIPit. (4) Data from SIPit 18-25 is archived at [1]. [1] Robert J. Sparks, SIPit Summaries, archived at https://www.sipit.net/SIPitSummaries In the last 3-4 bakeoffs, there weren't any implementations of S/MIME. In the earlier bakeoffs, there were very few implementations of S/MIME. If you want me to compile these for a summary, I can do so. I am preparing a review of sec-flows. I will include this table in the review comments as well. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From vkg@alcatel-lucent.com Tue Dec 22 12:28:59 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 425373A681E for ; Tue, 22 Dec 2009 12:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 nQvkYpfBj-iF for ; Tue, 22 Dec 2009 12:28:57 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 49A093A67B3 for ; Tue, 22 Dec 2009 12:28:56 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id nBMKSUtP019053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Dec 2009 14:28:31 -0600 (CST) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id nBMKSUMS006418; Tue, 22 Dec 2009 14:28:30 -0600 (CST) Message-ID: <4B312BEE.9040804@alcatel-lucent.com> Date: Tue, 22 Dec 2009 14:28:30 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Hibbard Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: SIPCORE Subject: [sipcore] Review of sipcore-sec-flows-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 20:28:59 -0000 First off, sorry for the delay in getting this review out. I had promised to send it shortly after Thanksgiving, but ... Second, I believe that this work is of importance to the development community that can use an additional resource to get a TLS-capable SIP entity tested and running. That said, here are the rest of my comments from my review. 1) S1, paragraph 2: OLD: Furthermore, testing at the events is often hampered by trying to get certificates signed by some common test root into the appropriate format for various clients. NEW: Furthermore, testing at the events is often hindered due to the lack of a commonly trusted certificate authority to sign the certificates used in the events. 2) S1, paragraph 2: The following text In addition, this document provides a common certificate and private key that can be used for a Certificate Authority (CA) to reduce the time it takes to set up a test at an interoperability event. makes the reader believe that the common certificate and private key can be used by any CA in the world. This is, of course, not the intent. The document is providing a common certificate and the associated private key for the express purpose of creating a mock CA to sign the certificates for the interoperability events. Thus, I would suggest the following paragraph as a substitute for the above one (please feel free to edit as needed): In addition, this document provides a common certificate and private key that can be used to set up a CA --- a mock CA --- during the SIP interoperability events. Certificate requests from the users will be signed by the private key of the mock CA. 3) S1, paragraph 4, last sentence: s/the same CA certificate/the same mock CA private key/ 4) S1, paragraph 5: s/list of things implementers/list of items that implementers/ 5) S1, paragraph 6: s/A way to make/Scripts and instructions to make/ s/is presented/are presented/ 6) S3.2, note that the DNS label in the certificate under the SAN extension is wrong. It should be "DNS:example.com" and not "DNS:com". Also, the example.net certificate suffers from the same problem, it also contains "DNS:net" in the SAN instead of "DNS:example.net". 7) S3.3, the sentence "The message could be coming from a host called atlanta.example.com, and the AOR in the user certificate would still be the same." adds ambiguity to the text without contributing much information. Unless there is a specific reason why the reader needs to know that the SIP message sent over a TLS channel established by this certificate originated from the host atlanta.example.com, I would suggest to remove the offending sentence completely. 8) S4.1, paragraph 1: s/TLSRFC/TLS RFC/ s/set to example.net/contains example.net 9) S4.1, the ssldump output: should not the second endpoint be identified as "www.example.net (5061)"? See the very first line of the ssldump output. 10) S4.2: The first paragraph says that the convention from rfc4475 is used, however, I do not see the element in the subsequent example. 11) S4.2, first open issue: If Contact is not allowed in a MESSAGE and its corresponding 2xx, simply take it out, no? Taking the Contact out does not result in any loss of generalization, nor does it detract from the point the example is trying to make. 12) S4.2, second open issue: If you take Contact out of the 200 OK, then you do not have this problem. The Contact in the 200 OK contains an IP address that is the same as the one in the top-most Via header (which is what leads to the confusion in the first place, I believe. The To and From contain URIs with domain names.) 13) S4.2, third open issue: I am not sure what you are trying to point out by referencing rfc3263 or connect-reuse here. IMHO, the section looks fine without referencing rfc3263 or connect-reuse. 14) S5.1: I would advise being consistent and using convention everywhere in this draft. 15) S5.1, this is a nit, but to be orthogonal to S4.2, it will help if the message body in S5.1 contained the same message as in S4.2 (i.e., "Hello!" instead of "hello"). 15) S5.3: I would advise being consistent and using convention everywhere in this draft. 16) S6: First open issue: Cullen has already stated that he and Kumiko has observed these. In addition, here is a table that contains the number of TLS implementations since SIPit 16: SIPit Unique Number of TLS No. Implementations implementations Percentage ---------------------------------------------------- 16 57 25 44% 18 73 30 41% 19 90 41 45% 20 90 42 46% 21 70 34 49% 22 80 50 63% 23 50 24 48% 24 43 22 52% 25 42 16 38% Note: (1) 16th SIPit was held in April 2005, 23 SIPit was held in October 2008. (2) Data for 16th SIPit is form my private archive and is not reflected in [1]. (3) I don't have data for 17th SIPit. (4) Rest of the table created from data at [1]. [1] Robert J. Sparks, SIPit Summaries, archived at https://www.sipit.net/SIPitSummaries In the last 3-4 bakeoffs, there weren't any implementations of S/MIME. In the earlier bakeoffs, there were very few implementations of S/MIME. If you want me to compile these for a summary, I can do so. 17) S6, second open issue: Does it matter? What is gained by further categorizing the SIP clients into UAS, UAC, or a proxy? 18) S7, general comment -- some "folklore" is specified in the domain-certs document (http://tools.ietf.org/html/draft-ietf-sip-domain-certs-04), which is with the IESG right now. The domain-certs document should be cited here as well. 18) S7, second bullet item is normatively specified in domain-certs. Suggest that a reference to domain-certs be included here for further reading. 19) S7, third open issue: I believe that IP addresses can appear in the SAN (rfc5280 says so.) Their handling is specified in domain-certs (I believe they will appear as "DNS:192.168.0.1"; we need to have someone -- from pkix? -- ascertain this. If this is the case, then their handling is specified in S7.1 of domain-certs.) 20) S7: For the test cases in S7, I wonder if it is worth creating test certificates issued by the mock CA and including these in the draft? That way, implementers can simply download the certificates and use them for their testing. If people think this is a good idea, I can spend some time doing this. 21) S7: last open issue: I think that the case of having one or more certificates in a path not provided or not available is a good one. Question is should we provide a certificate signed by a subordinate CA for testing to implementers or simply discuss this case? Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From paulej@packetizer.com Tue Dec 22 20:23:34 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6767F3A67F7 for ; Tue, 22 Dec 2009 20:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 W09xfpgFm2LJ for ; Tue, 22 Dec 2009 20:23:30 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 4A2CA3A679C for ; Tue, 22 Dec 2009 20:23:30 -0800 (PST) Received: from berlin.arid.us (rrcs-98-101-146-143.midsouth.biz.rr.com [98.101.146.143]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id nBN4N5Ah007829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Dec 2009 23:23:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1261542191; bh=0vZlMvXSCccUAJOX6nzUG1jlwIr8MV8lTKHgvNUJVMU=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=JJMyLmMF/rymCeTgafqqJ4I8oJPzgO/FQujGgQOSqrxcVGno7FMH1tMmvryxNWigQ AsgpQQo/+/g9RkcqcQK21D8FjdVnOQvpn8iSidSCFDbroEndV/WMcHMS7EYq8OW4eZ StCI2ixzFIK2ZEAVteLtWQxYGopxBx8eoS4XORSg= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id nBN4N3cm006495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Dec 2009 23:23:04 -0500 From: "Paul E. Jones" To: "'Richard Shockey'" , References: <013401ca679d$3a926700$afb73500$@us> In-Reply-To: <013401ca679d$3a926700$afb73500$@us> Date: Tue, 22 Dec 2009 23:22:57 -0500 Message-ID: <00cd01ca8387$9b46ea20$d1d4be60$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpnXhDNP6UoFkakQWCME6TnXYiPQAAPjF+ABvrLbzA= Content-Language: en-us Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 04:23:34 -0000 Folks, I didn't see any comments regarding this draft. What is the opinion about publishing this as an informational RFC? Paul > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Richard Shockey > Sent: Tuesday, November 17, 2009 10:47 AM > To: sipcore@ietf.org; dispatch@ietf.org > Subject: [sipcore] FW: I-D Action:draft-jones-sip-forum-fax-problem- > statement-00.txt > > > FYI to the general SIP community. > > There have been substantial field reports of difficulties with T.30 FAX > is > SIP networks and the SIP Forum was asked to help facilitate discussions > among a group of technical experts in fax order to provider > recommendations > to either the IETF and or ITU SG16 on possible approaches to the > problem. > > Fax is a essential realtime communications service that is not going > away > and making fax work properly needs to be addressed. > > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Tuesday, November 17, 2009 3:15 AM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : SIP Forum - Fax Over IP Task Group Problem > Statement > Author(s) : X. Chen, et al. > Filename : draft-jones-sip-forum-fax-problem-statement- > 00.txt > Pages : 13 > Date : 2009-11-17 > > This memo is published for informational purposes to document the > issues > identified by the SIP Forum with respect to the transmission of > facsimile > signaling messages and fax page data over Internet Protocol (IP) > networks. > Further, it is the intent of this memo to alert the IETF to the > formation of > a Fax Over IP Task Group within the SIP Forum chartered to investigate > and > address identified issues as they relate to the deployment of fax > services > in Session Initiation Protocol (SIP) networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jones-sip-forum-fax-problem- > statem > ent-00.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. > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From dean.willis@softarmor.com Wed Dec 23 19:19:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 477EC3A67DB for ; Wed, 23 Dec 2009 19:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 niN2fliCiUqC for ; Wed, 23 Dec 2009 19:19:29 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 839593A67A5 for ; Wed, 23 Dec 2009 19:19:29 -0800 (PST) Received: from [192.168.2.100] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id nBO3Iho7016868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Dec 2009 21:18:45 -0600 Message-ID: <4B32DD8F.7050402@softarmor.com> Date: Wed, 23 Dec 2009 21:18:39 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <7F45E9F5-ADFF-42D4-9505-882A5A19E198@cisco.com> <4B310591.7070808@alcatel-lucent.com> In-Reply-To: <4B310591.7070808@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 03:19:30 -0000 Vijay K. Gurbani wrote: > Here is a table that contains the number of TLS implementations > since SIPit 16: The adoption rate of TLS peaked a couple of years back, and has been steadily declining since? That should tell us something important. Like, maybe nobody can figure out how to implement this stuff, nobody actually uses it, or nobody runs SIP on a hostile network. Not sure which is the case, here. -- Dean From dean.willis@softarmor.com Wed Dec 23 19:24:49 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C085F3A682C for ; Wed, 23 Dec 2009 19:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 Cc2D6954bVMc for ; Wed, 23 Dec 2009 19:24:49 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id D99603A63C9 for ; Wed, 23 Dec 2009 19:24:48 -0800 (PST) Received: from [192.168.2.100] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id nBO3OTX7016927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Dec 2009 21:24:31 -0600 Message-ID: <4B32DEE9.5000302@softarmor.com> Date: Wed, 23 Dec 2009 21:24:25 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Paul E. Jones" References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> In-Reply-To: <00cd01ca8387$9b46ea20$d1d4be60$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 03:24:49 -0000 Paul E. Jones wrote: > Folks, > > I didn't see any comments regarding this draft. What is the opinion about > publishing this as an informational RFC? I'm sympathetic to the fax problem. But I'm not sure what the intent of publishing this draft as an RFC might be. It reads more like a liaison statement from FaxTG to IETF informing IETF of what FaxTG is working on. We have a less costly pulication route for LS available that might be a better alternative if that's the case. If, however, you're leading towards another fax effort in IETF, then it might make sense to take this draft along the individual informational route. -- Dean From paulej@packetizer.com Wed Dec 23 19:57:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCC3A3A68A5 for ; Wed, 23 Dec 2009 19:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 cDcmrFqDQ722 for ; Wed, 23 Dec 2009 19:57:28 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id B29413A684A for ; Wed, 23 Dec 2009 19:57:28 -0800 (PST) Received: from berlin.arid.us (rrcs-98-101-146-143.midsouth.biz.rr.com [98.101.146.143]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id nBO3v5do026803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Dec 2009 22:57:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1261627031; bh=QIEhqTuTtCct4rHAngkHBtPsHAz3lD0C0ZAmwkMD/xE=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=tqqf3stlieH1yyEzt1+GHmrAmOddN9PgE0mf49Hg2JW5QjVsjD4r12iI/PvkwsrL0 LGQE4ZyJBTSTPpUijzx8yRPuGDlBqzOvzqMe58QxpiaJhZBlQMpa/b0pcNNiQM1c7D moDYPaUf9g8MUgcd2wWNA2O+P4YWMP/9kVd+nMh0= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id nBO3v5hd008970 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Dec 2009 22:57:05 -0500 From: "Paul E. Jones" To: "'Dean Willis'" References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> In-Reply-To: <4B32DEE9.5000302@softarmor.com> Date: Wed, 23 Dec 2009 22:56:57 -0500 Message-ID: <018401ca844d$23615510$6a23ff30$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqESKErKufgI2OWSmyN/Gkjh9HpLAAAzXUA Content-Language: en-us Cc: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 03:57:29 -0000 Dean, The intent is not only to inform the IETF, but the public at large as to the issues identified with fax transmission. The next step is to try to fix the problems. That might result in the creation of one or more documents that prescribes a solution. Will that be in the ITU or IETF, or both? I don't know. (I'm just serving as editor.) Let's assume the work is only done in the ITU. Would the IETF want to publish an Informational document at all? It sounds like that answer might be "no". If the SIP Forum plans to come back to the IETF with some work, how ought we change this document to "pave the way" for that kind of work? I know a few folks working in the SIP Forum are on this list, but I'll take any feedback you and others provide to the group to ensure the message is conveyed. Paul PS - Merry Christmas, everyone! > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: Wednesday, December 23, 2009 10:24 PM > To: Paul E. Jones > Cc: sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-forum-fax- > problem-statement-00.txt > > Paul E. Jones wrote: > > Folks, > > > > I didn't see any comments regarding this draft. What is the opinion > about > > publishing this as an informational RFC? > > I'm sympathetic to the fax problem. > > But I'm not sure what the intent of publishing this draft as an RFC > might be. It reads more like a liaison statement from FaxTG to IETF > informing IETF of what FaxTG is working on. We have a less costly > pulication route for LS available that might be a better alternative if > that's the case. > > If, however, you're leading towards another fax effort in IETF, then it > might make sense to take this draft along the individual informational > route. > > -- > Dean > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@cisco.com Wed Dec 23 20:04:01 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 838063A68A5 for ; Wed, 23 Dec 2009 20:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 61ibUJLBe-pW for ; Wed, 23 Dec 2009 20:04:00 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 83E553A67EC for ; Wed, 23 Dec 2009 20:04:00 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIGAHd3MktAZnwM/2dsb2JhbACZCaY8lm6EMwQ X-IronPort-AV: E=Sophos;i="4.47,447,1257120000"; d="scan'208";a="76470672" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 24 Dec 2009 04:03:26 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nBO43QHu015204; Thu, 24 Dec 2009 04:03:26 GMT Received: from xfe-rtp-211.amer.cisco.com ([64.102.31.113]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Dec 2009 23:03:26 -0500 Received: from [10.86.246.48] ([10.86.246.48]) by xfe-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Dec 2009 23:03:25 -0500 Message-ID: <4B32E80D.3010003@cisco.com> Date: Wed, 23 Dec 2009 23:03:25 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <7F45E9F5-ADFF-42D4-9505-882A5A19E198@cisco.com> <4B310591.7070808@alcatel-lucent.com> <4B32DD8F.7050402@softarmor.com> In-Reply-To: <4B32DD8F.7050402@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Dec 2009 04:03:26.0046 (UTC) FILETIME=[0B01BFE0:01CA844E] Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 04:04:01 -0000 Dean Willis wrote: > Vijay K. Gurbani wrote: > >> Here is a table that contains the number of TLS implementations >> since SIPit 16: > > The adoption rate of TLS peaked a couple of years back, and has been > steadily declining since? That should tell us something important. Like, > maybe nobody can figure out how to implement this stuff, nobody actually > uses it, or nobody runs SIP on a hostile network. Not sure which is the > case, here. I don't know the data - perhaps this just says something about which products are being brought to sipit, and *which* sipits they go to. Thanks, Paul From shida@ntt-at.com Wed Dec 23 23:25:31 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B6B63A6922 for ; Wed, 23 Dec 2009 23:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 ZDMCoGiL3G1n for ; Wed, 23 Dec 2009 23:25:30 -0800 (PST) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.56.170.19]) by core3.amsl.com (Postfix) with SMTP id 4318B3A689C for ; Wed, 23 Dec 2009 23:25:30 -0800 (PST) Received: (qmail 24407 invoked from network); 24 Dec 2009 07:38:36 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway01.websitewelcome.com with SMTP; 24 Dec 2009 07:38:36 -0000 Received: from udp258607uds.hawaiiantel.net ([72.253.219.121]:50525 helo=[192.168.1.45]) by gator465.hostgator.com with esmtpa (Exim 4.69) (envelope-from ) id 1NNi48-0003vr-L7; Thu, 24 Dec 2009 01:24:56 -0600 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <4B1BEF51.1080805@cisco.com> Date: Thu, 24 Dec 2009 16:25:12 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <8FD558CE-A0DD-45B4-ABDD-148986C4C347@ntt-at.com> References: <4B13C4FC.5050907@sipstation.com><98E67934-70CE-49E4-A2C3-05C3EB42573F@skype.net><10A79C23-41FB-4FF8-AD55-2F83D7017EFC@gmail.com> <057B55FD-2B09-4296-AB60-6FA7E47EDD37@ntt-at.com> <9886E5FCA6D76549A3011068483A4BD40551C3B6@S4DE8PSAAQB.mitte.t-com.de> <52DC7475-F576-4397-B1CF-0C6ED6540089@gmail.com> <4B1BDE5A.1060608@ericsson.com> <4B1BEF51.1080805@cisco.com> To: Paul Kyzivat X-Mailer: Apple Mail (2.1077) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Cc: Francois Audet , sipcore@ietf.org, R.Jesske@telekom.de Subject: Re: [sipcore] Some comments on draft-barnes-sipcore-rfc4244bis-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 07:25:31 -0000 If the focus is about which target (AoR) is to be considered for=20 any special call handling such as voicemail (use of RFC4458?) , so when call is forwarded the receiving end knows there is a=20 preferred identity which is to be honored, then we may have=20 some work to do with History-Info but otherwise I don't think=20 there is much more to do beside elaborating the voicemail section. =20 Any thoughts?=20 =20 Regards Shida On Dec 7, 2009, at 2:52 AM, Paul Kyzivat wrote: > The main tactic I know of that is currently deployed to address this = need is to cancel the forwarded call after a few "rings", hopefully = before it is transferred to voicemail there. But of course that doesn't = work if you guess wrong about the number of rings, and especially if the = call goes direct to voicemail. >=20 > While there is no way, once I have forwarded a call to you, for me to = *prevent* you from handling the call as voicemail, it is typically in = the best interests of both of us. Specifically, if I am forwarding the = call to you, but asked you *not* to send the call to your voicemail, = then honoring that saves you the trouble handling the voicemail, and = also keeps you in my good graces. >=20 > So the key here is to communicate preferences for how the call should = be handed, and define the recommended handling of calls in the presence = of such a recommendation. >=20 > The basics to do this have been in callerprefs for a long time. But I = don't think they have been considered seriously in this context. I'm not = *certain* that is sufficient to address the problem, but it seems like = the right starting point. >=20 > Note that this sort of approach *does not* require looking back in the = History-Info to decide which voice mailbox to use. >=20 > Thanks, > Paul >=20 >=20 > Gonzalo Camarillo wrote: >> Hi, >>> When you think about it, it makes sense. >>>=20 >>> If you call me, you would expect to get my voicemail, not somebody = else's. >> yes, Paul's example has been discussed *many* times. So, addressing = it in some way would be a good thing. >> Cheers, >> Gonzalo >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From gonzalo.camarillo@ericsson.com Thu Dec 24 02:30:54 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E44E3A6A41 for ; Thu, 24 Dec 2009 02:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 LF1bFieJmQ6u for ; Thu, 24 Dec 2009 02:30:53 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 9B1E43A69E0 for ; Thu, 24 Dec 2009 02:30:52 -0800 (PST) X-AuditID: c1b4fb24-b7beeae000003a71-c5-4b3342c90c55 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id A3.34.14961.9C2433B4; Thu, 24 Dec 2009 11:30:33 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Dec 2009 11:30:33 +0100 Received: from [159.107.48.238] ([159.107.48.238]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Dec 2009 11:30:32 +0100 Message-ID: <4B3342C8.8090400@ericsson.com> Date: Thu, 24 Dec 2009 12:30:32 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: SIPCORE References: <4B20DDCF.9000409@ericsson.com> <4B2A4717.5090100@ericsson.com> In-Reply-To: <4B2A4717.5090100@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Dec 2009 10:30:32.0836 (UTC) FILETIME=[1F40A440:01CA8484] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] WGLC draft-ietf-sipcore-info-events-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 10:30:54 -0000 Hi, this WGLC ends today and we have not received *any* comments. Cheers, Gonzalo Gonzalo Camarillo wrote: > Hi, > > we are half-way through this WGLC and no comments have been received. > You need to fire up! ;o) > > Cheers, > > Gonzalo > > Gonzalo Camarillo wrote: >> Folks, >> >> Christer has submitted a new version of the INFO Events draft (see email >> below) that is supposed to address all the comments received so far. >> Since there have been extensive discussions on this topic since the last >> time we WGLCed this draft, we are going to WGLC it again. >> >> http://tools.ietf.org/html/draft-ietf-sipcore-info-events-03 >> >> So, please, have a look at this new version and let us know whether or >> not you also think all comments have been addressed. Of course, you are >> also welcome to submit new comments should you have some. This WGLC will >> end on December 24th. >> >> Thanks, >> >> Gonzalo >> SIPCORE co-chair >> >> -------- Original Message -------- >> Subject: [sipcore] Draft new version: draft-ietf-sipcore-info-events >> Date: Wed, 2 Dec 2009 09:59:24 +0100 >> From: Christer Holmberg >> To: >> >> >> >> >> Hi, >> >> I've submitted a new version of the info draft. Hopefully all comments >> and feedback have now been addressed. >> >> The biggest changes are: >> >> - Section 4.2: The usage of the Recv-Info header has been clarified, >> some simple rules have been added, and there were some discussions that >> since the re-INVITE fallback issue also affects Recv-Info (if you >> receive a Recv-Info in a 18x to a re-INVITE, and the re-INVITE then >> fails) and that we need some words about that. The text now says that IF >> the request contains a Recv-Info header, the response must also contain it. >> >> - Section 11.4: Contains new wording about the IANA process for >> registering info packages, including the expert review etc. >> >> - Section 12: Additional examples have been added >> >> >> Please note that I did NOT remove Recv-Info in PRACKs, since there in my >> opinion was no concensus to do so. >> >> >> The draft can also be found at: >> >> _http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-info-events-03.txt_ >> >> >> >> >> Regards, >> >> Christer >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From vkg@alcatel-lucent.com Thu Dec 24 08:23:06 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D56E3A68AC for ; Thu, 24 Dec 2009 08:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 IORDlLoPSgPY for ; Thu, 24 Dec 2009 08:23:05 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 432183A699A for ; Thu, 24 Dec 2009 08:23:05 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id nBOGMgP6011331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Dec 2009 10:22:44 -0600 (CST) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id nBOGMgWm024962; Thu, 24 Dec 2009 10:22:42 -0600 (CST) Message-ID: <4B339552.1000402@alcatel-lucent.com> Date: Thu, 24 Dec 2009 10:22:42 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dean Willis References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <7F45E9F5-ADFF-42D4-9505-882A5A19E198@cisco.com> <4B310591.7070808@alcatel-lucent.com> <4B32DD8F.7050402@softarmor.com> In-Reply-To: <4B32DD8F.7050402@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 16:23:06 -0000 Dean Willis wrote: > The adoption rate of TLS peaked a couple of years back, and has been > steadily declining since? That should tell us something important. Like, > maybe nobody can figure out how to implement this stuff, nobody actually > uses it, or nobody runs SIP on a hostile network. Not sure which is the > case, here. I don't think we can draw that general an argument that after peaking the support for TLS is slipping now. We probably need more data about the early bakeoffs -- going back to the 11th bakeoff, which is the first one that took place after rfc3261 was released. In any case, I think the data tells us that over the 9 SIPits during which the data has been available, the support for TLS has hovered in [0.38 - 0.63] range, with an average of 0.47. Essentially, less than 1/2 of the SIPit implementations that are brought to the event support TLS. That itself is a telling statistic. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From richard@shockey.us Thu Dec 24 08:43:10 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 762513A6881 for ; Thu, 24 Dec 2009 08:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_50=0.001, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6] 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 DqvhCJnOO-5X for ; Thu, 24 Dec 2009 08:43:10 -0800 (PST) Received: from outbound-mail-146.bluehost.com (outbound-mail-146.bluehost.com [67.222.38.36]) by core3.amsl.com (Postfix) with SMTP id 367213A6878 for ; Thu, 24 Dec 2009 08:43:10 -0800 (PST) Received: (qmail 19408 invoked by uid 0); 24 Dec 2009 16:36:13 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy5.bluehost.com with SMTP; 24 Dec 2009 16:36:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=O1zBKjmbLWm95OIfDoHEgm9JjIv6Mw4OkHZh0/43OXg/DipTjoSBO6XY29ge6WbVpe4rzu6/5fkE5W4h5OoO987d48gA95o1HhVf7BiYSfsFnXvuhUf9H5VwoZQ9INhQ; Received: from pool-96-241-233-91.washdc.fios.verizon.net ([96.241.233.91] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NNqfc-0002wv-Sw; Thu, 24 Dec 2009 09:36:13 -0700 From: "Richard Shockey" To: "'Dean Willis'" , "'Paul E. Jones'" References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> In-Reply-To: <4B32DEE9.5000302@softarmor.com> Date: Thu, 24 Dec 2009 11:36:11 -0500 Message-ID: <007301ca84b7$343dd6f0$9cb984d0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqESKCTJBOCvkc8RXWRCJ9hm+tiBwAbAu2Q Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.233.91 authed with richard+shockey.us} Cc: dispatch@ietf.org, sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 16:43:10 -0000 The intent of the draft is to inform and clearly document to the IETF SIP community that "there is a problem" with fax in SIP networks. In fact, the problem seems to be much worse than some of us have originally believed. I recently met with several folks from the international wholesale carrier community (the i3forum ) who are reporting similar problems with fax in their networks. These issues have the potential for delaying significant SIP deployment in these networks, aka loss of sales for the supplier community. (hint) Let us not forget that fax is a essential communications service in the PSTN and that SIP networks MUST figure out ways to accommodate it. The SIP Forum Fax Task group is currently investigating the problems documented in the draft and taking additional input from all parties. Everyone in the IETF SIP Community is free to participate in this work. http://www.sipforum.org/content/view/310/252/ The goal is to develop a formal SIP Forum recommendation on what steps can be taken to fix the problems. If it is determined that either SIP or T.38 protocols needs to be modified in some way then a follow on document ( ID or ITU Liaison letter ) will be developed suggesting alternatives for consideration. With that follow up document in mind I do think is important to publish the fax problem statement as Informational. Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 skype: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 http//www.sipforum.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, December 23, 2009 10:24 PM > To: Paul E. Jones > Cc: 'Richard Shockey'; sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-forum-fax- > problem-statement-00.txt > > Paul E. Jones wrote: > > Folks, > > > > I didn't see any comments regarding this draft. What is the opinion > about > > publishing this as an informational RFC? > > I'm sympathetic to the fax problem. > > But I'm not sure what the intent of publishing this draft as an RFC > might be. It reads more like a liaison statement from FaxTG to IETF > informing IETF of what FaxTG is working on. We have a less costly > pulication route for LS available that might be a better alternative > if > that's the case. > > If, however, you're leading towards another fax effort in IETF, then > it > might make sense to take this draft along the individual informational > route. > > -- > Dean From pkyzivat@cisco.com Thu Dec 24 12:33:58 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B9BD3A6900; Thu, 24 Dec 2009 12:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.299 X-Spam-Level: X-Spam-Status: No, score=-7.299 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] 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 Ns0UeDasYeEB; Thu, 24 Dec 2009 12:33:57 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id EC3833A68F4; Thu, 24 Dec 2009 12:33:56 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEGAAtfM0tAZnwM/2dsb2JhbACZDaVbiQ0JjRSCSoFpBA X-IronPort-AV: E=Sophos;i="4.47,451,1257120000"; d="scan'208";a="76501701" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 24 Dec 2009 20:33:36 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nBOKXapF016840; Thu, 24 Dec 2009 20:33:36 GMT Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Dec 2009 15:33:36 -0500 Received: from [10.86.246.48] ([10.86.246.48]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Dec 2009 15:33:36 -0500 Message-ID: <4B33D01C.9000006@cisco.com> Date: Thu, 24 Dec 2009 15:33:32 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Richard Shockey References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> <007301ca84b7$343dd6f0$9cb984d0$@us> In-Reply-To: <007301ca84b7$343dd6f0$9cb984d0$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Dec 2009 20:33:36.0068 (UTC) FILETIME=[5E23B040:01CA84D8] Cc: "'Paul E. Jones'" , dispatch@ietf.org, sipcore@ietf.org Subject: Re: [sipcore] [dispatch] FW: I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 20:33:58 -0000 I know this is a bit off topic, and doesn't alleviate the problem, but has anybody ever proposed that an INVITE with offer for fax be responded to with a 3xx containing a mailto: URI? Or that ENUM for a fax device yield a mailto uri? Thanks, Paul Richard Shockey wrote: > The intent of the draft is to inform and clearly document to the IETF SIP > community that "there is a problem" with fax in SIP networks. In fact, the > problem seems to be much worse than some of us have originally believed. > > I recently met with several folks from the international wholesale carrier > community (the i3forum ) who are reporting similar problems with fax in > their networks. These issues have the potential for delaying significant SIP > deployment in these networks, aka loss of sales for the supplier community. > (hint) > > Let us not forget that fax is a essential communications service in the PSTN > and that SIP networks MUST figure out ways to accommodate it. > > The SIP Forum Fax Task group is currently investigating the problems > documented in the draft and taking additional input from all parties. > Everyone in the IETF SIP Community is free to participate in this work. > > http://www.sipforum.org/content/view/310/252/ > > The goal is to develop a formal SIP Forum recommendation on what steps can > be taken to fix the problems. If it is determined that either SIP or T.38 > protocols needs to be modified in some way then a follow on document ( ID or > ITU Liaison letter ) will be developed suggesting alternatives for > consideration. > > With that follow up document in mind I do think is important to publish the > fax problem statement as Informational. > > > Richard Shockey > Shockey Consulting > Chairman of the Board of Directors SIP Forum > PSTN Mobile: +1 703.593.2683 > > skype: rshockey101 > LinkedIn : http://www.linkedin.com/in/rshockey101 > http//www.sipforum.org > > > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Wednesday, December 23, 2009 10:24 PM >> To: Paul E. Jones >> Cc: 'Richard Shockey'; sipcore@ietf.org >> Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-forum-fax- >> problem-statement-00.txt >> >> Paul E. Jones wrote: >> > Folks, >> > >> > I didn't see any comments regarding this draft. What is the opinion >> about >> > publishing this as an informational RFC? >> >> I'm sympathetic to the fax problem. >> >> But I'm not sure what the intent of publishing this draft as an RFC >> might be. It reads more like a liaison statement from FaxTG to IETF >> informing IETF of what FaxTG is working on. We have a less costly >> pulication route for LS available that might be a better alternative >> if >> that's the case. >> >> If, however, you're leading towards another fax effort in IETF, then >> it >> might make sense to take this draft along the individual informational >> route. >> >> -- >> Dean > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From paulej@packetizer.com Thu Dec 24 13:27:34 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A5FB3A6991; Thu, 24 Dec 2009 13:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_15=0.6] 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 htrgI40mGpfX; Thu, 24 Dec 2009 13:27:32 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 70E533A694A; Thu, 24 Dec 2009 13:27:32 -0800 (PST) Received: from berlin.arid.us (rrcs-98-101-146-143.midsouth.biz.rr.com [98.101.146.143]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id nBOLR7bK009209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Dec 2009 16:27:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1261690033; bh=DpPUed1p6h2R+rX8OF+Xlct9PWBG/JQRbBi//WkB/go=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=BHVhf4qF6MAIvt7a/Um8un6OAohqWWPGge8AdsytCEz7JIadg78w1KVE7ZgsRjNjA AKenDWSXf8gqMAySx94QwPYq98PlRdmabQ8iL7Vz5JqXiVBwn2qEZCFy5V0WK+mrpo QZ97NisRfRyw2z/7uW1GodfKlklc9sbREeHUAL90= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id nBOLR6fS014233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Dec 2009 16:27:06 -0500 From: "Paul E. Jones" To: "'Paul Kyzivat'" , "'Richard Shockey'" References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> <007301ca84b7$343dd6f0$9cb984d0$@us> <4B33D01C.9000006@cisco.com> In-Reply-To: <4B33D01C.9000006@cisco.com> Date: Thu, 24 Dec 2009 16:26:57 -0500 Message-ID: <002801ca84df$d2acbdb0$78063910$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqE2GjTh3dt4UyxQtKK1ILroEe7OwABDGxg Content-Language: en-us Cc: dispatch@ietf.org, sipcore@ietf.org Subject: Re: [sipcore] [dispatch] I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 21:27:34 -0000 Paul, That could certainly be done and T.37 could be used on gateways to make that work. But, as you said, it does not fix the problem with T.38. Perhaps equally important, I think there are many, many businesses that will not be moving to email anytime soon. I wish they would -- that would solve this problem :-) Paul > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Thursday, December 24, 2009 3:34 PM > To: Richard Shockey > Cc: 'Paul E. Jones'; dispatch@ietf.org; sipcore@ietf.org > Subject: Re: [sipcore] [dispatch] FW: I-D Action:draft-jones-sip-forum- > fax-problem-statement-00.txt > > I know this is a bit off topic, and doesn't alleviate the problem, but > has anybody ever proposed that an INVITE with offer for fax be > responded > to with a 3xx containing a mailto: URI? Or that ENUM for a fax device > yield a mailto uri? > > Thanks, > Paul > > Richard Shockey wrote: > > The intent of the draft is to inform and clearly document to the IETF > SIP > > community that "there is a problem" with fax in SIP networks. In > fact, the > > problem seems to be much worse than some of us have originally > believed. > > > > I recently met with several folks from the international wholesale > carrier > > community (the i3forum ) who are reporting similar problems with fax > in > > their networks. These issues have the potential for delaying > significant SIP > > deployment in these networks, aka loss of sales for the supplier > community. > > (hint) > > > > Let us not forget that fax is a essential communications service in > the PSTN > > and that SIP networks MUST figure out ways to accommodate it. > > > > The SIP Forum Fax Task group is currently investigating the problems > > documented in the draft and taking additional input from all parties. > > Everyone in the IETF SIP Community is free to participate in this > work. > > > > http://www.sipforum.org/content/view/310/252/ > > > > The goal is to develop a formal SIP Forum recommendation on what > steps can > > be taken to fix the problems. If it is determined that either SIP or > T.38 > > protocols needs to be modified in some way then a follow on document > ( ID or > > ITU Liaison letter ) will be developed suggesting alternatives for > > consideration. > > > > With that follow up document in mind I do think is important to > publish the > > fax problem statement as Informational. > > > > > > Richard Shockey > > Shockey Consulting > > Chairman of the Board of Directors SIP Forum > > PSTN Mobile: +1 703.593.2683 > > > > skype: rshockey101 > > LinkedIn : http://www.linkedin.com/in/rshockey101 > > http//www.sipforum.org > > > > > > > >> -----Original Message----- > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > >> Sent: Wednesday, December 23, 2009 10:24 PM > >> To: Paul E. Jones > >> Cc: 'Richard Shockey'; sipcore@ietf.org > >> Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-forum-fax- > >> problem-statement-00.txt > >> > >> Paul E. Jones wrote: > >> > Folks, > >> > > >> > I didn't see any comments regarding this draft. What is the > opinion > >> about > >> > publishing this as an informational RFC? > >> > >> I'm sympathetic to the fax problem. > >> > >> But I'm not sure what the intent of publishing this draft as an RFC > >> might be. It reads more like a liaison statement from FaxTG to IETF > >> informing IETF of what FaxTG is working on. We have a less costly > >> pulication route for LS available that might be a better > alternative > >> if > >> that's the case. > >> > >> If, however, you're leading towards another fax effort in IETF, > then > >> it > >> might make sense to take this draft along the individual > informational > >> route. > >> > >> -- > >> Dean > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From eburger@standardstrack.com Fri Dec 25 04:10:20 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DAD03A68D6 for ; Fri, 25 Dec 2009 04:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 JnDlp60DFrlC for ; Fri, 25 Dec 2009 04:10:17 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id C6B803A68EB for ; Fri, 25 Dec 2009 04:10:17 -0800 (PST) Received: from cpe-74-76-235-32.nycap.res.rr.com ([74.76.235.32] helo=[192.168.0.196]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1NO8zK-0002MX-1t; Fri, 25 Dec 2009 04:09:46 -0800 Message-Id: <780AED7C-FE17-450F-AA50-0A768CD0E7E4@standardstrack.com> From: Eric Burger To: Gonzalo Camarillo In-Reply-To: <4B3342C8.8090400@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 25 Dec 2009 07:09:55 -0500 References: <4B20DDCF.9000409@ericsson.com> <4B2A4717.5090100@ericsson.com> <4B3342C8.8090400@ericsson.com> X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: SIPCORE Subject: Re: [sipcore] WGLC draft-ietf-sipcore-info-events-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Dec 2009 12:10:20 -0000 I guess that means that after two years we're perfect? :-) On Dec 24, 2009, at 5:30 AM, Gonzalo Camarillo wrote: > Hi, > > this WGLC ends today and we have not received *any* comments. > > Cheers, > > Gonzalo > > Gonzalo Camarillo wrote: >> Hi, >> we are half-way through this WGLC and no comments have been >> received. You need to fire up! ;o) >> Cheers, >> Gonzalo >> Gonzalo Camarillo wrote: >>> Folks, >>> >>> Christer has submitted a new version of the INFO Events draft (see >>> email below) that is supposed to address all the comments received >>> so far. Since there have been extensive discussions on this topic >>> since the last time we WGLCed this draft, we are going to WGLC it >>> again. >>> >>> http://tools.ietf.org/html/draft-ietf-sipcore-info-events-03 >>> >>> So, please, have a look at this new version and let us know >>> whether or not you also think all comments have been addressed. Of >>> course, you are also welcome to submit new comments should you >>> have some. This WGLC will end on December 24th. >>> >>> Thanks, >>> >>> Gonzalo >>> SIPCORE co-chair >>> >>> -------- Original Message -------- >>> Subject: [sipcore] Draft new version: draft-ietf-sipcore-info- >>> events >>> Date: Wed, 2 Dec 2009 09:59:24 +0100 >>> From: Christer Holmberg >>> To: >>> >>> >>> >>> >>> Hi, >>> >>> I've submitted a new version of the info draft. Hopefully all >>> comments >>> and feedback have now been addressed. >>> >>> The biggest changes are: >>> >>> - Section 4.2: The usage of the Recv-Info header has been clarified, >>> some simple rules have been added, and there were some discussions >>> that >>> since the re-INVITE fallback issue also affects Recv-Info (if you >>> receive a Recv-Info in a 18x to a re-INVITE, and the re-INVITE then >>> fails) and that we need some words about that. The text now says >>> that IF >>> the request contains a Recv-Info header, the response must also >>> contain it. >>> >>> - Section 11.4: Contains new wording about the IANA process for >>> registering info packages, including the expert review etc. >>> >>> - Section 12: Additional examples have been added >>> >>> >>> Please note that I did NOT remove Recv-Info in PRACKs, since there >>> in my >>> opinion was no concensus to do so. >>> >>> >>> The draft can also be found at: >>> >>> _http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-info-events-03.txt_ >>> >>> >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From richard@shockey.us Sat Dec 26 09:29:46 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F1373A6919 for ; Sat, 26 Dec 2009 09:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.126 X-Spam-Level: X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_50=0.001, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6] 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 873hSxBhL+ET for ; Sat, 26 Dec 2009 09:29:46 -0800 (PST) Received: from outbound-mail-150.bluehost.com (outbound-mail-150.bluehost.com [67.222.38.40]) by core3.amsl.com (Postfix) with SMTP id 3EDE33A67BE for ; Sat, 26 Dec 2009 09:29:46 -0800 (PST) Received: (qmail 19382 invoked by uid 0); 26 Dec 2009 17:22:48 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy5.bluehost.com with SMTP; 26 Dec 2009 17:22:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=QwSK0ioW5xGEHMvZ7fW+NIO+zGQ/Zj2xqmUGsynyYvv440yZFx0RT7qrhVJYrbQNOzOkve6c1UUUyHbaUP4qv/s11n/fptercNi14I9ZvaI4cbj7gfFC6/CGgKnpkQFU; Received: from pool-96-241-233-91.washdc.fios.verizon.net ([96.241.233.91] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NOaLo-0003OP-7n; Sat, 26 Dec 2009 10:22:48 -0700 From: "Richard Shockey" To: "'Paul Kyzivat'" References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> <007301ca84b7$343dd6f0$9cb984d0$@us> <4B33D01C.9000006@cisco.com> In-Reply-To: <4B33D01C.9000006@cisco.com> Date: Sat, 26 Dec 2009 12:22:47 -0500 Message-ID: <014c01ca8650$0bab1eb0$23015c10$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqE2F9KlbLPPQV9SOqtJG2oa7TRbwBdHa8w Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.233.91 authed with richard+shockey.us} Cc: "'Paul E. Jones'" , dispatch@ietf.org, sipcore@ietf.org Subject: Re: [sipcore] [dispatch] FW: I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2009 17:29:46 -0000 Paul its certainly not off topic and a reasonable idea, but not practical for a number of reasons. What you describe is a classic T.37 mode for fax that the old IETF Fax WG documented in RFC 3965. The problem is "non repudiation". Fax has a certain legal standing and there is the requirement that there be actual documentation that a fax was sent by foo at such and such a time to bar and that the service provider or appropriate intermediary can provide the appropriate documentation of such a transaction. The problem is becoming more acute due to a variety of regulations, HIPPA and USA SOX, real estate etal which require the transmission of a signature as part of a legal filing and no, digital signatures have not proven to be successful even though they have legal standing in most countries now. Health care records cannot be sent by email for privacy reasons especially test results. Fax is pretty simple and it works for these class of transactions. As a result my contacts in the fax industry have noted a minor resurgence in fax machine and fax port sales. Some of us years ago thought using a variant of the Internet Print Protocol, based on HTTP for real time document transmission would have been a better idea but that went nowhere as well. The issue is there something in SIP signaling that can alert the first hop what this session really is such as ;USER=FAX that can help. I don't know, that is what needs to be investigated. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, December 24, 2009 3:34 PM > To: Richard Shockey > Cc: 'Dean Willis'; 'Paul E. Jones'; dispatch@ietf.org; > sipcore@ietf.org > Subject: Re: [dispatch] [sipcore] FW: I-D Action:draft-jones-sip- > forum-fax-problem-statement-00.txt > > I know this is a bit off topic, and doesn't alleviate the problem, but > has anybody ever proposed that an INVITE with offer for fax be > responded > to with a 3xx containing a mailto: URI? Or that ENUM for a fax > device > yield a mailto uri? > > Thanks, > Paul > > Richard Shockey wrote: > > The intent of the draft is to inform and clearly document to the > IETF SIP > > community that "there is a problem" with fax in SIP networks. In > fact, the > > problem seems to be much worse than some of us have originally > believed. > > > > I recently met with several folks from the international wholesale > carrier > > community (the i3forum ) who are reporting similar problems with fax > in > > their networks. These issues have the potential for delaying > significant SIP > > deployment in these networks, aka loss of sales for the supplier > community. > > (hint) > > > > Let us not forget that fax is a essential communications service in > the PSTN > > and that SIP networks MUST figure out ways to accommodate it. > > > > The SIP Forum Fax Task group is currently investigating the problems > > documented in the draft and taking additional input from all > parties. > > Everyone in the IETF SIP Community is free to participate in this > work. > > > > http://www.sipforum.org/content/view/310/252/ > > > > The goal is to develop a formal SIP Forum recommendation on what > steps can > > be taken to fix the problems. If it is determined that either SIP or > T.38 > > protocols needs to be modified in some way then a follow on document > ( ID or > > ITU Liaison letter ) will be developed suggesting alternatives for > > consideration. > > > > With that follow up document in mind I do think is important to > publish the > > fax problem statement as Informational. > > > > > > Richard Shockey > > Shockey Consulting > > Chairman of the Board of Directors SIP Forum > > PSTN Mobile: +1 703.593.2683 > > > > skype: rshockey101 > > LinkedIn : http://www.linkedin.com/in/rshockey101 > > http//www.sipforum.org > > > > > > > >> -----Original Message----- > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > >> Sent: Wednesday, December 23, 2009 10:24 PM > >> To: Paul E. Jones > >> Cc: 'Richard Shockey'; sipcore@ietf.org > >> Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-forum-fax- > >> problem-statement-00.txt > >> > >> Paul E. Jones wrote: > >> > Folks, > >> > > >> > I didn't see any comments regarding this draft. What is the > opinion > >> about > >> > publishing this as an informational RFC? > >> > >> I'm sympathetic to the fax problem. > >> > >> But I'm not sure what the intent of publishing this draft as an > RFC > >> might be. It reads more like a liaison statement from FaxTG to > IETF > >> informing IETF of what FaxTG is working on. We have a less costly > >> pulication route for LS available that might be a better > alternative > >> if > >> that's the case. > >> > >> If, however, you're leading towards another fax effort in IETF, > then > >> it > >> might make sense to take this draft along the individual > informational > >> route. > >> > >> -- > >> Dean > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > From paulej@packetizer.com Sat Dec 26 12:48:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ACFC3A6856 for ; Sat, 26 Dec 2009 12:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_15=0.6] 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 WNjCsstNPZNt for ; Sat, 26 Dec 2009 12:48:02 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 9796A3A6819 for ; Sat, 26 Dec 2009 12:48:02 -0800 (PST) Received: from berlin.arid.us (rrcs-98-101-146-143.midsouth.biz.rr.com [98.101.146.143]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id nBQKlUhc025286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 26 Dec 2009 15:47:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1261860457; bh=e1z7FCtQwectz0dJx3yK4ym98ivTY+gkISwBXcgKggU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=NJxb7r2JUIsYdcBp/fTGC6q3i0KdHEFVTby1u6OMb80qTWAlabspHNcOtMefT9GI+ OU6eB6lOjAlfJVSw46tbensMlZqDNOGNLxIERlMMPwD1KI7I37dg8U8gUNpBY7sDnD 4dsLbbm8dh1wrB3+sbRu1db1Xx+n+xYZRhoy4Ne0= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id nBQKlSb9017974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 26 Dec 2009 15:47:29 -0500 From: "Paul E. Jones" To: "'Richard Shockey'" , "'Paul Kyzivat'" References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> <007301ca84b7$343dd6f0$9cb984d0$@us> <4B33D01C.9000006@cisco.com> <014c01ca8650$0bab1eb0$23015c10$@us> In-Reply-To: <014c01ca8650$0bab1eb0$23015c10$@us> Date: Sat, 26 Dec 2009 15:47:16 -0500 Message-ID: <000301ca866c$9ca06df0$d5e149d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcqE2F9KlbLPPQV9SOqtJG2oa7TRbwBdHa8wAAWVLEA= Content-Language: en-us Cc: sipcore@ietf.org Subject: Re: [sipcore] [dispatch] I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2009 20:48:04 -0000 Richard, All of your points are correct, though I think the biggest reason why fax is important is that fax is simple and works. (Well, except that it does not work well on SIP networks, thus the reason we're discussing this.) The statement about legal standing of faxes is something I've often heard, but I've been curious about it. How could a fax document have any legal standing when I can so easily (and legally) forge the phone number I use to place the call? If "legal reasons" are the primary reason for using fax, I believe we could find a more modern solution to the need to transmit paper documents. I think it's important to solve the fax issues, because that's the technology people have in their hands right now. That said, I'll also tell you that I really, really like those new "scan / PDF / email" machines we have in our office. I can't say enough good words about those machines and I now use those (or just a simple scanner) when I need to sign and transmit legal documents. I've not used a fax machine in years. While there is a non-repudiation issue, that bothers me very little since I know someone could easily take my signature and insert it into a document and fax it. At the end of the day, issues can only be resolved by having a person swear under oath that he/she did or did not produce/sign/transmit some document. I think our society sometimes goes overboard with their perception of "security". People do not fully understand that most security measures are not "secure" but just assurance levels. As evidence to this misguided thought, I went to the bank one day this year to withdraw money. The teller did not like my signature because it did not match the one she had on file from 10 years ago. "Forget about the signature: it's not that important", I told her. She could not believe I would utter such a thing. As far as she was concerned, that signature meant everything in the world in terms of security. For me, though, my identification and me standing right before you has more weight. The lady who works by the front door of the bank has been there since I started banking there and she knows me by name, so I told the teller to ask her to come over and verify my identity. She refused. She put more trust in that signature than she would in my face, my identification card, and the word of an employee who knew me as decade-long customer. But, I bet she was just following some misguided directions in the name of "security". The point is that the tools we put into place only help to provide some level of assurances, and fax is relatively weak in that regard. It's even worse than my signature, since so many aspects of that document can be forged. (Heck, a pair of alligator clips are the only tools one needs to intercept PSTN calls, and it takes little more than that to alter the transmitted fax data.) So, I that we really have two issues: 1) We need to resolve the fax transmission issues in SIP networks, because fax is being used by many, many businesses and might even be the primary business tool for some businesses. How long will this be the norm? 2) We need to explore alternatives that can provide whatever reasonable assurances we can. It seems the market is setting the direction here (emailed PDF documents), as I am seeing this capability in relatively low-end machines at Office Depot now. Perhaps this is sufficient, as we now have tools like DKIM, S/MIME, etc. to assist with the assurance aspects. What Paul K. was suggesting, I guess, was to start migrating from (1) to (2) through the use of NAPTR records. I think it's a reasonable thing to consider, as I believe the world is moving to (2), anyway. I just doubt the world will move entirely to email or any other transmission system for a few years, so I don't want us to be distracted from the immediate problem at hand, else we'll be fighting this another 10 years. Paul > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Saturday, December 26, 2009 12:23 PM > To: 'Paul Kyzivat' > Cc: 'Dean Willis'; 'Paul E. Jones'; dispatch@ietf.org; sipcore@ietf.org > Subject: RE: [dispatch] [sipcore] FW: I-D Action:draft-jones-sip-forum- > fax-problem-statement-00.txt > > Paul its certainly not off topic and a reasonable idea, but not > practical > for a number of reasons. What you describe is a classic T.37 mode for > fax > that the old IETF Fax WG documented in RFC 3965. The problem is "non > repudiation". Fax has a certain legal standing and there is the > requirement > that there be actual documentation that a fax was sent by foo at such > and > such a time to bar and that the service provider or appropriate > intermediary > can provide the appropriate documentation of such a transaction. > > The problem is becoming more acute due to a variety of regulations, > HIPPA > and USA SOX, real estate etal which require the transmission of a > signature > as part of a legal filing and no, digital signatures have not proven to > be > successful even though they have legal standing in most countries now. > Health care records cannot be sent by email for privacy reasons > especially > test results. > > Fax is pretty simple and it works for these class of transactions. As a > result my contacts in the fax industry have noted a minor resurgence in > fax > machine and fax port sales. > > Some of us years ago thought using a variant of the Internet Print > Protocol, > based on HTTP for real time document transmission would have been a > better > idea but that went nowhere as well. > > The issue is there something in SIP signaling that can alert the first > hop > what this session really is such as ;USER=FAX that can help. I don't > know, > that is what needs to be investigated. > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Thursday, December 24, 2009 3:34 PM > > To: Richard Shockey > > Cc: 'Dean Willis'; 'Paul E. Jones'; dispatch@ietf.org; > > sipcore@ietf.org > > Subject: Re: [dispatch] [sipcore] FW: I-D Action:draft-jones-sip- > > forum-fax-problem-statement-00.txt > > > > I know this is a bit off topic, and doesn't alleviate the problem, > but > > has anybody ever proposed that an INVITE with offer for fax be > > responded > > to with a 3xx containing a mailto: URI? Or that ENUM for a fax > > device > > yield a mailto uri? > > > > Thanks, > > Paul > > > > Richard Shockey wrote: > > > The intent of the draft is to inform and clearly document to the > > IETF SIP > > > community that "there is a problem" with fax in SIP networks. In > > fact, the > > > problem seems to be much worse than some of us have originally > > believed. > > > > > > I recently met with several folks from the international wholesale > > carrier > > > community (the i3forum ) who are reporting similar problems with > fax > > in > > > their networks. These issues have the potential for delaying > > significant SIP > > > deployment in these networks, aka loss of sales for the supplier > > community. > > > (hint) > > > > > > Let us not forget that fax is a essential communications service > in > > the PSTN > > > and that SIP networks MUST figure out ways to accommodate it. > > > > > > The SIP Forum Fax Task group is currently investigating the > problems > > > documented in the draft and taking additional input from all > > parties. > > > Everyone in the IETF SIP Community is free to participate in this > > work. > > > > > > http://www.sipforum.org/content/view/310/252/ > > > > > > The goal is to develop a formal SIP Forum recommendation on what > > steps can > > > be taken to fix the problems. If it is determined that either SIP > or > > T.38 > > > protocols needs to be modified in some way then a follow on > document > > ( ID or > > > ITU Liaison letter ) will be developed suggesting alternatives for > > > consideration. > > > > > > With that follow up document in mind I do think is important to > > publish the > > > fax problem statement as Informational. > > > > > > > > > Richard Shockey > > > Shockey Consulting > > > Chairman of the Board of Directors SIP Forum > > > PSTN Mobile: +1 703.593.2683 > > > > > > skype: rshockey101 > > > LinkedIn : http://www.linkedin.com/in/rshockey101 > > > http//www.sipforum.org > > > > > > > > > > > >> -----Original Message----- > > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > > >> Sent: Wednesday, December 23, 2009 10:24 PM > > >> To: Paul E. Jones > > >> Cc: 'Richard Shockey'; sipcore@ietf.org > > >> Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-forum-fax- > > >> problem-statement-00.txt > > >> > > >> Paul E. Jones wrote: > > >> > Folks, > > >> > > > >> > I didn't see any comments regarding this draft. What is the > > opinion > > >> about > > >> > publishing this as an informational RFC? > > >> > > >> I'm sympathetic to the fax problem. > > >> > > >> But I'm not sure what the intent of publishing this draft as an > > RFC > > >> might be. It reads more like a liaison statement from FaxTG to > > IETF > > >> informing IETF of what FaxTG is working on. We have a less > costly > > >> pulication route for LS available that might be a better > > alternative > > >> if > > >> that's the case. > > >> > > >> If, however, you're leading towards another fax effort in IETF, > > then > > >> it > > >> might make sense to take this draft along the individual > > informational > > >> route. > > >> > > >> -- > > >> Dean > > > > > > > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > From richard@shockey.us Sun Dec 27 12:58:11 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB4E43A68B8 for ; Sun, 27 Dec 2009 12:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.423 X-Spam-Level: X-Spam-Status: No, score=-0.423 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] 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 kka15Wuu-Jds for ; Sun, 27 Dec 2009 12:58:09 -0800 (PST) Received: from outbound-mail-37.bluehost.com (outbound-mail-37.bluehost.com [69.89.20.191]) by core3.amsl.com (Postfix) with SMTP id 6893F3A6918 for ; Sun, 27 Dec 2009 12:58:09 -0800 (PST) Received: (qmail 2495 invoked by uid 0); 27 Dec 2009 20:57:50 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy2.bluehost.com with SMTP; 27 Dec 2009 20:57:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=QJTI9Ot3cyFWehhWAdZ+gzVliLfoFg78hmuyigBjxfVGN0gAa02nbU1CsPohbbAG2B6aVnbyp1+8zHAw2WkzHUQR+VIi2f4HMSv5a5MGCIsvGa+ClCuSMC2HU8O0HBSs; Received: from pool-96-241-233-91.washdc.fios.verizon.net ([96.241.233.91] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NP0BR-0005J6-TF; Sun, 27 Dec 2009 13:57:50 -0700 From: "Richard Shockey" To: "'Paul E. Jones'" , "'Paul Kyzivat'" References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> <007301ca84b7$343dd6f0$9cb984d0$@us> <4B33D01C.9000006@cisco.com> <014c01ca8650$0bab1eb0$23015c10$@us> <000301ca866c$9ca06df0$d5e149d0$@com> In-Reply-To: <000301ca866c$9ca06df0$d5e149d0$@com> Date: Sun, 27 Dec 2009 15:57:43 -0500 Message-ID: <008101ca8737$3d1f1a40$b75d4ec0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqE2F9KlbLPPQV9SOqtJG2oa7TRbwBdHa8wAAWVLEAACJN2YA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.233.91 authed with richard+shockey.us} Cc: sipcore@ietf.org Subject: Re: [sipcore] [dispatch] I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Dec 2009 20:58:11 -0000 > Richard, > > All of your points are correct, though I think the biggest reason why > fax is important is that fax is simple and works. (Well, except that it does > not work well on SIP networks, thus the reason we're discussing this.) Exactly .. its an essential PSTN communications service that SIP networks must be able to support. Its clean simple and its works ..just like phone numbers. > The statement about legal standing of faxes is something I've often > heard, but I've been curious about it. How could a fax document have any > legal standing when I can so easily (and legally) forge the phone number I > use to place the call? If "legal reasons" are the primary reason for using > fax, I believe we could find a more modern solution to the need to transmit > paper documents. I know .. but it's the 3rd party validation of the transaction through carrier networks that carries some of the legal weight. Though with some checking I found out that in the US because of the Uniform Electronic Clear Transactions Act of 1999, and various legislature passed since then, contracts are no longer limited to pristine original copies on clean, white paper. Fax is preferred to email for health care transactions due the perceived notion that fax is more "secure" a point to point communication without intermediaries. In fact, according to the UETA, email and fax contracts are now legally binding. This means that any agreement you make through any medium - electronic or otherwise - will hold up in court. As for alternative real time transport I had this argument 15 years ago in the FAX WG and as I mentioned HTTP would be much more useful transport for documents but alas for reasons I don't need to go into that did not happen. > > I think it's important to solve the fax issues, because that's the > technology people have in their hands right now. That said, I'll also > tell you that I really, really like those new "scan / PDF / email" machines > we have in our office. I can't say enough good words about those > machines and I now use those (or just a simple scanner) when I need to sign and > transmit legal documents. Yep I worked on one of the originals as a consultant years ago ..HP's Digital Sender. Great device still have one in my office gathering dust. > I think our society sometimes goes overboard with their perception of > "security". People do not fully understand that most security > measures are not "secure" but just assurance levels. As evidence to this misguided > thought, I went to the bank one day this year to withdraw money. The > teller did not like my signature because it did not match the one she had on > file from 10 years ago. "Forget about the signature: it's not that > important", I> told her. She could not believe I would utter such a thing. As far > as she was concerned, that signature meant everything in the world in terms > of security. Yep that the key .. > > So, I that we really have two issues: > 1) We need to resolve the fax transmission issues in SIP networks, > because fax is being used by many, many businesses and might even be the > primary business tool for some businesses. How long will this be the norm? Probably till we're dead. > 2) We need to explore alternatives that can provide whatever > reasonable> assurances we can. It seems the market is setting the direction here > (emailed PDF documents), as I am seeing this capability in relatively > low-end machines at Office Depot now. Perhaps this is sufficient, as > we now have tools like DKIM, S/MIME, etc. to assist with the assurance > aspects. We're geeks ..we think that is the direction the market is going. The reality of carrier networks is very different and don't get me started on DKIM AND S/MIME as solutions. > > What Paul K. was suggesting, I guess, was to start migrating from (1) > to (2) through the use of NAPTR records. You want a lecture on why RFC 3761 [ENUM] in e164.arpa failed? I regularly give lectures on that subject. To Paul's point it would be trivial but even private carrier enum systems have their deployment issues. I think it's a reasonable thing to > consider, as I believe the world is moving to (2), anyway. I just > doubt the world will move entirely to email or any other transmission system for > a few years, so I don't want us to be distracted from the immediate problem > at hand, else we'll be fighting this another 10 years. To your point the problem at hand is that SIP carrier networks still need to handle T.30 fax and ultimately they are paying a lot of our salaries. I thing the FAX task group in the SIP Forum has made a excellent start but they still need input. > > Paul > > > -----Original Message----- > > From: Richard Shockey [mailto:richard@shockey.us] > > Sent: Saturday, December 26, 2009 12:23 PM > > To: 'Paul Kyzivat' > > Cc: 'Dean Willis'; 'Paul E. Jones'; dispatch@ietf.org; > sipcore@ietf.org > > Subject: RE: [dispatch] [sipcore] FW: I-D Action:draft-jones-sip- > forum- > > fax-problem-statement-00.txt > > > > Paul its certainly not off topic and a reasonable idea, but not > > practical > > for a number of reasons. What you describe is a classic T.37 mode > for > > fax > > that the old IETF Fax WG documented in RFC 3965. The problem is "non > > repudiation". Fax has a certain legal standing and there is the > > requirement > > that there be actual documentation that a fax was sent by foo at > such > > and > > such a time to bar and that the service provider or appropriate > > intermediary > > can provide the appropriate documentation of such a transaction. > > > > The problem is becoming more acute due to a variety of regulations, > > HIPPA > > and USA SOX, real estate etal which require the transmission of a > > signature > > as part of a legal filing and no, digital signatures have not proven > to > > be > > successful even though they have legal standing in most countries > now. > > Health care records cannot be sent by email for privacy reasons > > especially > > test results. > > > > Fax is pretty simple and it works for these class of transactions. > As a > > result my contacts in the fax industry have noted a minor resurgence > in > > fax > > machine and fax port sales. > > > > Some of us years ago thought using a variant of the Internet Print > > Protocol, > > based on HTTP for real time document transmission would have been a > > better > > idea but that went nowhere as well. > > > > The issue is there something in SIP signaling that can alert the > first > > hop > > what this session really is such as ;USER=FAX that can help. I don't > > know, > > that is what needs to be investigated. > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: Thursday, December 24, 2009 3:34 PM > > > To: Richard Shockey > > > Cc: 'Dean Willis'; 'Paul E. Jones'; dispatch@ietf.org; > > > sipcore@ietf.org > > > Subject: Re: [dispatch] [sipcore] FW: I-D Action:draft-jones-sip- > > > forum-fax-problem-statement-00.txt > > > > > > I know this is a bit off topic, and doesn't alleviate the > problem, > > but > > > has anybody ever proposed that an INVITE with offer for fax be > > > responded > > > to with a 3xx containing a mailto: URI? Or that ENUM for a fax > > > device > > > yield a mailto uri? > > > > > > Thanks, > > > Paul > > > > > > > > > > > Richard Shockey > > > > Shockey Consulting > > > > Chairman of the Board of Directors SIP Forum > > > > PSTN Mobile: +1 703.593.2683 > > > > > > > > skype: rshockey101 > > > > LinkedIn : http://www.linkedin.com/in/rshockey101 > > > > http//www.sipforum.org From pkyzivat@cisco.com Mon Dec 28 10:32:07 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A87E3A6920 for ; Mon, 28 Dec 2009 10:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.386 X-Spam-Level: X-Spam-Status: No, score=-5.386 tagged_above=-999 required=5 tests=[AWL=-1.387, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] 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 n31xcS1BgjVG for ; Mon, 28 Dec 2009 10:32:05 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E33103A697B for ; Mon, 28 Dec 2009 10:32:04 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAFAPeHOEtAZnwN/2dsb2JhbACYeagPiQ0JizqCJgUfgTE4BIMY X-IronPort-AV: E=Sophos;i="4.47,463,1257120000"; d="scan'208";a="77012459" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 28 Dec 2009 18:31:42 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nBSIVgK0025464; Mon, 28 Dec 2009 18:31:42 GMT Received: from xfe-rtp-211.amer.cisco.com ([64.102.31.113]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Dec 2009 13:31:42 -0500 Received: from [10.86.252.202] ([10.86.252.202]) by xfe-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Dec 2009 13:31:42 -0500 Message-ID: <4B38F98D.5030209@cisco.com> Date: Mon, 28 Dec 2009 13:31:41 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Richard Shockey References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> <007301ca84b7$343dd6f0$9cb984d0$@us> <4B33D01C.9000006@cisco.com> <014c01ca8650$0bab1eb0$23015c10$@us> <000301ca866c$9ca06df0$d5e149d0$@com> <008101ca8737$3d1f1a40$b75d4ec0$@us> In-Reply-To: <008101ca8737$3d1f1a40$b75d4ec0$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Dec 2009 18:31:42.0399 (UTC) FILETIME=[00815CF0:01CA87EC] Cc: "'Paul E. Jones'" , sipcore@ietf.org Subject: Re: [sipcore] [dispatch] I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 18:32:07 -0000 I'm not going to pretend that I know the issues here. Some of them seem to be irrational, but that doesn't make them any less real. (Surely nobody considers government and law making rational.) What I had in mind was using email to transmit the same bits that would otherwise be transmitted via T.38. That does involve *different* intermediaries, but probably not *more* of them than transmitting via sip. It would be another optimization above that to transmit the doc in a more symbolic encoding. I suppose the real issue is *which* intermediaries, and who is in a position to vouch for their security. It they are all controlled by same service providers it wouldn't really matter, would it? Suppose we were considering the case of traditional fax machines on both ends, connected via traditional telephony infrastructure to gateways that then communicate via sip. In such a case, would it really matter if the gateways decided to transmit fax using email rather than sip? Thanks, Paul Richard Shockey wrote: >> Richard, >> >> All of your points are correct, though I think the biggest reason why >> fax is important is that fax is simple and works. (Well, except that it > does >> not work well on SIP networks, thus the reason we're discussing this.) > > Exactly .. its an essential PSTN communications service that SIP networks > must be able to support. Its clean simple and its works ..just like phone > numbers. > > >> The statement about legal standing of faxes is something I've often >> heard, but I've been curious about it. How could a fax document have > any >> legal standing when I can so easily (and legally) forge the phone number > I >> use to place the call? If "legal reasons" are the primary reason for > using >> fax, I believe we could find a more modern solution to the need to > transmit >> paper documents. > > I know .. but it's the 3rd party validation of the transaction through > carrier networks that carries some of the legal weight. Though with some > checking I found out that in the US because of the Uniform Electronic Clear > Transactions Act of 1999, and various legislature passed since then, > contracts are no longer limited to pristine original copies on clean, white > paper. Fax is preferred to email for health care transactions due the > perceived notion that fax is more "secure" a point to point communication > without intermediaries. > > In fact, according to the UETA, email and fax contracts are now legally > binding. This means that any agreement you make through any medium - > electronic or otherwise - will hold up in court. As for alternative real > time transport I had this argument 15 years ago in the FAX WG and as I > mentioned HTTP would be much more useful transport for documents but alas > for reasons I don't need to go into that did not happen. > >> >> I think it's important to solve the fax issues, because that's the >> technology people have in their hands right now. That said, I'll also >> tell you that I really, really like those new "scan / PDF / email" > machines >> we have in our office. I can't say enough good words about those >> machines and I now use those (or just a simple scanner) when I need to > sign and >> transmit legal documents. > > Yep I worked on one of the originals as a consultant years ago ..HP's > Digital Sender. Great device still have one in my office gathering dust. > > >> I think our society sometimes goes overboard with their perception of >> "security". People do not fully understand that most security >> measures are not "secure" but just assurance levels. As evidence to > this misguided >> thought, I went to the bank one day this year to withdraw money. The >> teller did not like my signature because it did not match the one she > had on >> file from 10 years ago. "Forget about the signature: it's not that >> important", I> told her. She could not believe I would utter such a > thing. As far >> as she was concerned, that signature meant everything in the world in > terms >> of security. > > Yep that the key .. > >> >> So, I that we really have two issues: >> 1) We need to resolve the fax transmission issues in SIP networks, >> because fax is being used by many, many businesses and might even be the >> primary business tool for some businesses. How long will this be the > norm? > > Probably till we're dead. > > >> 2) We need to explore alternatives that can provide whatever >> reasonable> assurances we can. It seems the market is setting the > direction here >> (emailed PDF documents), as I am seeing this capability in relatively >> low-end machines at Office Depot now. Perhaps this is sufficient, as >> we now have tools like DKIM, S/MIME, etc. to assist with the assurance >> aspects. > > > We're geeks ..we think that is the direction the market is going. The > reality of carrier networks is very different and don't get me started on > DKIM AND S/MIME as solutions. > >> >> What Paul K. was suggesting, I guess, was to start migrating from (1) >> to (2) through the use of NAPTR records. > > You want a lecture on why RFC 3761 [ENUM] in e164.arpa failed? I regularly > give lectures on that subject. To Paul's point it would be trivial but even > private carrier enum systems have their deployment issues. > > I think it's a reasonable thing to >> consider, as I believe the world is moving to (2), anyway. I just >> doubt the world will move entirely to email or any other transmission > system for >> a few years, so I don't want us to be distracted from the immediate > problem >> at hand, else we'll be fighting this another 10 years. > > > To your point the problem at hand is that SIP carrier networks still need to > handle T.30 fax and ultimately they are paying a lot of our salaries. I > thing the FAX task group in the SIP Forum has made a excellent start but > they still need input. > >> >> Paul >> >> > -----Original Message----- >> > From: Richard Shockey [mailto:richard@shockey.us] >> > Sent: Saturday, December 26, 2009 12:23 PM >> > To: 'Paul Kyzivat' >> > Cc: 'Dean Willis'; 'Paul E. Jones'; dispatch@ietf.org; >> sipcore@ietf.org >> > Subject: RE: [dispatch] [sipcore] FW: I-D Action:draft-jones-sip- >> forum- >> > fax-problem-statement-00.txt >> > >> > Paul its certainly not off topic and a reasonable idea, but not >> > practical >> > for a number of reasons. What you describe is a classic T.37 mode >> for >> > fax >> > that the old IETF Fax WG documented in RFC 3965. The problem is "non >> > repudiation". Fax has a certain legal standing and there is the >> > requirement >> > that there be actual documentation that a fax was sent by foo at >> such >> > and >> > such a time to bar and that the service provider or appropriate >> > intermediary >> > can provide the appropriate documentation of such a transaction. >> > >> > The problem is becoming more acute due to a variety of regulations, >> > HIPPA >> > and USA SOX, real estate etal which require the transmission of a >> > signature >> > as part of a legal filing and no, digital signatures have not proven >> to >> > be >> > successful even though they have legal standing in most countries >> now. >> > Health care records cannot be sent by email for privacy reasons >> > especially >> > test results. >> > >> > Fax is pretty simple and it works for these class of transactions. >> As a >> > result my contacts in the fax industry have noted a minor resurgence >> in >> > fax >> > machine and fax port sales. >> > >> > Some of us years ago thought using a variant of the Internet Print >> > Protocol, >> > based on HTTP for real time document transmission would have been a >> > better >> > idea but that went nowhere as well. >> > >> > The issue is there something in SIP signaling that can alert the >> first >> > hop >> > what this session really is such as ;USER=FAX that can help. I don't >> > know, >> > that is what needs to be investigated. >> > >> > > -----Original Message----- >> > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> > > Sent: Thursday, December 24, 2009 3:34 PM >> > > To: Richard Shockey >> > > Cc: 'Dean Willis'; 'Paul E. Jones'; dispatch@ietf.org; >> > > sipcore@ietf.org >> > > Subject: Re: [dispatch] [sipcore] FW: I-D Action:draft-jones-sip- >> > > forum-fax-problem-statement-00.txt >> > > >> > > I know this is a bit off topic, and doesn't alleviate the >> problem, >> > but >> > > has anybody ever proposed that an INVITE with offer for fax be >> > > responded >> > > to with a 3xx containing a mailto: URI? Or that ENUM for a fax >> > > device >> > > yield a mailto uri? >> > > >> > > Thanks, >> > > Paul >> > > >> > > > >> > > > Richard Shockey >> > > > Shockey Consulting >> > > > Chairman of the Board of Directors SIP Forum >> > > > PSTN Mobile: +1 703.593.2683 >> > > > >> > > > skype: rshockey101 >> > > > LinkedIn : http://www.linkedin.com/in/rshockey101 >> > > > http//www.sipforum.org > > > From dean.willis@softarmor.com Mon Dec 28 23:22:54 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5CE03A66B4; Mon, 28 Dec 2009 23:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.520, 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 BOId-Y5QtpUE; Mon, 28 Dec 2009 23:22:53 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1CCBB3A67A8; Mon, 28 Dec 2009 23:22:53 -0800 (PST) Received: from [192.168.2.103] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id nBT7MUuL024126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Dec 2009 01:22:32 -0600 Message-ID: <4B39AE2C.9090304@softarmor.com> Date: Tue, 29 Dec 2009 01:22:20 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> <007301ca84b7$343dd6f0$9cb984d0$@us> <4B33D01C.9000006@cisco.com> In-Reply-To: <4B33D01C.9000006@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Paul E. Jones'" , dispatch@ietf.org, sipcore@ietf.org Subject: Re: [sipcore] [dispatch] FW: I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2009 07:22:54 -0000 Paul Kyzivat wrote: > I know this is a bit off topic, and doesn't alleviate the problem, but > has anybody ever proposed that an INVITE with offer for fax be responded > to with a 3xx containing a mailto: URI? Or that ENUM for a fax device > yield a mailto uri? I was going to say "redirect to T.37, since real-time fax over VoIP is just a bad idea" but Paul beat me to it. Seriously: fax over IP really only works when the real-time conversion is done close to the edge of the IP network. and the core transit is store-and-forward/ The close to the consumer edge, the better. Trying to retrofit the timing equirements of fax onto RTP is an exercise in futility for those who don't understand the concept of lossy networks. -- Dean From richard@shockey.us Wed Dec 30 14:18:55 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BA263A6968 for ; Wed, 30 Dec 2009 14:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.385 X-Spam-Level: X-Spam-Status: No, score=-0.385 tagged_above=-999 required=5 tests=[AWL=-0.720, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] 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 MXmWjxUx3aCB for ; Wed, 30 Dec 2009 14:18:54 -0800 (PST) Received: from outbound-mail-34.bluehost.com (outbound-mail-34.bluehost.com [69.89.18.154]) by core3.amsl.com (Postfix) with SMTP id A26173A695B for ; Wed, 30 Dec 2009 14:18:54 -0800 (PST) Received: (qmail 9805 invoked by uid 0); 30 Dec 2009 22:18:34 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy2.bluehost.com with SMTP; 30 Dec 2009 22:18:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:Reply-To:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:List-Unsubscribe:Thread-Index:Content-Language:List-Help:List-Subscribe:X-Identified-User; b=S4rKmyGalbiXO5qOBgYQFFSj4N41MMiyub/Ue3L3uVzl6IBl7FcZJVgdFaoRjisQMRFrraPqd+BiM3f0uPryasq8RL0J2Qe4SnsJOB23btOL2g1X7EtQHA7D1jRcQvHR; Received: from pool-96-241-233-91.washdc.fios.verizon.net ([96.241.233.91] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NQ6sE-00009M-2I for sipcore@ietf.org; Wed, 30 Dec 2009 15:18:34 -0700 From: "Richard Shockey" To: References: <200912290750.nBT7o2og018883@lserv-m02.elist.aol.com> <200912300053.nBU0r1Lb018513@lserv-m02.elist.aol.com> In-Reply-To: <200912300053.nBU0r1Lb018513@lserv-m02.elist.aol.com> Date: Wed, 30 Dec 2009 17:18:27 -0500 Message-ID: <00e801ca899e$035ec120$0a1c4360$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqIW4qB/DMwqtudQG2cKCoXYXpjyQAimmbgACa/RjA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.233.91 authed with richard+shockey.us} Subject: [sipcore] FYI: ATT to FCC POTS is Dead.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Telecom Regulation & the Internet List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 22:18:55 -0000 http://gigaom.com/2009/12/30/att-to-fcc-let-my-landlines-go/ Nice work folks.. Happy New Year!