From marc.lampo@eurid.eu Mon Aug 1 07:42:57 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6F911E80F1 for ; Mon, 1 Aug 2011 07:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.943 X-Spam-Level: X-Spam-Status: No, score=-7.943 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0gefNRNbDSS for ; Mon, 1 Aug 2011 07:42:56 -0700 (PDT) Received: from barra.eurid.eu (mx.eurid.eu [212.190.206.103]) by ietfa.amsl.com (Postfix) with ESMTP id E3CE011E80ED for ; Mon, 1 Aug 2011 07:42:52 -0700 (PDT) X-ASG-Debug-ID: 1312209777-0369494a3651ed0001-qAklQb Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id g1ky28vMrJcn19Sn; Mon, 01 Aug 2011 16:42:57 +0200 (CEST) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 07144E4071; Mon, 1 Aug 2011 16:42:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQbvCeH5DBeI; Mon, 1 Aug 2011 16:42:56 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id B08CDE4050; Mon, 1 Aug 2011 16:42:56 +0200 (CEST) From: "Marc Lampo" To: Date: Mon, 1 Aug 2011 16:42:56 +0200 (CEST) X-ASG-Orig-Subj: draft-sandbakken-dispatch-bfcp-udp - TCP "reliable delivery" Message-ID: <073001cc5059$5070e870$f152b950$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: AcxQWVAZo+mNyu5TQ8WTQb9OhGM1hQ== Content-Language: en-za X-Originating-IP: [172.20.1.97] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1312209777 X-Barracuda-URL: http://172.20.1.190:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu X-Mailman-Approved-At: Mon, 01 Aug 2011 10:28:46 -0700 Subject: [dispatch] draft-sandbakken-dispatch-bfcp-udp - TCP "reliable delivery" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 14:42:57 -0000 Last week I had a very brief talk with the presenter of this draft, promising to post a follow-up on the list. In 4.9.1. the present document states : "TCP provides an in-order reliable delivery of a stream of bytes." This statement is kind of ambiguous, depending if one looks from the senders or receivers perspective ! The point is that TCP does not guarantee that data sent, by sending application, will actually make it, to the receiving application. The only thing that is guaranteed is that "if a byte is received by an application, it is in-order and correct." (with emphasis on the first *if* !) This observation is not so important for this particular draft, but : because UDP does not reliably deliver data, some protocol changes, to BFCP, are proposed in this draft. (like making explicit ACK messages mandatory, introduction of timers). >From that "introduction" of these protocol changes, I deduce that these are not present when the transport protocol is layer 4. And *that* is weird ! There are certainly conditions in which TCP will fail to deliver, and explicit "ACK" (in layers 5+, so to say) and time-out protection are required for reliable operation. If missing, I'd say this protocol is running in quite "protected" environments indeed. Kind regards, Marc Lampo Security Officer       EURid     Woluwelaan 150         1831 Diegem - Belgium     marc.lampo@eurid.eu     http://www.eurid.eu From gonzalo.camarillo@ericsson.com Mon Aug 8 03:36:52 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E846221F8ACA for ; Mon, 8 Aug 2011 03:36:52 -0700 (PDT) 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.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfcvdgyoSzX9 for ; Mon, 8 Aug 2011 03:36:52 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id CB2A621F8AC9 for ; Mon, 8 Aug 2011 03:36:51 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-fd-4e3fbc5ca87d Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C3.CA.20773.C5CBF3E4; Mon, 8 Aug 2011 12:37:16 +0200 (CEST) Received: from [131.160.36.41] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Mon, 8 Aug 2011 12:37:16 +0200 Message-ID: <4E3FBC5B.2090103@ericsson.com> Date: Mon, 8 Aug 2011 13:37:15 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Marc Lampo References: <073001cc5059$5070e870$f152b950$@lampo@eurid.eu> In-Reply-To: <073001cc5059$5070e870$f152b950$@lampo@eurid.eu> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-sandbakken-dispatch-bfcp-udp - TCP "reliable delivery" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 10:36:53 -0000 Hi, yes, that is a good point. Providing application-level ack messages for reliability has the effect of making those acks visible at the application layer (instead of being only visible at the transport layer, which is the case when TCP is used). I agree the draft needs to discuss this. When we originally designed BFCP, we chose not to provide application-level acks for some messages in order to be able to use BFCP in environments with tight bandwidth and delay requirements (at that time, the push to talk over cellular service was the main example of those environments). Cheers, Gonzalo On 01/08/2011 5:42 PM, Marc Lampo wrote: > Last week I had a very brief talk with the presenter of this draft, > promising to post a follow-up on the list. > > In 4.9.1. the present document states : > "TCP provides an in-order reliable delivery of a stream of bytes." > > This statement is kind of ambiguous, > depending if one looks from the senders or receivers perspective ! > > > The point is that TCP does not guarantee that data sent, by sending > application, > will actually make it, to the receiving application. > The only thing that is guaranteed is that > "if a byte is received by an application, > it is in-order and correct." (with emphasis on the first *if* !) > > > This observation is not so important for this particular draft, > but : > because UDP does not reliably deliver data, > some protocol changes, to BFCP, are proposed in this draft. > (like making explicit ACK messages mandatory, > introduction of timers). > >>From that "introduction" of these protocol changes, > I deduce that these are not present when the transport protocol is layer > 4. > And *that* is weird ! > There are certainly conditions in which TCP will fail to deliver, > and explicit "ACK" (in layers 5+, so to say) and time-out protection > are required for reliable operation. > If missing, I'd say this protocol is running in quite "protected" > environments indeed. > > > Kind regards, > > > Marc Lampo > Security Officer > > EURid > Woluwelaan 150 > 1831 Diegem - Belgium > marc.lampo@eurid.eu > http://www.eurid.eu > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From fluffy@cisco.com Tue Aug 9 07:43:33 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356A421F8A58 for ; Tue, 9 Aug 2011 07:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.543 X-Spam-Level: X-Spam-Status: No, score=-103.543 tagged_above=-999 required=5 tests=[AWL=-0.944, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lvM1UMERlLj for ; Tue, 9 Aug 2011 07:43:32 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 87B4D21F89BA for ; Tue, 9 Aug 2011 07:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2582; q=dns/txt; s=iport; t=1312901041; x=1314110641; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=l7cCNfni7SNKEeJoTRt6sAt2ijqJqgyXNRDhZx5xb/s=; b=ZH4RtsrRhXhxtl/kz1gIyZpgD7QtoMkiNpJv/ZJNn4WAf+MlruIPRbjq CidBuJ4gYHEv3E9UA6xPaJgCq6mQUj7Im9MEgAQGR8rbWHiejvEiVH2k2 /N/e2OsYiFdGTiASx4enetpGIUWm05Ml1JZmTGTJZp+w7JS23C8wW8NPM Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAGlGQU6rRDoG/2dsb2JhbABCpzl3gVkBJzRKfxMipgGBIwGeeIVnXwSHXIsphQmMAg X-IronPort-AV: E=Sophos;i="4.67,343,1309737600"; d="scan'208";a="11306337" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-6.cisco.com with ESMTP; 09 Aug 2011 14:44:01 +0000 Received: from [10.21.71.208] ([10.21.71.208]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p79Ei04p017267 for ; Tue, 9 Aug 2011 14:44:00 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Aug 2011 07:44:00 -0700 Message-Id: <382883C8-A431-4511-861F-FA7E5CE0DD84@cisco.com> To: DISPATCH list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dispatch] Proposed WG Charter for UDP based BFCP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 14:43:33 -0000 At the last IETF there was a strong hum from the folks in the room to do = a UDP based version of BFCP. To get moving on seeing what we have = consensus on, I have written up a draft charter as strawman to start = getting some comments. Can people have a look at this, and if you think = parts of need changes or additions, send proposed text. Thanks, Cullen Working Group Name: =20 Chairs: TBD Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: TBD Mailing Lists: General Discussion: TBD To Subscribe: TBD Archive: TBD The BFCPBIS working group is charted to specify a revision of BFCP (RFC = 4582) to support using both TCP and UDP as transports. The current = version of BFCP only supports TCP but when both endpoints are behind = NATs or firewalls, this has a lower success rate than using the ICE = techniques with an UDP based transport for BFCP. The need for video = endpoints to work in these types of environments is driving a strong = desire to support a UDP based transport as well as TCP.=20 This WG will create a revision of RFC 4582 which adds optional support = for UDP to BFCP. The security when using UDP will be based on DTLS. The = updated protocol will use an existing approach to congestion safety and = be TCP friendly as well as congestion safe. It is likely that the WG = will choose to use a stop and wait with a single outstanding transaction = approach to congestion safety and reliability. The WG will provide a way = to deal with reliable response deliver for the case where it is needed. = The WG will research the size of messages used and decide what if = fragmenting a request or response over multiple UDP packets is required. = The new protocol will be backwards compatible with RFC 4582 when used in = TCP mode.=20 The BFCPBIS WG will coordinate closely with the MMUSIC WG to create a = revision of RFC 4583 specifying how BFCP is signaled in SDP so that it = supports UDP as well as TCP transports. This WG would ask the MMUSIC WG = to add a milestone to create a revisions of RFC 4583 to address = signaling the use of UDP in SDP. The WG will coordinate with = International Multimedia Telecommunications Consortium (IMTC) and other = industry forums.=20 Milestones: April 2012 Draft revision of RFC 4582 to IESG=20 From eckelcu@cisco.com Fri Aug 12 13:32:27 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1C821F8686 for ; Fri, 12 Aug 2011 13:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.84 X-Spam-Level: X-Spam-Status: No, score=-2.84 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFEkUAenslPX for ; Fri, 12 Aug 2011 13:32:26 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id B744721F859E for ; Fri, 12 Aug 2011 13:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=3201; q=dns/txt; s=iport; t=1313181185; x=1314390785; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=+qJu1F2rR0ZYSxnGm9C2aMEg2+LszuLVo4Z56ZlZ1x4=; b=d+/hmxdWnbFW0oKXm4dEz+hXKDWeR1IAJK2ZYwiA82/Kgq7TiAFIC/bn kXVD3+q/xgdrazV5Y1PGrB5wKv1waE/pYZw7M5nq5n6WIycyNDpjodi2b RIgMXGVwyofiyD0pnVlasqvgjVyDO8GnFTuI8RmRNxGclIOONpwf5CTJu Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYAAP+MRU6rRDoH/2dsb2JhbABBmCyPTXeBQAEBAQEDAQEBDwEdCjQXBAIBCBEEAQELAgQXAQYBJh8JCAEBBAESCBqHUZtqAZ53hWhfBIdfkEaLfA X-IronPort-AV: E=Sophos;i="4.67,364,1309737600"; d="scan'208";a="12706027" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-2.cisco.com with ESMTP; 12 Aug 2011 20:33:04 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7CKX3bS032417 for ; Fri, 12 Aug 2011 20:33:04 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 12 Aug 2011 13:33:03 -0700 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: Fri, 12 Aug 2011 13:33:02 -0700 Message-ID: In-Reply-To: <382883C8-A431-4511-861F-FA7E5CE0DD84@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Proposed WG Charter for UDP based BFCP Thread-Index: AcxWosqJQ/o6kRvcTsyL6oT9f8TQwACi4T+w References: <382883C8-A431-4511-861F-FA7E5CE0DD84@cisco.com> From: "Charles Eckel (eckelcu)" To: "Cullen Jennings (fluffy)" , "DISPATCH list" X-OriginalArrivalTime: 12 Aug 2011 20:33:03.0216 (UTC) FILETIME=[08C1DF00:01CC592F] Subject: Re: [dispatch] Proposed WG Charter for UDP based BFCP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 20:32:27 -0000 This looks good to me, and I am interested in working toward this charter. Cheers, Charles > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Cullen Jennings > (fluffy) > Sent: Tuesday, August 09, 2011 7:44 AM > To: DISPATCH list > Subject: [dispatch] Proposed WG Charter for UDP based BFCP >=20 >=20 > At the last IETF there was a strong hum from the folks in the room to do a UDP based version of BFCP. > To get moving on seeing what we have consensus on, I have written up a draft charter as strawman to > start getting some comments. Can people have a look at this, and if you think parts of need changes or > additions, send proposed text. >=20 > Thanks, Cullen >=20 >=20 >=20 > Working Group Name: >=20 > Chairs: > TBD >=20 > Real-time Applications and Infrastructure Area Directors: > Gonzalo Camarillo > Robert Sparks >=20 > Real-time Applications and Infrastructure Area Advisor: > TBD >=20 > Mailing Lists: > General Discussion: TBD > To Subscribe: TBD > Archive: TBD >=20 >=20 > The BFCPBIS working group is charted to specify a revision of BFCP (RFC 4582) to support using both > TCP and UDP as transports. The current version of BFCP only supports TCP but when both endpoints are > behind NATs or firewalls, this has a lower success rate than using the ICE techniques with an UDP > based transport for BFCP. The need for video endpoints to work in these types of environments is > driving a strong desire to support a UDP based transport as well as TCP. >=20 > This WG will create a revision of RFC 4582 which adds optional support for UDP to BFCP. The security > when using UDP will be based on DTLS. The updated protocol will use an existing approach to congestion > safety and be TCP friendly as well as congestion safe. It is likely that the WG will choose to use a > stop and wait with a single outstanding transaction approach to congestion safety and reliability. The > WG will provide a way to deal with reliable response deliver for the case where it is needed. The WG > will research the size of messages used and decide what if fragmenting a request or response over > multiple UDP packets is required. The new protocol will be backwards compatible with RFC 4582 when > used in TCP mode. >=20 > The BFCPBIS WG will coordinate closely with the MMUSIC WG to create a revision of RFC 4583 specifying > how BFCP is signaled in SDP so that it supports UDP as well as TCP transports. This WG would ask the > MMUSIC WG to add a milestone to create a revisions of RFC 4583 to address signaling the use of UDP in > SDP. The WG will coordinate with International Multimedia Telecommunications Consortium (IMTC) and > other industry forums. >=20 >=20 > Milestones: >=20 > April 2012 Draft revision of RFC 4582 to IESG >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From Even.roni@huawei.com Fri Aug 12 15:54:49 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8589411E8094 for ; Fri, 12 Aug 2011 15:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgPwbkvsKoqd for ; Fri, 12 Aug 2011 15:54:48 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id C052321F8A4D for ; Fri, 12 Aug 2011 15:54:48 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPU00JNF7ODX7@szxga05-in.huawei.com> for dispatch@ietf.org; Sat, 13 Aug 2011 06:55:25 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPU00KSM7OCL7@szxga05-in.huawei.com> for dispatch@ietf.org; Sat, 13 Aug 2011 06:55:25 +0800 (CST) Received: from windows8d787f9 (bzq-79-180-16-191.red.bezeqint.net [79.180.16.191]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LPU00ELC7O7L4@szxml12-in.huawei.com>; Sat, 13 Aug 2011 06:55:24 +0800 (CST) Date: Sat, 13 Aug 2011 01:52:11 +0300 From: Roni Even In-reply-to: To: "'Charles Eckel (eckelcu)'" , "'Cullen Jennings (fluffy)'" , 'DISPATCH list' Message-id: <026201cc5942$7be105c0$73a31140$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcxWosqJQ/o6kRvcTsyL6oT9f8TQwACi4T+wAAUG0aA= References: <382883C8-A431-4511-861F-FA7E5CE0DD84@cisco.com> Subject: Re: [dispatch] Proposed WG Charter for UDP based BFCP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 22:54:49 -0000 +1 Roni Even > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Charles Eckel (eckelcu) > Sent: Friday, August 12, 2011 11:33 PM > To: Cullen Jennings (fluffy); DISPATCH list > Subject: Re: [dispatch] Proposed WG Charter for UDP based BFCP > > This looks good to me, and I am interested in working toward this > charter. > > Cheers, > Charles > > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Cullen Jennings > > (fluffy) > > Sent: Tuesday, August 09, 2011 7:44 AM > > To: DISPATCH list > > Subject: [dispatch] Proposed WG Charter for UDP based BFCP > > > > > > At the last IETF there was a strong hum from the folks in the room to > do a UDP based version of BFCP. > > To get moving on seeing what we have consensus on, I have written up > a > draft charter as strawman to > > start getting some comments. Can people have a look at this, and if > you think parts of need changes or > > additions, send proposed text. > > > > Thanks, Cullen > > > > > > > > Working Group Name: > > > > Chairs: > > TBD > > > > Real-time Applications and Infrastructure Area Directors: > > Gonzalo Camarillo > > Robert Sparks > > > > Real-time Applications and Infrastructure Area Advisor: > > TBD > > > > Mailing Lists: > > General Discussion: TBD > > To Subscribe: TBD > > Archive: TBD > > > > > > The BFCPBIS working group is charted to specify a revision of BFCP > (RFC 4582) to support using both > > TCP and UDP as transports. The current version of BFCP only supports > TCP but when both endpoints are > > behind NATs or firewalls, this has a lower success rate than using > the > ICE techniques with an UDP > > based transport for BFCP. The need for video endpoints to work in > these types of environments is > > driving a strong desire to support a UDP based transport as well as > TCP. > > > > This WG will create a revision of RFC 4582 which adds optional > support > for UDP to BFCP. The security > > when using UDP will be based on DTLS. The updated protocol will use > an > existing approach to congestion > > safety and be TCP friendly as well as congestion safe. It is likely > that the WG will choose to use a > > stop and wait with a single outstanding transaction approach to > congestion safety and reliability. The > > WG will provide a way to deal with reliable response deliver for the > case where it is needed. The WG > > will research the size of messages used and decide what if > fragmenting > a request or response over > > multiple UDP packets is required. The new protocol will be backwards > compatible with RFC 4582 when > > used in TCP mode. > > > > The BFCPBIS WG will coordinate closely with the MMUSIC WG to create a > revision of RFC 4583 specifying > > how BFCP is signaled in SDP so that it supports UDP as well as TCP > transports. This WG would ask the > > MMUSIC WG to add a milestone to create a revisions of RFC 4583 to > address signaling the use of UDP in > > SDP. The WG will coordinate with International Multimedia > Telecommunications Consortium (IMTC) and > > other industry forums. > > > > > > Milestones: > > > > April 2012 Draft revision of RFC 4582 to IESG > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From christer.holmberg@ericsson.com Tue Aug 16 01:06:38 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E7D21F8C17 for ; Tue, 16 Aug 2011 01:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbKdQ+y0UfoT for ; Tue, 16 Aug 2011 01:06:37 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 832A921F8BAE for ; Tue, 16 Aug 2011 01:06:36 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-b7-4e4a253bb311 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A2.B5.20773.B352A4E4; Tue, 16 Aug 2011 10:07:23 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.195]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 16 Aug 2011 10:07:23 +0200 From: Christer Holmberg To: "dispatch@ietf.org" Date: Tue, 16 Aug 2011 10:07:22 +0200 Thread-Topic: IETF#81: My DISPATCH notes Thread-Index: Acxb64blg3Ji8kcmRxaBtU7aTSD+4Q== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852203CD9EF4@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05852203CD9EF4ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] IETF#81: My DISPATCH notes X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 08:06:38 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852203CD9EF4ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Below are my notes from the DISPATCH session. (Hopefully the other note taker managed to cover the Global Service Provide= r Identification Number part.) Regards, Christer ------------- Topic: Session-id Presenter: Salvatore Loreto Focus: Use-cases and proposed charter Draft: draft-jones-ipmc-session-id-reqts-00 The presenter suggested that the work should only cover a limited set of us= e-cases. It was commented that the draft discusses many more use-cases, and that people are interested in a solution= that also solves use-cases not listed in the suggested charter. It was indicated that, in order to solve more use-cases, a re-charter would= be needed, but that everytime people have tried to expand the proposed charter something has come up that others= are not happy with. It was indicated that, instead of talking about which use-cases are NOT cov= ered, we should focus on the use-cases that we do want to solve. It was indicated that there would need to be a requirement on SBC customers= not to modify the session-id information. However, it is not possible to make such requirement, as it is not technical, and since th= ere might be different reasons why customers want to remove/modify specific information. It was indicated that there might be different understandings on what the i= dentified session is, and it needs to be clear in order for everyone to have a common understanding. It was asked whether the problem could be solved by making sure that user i= dentity is not revealed in the Call-Id header. However, there might be other reasons why B2BUAs need to modify the Call-Id. In addition to the charter discussions, there were discussions whether fork= ing is covered, whether end-users need the information, and whether the session-id can change during the call, e.g. due to different applications, = but where the call is still considered to be the same. It was clarified that, if it could be guaranteed that it would remain uncha= nged, the Call-Id would solve the use-cases in the currently proposed charter. HUM: Question: People who are in favor in moving forward with the propsed = charter? vs People who are in oppose in moving forward with the propsed cha= rter? Result: There was strong consensus in favor of moving the work forw= ard. ------------- Topic: Load balancing Presenter: Vijay Gurbani Focus: Proposed charter Draft: None specific for the meeting. It was commented that the difference between overload control is not clear.= It was indicated that, with load balancing, you will not have to put effort associated with overload control, as the idea is to avoid ove= rload scenarios to take place. It was commented that there currently are multiple different solutions avai= lable, without any guarantee of interoperability, but that a standardized solution hopefully would make that problem go away. It was questioned what, if any, IETF standardization work is needed, or whe= ther this would be better as a reasearch topic? It was indicated that there are solutions that be used to provide feedback = from server, which receiving entities might use to perform load balancing, and that it would be good to have a BCP or use-case= document. It was indicated that there has been no discussions with the APPS people re= garding this topic. There was an indication that people are interested in the topic as such, bu= t that it is unclear where and what work should be done. People were encouraged to continue the discussions per e-ma= il, and it was indicated that the focus should be on what needs to be done from an engineering perspective. ------------- Topic: Binary Floor Control Protocol (BFCP) Presenter: Charles Eckel Focus: Proposed charter Draft: draft-sandbakken-dispatch-bfcp-udp It was indicated that, if it is possible to do BFCP both with UDP and TCP, = there might be a need to specify gateway procedures, as we don't want to mandate support of both = transport options. It was discussed where the work would be done, as the XCON WG is closing up= . Most likely a mini WG would be created. Also indicated that it needs to be done in a WG, rather than as an AD spons= ored wrok, as one would have to deal with how different versions of the protocol wold interoperate. Indicated that there seems to be an assumption that a protocol that relies = on a reliable transport can be moved to an unreliable transport just by adding responses. There was some confusion of what the purpose, and intended outcome of the w= ork is. If the purpose is to simply describe existing implementations, the outcome should beinformational rathe= r than a standards track. It was claried that the proposal is for a new standards track protoc= ol. HUM: Question: Are people in favor in IETF publishing an RFC how to do BFC= F over UDP? Result: Strong concensus for doing BFCP over UDP. HUM: Question: Do people whink it should be standards/informational/do not= care? Result: Equal between people who care, and more strong among people= who do not care. --_000_7F2072F1E0DE894DA4B517B93C6A05852203CD9EF4ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
Below are my notes from the DISPATCH session.<= /div>
 
(Hopefully the other note taker managed to cover the = Global Service Provider Identification Number part.)
 
Regards,
 
Christer
 
 
 
-------------
 
Topic:        = ;  Session-id
Presenter:       Salvat= ore Loreto
Focus:        = ;  Use-cases and proposed charter
Draft:        = ;   draft-jones-ipmc-session-id-reqts-00
 
 
The presenter suggested that the work should only cov= er a limited set of use-cases. It was commented that the draft
discusses many more use-cases, and that people are in= terested in a solution that also solves use-cases not listed in
the suggested charter.
 
It was indicated that, in order to solve more use-cas= es, a re-charter would be needed, but that everytime people
have tried to expand the proposed charter something h= as come up that others are not happy with.
 
It was indicated that, instead of talking about which= use-cases are NOT covered, we should focus on the use-cases that
we do want to solve.
 
It was indicated that there would need to be a requir= ement on SBC customers not to modify the session-id information. However, i= t is
not possible to make such requirement, as it is not t= echnical, and since there might be different reasons why customers want
to remove/modify specific information.
 
It was indicated that there might be different unders= tandings on what the identified session is, and it needs to be clear=
in order for everyone to have a common understanding.=
 
It was asked whether the problem could be solved by m= aking sure that user identity is not revealed in the Call-Id header. Howeve= r,
there might be other reasons why B2BUAs need to modif= y the Call-Id.
 
In addition to the charter discussions, there were di= scussions whether forking is covered, whether end-users need the informatio= n, and whether the
session-id can change during the call, e.g. due to di= fferent applications, but where the call is still
considered to be the same.
 
 
It was clarified that, if it could be guaranteed that= it would remain unchanged, the Call-Id would solve the use-cases
in the currently proposed charter.
 
 
HUM:
 
Question:        P= eople who are in favor in moving forward with the propsed charter? vs Peopl= e who are in oppose in moving forward with the propsed charter?
Result:  There was strong consensus in favor of = moving the work forward.
 
 
-------------
 
 
Topic:        = ;  Load balancing
Presenter:       Vijay = Gurbani
Focus:        = ;  Proposed charter
Draft:        = ;  None specific for the meeting.
 
 
It was commented that the difference between overload= control is not clear. It was indicated that, with load balancing, you will= not have
to put effort associated with overload control, as th= e idea is to avoid overload scenarios to take place.
 
It was commented that there currently are multiple di= fferent solutions available, without any guarantee of interoperability, but= that
a standardized solution hopefully would make that pro= blem go away.
 
It was questioned what, if any, IETF standardization = work is needed, or whether this would be better as a reasearch topic?
 
It was indicated that there are solutions that be use= d to provide feedback from server, which receiving entities might use to
perform load balancing, and that it would be good to = have a BCP or use-case document.
 
It was indicated that there has been no discussions w= ith the APPS people regarding this topic.
 
 
There was an indication that people are interested in= the topic as such, but that it is unclear where and what work
should be done. People were encouraged to continue th= e discussions per e-mail, and it was indicated that the
focus should be on what needs to be done from an engi= neering perspective.
 
 
-------------
 
 
Topic:        = ;  Binary Floor Control Protocol (BFCP)
Presenter:       Charle= s Eckel
Focus:        = ;  Proposed charter
Draft:        = ;   draft-sandbakken-dispatch-bfcp-udp
 
It was indicated that, if it is possible to do BFCP b= oth with UDP and TCP, there might be a need
to specify gateway procedures, as we don't want to ma= ndate support of both transport options.
 
It was discussed where the work would be done, as the= XCON WG is closing up. Most likely a mini WG would be created.
Also indicated that it needs to be done in a WG, rath= er than as an AD sponsored wrok, as one would have to
deal with how different versions of the protocol wold= interoperate.
 
Indicated that there seems to be an assumption that a= protocol that relies on a reliable transport can be moved
to an unreliable transport just by adding responses.<= /font>
 
There was some confusion of what the purpose, and int= ended outcome of the work is. If the purpose is to simply
describe existing implementations, the outcome should= beinformational rather than a standards
track. It was claried that the proposal is for a new = standards track protocol.
 
 
HUM:
 
Question:        A= re people in favor in IETF publishing an RFC how to do BFCF over UDP?
Result:       &nbs= p;  Strong concensus for doing BFCP over UDP.
 
 
HUM:
 
Question:        D= o people whink it should be standards/informational/do not care?
Result:  Equal between people who care, and more= strong among people who do not care.
 
 
 
 
 
 
 
 
 
 
 
 --_000_7F2072F1E0DE894DA4B517B93C6A05852203CD9EF4ESESSCMS0356e_-- From samirs.lists@gmail.com Sun Aug 21 23:00:33 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60AA21F85A4; Sun, 21 Aug 2011 23:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=-0.870, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGwiz8XtDijq; Sun, 21 Aug 2011 23:00:33 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5F09521F8538; Sun, 21 Aug 2011 23:00:17 -0700 (PDT) Received: by pzk33 with SMTP id 33so15611494pzk.18 for ; Sun, 21 Aug 2011 23:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=ic4niLsIaJdfu70pBr+aIqlFttAtY8FsruFTpUHBvZM=; b=Z0nb0R6UIgLQ8LtQi2dEUKd0eMfK2bDYyiMDItX50/JLuJHPM8Oco/PJuR/QmtMBtm jV0HCVASNKRFRGQsRQZ4s3iKDDSvWXKMyIL4YK7NgfZ3Mzdq2RmXAd2nenGtFWA94QUW M22cUUcCie2YItMJZQ4LXVaT78Dga5e8PX+Z0= MIME-Version: 1.0 Received: by 10.142.125.18 with SMTP id x18mr1461314wfc.412.1313992880843; Sun, 21 Aug 2011 23:01:20 -0700 (PDT) Received: by 10.68.49.106 with HTTP; Sun, 21 Aug 2011 23:01:20 -0700 (PDT) Date: Sun, 21 Aug 2011 23:01:20 -0700 Message-ID: From: Samir Srivastava To: sipcore@ietf.org, secdir@ietf.org, dispatch@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [dispatch] Volunteers please for coauthor X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 06:00:34 -0000 Hi, It is quite unusual to send this note on list. I approched couple of folks privately but in vain. Due to unavoidable situation, I have limited internet access with which I cannot submit draft. I am looking for coauthors for a draft covering unaddressed issues by SIPS and work on cashless economy etc at http://samirsrivastava.typepad.com . To the best of my knowledge and skills it will *AVOID* various security issues of SIP/ INTERNET. Volunteers pl. People from persmal id gmail etc can also help. BTW I have solution for overwhelmed response (which I doubt). CCing secdir for any help. Regards Samir From mary.ietf.barnes@gmail.com Mon Aug 22 13:43:36 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7FB721F8C83 for ; Mon, 22 Aug 2011 13:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.434 X-Spam-Level: X-Spam-Status: No, score=-103.434 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjKnqJ9cu1fZ for ; Mon, 22 Aug 2011 13:43:35 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 09EE721F8C80 for ; Mon, 22 Aug 2011 13:43:34 -0700 (PDT) Received: by vxi29 with SMTP id 29so5724867vxi.31 for ; Mon, 22 Aug 2011 13:44:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ymly5DMgVI1kudzKhfl9bRQhJ0rPmu1HNrdrbe/utRg=; b=GYfMTCPaXVkGXWJZm5GqYNKKTaLoeum592dL4eJN3gjtKTBO6fHOiptVGRw2mI6yhd k+yr1fSnD9/ZjaTHTZA5hpwWSBAmUP0mYXSmt8Z55NAk5Up4b7nwKDcwhx2UODiTsWTW 0BAc+8l7a1khWBT+AS9qBHQAL/pTEa0GNg16k= MIME-Version: 1.0 Received: by 10.52.21.65 with SMTP id t1mr2732136vde.183.1314045880410; Mon, 22 Aug 2011 13:44:40 -0700 (PDT) Received: by 10.52.160.36 with HTTP; Mon, 22 Aug 2011 13:44:40 -0700 (PDT) In-Reply-To: <20110822181534.B109121F850B@ietfa.amsl.com> References: <20110822181534.B109121F850B@ietfa.amsl.com> Date: Mon, 22 Aug 2011 15:44:40 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=20cf307d05a6eba04104ab1e2517 Cc: rai-ads@tools.ietf.org Subject: [dispatch] 82nd IETF - Working Group/BOF Scheduling X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 20:43:37 -0000 --20cf307d05a6eba04104ab1e2517 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable FYI... the DISPATCH specific deadlines are as follows and are also on the W= G wiki. Please note that the initial deadline is just two weeks away. There has been alot of fuss about these deadlines However, folks need to understand that the first deadline is just letting the chairs know that you want to discuss a particular work item - i.e., one sentence is all we need by that date. You have a week to refine that idea into a *rough* charter. Based upon discussions over the next two weeks, the chairs (conferring with the ADs) will decide what topics are targeted for the meeting. You then have 4 weeks to work on a draft related to the topic. However, you don't necessarily need a draft since the focus is on the charter (with that term used very loosely). We need a problem statement along with a guess at deliverables. The objective of the discussions on th= e mailing list and at the f2f meeting is to determine if the problem/work ite= m is scoped tightly enough that it's solvable/doable, as well as to guage WG interest in the topic and willingness to contribute. If it's agreed, then we can use the mailing list to refine the charter. We have been flexible about the dates as long as folks can give us an idea of when they will be able to meet the deadlines. We need a rough idea of the topics in order to request an appropriate length agenda slot. The length tends to be far more variable than other WGs. Note, that the deadline for the topic announcements aligns with the deadline for requestin= g a WG slot. Regards, Mary. DISPATCH WG co-chair. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D * Sept. 5th, 2011. Cutoff date to notify the chairs/DISPATCH WG of plans t= o submit a proposal. [Two weeks prior to BoF proposal deadline, 7 weeks befor= e -00 deadline] *2 weeks from today* * Sept. 12th, 2011. Cutoff for charter proposals for topics. [Three weeks prior to BoF proposal deadline, two weeks before announcement of topics] * Sept. 26th, 2011. Topics that are to be the focus of IETF-82 are announced. [10 days before AD BoF approval and deadline to request WG slot, 4 weeks before -00 deadline, deadline for requesting WG session] * October 24th, 2011. -00 draft deadline. * October 31st, 2011. Draft deadline. ---------- Forwarded message ---------- From: IETF Agenda Date: Mon, Aug 22, 2011 at 1:15 PM Subject: 82nd IETF - Working Group/BOF Scheduling To: Working Group Chairs Cc: irsg@irtf.org ----------------------------------------------------------------- 82nd IETF =96 Taipei, Taiwan Meeting Dates: November 13-18, 2011 Host: Taiwan Network Information Center (TWNIC) ----------------------------------------------------------------- IETF meetings start Monday morning and run through Friday mid-afternoon (15:15). We are accepting scheduling requests for all Working Groups and BOFs starting today. The milestones and deadlines for scheduling-related activities are as follows: NOTE: cutoff dates are subject to change. - 2011-08-15 (Monday): Working Group and BOF scheduling begins. To request = a Working Group session, use the IETF Meeting Session Request Tool. - 2011-09-26 (Monday): Cutoff date for requests to schedule Working Group meetings at 17:00 PT (00:00 UTC). To request a Working Group session, use the IETF Meeting Session Request Tool. - 2011- 10-03 (Monday): Cutoff date for BOF proposal requests to Area Directors at 17:00 PT (00:00 UTC). To request a BOF, please see instruction= s on Requesting a BOF. - 2011-10-06 (Thursday): Cutoff date for Area Directors to approve BOFs at 17:00 PT (00:00 UTC). - 2011-10-13 (Thursday): Preliminary agenda published for comment. - 2011-10-17 (Monday): Cutoff date for requests to reschedule Working Group and BOF meetings 17:00 PT (00:00 UTC). - 2011-10-21 (Friday): Final agenda to be published. - 2011-11-02 (Wednesday): Draft Working Group agendas due by 17:00 PT (00:0= 0 UTC), upload using IETF Meeting Materials Management Tool. - 2011-11-07 (Monday): Revised Working Group agendas due by 17:00 PT (00:00 UTC), upload using IETF Meeting Materials Management Tool. Submitting Requests for Working Group and BOF Sessions Please submit requests to schedule your Working Group sessions using the "IETF Meeting Session Request Tool," a Web-based tool for submitting all of the information that the Secretariat requires to schedule your sessions. The URL for the tool is: https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi Instructions for using the tool are available at: http://www.ietf.org/instructions/session_request_tool_instruction.html Please send requests to schedule your BOF sessions to agenda@ietf.org. Please include the acronym of your BOF in the subject line of the message, and include all of the information specified in item (4) of "Requesting Meeting Sessions at IETF Meetings" in the body. (This document is included below.) Submitting Session Agendas For the convenience of meeting attendees, we ask that you submit the agenda= s for your Working Group sessions as early as possible. Draft Working Group agendas are due Wednesday, November 2, 2011 by 17:00 PT. Revised Working Group agendas are due no later than Monday, November 7, 2011 at 17:00 PT. The proposed agenda for a BOF session should be submitted along with your request for a session. Please be sure to copy your Area Director on that message. Please submit the agendas for your Working Group sessions using the "IETF Meeting Materials Management Tool," a Web-based tool for making your meetin= g agenda, minutes, and presentation slides available to the community before, during, and after an IETF meeting. If you are a BOF chair, then you may us= e the tool to submit a revised agenda as well as other materials for your BOF once the BOF has been approved. The URL for the tool is: https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi Additional information about this tool is available at: http://www.ietf.org/instructions/meeting_materials_tool.html Agendas submitted via the tool will be available to the public on the "IETF Meeting Materials" Web page as soon as they are submitted. The URL for the "IETF 82 Meeting Materials" Web page is: https://datatracker.ietf.org/meeting/82/materials.html If you are a Working Group chair, then you already have accounts on the "IETF Meeting Session Request Tool" and the "IETF Meeting Materials Management Tool." The same User ID and password will work for both tools. If you are a BOF chair who is not also a Working Group chair, then you wil= l be given an account on the "IETF Meeting Materials Management Tool" when your BOF has been approved. If you require assistance in using either tool= , or wish to report a bug, then please send a message to: ietf-action@ietf.org. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D For your convenience, comprehensive information on requesting meeting sessions at IETF 82 is presented below: 1. Requests to schedule Working Group sessions should be submitted using th= e "IETF Meeting Session Request Tool," a Web-based tool for submitting all of the information required by the Secretariat to schedule your sessions. The URL for the tool is: https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi Instructions for using the tool are available at: http://www.ietf.org/instructions/session_request_tool_instruction.html If you require an account on this tool, or assistance in using it, then please send a message to ietf-action@ietf.org. If you are unable to use th= e tool, then you may send your request via e-mail to agenda@ietf.org, with a copy to the appropriate Area Director(s). Requests to schedule BOF sessions must be sent to agenda@ietf.org with a copy to the appropriate Area Director(s). When submitting a Working Group or BOF session request by e-mail, please include the Working Group or BOF acronym in the Subject line. 2. BOFs will NOT be scheduled unless the Area Director(s) approved request is accompanied by a BOF'S FULL NAME AND ACRONYM, AREA, CHAIR(S) NAME(S) (given together with e-mail address(es)), AN AGENDA AND FULL DESCRIPTION, and the information requested in (4) below. (Please read the BOF Procedure at: http://www.ietf.org/ietf/1bof-procedures.txt before requesting a sessio= n for a BOF.) 3. A Working Group may request either one or two sessions. If your Working Group requires more than two sessions, then your request must be approved b= y an Area Director. Additional sessions will be assigned, based on availability, after Monday, October 17, 2011 at 17:00 PT, the cut-off date for requests to reschedule a session. 4. You MUST provide the following information before a Working Group or BOF session will be scheduled: a. Working Group or BOF full name with acronym in brackets: b. AREA under which Working Group or BOF appears: c. CONFLICTS you wish to avoid, please be as specific as possible: d. Expected Attendance: e. Special requests: f. Number of sessions: g. Length of session: - 1 hour - 1 1/2 hours - 2 hours - 2 1/2 hours For more information on scheduling Working Group and BOF sessions, please refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and Procedures" = ( http://www.ietf.org/rfc/rfc2418.txt). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D For your convenience please find here a list of the IETF Area Directors wit= h their e-mail addresses: IETF Chair Russ Housley Applications Area (app) Pete Resnick Peter Saint-Andre Internet Area (int) Jari Arkko Ralph Droms Operations & Management Area (ops) Ronald Bonica Dan Romascanu Real-time Applications and Infrastructure Area (rai) Gonzalo Camarillo Robert Sparks Routing Area (rtg) Stewart Bryant Adrian Farrel Security Area (sec) Stephen Farrell Sean Turner Transport Area (tsv) Wesley Eddy David Harrington =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 81th IETF Meeting Attendance Number - TBA --20cf307d05a6eba04104ab1e2517 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable FYI... the DISPATCH specific deadlines are as follows and are also on the W= G wiki. Please note that the initial deadline is just two weeks away. =A0Th= ere has been alot of fuss about these deadlines However, folks need to unde= rstand that the first deadline is just letting the chairs know that you wan= t to discuss a particular work item - i.e., one sentence is all we need by = that date. =A0You have a week to refine that idea into a *rough* charter. = =A0

Based upon discussions over the next two weeks, the chairs (= conferring with the ADs) will decide what topics are targeted for the meeti= ng. =A0You then have 4 weeks to work on a draft related to the topic. =A0

However, you don't necessarily need a draft since t= he focus is on the charter (with that term used very loosely). =A0We need a= problem statement along with a guess at deliverables. =A0The objective of = the discussions on the mailing list and at the f2f meeting is to determine = if the problem/work item is scoped tightly enough that it's solvable/do= able, as well as to guage WG interest in the topic and willingness to contr= ibute. =A0If it's agreed, then we can use the mailing list to refine th= e charter. =A0

We have been flexible about the dates as long as folks = can give us an idea of when they will be able to meet the deadlines. =A0We = need a rough idea of the topics in order to request an appropriate length a= genda slot. =A0The length tends to be far more variable than other WGs. =A0= Note, that the deadline for the topic announcements aligns with the deadlin= e for requesting a WG slot.=A0

Regards,
Mary.
DISPATCH WG co-chair= .

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=
* =A0Sept. 5th, 2011. Cutoff date to notify the chairs/DISPATCH WG of = plans to submit a proposal. [Two weeks prior to BoF proposal deadline, 7 we= eks before -00 deadline] =A0 =A0 *2 weeks from today*=A0

* Sept. 12th, 2011. Cutoff for charter proposals for to= pics. [Three weeks prior to BoF proposal deadline, two weeks before announc= ement of topics]

* Sept. 26th, 2011. Topics that a= re to be the focus of IETF-82 are announced. [10 days before AD BoF approva= l and deadline to request WG slot, 4 weeks before -00 deadline, deadline fo= r requesting WG session]

* October 24th, 2011. -00 draft deadline.
* October 31st, 2011. Draft deadline.



---------- Forwarded message -----= -----
From: IETF Agenda <<= a href=3D"mailto:agenda@ietf.org">agenda@ietf.org>
Date: M= on, Aug 22, 2011 at 1:15 PM
Subject: 82nd IETF - Working Group/BOF Sched= uling
To: Working Group Chairs <wgchairs@= ietf.org>
Cc: irsg@irtf.org<= br>

----------------------------------------------------------------= -
82nd IETF =96 Taipei, Taiwan
Meeting Dates: November 13-18, 2011
Host: Taiwan Network Information Center (TWNIC)
-----------------------------------------------------------------
IETF meetings start Monday morning and run through Friday mid-afternoon (15= :15).

We are accepting scheduling requests for all Working Groups and BOFs starti= ng today. =A0The milestones and deadlines for scheduling-related activities= are as follows:

NOTE: cutoff dates are subject to change.

- 2011-08-15 (Monday): Working Group and BOF scheduling begins. To request = a Working Group session, use the IETF Meeting Session Request Tool.
- 2011-09-26 (Monday): Cutoff date for requests to schedule Working Group m= eetings at 17:00 PT (00:00 UTC). To request a Working Group session, use th= e IETF Meeting Session Request Tool.
- 2011- 10-03 (Monday): Cutoff date for BOF proposal requests to Area Direc= tors at 17:00 PT (00:00 UTC). To request a BOF, please see instructions on = Requesting a BOF.
- 2011-10-06 (Thursday): Cutoff date for Area Directors to approve BOFs at = 17:00 PT (00:00 UTC).
- 2011-10-13 (Thursday): Preliminary agenda published for comment.
- 2011-10-17 (Monday): Cutoff date for requests to reschedule Working Group= and BOF meetings 17:00 PT (00:00 UTC).
- 2011-10-21 (Friday): Final agenda to be published.
- 2011-11-02 (Wednesday): Draft Working Group agendas due by 17:00 PT (00:0= 0 UTC), upload using IETF Meeting Materials Management Tool.
- 2011-11-07 (Monday): Revised Working Group agendas due by 17:00 PT (00:00= UTC), upload using IETF Meeting Materials Management Tool.

Submitting Requests for Working Group and BOF Sessions

Please submit requests to schedule your Working Group sessions using the &q= uot;IETF Meeting Session Request Tool," a Web-based tool for submittin= g all of the information that the Secretariat requires to schedule your ses= sions.

The URL for the tool is:

https://datatracker.ietf.org/cgi-bin/wg/wg_session_requ= ester.cgi

Instructions for using the tool are available at:

http://www.ietf.org/instructions/session_request_= tool_instruction.html

Please send requests to schedule your BOF sessions to agenda@ietf.org. =A0Please include the acronym of your BO= F in the subject line of the message, and include all of the information sp= ecified in item (4) of "Requesting Meeting Sessions at IETF Meetings&q= uot; in the body. =A0(This document is included below.)

Submitting Session Agendas

For the convenience of meeting attendees, we ask that you submit the agenda= s for your Working Group sessions as early as possible. =A0Draft Working Gr= oup agendas are due Wednesday, November 2, 2011 by 17:00 PT. =A0Revised Wor= king Group agendas are due no later than Monday, November 7, 2011 at 17:00 = PT. =A0The proposed agenda for a BOF session should be submitted along with= your request for a session. =A0Please be sure to copy your Area Director o= n that message.

Please submit the agendas for your Working Group sessions using the "I= ETF Meeting Materials Management Tool," a Web-based tool for making yo= ur meeting agenda, minutes, and presentation slides available to the commun= ity before, during, and after an IETF meeting. =A0If you are a BOF chair, t= hen you may use the tool to submit a revised agenda as well as other materi= als for your BOF once the BOF has been approved.

The URL for the tool is:

https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi

Additional information about this tool is available at:

http://www.ietf.org/instructions/meeting_materials_tool.htm= l

Agendas submitted via the tool will be available to the public on the "= ;IETF Meeting Materials" Web page as soon as they are submitted.

The URL for the "IETF 82 Meeting Materials" Web page is:

https://datatracker.ietf.org/meeting/82/materials.html

If you are a Working Group chair, then you already have accounts on the &qu= ot;IETF Meeting Session Request Tool" and the "IETF Meeting Mater= ials Management Tool." =A0The same User ID and password will work for = both tools. =A0If you are a BOF chair who is not also a Working Group chair= , then you will be given an account on the "IETF Meeting Materials Man= agement Tool" when your BOF has been approved. =A0If you require assis= tance in using either tool, or wish to report a bug, then please send a mes= sage to:
ietf-action@ietf.org.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
For your convenience, comprehensive information on requesting meeting sessi= ons at IETF 82 is presented below:

1. Requests to schedule Working Group sessions should be submitted using th= e "IETF Meeting Session Request Tool," a Web-based tool for submi= tting all of the information required by the Secretariat to schedule your s= essions. =A0The URL for the tool is:

https://datatracker.ietf.org/cgi-bin/wg/wg_session_requ= ester.cgi

Instructions for using the tool are available at:

http://www.ietf.org/instructions/session_request_= tool_instruction.html

If you require an account on this tool, or assistance in using it, then ple= ase send a message to ietf-action@i= etf.org. =A0If you are unable to use the tool, then you may send your r= equest via e-mail to agenda@ietf.org= , with a copy to the appropriate Area Director(s).

Requests to schedule BOF sessions must be sent to agenda@ietf.org with a copy to the appropriate Area Director(= s).

When submitting a Working Group or BOF session request by e-mail, please in= clude the Working Group or BOF acronym in the Subject line.

2. BOFs will NOT be scheduled unless the Area Director(s) approved request = is accompanied by a BOF'S FULL NAME AND ACRONYM, AREA, CHAIR(S) NAME(S)= (given together with e-mail address(es)), AN AGENDA AND FULL DESCRIPTION, = and the information requested in (4) below. (Please read the BOF Procedure = at: http://www.ietf.org/ietf/1bof-procedures.txt before requesting a se= ssion for a BOF.)

3. A Working Group may request either one or two sessions. =A0If your Worki= ng Group requires more than two sessions, then your request must be approve= d by an Area Director. =A0Additional sessions will be assigned, based on av= ailability, after Monday, October 17, 2011 at 17:00 PT, the cut-off date fo= r requests to reschedule a session.

4. You MUST provide the following information before a Working Group or BOF= session will be scheduled:

=A0 =A0a. Working Group or BOF full name with acronym in brackets:

=A0 =A0b. AREA under which Working Group or BOF appears:

=A0 =A0c. CONFLICTS you wish to avoid, please be as specific as possible:<= br>
=A0 =A0d. Expected Attendance:

=A0 =A0e. Special requests:

=A0 =A0f. Number of sessions:

=A0 =A0g. Length of session:
=A0 =A0 =A0 - 1 hour
=A0 =A0 =A0 - 1 1/2 hours
=A0 =A0 =A0 - 2 hours
=A0 =A0 =A0 - 2 1/2 hours

For more information on scheduling Working Group and BOF sessions, please r= efer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and Procedur= es" (http://www.ietf.org/rfc/rfc2418.txt).
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
For your convenience please find here a list of the IETF Area Directors wit= h their e-mail addresses:

IETF Chair
Russ Housley <housley@vigilsec.c= om>

Applications Area (app)
Pete Resnick <presnick@qualcomm= .com>
Peter Saint-Andre <stpeter@stpeter= .im>

Internet Area (int)
Jari Arkko <jari.arkko@piuha.net= >
Ralph Droms <rdroms.ietf@gmail.= com>

Operations & Management Area (ops)
Ronald Bonica <rbonica@juniper.ne= t>
Dan Romascanu <dromasca@avaya.com<= /a>>

Real-time Applications and Infrastructure Area (rai)
Gonzalo Camarillo <gon= zalo.camarillo@ericsson.com>
Robert Sparks <rjsparks@nostrum.= com>

Routing Area (rtg)
Stewart Bryant <stbryant@cisco.com= >
Adrian Farrel <adrian@olddog.co.u= k>

Security Area (sec)
Stephen Farrell <stephen.fa= rrell@cs.tcd.ie>
Sean Turner <turners@ieca.com>= ;

Transport Area (tsv)
Wesley Eddy <wes@mti-systems.com<= /a>>
David Harrington <ietfdbh@comcast= .net>
=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
81th IETF Meeting Attendance Number - TBA

--20cf307d05a6eba04104ab1e2517-- From sunilkumarsinha9@rediffmail.com Wed Aug 24 02:59:05 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93AA21F8B06 for ; Wed, 24 Aug 2011 02:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.096 X-Spam-Level: ** X-Spam-Status: No, score=2.096 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_50=0.001, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MSGID_FROM_MTA_HEADER=0.803, SARE_SUB_ENC_UTF8=0.152, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8o7vj+laP3m for ; Wed, 24 Aug 2011 02:59:05 -0700 (PDT) Received: from rediffmail.com (f5mail-224-156.rediffmail.com [114.31.224.156]) by ietfa.amsl.com (Postfix) with SMTP id 2404221F8B02 for ; Wed, 24 Aug 2011 02:59:02 -0700 (PDT) Received: (qmail 11151 invoked by uid 510); 24 Aug 2011 10:00:03 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=redf; d=rediffmail.com; b=U6Y/A0YTUpGEFav6R5DgcPPddT4FXzbJSlX2hI0/gylwwqCh+FVUe+B4Di+WddP0sVajpGZNUMNMgn9dReUIypPuSZ70iO+wiabqOiCMax9q21Xhh2jPyh0Owd2OSNPFz2me5ujL+8pKp3pVAWF0Lllu9Th6ebf3n/UqDQQFdxU= ; x-m-msg: asd54ad564ad7aa6sd5as6d5; a6da7d6asas6dasd77; 5dad65ad5sd; X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-Flags: : 0 X-CTCH-RefID: str=0001.0A150201.4E54CBA4.0028,ss=1,re=0.000,fgs=0 Date: 24 Aug 2011 10:00:02 -0000 Message-ID: <20110824100002.11118.qmail@f5mail-224-156.rediffmail.com> MIME-Version: 1.0 To: Received: from unknown 72.163.180.205 by rediffmail.com via HTTP; 24 Aug 2011 10:00:02 -0000 From: "sunil kumar sinha" Content-Type: multipart/alternative; boundary="=_503c37193f9d1251588c919ba14db4df" Subject: [dispatch] =?utf-8?q?New_Draft_-_draft-sinha-dispatch-sip-continu?= =?utf-8?q?ation-option?= X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 09:59:05 -0000 --=_503c37193f9d1251588c919ba14db4df Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Hi Everyone, This draft proposed a mechanism to resolve the problem – when callee is not in a favorable state to accepts incoming calls. http://tools.ietf.org/id/draft-sinha-dispatch-sip-continuation-option-00.txt Unfavorable condition highlighted in the draft are -1) Caller and Callee both are in different time-zone 2) Callee is in a mild-DND(NDDND) state. Unfortunately, there could be a number of factors that contribute to the above un-favorable condition for a callee . But at the same time under such a case, non-emergency calls needs to be avoided and emergency calls needs to be communicated - is addressed in the draft. Comments on the draft or which WG it should go to are much appreciated. Please let us know your thoughts. Best regards, Sunil Kumar Sinha --=_503c37193f9d1251588c919ba14db4df Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Hi Everyone,

This draft proposed a mechanism to resolve the problem =E2=80=93 when calle= e is not in a favorable state to accepts incoming calls.
http://tools.ietf.org/id/draft-sinha-dispatch-sip-continuation-option-00.tx= t

Unfavorable condition highlighted in the draft are -1) Caller and Callee bo= th are in different time-zone 2) Callee is in a mild-DND(NDDND) state. Unfo= rtunately, there could be a number of factors that contribute to the above = un-favorable condition for a callee .

But at the same time under such a case, non-emergency calls needs to be avo= ided and emergency calls needs to be communicated - is addressed in the dra= ft.

Comments on the draft or which WG it should go to are much
appreciated. Please let us know your thoughts.

Best regards,
Sunil Kumar Sinha



Treat yours= elf at a restaurant, spa, resort and much more with Rediff Deal ho jaye! --=_503c37193f9d1251588c919ba14db4df-- From john.elwell@siemens-enterprise.com Thu Aug 25 04:01:55 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D3B21F854D for ; Thu, 25 Aug 2011 04:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.16 X-Spam-Level: X-Spam-Status: No, score=-103.16 tagged_above=-999 required=5 tests=[AWL=-0.561, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sX3P48uFxdAh for ; Thu, 25 Aug 2011 04:01:55 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id D5CAE21F851A for ; Thu, 25 Aug 2011 04:01:54 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 512021EB842C; Thu, 25 Aug 2011 13:03:05 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 25 Aug 2011 13:03:05 +0200 From: "Elwell, John" To: Roni Even , "'Charles Eckel (eckelcu)'" , "'Cullen Jennings (fluffy)'" , 'DISPATCH list' Date: Thu, 25 Aug 2011 13:03:04 +0200 Thread-Topic: [dispatch] Proposed WG Charter for UDP based BFCP Thread-Index: AcxWosqJQ/o6kRvcTsyL6oT9f8TQwACi4T+wAAUG0aACdQcm4A== Message-ID: References: <382883C8-A431-4511-861F-FA7E5CE0DD84@cisco.com> <026201cc5942$7be105c0$73a31140$%roni@huawei.com> In-Reply-To: <026201cc5942$7be105c0$73a31140$%roni@huawei.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: [dispatch] Proposed WG Charter for UDP based BFCP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 11:01:56 -0000 Looks good. John=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Roni Even > Sent: 12 August 2011 23:52 > To: 'Charles Eckel (eckelcu)'; 'Cullen Jennings (fluffy)';=20 > 'DISPATCH list' > Subject: Re: [dispatch] Proposed WG Charter for UDP based BFCP >=20 > +1 > Roni Even >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On > > Behalf Of Charles Eckel (eckelcu) > > Sent: Friday, August 12, 2011 11:33 PM > > To: Cullen Jennings (fluffy); DISPATCH list > > Subject: Re: [dispatch] Proposed WG Charter for UDP based BFCP > >=20 > > This looks good to me, and I am interested in working toward this > > charter. > >=20 > > Cheers, > > Charles > >=20 > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On > > Behalf Of Cullen Jennings > > > (fluffy) > > > Sent: Tuesday, August 09, 2011 7:44 AM > > > To: DISPATCH list > > > Subject: [dispatch] Proposed WG Charter for UDP based BFCP > > > > > > > > > At the last IETF there was a strong hum from the folks in=20 > the room to > > do a UDP based version of BFCP. > > > To get moving on seeing what we have consensus on, I have=20 > written up > > a > > draft charter as strawman to > > > start getting some comments. Can people have a look at=20 > this, and if > > you think parts of need changes or > > > additions, send proposed text. > > > > > > Thanks, Cullen > > > > > > > > > > > > Working Group Name: > > > > > > Chairs: > > > TBD > > > > > > Real-time Applications and Infrastructure Area Directors: > > > Gonzalo Camarillo > > > Robert Sparks > > > > > > Real-time Applications and Infrastructure Area Advisor: > > > TBD > > > > > > Mailing Lists: > > > General Discussion: TBD > > > To Subscribe: TBD > > > Archive: TBD > > > > > > > > > The BFCPBIS working group is charted to specify a revision of BFCP > > (RFC 4582) to support using both > > > TCP and UDP as transports. The current version of BFCP=20 > only supports > > TCP but when both endpoints are > > > behind NATs or firewalls, this has a lower success rate than using > > the > > ICE techniques with an UDP > > > based transport for BFCP. The need for video endpoints to work in > > these types of environments is > > > driving a strong desire to support a UDP based transport=20 > as well as > > TCP. > > > > > > This WG will create a revision of RFC 4582 which adds optional > > support > > for UDP to BFCP. The security > > > when using UDP will be based on DTLS. The updated=20 > protocol will use > > an > > existing approach to congestion > > > safety and be TCP friendly as well as congestion safe. It=20 > is likely > > that the WG will choose to use a > > > stop and wait with a single outstanding transaction approach to > > congestion safety and reliability. The > > > WG will provide a way to deal with reliable response=20 > deliver for the > > case where it is needed. The WG > > > will research the size of messages used and decide what if > > fragmenting > > a request or response over > > > multiple UDP packets is required. The new protocol will=20 > be backwards > > compatible with RFC 4582 when > > > used in TCP mode. > > > > > > The BFCPBIS WG will coordinate closely with the MMUSIC WG=20 > to create a > > revision of RFC 4583 specifying > > > how BFCP is signaled in SDP so that it supports UDP as well as TCP > > transports. This WG would ask the > > > MMUSIC WG to add a milestone to create a revisions of RFC 4583 to > > address signaling the use of UDP in > > > SDP. The WG will coordinate with International Multimedia > > Telecommunications Consortium (IMTC) and > > > other industry forums. > > > > > > > > > Milestones: > > > > > > April 2012 Draft revision of RFC 4582 to IESG > > > > > > > > > > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From pkyzivat@alum.mit.edu Thu Aug 25 07:59:24 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E5121F89BA for ; Thu, 25 Aug 2011 07:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.934 X-Spam-Level: X-Spam-Status: No, score=-0.934 tagged_above=-999 required=5 tests=[AWL=-1.535, BAYES_50=0.001, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZI0XUQmW9nOI for ; Thu, 25 Aug 2011 07:59:23 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2D121F8997 for ; Thu, 25 Aug 2011 07:59:23 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta14.westchester.pa.mail.comcast.net with comcast id Qeyn1h0030Fqzac5Ef0dNu; Thu, 25 Aug 2011 15:00:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta08.westchester.pa.mail.comcast.net with comcast id Qf0c1h00x0tdiYw3Uf0cQr; Thu, 25 Aug 2011 15:00:37 +0000 Message-ID: <4E566392.1070405@alum.mit.edu> Date: Thu, 25 Aug 2011 11:00:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <20110824100002.11118.qmail@f5mail-224-156.rediffmail.com> In-Reply-To: <20110824100002.11118.qmail@f5mail-224-156.rediffmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dispatch] New Draft - draft-sinha-dispatch-sip-continuation-option X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 14:59:24 -0000 Sunil, I'm having trouble understanding the assumptions and intended use of this mechanism. I also think there are probably other ways of accomplishing something similar. Some comments and questions on the draft: Figure 2: You don't show the F1 message. Does it contain 'Supported:continue'? If not, then putting Require:continue in the response is very questionable, since it can't be refused in a response. Is it intended that the 182 + Require:continue is to be interpreted by the UAC as indicating that the call hasn't yet alerted, and won't unless Continue:yes is sent? (That is an improper use of Require. It is supposed to mean "I require that you *support* this option", not that I require you to use it.) Also, what is the intended behavior when the UAC does not support this mechanism? If it receives a 182 response, it will probably treat it just like a 180 and wait, assuming the call is alerting and will eventually be answered. Or does the UAS note there is no Supported:continue and return 486 rather than 182? Section 4: IIUC this lists a number of cases where this feature might be used, yet to the UAC these are all indicated in the same way. So the user of the UAC has no idea why he is being asked to confirm or deny the importance of his call. General comments: This seems to be yet another spin on presence. Have you investigated how you might explicitly use presence for this? For instance, the UAS that wants this behavior could refuse (perhaps with 486) any call that doesn't have a Priority header with a sufficiently high value. In the response it could include a PIDF in the body (or content indirection to one). Then the UAC could interpret that, interact with its user, and perhaps generate another INVITE with a Priority header. Or, UACs that support this mechanism could simply subscribe to presence of the callee before sending the invite, and make a decision how to make the call based on what is received. Or, if you really feel its essential to do this with one invite, an existing mechanism to defer alerting is through use of preconditions. You could conceivably create a new precondition type to get the desired effect. (But this direction isn't appealing to me.) Most, I suggest you spend more time refining the requirements before getting involved in the mechanism. Thanks, Paul On 8/24/11 6:00 AM, sunil kumar sinha wrote: > Hi Everyone, > > This draft proposed a mechanism to resolve the problem – when callee is > not in a favorable state to accepts incoming calls. > http://tools.ietf.org/id/draft-sinha-dispatch-sip-continuation-option-00.txt > > Unfavorable condition highlighted in the draft are -1) Caller and Callee > both are in different time-zone 2) Callee is in a mild-DND(NDDND) state. > Unfortunately, there could be a number of factors that contribute to the > above un-favorable condition for a callee . > > But at the same time under such a case, non-emergency calls needs to be > avoided and emergency calls needs to be communicated - is addressed in > the draft. > > Comments on the draft or which WG it should go to are much > appreciated. Please let us know your thoughts. > > Best regards, > Sunil Kumar Sinha > > > > > > Treat yourself at a restaurant, spa, resort and much more with *Rediff > Deal ho jaye! > * > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From dworley@avaya.com Thu Aug 25 13:26:23 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C804D21F8B91 for ; Thu, 25 Aug 2011 13:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.448 X-Spam-Level: X-Spam-Status: No, score=-104.448 tagged_above=-999 required=5 tests=[AWL=1.151, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2g774WbhkJh9 for ; Thu, 25 Aug 2011 13:26:23 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id D881321F8B1D for ; Thu, 25 Aug 2011 13:26:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKuuVk6HCzI1/2dsb2JhbABDqAV3gUABAQUSKE8CAQgNCh8QMh0IAQEEARoRCaYeApwbhWxgBJhEi2w X-IronPort-AV: E=Sophos;i="4.68,282,1312171200"; d="scan'208";a="264484911" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 25 Aug 2011 15:56:44 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 25 Aug 2011 15:47:12 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 25 Aug 2011 15:55:43 -0400 From: "Worley, Dale R (Dale)" To: sunil kumar sinha , "dispatch@ietf.org" Date: Thu, 25 Aug 2011 15:55:43 -0400 Thread-Topic: [dispatch] New Draft - draft-sinha-dispatch-sip-continuation-option Thread-Index: AcxiRKMJcNoF4T3pTyikLnOSja1Y2wBGmHM5 Message-ID: References: <20110824100002.11118.qmail@f5mail-224-156.rediffmail.com> In-Reply-To: <20110824100002.11118.qmail@f5mail-224-156.rediffmail.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: [dispatch] New Draft - draft-sinha-dispatch-sip-continuation-option X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 20:26:23 -0000 I have just skimmed this draft. Some comments that come to mind are: The use and operation of the mechanism is not very clearly stated. In part= icular, there should be a narrative of the specific items in the messages that perf= orm the call queueing and continuation operations, and their significance to th= e users. E.g., I see no place stating "When the callee receives the INVITE but would= prefer not to be alerted, it sends a 182 response with "Require: continue" header.= .." As Paul has noted, the use of "Require: continue" is not correct. The mean= ing of that header is "The UAS must reject the request if it does not implement th= e extension named 'continue'." In this case, we are adding an indication to a 182 resp= onse to mean, "the call has been queued and will remain queued unless the UAS recei= ves a PRACK with 'Continue: yes'", which is much different. For that matter, why not allocate another 18x response specifically to carr= y this meaning? Given the use of PRACK, the UAC and UAS must support 100rel for this mechan= ism to work. That needs to be explicitly stated. The example message flows should show the INVITEs, even if they are no diff= erent from other situations. At the least, "Supported: 100rel" should be shown, = as that is necessary for the UAS to be able to use the continue mechanism. The short form of the header name is "cn", while all the other short forms = are a single letter. I would prefer to use the Priority header to control such a facility: 20.26 Priority The Priority header field indicates the urgency of the request as perceived by the client. The Priority header field describes the priority that the SIP request should have to the receiving human or its agent. For example, it may be factored into decisions about call routing and acceptance. For these decisions, a message containing no Priority header field SHOULD be treated as if it specified a Priority of "normal". The Priority header field does not influence the use of communications resources such as packet forwarding priority in routers or access to circuits in PSTN gateways. The header field can have the values "non-urgent", "normal", "urgent", and "emergency", but additional values can be defined elsewhere. It is RECOMMENDED that the value of "emergency" only be used when life, limb, or property are in imminent danger. Otherwise, there are no semantics defined for this header field. These are the values of RFC 2076 [38], with the addition of "emergency". Examples: Subject: A tornado is heading our way! Priority: emergency or Subject: Weekend plans Priority: non-urgent Dale From john.elwell@siemens-enterprise.com Fri Aug 26 02:28:54 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E489721F8B38 for ; Fri, 26 Aug 2011 02:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.845 X-Spam-Level: X-Spam-Status: No, score=-102.845 tagged_above=-999 required=5 tests=[AWL=-0.846, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xYNjgNrJWNu for ; Fri, 26 Aug 2011 02:28:52 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9426721F8B27 for ; Fri, 26 Aug 2011 02:28:51 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id A190823F04AC; Fri, 26 Aug 2011 11:29:58 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 26 Aug 2011 11:29:58 +0200 From: "Elwell, John" To: Paul Kyzivat , "dispatch@ietf.org" Date: Fri, 26 Aug 2011 11:29:57 +0200 Thread-Topic: [dispatch] New Draft - draft-sinha-dispatch-sip-continuation-option Thread-Index: AcxjN8HvRdlIxDWlTyqIVmRk4RGxjAAmZXvg Message-ID: References: <20110824100002.11118.qmail@f5mail-224-156.rediffmail.com> <4E566392.1070405@alum.mit.edu> In-Reply-To: <4E566392.1070405@alum.mit.edu> 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: [dispatch] New Draft - draft-sinha-dispatch-sip-continuation-option X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 09:28:54 -0000 The problem with a mechanism like this is that the special capability desir= ed by the callee is only available if the caller's device supports this pro= posed new extension, so in many situations it simply would not work as requ= ired, and the default behaviour would be that the call is not established. Another approach would be to answer the call and play an announcement, stat= ing something like "hold the line if there is an urgent need to proceed wit= h this call", and then put it through if the caller has not cleared within = a given number of seconds. If you really want the caller to take positive a= ction to proceed, DTMF could be used, which would then also work for PSTN c= allers. OK, this is old-fashioned technology, but it would work pretty well= universally and people are comfortable with this sort of thing. For a superior experience where the entities involved provide appropriate s= upport, something based on presence, as already proposed, would be more app= ropriate, perhaps coupled with Priority. A technical point: the proposed use of PRACK is a bit of an abuse. It requi= res delaying the PRACK while waiting for the caller to decide whether to pr= oceed or not. So it might cause the 182 to be repeated a number of times. I= don't know whether that matters, but it was not what PRACK was designed fo= r. John John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 25 August 2011 16:01 > To: dispatch@ietf.org > Subject: Re: [dispatch] New Draft -=20 > draft-sinha-dispatch-sip-continuation-option >=20 > Sunil, >=20 > I'm having trouble understanding the assumptions and intended use of=20 > this mechanism. I also think there are probably other ways of=20 > accomplishing something similar. >=20 > Some comments and questions on the draft: >=20 > Figure 2: >=20 > You don't show the F1 message. Does it contain=20 > 'Supported:continue'? If=20 > not, then putting Require:continue in the response is very=20 > questionable,=20 > since it can't be refused in a response. >=20 > Is it intended that the 182 + Require:continue is to be=20 > interpreted by=20 > the UAC as indicating that the call hasn't yet alerted, and=20 > won't unless=20 > Continue:yes is sent? >=20 > (That is an improper use of Require. It is supposed to mean=20 > "I require=20 > that you *support* this option", not that I require you to use it.) >=20 > Also, what is the intended behavior when the UAC does not=20 > support this=20 > mechanism? If it receives a 182 response, it will probably=20 > treat it just=20 > like a 180 and wait, assuming the call is alerting and will=20 > eventually=20 > be answered. Or does the UAS note there is no Supported:continue and=20 > return 486 rather than 182? >=20 > Section 4: >=20 > IIUC this lists a number of cases where this feature might be=20 > used, yet=20 > to the UAC these are all indicated in the same way. So the=20 > user of the=20 > UAC has no idea why he is being asked to confirm or deny the=20 > importance=20 > of his call. >=20 > General comments: >=20 > This seems to be yet another spin on presence. Have you=20 > investigated how=20 > you might explicitly use presence for this? For instance, the=20 > UAS that=20 > wants this behavior could refuse (perhaps with 486) any call that=20 > doesn't have a Priority header with a sufficiently high value. In the=20 > response it could include a PIDF in the body (or content=20 > indirection to=20 > one). Then the UAC could interpret that, interact with its user, and=20 > perhaps generate another INVITE with a Priority header. >=20 > Or, UACs that support this mechanism could simply subscribe=20 > to presence=20 > of the callee before sending the invite, and make a decision=20 > how to make=20 > the call based on what is received. >=20 > Or, if you really feel its essential to do this with one invite, an=20 > existing mechanism to defer alerting is through use of preconditions.=20 > You could conceivably create a new precondition type to get=20 > the desired=20 > effect. (But this direction isn't appealing to me.) >=20 > Most, I suggest you spend more time refining the requirements before=20 > getting involved in the mechanism. >=20 > Thanks, > Paul >=20 > On 8/24/11 6:00 AM, sunil kumar sinha wrote: > > Hi Everyone, > > > > This draft proposed a mechanism to resolve the problem -=20 > when callee is > > not in a favorable state to accepts incoming calls. > >=20 > http://tools.ietf.org/id/draft-sinha-dispatch-sip-continuation > -option-00.txt > > > > Unfavorable condition highlighted in the draft are -1)=20 > Caller and Callee > > both are in different time-zone 2) Callee is in a=20 > mild-DND(NDDND) state. > > Unfortunately, there could be a number of factors that=20 > contribute to the > > above un-favorable condition for a callee . > > > > But at the same time under such a case, non-emergency calls=20 > needs to be > > avoided and emergency calls needs to be communicated - is=20 > addressed in > > the draft. > > > > Comments on the draft or which WG it should go to are much > > appreciated. Please let us know your thoughts. > > > > Best regards, > > Sunil Kumar Sinha > > > > > >=20 > fmail.com/signatureline.htm@Middle?> > > > > > > Treat yourself at a restaurant, spa, resort and much more=20 > with *Rediff > > Deal ho jaye! > >=20 > .com?sc_cid=3Dmailsignature___&cmp=3Dsignature&lnk=3Drediffmailsigna > ture&newservice=3Ddeals>* > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From dworley@avaya.com Fri Aug 26 08:57:44 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F98821F89BA for ; Fri, 26 Aug 2011 08:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.465 X-Spam-Level: X-Spam-Status: No, score=-103.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azWjdKgrMa6y for ; Fri, 26 Aug 2011 08:57:43 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 90B0C21F8770 for ; Fri, 26 Aug 2011 08:57:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAF/CV07GmAcF/2dsb2JhbABCqCJ3gUABAgEDEihRAQgNKUInBBsaoWOECAKcMoVsYASYRYtx X-IronPort-AV: E=Sophos;i="4.68,285,1312171200"; d="scan'208";a="300091024" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 26 Aug 2011 11:58:59 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Aug 2011 11:54:53 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Fri, 26 Aug 2011 11:58:58 -0400 From: "Worley, Dale R (Dale)" To: "dispatch@ietf.org" Date: Fri, 26 Aug 2011 11:54:09 -0400 Thread-Topic: [dispatch] New Draft - draft-sinha-dispatch-sip-continuation-option Thread-Index: AQHMZAkQshyIhMtpe0+uXw/AkqC/yw== Message-ID: 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: [dispatch] New Draft - draft-sinha-dispatch-sip-continuation-option X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 15:57:44 -0000 An alternative approach would be to use the Priority header in the initial = INVITE, allowing the UAS to decide whether it wanted to accept the call based on it= s priority. This would have the advantage that if the call was not high prio= rity, the call could be immediately sent to an alternative destination (e.g., voi= cemail). However, this behavior is sociologically different from the draft, as it re= quires the caller to decide on the call's priority before initiating the call, and to = indicate high priority before discovering that the callee was filtering based on priority= . Another approach would be that if the Priority in the initial INVITE is not= high, the UAS would respond with (say) "184 Inadequate Priority". The caller cou= ld then send an UPDATE to the UAS with "Priority: high". Another aspect of this is the matter of presence information. I have not n= oticed any of our models of presence allowing a way to indicate "available for hig= h-priority requests but not normal-priority requests". Dale From rmohanr@cisco.com Mon Aug 29 07:08:53 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AC821F8B11 for ; Mon, 29 Aug 2011 07:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.387 X-Spam-Level: X-Spam-Status: No, score=-7.387 tagged_above=-999 required=5 tests=[AWL=-2.289, BAYES_50=0.001, HS_INDEX_PARAM=0.001, J_CHICKENPOX_83=0.6, MANGLED_DEALS=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-onMYM3vGpE for ; Mon, 29 Aug 2011 07:08:52 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 74CE521F8B0D for ; Mon, 29 Aug 2011 07:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=4913; q=dns/txt; s=iport; t=1314627016; x=1315836616; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=bzkkfQpM0fuwdiWIaNe9JdNUvwQbcXUbOZAnG74Tc3c=; b=VeF7ReZb98gTNQS+3KuC219VOgpPTguyx+IZO0CR8eqTQqju+tV5ZTaf 72rj6Z8TOJfOAblmRcvjTMKnZbW+x8gxJ8DmYdnfCHOpM7iPRhlFz4hyo BEolT98c7WWsngaXC/s5pX2CkQW5vnVdHhcXTDyOcdwuJSIAPDWWpAT5j c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQAALCcW05Io8UQ/2dsb2JhbABCmCeKdoRkd4FAAQEBAQMBAQEPAR0KNBcEAgEIEQQBAQEKAgQXAQYBJh8JCAEBBAsICBMHh1SZfwGeWoVsYASHYpBUi3U X-IronPort-AV: E=Sophos;i="4.68,296,1312156800"; d="scan'208";a="52482586" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 29 Aug 2011 14:10:14 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7TEADrW003319 for ; Mon, 29 Aug 2011 14:10:13 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Aug 2011 19:40:13 +0530 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, 29 Aug 2011 19:40:11 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD077D811C@XMB-BGL-417.cisco.com> In-Reply-To: <4E566392.1070405@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] New Draft -draft-sinha-dispatch-sip-continuation-option Thread-Index: AcxjN9EOaDeXWWSSRjieoiYzLZBCZwDHP+Dw References: <20110824100002.11118.qmail@f5mail-224-156.rediffmail.com> <4E566392.1070405@alum.mit.edu> From: "Ram Mohan R (rmohanr)" To: X-OriginalArrivalTime: 29 Aug 2011 14:10:13.0519 (UTC) FILETIME=[5EC601F0:01CC6655] Subject: Re: [dispatch] New Draft -draft-sinha-dispatch-sip-continuation-option X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 14:08:53 -0000 Sunil, I skimmed through the draft and I have the same question asked by Paul and others. My first impression after reading the problem is a solution based of presence ( as already suggested by Paul in his first general comment) can be used. Any reasons why you feel the current mechanisms are not sufficient and there is a need for the new mechanism ? Regards, Ram > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Thursday, August 25, 2011 8:31 PM > To: dispatch@ietf.org > Subject: Re: [dispatch] New Draft -draft-sinha-dispatch-sip- > continuation-option >=20 > Sunil, >=20 > I'm having trouble understanding the assumptions and intended use of > this mechanism. I also think there are probably other ways of > accomplishing something similar. >=20 > Some comments and questions on the draft: >=20 > Figure 2: >=20 > You don't show the F1 message. Does it contain 'Supported:continue'? If > not, then putting Require:continue in the response is very > questionable, > since it can't be refused in a response. >=20 > Is it intended that the 182 + Require:continue is to be interpreted by > the UAC as indicating that the call hasn't yet alerted, and won't > unless > Continue:yes is sent? >=20 > (That is an improper use of Require. It is supposed to mean "I require > that you *support* this option", not that I require you to use it.) >=20 > Also, what is the intended behavior when the UAC does not support this > mechanism? If it receives a 182 response, it will probably treat it > just > like a 180 and wait, assuming the call is alerting and will eventually > be answered. Or does the UAS note there is no Supported:continue and > return 486 rather than 182? >=20 > Section 4: >=20 > IIUC this lists a number of cases where this feature might be used, yet > to the UAC these are all indicated in the same way. So the user of the > UAC has no idea why he is being asked to confirm or deny the importance > of his call. >=20 > General comments: >=20 > This seems to be yet another spin on presence. Have you investigated > how > you might explicitly use presence for this? For instance, the UAS that > wants this behavior could refuse (perhaps with 486) any call that > doesn't have a Priority header with a sufficiently high value. In the > response it could include a PIDF in the body (or content indirection to > one). Then the UAC could interpret that, interact with its user, and > perhaps generate another INVITE with a Priority header. >=20 > Or, UACs that support this mechanism could simply subscribe to presence > of the callee before sending the invite, and make a decision how to > make > the call based on what is received. >=20 > Or, if you really feel its essential to do this with one invite, an > existing mechanism to defer alerting is through use of preconditions. > You could conceivably create a new precondition type to get the desired > effect. (But this direction isn't appealing to me.) >=20 > Most, I suggest you spend more time refining the requirements before > getting involved in the mechanism. >=20 > Thanks, > Paul >=20 > On 8/24/11 6:00 AM, sunil kumar sinha wrote: > > Hi Everyone, > > > > This draft proposed a mechanism to resolve the problem - when callee > is > > not in a favorable state to accepts incoming calls. > > http://tools.ietf.org/id/draft-sinha-dispatch-sip-continuation- > option-00.txt > > > > Unfavorable condition highlighted in the draft are -1) Caller and > Callee > > both are in different time-zone 2) Callee is in a mild-DND(NDDND) > state. > > Unfortunately, there could be a number of factors that contribute to > the > > above un-favorable condition for a callee . > > > > But at the same time under such a case, non-emergency calls needs to > be > > avoided and emergency calls needs to be communicated - is addressed > in > > the draft. > > > > Comments on the draft or which WG it should go to are much > > appreciated. Please let us know your thoughts. > > > > Best regards, > > Sunil Kumar Sinha > > > > > > > /signatureline.htm@Middle?> > > > > > > Treat yourself at a restaurant, spa, resort and much more with > *Rediff > > Deal ho jaye! > > > id=3Dmailsignature___&cmp=3Dsignature&lnk=3Drediffmailsignature&newservic= e=3Dde > als>* > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From sunilkumarsinha9@rediffmail.com Mon Aug 29 15:38:04 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851DA21F8C97 for ; Mon, 29 Aug 2011 15:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.027 X-Spam-Level: *** X-Spam-Status: No, score=3.027 tagged_above=-999 required=5 tests=[AWL=-0.931, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, MSGID_FROM_MTA_HEADER=0.803, SARE_SUB_ENC_UTF8=0.152, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v67hHRa65fSO for ; Mon, 29 Aug 2011 15:38:03 -0700 (PDT) Received: from rediffmail.com (f5mail-224-128.rediffmail.com [114.31.224.128]) by ietfa.amsl.com (Postfix) with SMTP id D732C21F8C95 for ; Mon, 29 Aug 2011 15:38:01 -0700 (PDT) Received: (qmail 9211 invoked by uid 510); 29 Aug 2011 22:39:18 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=redf; d=rediffmail.com; b=WnH877GodYKjYhouTDRjkL3eA8vd851DnvxjIStrduUU9Er2730t+Wb86xNxPeSvAndw3KjLl1DDcf9BIvXLfy+yE77AHwKdfXnY0/wHASZqO/A0dxaqMp+fFAb+4xTxwNPU8ER9ufagj4MDMbEGUSmHDLifP1qip5C6LBs/haQ= ; x-m-msg: asd54ad564ad7aa6sd5as6d5; a6da7d6asas6dasd77; 5dad65ad5sd; X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-Flags: : 0 X-CTCH-RefID: str=0001.0A150201.4E5C1518.0114,ss=1,re=-2.300,fgs=0 Date: 29 Aug 2011 22:39:18 -0000 Message-ID: <20110829223918.9191.qmail@f5mail-224-128.rediffmail.com> MIME-Version: 1.0 To: , , , Received: from unknown 86.179.190.9 by rediffmail.com via HTTP; 29 Aug 2011 22:39:18 -0000 From: "sunil kumar sinha" Content-Type: multipart/alternative; boundary="=_bf07a24b1b1668d18328bac12ac9c9c6" Cc: dispatch@ietf.org, de_subhrajyoti@yahoo.co.uk Subject: Re: [dispatch] =?utf-8?q?New_Draft_-_draft-sinha-dispatch-sip-continu?= =?utf-8?q?ation-option?= X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 22:38:04 -0000 --=_bf07a24b1b1668d18328bac12ac9c9c6 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Dear All Please find my answers inline wrt Paul Question. I am keeping everyone in loop for discussion so that most of the common queries I think has been addressed. In case there is any other question / clarification needed, please let us know. We will incorporate your valuable feedbacks based on the agreed items in our next document version. Once again many thanks for your valuable feedbacks, much appreciate your valuable inputs and time.  Regards Sunil kumar sinha     Sunil,I'm having trouble understanding the assumptions and intended use of this mechanism. I also think there are probably other ways of accomplishing something similar. [Sunil] Intended use: Applications as mentioned in Section 4, this is used as Called Party Voice feature service when Callee is not in a favorable state to receive calls, Callee is NOT in DND and can accept calls, Callee can set a parameter called NDDND (Non Dedicated Do Not Disturb) in Handsets / IP Devices or with NSP which initiates the mentioned 182 response on receiving INVITE instead of 180 Ringing from Handset or VFS as the case may be based on the configuration, finally its upto the sole discretion of Caller to make progress with placing the call or disconnect. Detailed Call Flow given in the proposal. We have studied all the methodologies and SIP parameters and found it difficult to incorporate this feature, so proposed this new SIP Header “Continue” with the designed call flows  and behavior at UEs and Proxies. Some comments and questions on the draft:Figure 2:You don't show the F1 message. Does it contain 'Supported:continue'? If not, then putting Require: continue in the response is very questionable, since it can't be refused in a response. [Sunil] INVITE contains “Supported: continue”, we will make the needful addition of INVITE (F1) in call flow as suggested by you in the next version. Thanks for your valuable suggestion.Is it intended that the 182 + Require: continue is to be interpreted by the UAC as indicating that the call hasn't yet alerted, and won't unless Continue:yes is sent? [Sunil] Correct (That is an improper use of Require. It is supposed to mean "I require that you *support* this option", not that I require you to use it.) [Sunil] Latter meaning holds good for the usage of “Require: continue” header, we have also portrayed in the same way. If there’s anything else you would like to know or want us to incorporate anything else,pls let us know Also, what is the intended behavior when the UAC does not support this mechanism? If it receives a 182 response, it will probably treat it just like a 180 and wait, assuming the call is alerting and will eventually be answered. Or does the UAS note there is no Supported:continue and return 486 rather than 182? [Sunil] Agreed, accept your point fully, this is the case when caller doesn’t support this mechanism but callee does, so NDDND will not work for callee as the concept behind the usage of NDDND as a called party voice feature is to give option to the supported caller to display an option whether to finally place a call or not, the call will be placed based on the sole discretion of Caller. If Caller doesn’t support this functionality whether a DND will be flagged or Normal Call Treatment to be done I feel need to be again a configuration dependent on the Device/NSP or Device manufacturer / Service Provider implementation specific. I will incorporate the outcome behavior of this scenario in the next version after discussing with co-authors. Many thanks for your valuable feedbacks. In this case 182 won’t be responded by Callee, either 180 or 486 would be responded Section 4:IIUC this lists a number of cases where this feature might be used, yet to the UAC these are all ind icated in the same way. So the user of the UAC has no idea why he is being asked to confirm or deny the importance of his call. [Sunil] This is described above.  Pls let me know if you have any questions. General comments:This seems to be yet another spin on presence. Have you investigated how you might explicitly use presence for this? For instance, the UAS that wants this behavior could refuse (perhaps with 486) any call that doesn't have a Priority header with a sufficiently high value. In the response it could include a PIDF in the body (or content indirection to one). Then the UAC could interpret that, interact with its user, and perhaps generate another INVITE with a Priority header. [Sunil] I agree to most of your points on the usage of Priority header, except one scenario which cannot be implemented. If Called Party supports the feature and Caller doesn’t support Priority, then this feature will be just DND. Our purpose is not to have DND by any means. In our case decision to treat this feature or not at the Callee although it is set at Callee based on Supported: continue present in initial INVITE from Caller. If Caller is not up-to-date with this feature, then he doesn’t send Supported: continue in initial INVITE and this call is treated as Normal Call with 180 Ringing sent by Called Party suppressing the feature set at Called Party. My apologies we haven’t put all the combination of scenarios in the first version of draft, we will send all position combination in our next version. Once again many thanks for your valuable feedbacks.Or, UACs that support this mechanism could simply subscribe to presence of the callee before sending the invite, and make a decision how to make the call based on what is received.  [Sunil] Not all Handsets supports this.  Or, if you really feel its essential to do this with one invite, an existing mechanism to defer alerting is through use of preconditions. You could conceivably create a new precondition type to get the desired effect. (But this direction isn't appealing to me.)Most, I suggest you spend more time refining the requirements before getting involved in the mechanism.Thanks,Paul --=_bf07a24b1b1668d18328bac12ac9c9c6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8"

Dear All


Please find my answers inline wrt Paul Question. I am keeping ev= eryone in loop for discussion so that most of the common queries I think ha= s been addressed. In case there is any other question / clarification neede= d, please let us know. We will incorporate your valuable feedbacks based on= the agreed items in our next document version.


Once again many thanks for your valuable feedbacks, much appreci= ate your valuable inputs and time.


 Regards


Sunil kumar sinha


 


 


Sunil,
<= BR>I'm having trouble understanding the assumptions and intended use of thi= s mechanism. I also think there are probably other ways of
accomplishin= g something similar.


[Sunil] Intended use: Applications as mentioned = in Section 4, this is used as Called Party Voice feature service when Calle= e is not in a favorable state to receive calls, Callee is NOT in DND and can accept calls, Callee can se= t a parameter called NDDND (Non Dedicated Do Not Disturb) in Handsets / IP = Devices or with NSP which initiates the mentioned 182 response on receiving= INVITE instead of 180 Ringing from Handset or VFS as the case may be based= on the configuration, finally its upto the sole discretion of Caller to ma= ke progress with placing the call or disconnect. Detailed Call Flow given i= n the proposal. We have studied all the methodologies and SIP parameters an= d found it difficult to incorporate this feature, so proposed this new SIP = Header =E2=80=9CContinue=E2=80=9D with the designed call flows  and behavior at UEs and Proxies.


[Sunil] INVITE contains =E2=80=9CSupported: cont= inue=E2=80=9D, we will make the needful addition of INVITE (F1) in call flo= w as suggested by you in the next version. Thanks for your valuable suggest= ion.

Is it intended that the 182 + Require= : continue is to be interpreted by the UAC as indicating that the call hasn= 't yet alerted, and won't unless Continue:yes is sent?


[Sunil] Correct
(That is an improper use of Require. It is supposed to mean "I require th= at you *support* this option", not that I require you to use it.)

[Sunil] Latter meaning holds good for the usage = of =E2=80=9CRequire: continue=E2=80=9D header, we have also portrayed in th= e same way. If there=E2=80=99s anything else you would like to know or want= us to incorporate anything else,pls let us know



Also, w= hat is the intended behavior when the UAC does not support this mechanism? = If it receives a 182 response, it will probably treat it just like a 180 an= d wait, assuming the call is alerting and will eventually be answered. Or d= oes the UAS note there is no Supported:continue and return 486 rather than = 182?


[Sunil] Agreed, accept your point fully, this is= the case when caller doesn=E2=80=99t support this mechanism but callee doe= s, so NDDND will not work for callee as the concept behind the usage of NDD= ND as a called party voice feature is to give option to the supported calle= r to display an option whether to finally place a call or not, the call wil= l be placed based on the sole discretion of Caller. If Caller doesn=E2=80= =99t support this functionality whether a DND will be flagged or Normal Cal= l Treatment to be done I feel need to be again a configuration dependent on= the Device/NSP or Device manufacturer / Service Provider implementation sp= ecific. I will incorporate the outcome behavior of this scenario in the nex= t version after discussing with co-authors. Many thanks for your valuable f= eedbacks. In this case 182 won=E2=80=99t be responded by Callee, either 180= or 486 would be responded

Section 4:
=
IIUC this lists a number of cases where this feature might be used, yet= to the UAC these are all indicated in the same way. So the user of the UAC= has no idea why he is being asked to confirm or deny the importance of his= call.


[Sunil] This is described above.  Pls let me know if you have any questions.




Gen= eral comments:

This seems to be yet another spin on presence. Have y= ou investigated how you might explicitly use presence for this? For instanc= e, the UAS that wants this behavior could refuse (perhaps with 486) any cal= l that doesn't have a Priority header with a sufficiently high value. In th= e response it could include a PIDF in the body (or content indirection to o= ne). Then the UAC could interpret that, interact with its user, and perhaps= generate another INVITE with a Priority header.


[Sunil] I agree to most of your points on the us= age of Priority header, except one scenario which cannot be implemented. If= Called Party supports the feature and Caller doesn=E2=80=99t support Prior= ity, then this feature will be just DND. Our purpose is not to have DND by = any means. In our case decision to treat this feature or not at the Callee = although it is set at Callee based on Supported: continue present in initia= l INVITE from Caller. If Caller is not up-to-date with this feature, then h= e doesn=E2=80=99t send Supported: continue in initial INVITE and this call = is treated as Normal Call with 180 Ringing sent by Called Party suppressing= the feature set at Called Party. My apologies we haven=E2=80=99t put all t= he combination of scenarios in the first version of draft, we will send all= position combination in our next version. Once again many thanks for your = valuable feedbacks.

Or, UACs that support = this mechanism could simply subscribe to presence of the callee before send= ing the invite, and make a decision how to make the call based on what is r= eceived.



 [Sunil] Not all Handsets supports this.


 
Or, if you really= feel its essential to do this with one invite, an existing mechanism to de= fer alerting is through use of preconditions.
You could conceivably cre= ate a new precondition type to get the desired effect. (But this direction = isn't appealing to me.)

Most, I suggest you spend more time refining= the requirements before getting involved in the mechanism.

Thanks,<= BR>Paul





Treat yourself at a restaurant, spa, reso= rt and much more with Rediff Deal ho = jaye! --=_bf07a24b1b1668d18328bac12ac9c9c6--