From bliss-bounces@ietf.org Mon Jan 15 21:28:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6e3Z-00088Q-HM; Mon, 15 Jan 2007 21:28:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6e3Y-00088H-AZ for Bliss@ietf.org; Mon, 15 Jan 2007 21:28:12 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6e3L-0002KG-IR for Bliss@ietf.org; Mon, 15 Jan 2007 21:28:12 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 15 Jan 2007 18:27:59 -0800 X-IronPort-AV: i="4.13,193,1167638400"; d="scan'208"; a="101917864:sNHT35476704" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0G2Rwid015909 for ; Mon, 15 Jan 2007 18:27:58 -0800 Received: from [192.168.1.5] (sjc-vpn7-452.cisco.com [10.21.145.196]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l0G2RiV0029074 for ; Mon, 15 Jan 2007 18:27:58 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <1353EFF8-D5FC-4722-BC8C-B4041BE5874E@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Bliss@ietf.org From: Cullen Jennings Date: Mon, 15 Jan 2007 18:25:58 -0800 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=17; t=1168914478; x=1169778478; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20test=202 |Sender:=20 |To:=20Bliss@ietf.org |Content-Type:=20text/plain=3B=20charset=3DUS-ASCII=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0=20(Apple=20Message=20framework=20v752.3); bh=cVHIhhMRWLXeK9ljFRy3BSKY5kzenOIl8p2T2OVroeY=; b=LMXtFgnC6eICvnpjiydnMmPLaS2r5kXypN7iY3PV3f9s+keaLMRv8rjHYsoLyMoYGqejuwV1 obQxPZOLaCPJ6qC7+PWo6Xj5dL+aikqbqO/Nl1MlxOt8C+UCVqSTbPiKKUK9FtXQQE27W1Ajvd 84N1XlgxScKASNr4GDlXNuxLQ=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Cc: Subject: [BLISS] test 2 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org test to bliss _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Jan 19 16:23:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H81D4-0002wm-8W; Fri, 19 Jan 2007 16:23:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H81D2-0002wh-FL for bliss@ietf.org; Fri, 19 Jan 2007 16:23:40 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H81D1-0005V8-6w for bliss@ietf.org; Fri, 19 Jan 2007 16:23:40 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 19 Jan 2007 13:23:38 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l0JLNcOM029872 for ; Fri, 19 Jan 2007 13:23:38 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0JLNMnf005336 for ; Fri, 19 Jan 2007 13:23:38 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 16:23:24 -0500 Received: from jmpolk-wxp.cisco.com ([10.89.20.45]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 16:23:24 -0500 Message-Id: <4.3.2.7.2.20070119152259.029bceb8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 19 Jan 2007 15:23:23 -0600 To: bliss@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 19 Jan 2007 21:23:24.0425 (UTC) FILETIME=[0D564790:01C73C10] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2; t=1169241818; x=1170105818; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20test=20please=20ignore |Sender:=20; bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=; b=bwPWogNqfEKFIFzE7ctDQRQQ8wCiCIF/szR/dnHteOC7AMw4DWZrJGBQAPL+ThSJnL2ZWEp9 oAIKd34c8meK9BYt6NGf0/O/k1MrbEx1zd1qTCbUAi0Vqr9zjF1DfnFf; Authentication-Results: sj-dkim-6; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 Subject: [BLISS] test please ignore X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Jan 19 17:14:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H820c-0002ga-LI; Fri, 19 Jan 2007 17:14:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H820b-0002gP-Oq for bliss@ietf.org; Fri, 19 Jan 2007 17:14:53 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H820a-0002Xo-E8 for bliss@ietf.org; Fri, 19 Jan 2007 17:14:53 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 19 Jan 2007 14:14:52 -0800 X-IronPort-AV: i="4.13,213,1167638400"; d="scan'208"; a="458561857:sNHT44535144" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0JMEppX027753 for ; Fri, 19 Jan 2007 14:14:51 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0JMEoGm003070 for ; Fri, 19 Jan 2007 14:14:50 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 14:14:37 -0800 Received: from [10.32.241.158] ([10.32.241.158]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 14:14:37 -0800 Message-ID: <45B142CC.3070508@cisco.com> Date: Fri, 19 Jan 2007 17:14:36 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bliss@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jan 2007 22:14:37.0772 (UTC) FILETIME=[3531D0C0:01C73C17] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=946; t=1169244891; x=1170108891; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Welcome!=20Main=20question=20-=20what=20services? |Sender:=20 |To:=20bliss@ietf.org |Content-Type:=20text/plain=3B=20charset=3Dus-ascii=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=ufpiC7W3kx/vqJy1EMf3+YJsinRCXsgXV+aspAzl5ks=; b=SoOLlqNNy/EXKTEEeYN76AZVyO8vV26gmSvgNGk88U2tqB7dFusJ4OXEmr1oFaaLLRhNbjJl i5jDFZeMkqffZqm55eSpjRpnVYpbbKxR71e+XcKfRkvtsCs9zXPDQQHwtTEQNmeRbXvR1l2JWo kxzvF8Op7EoHF+WBy9k4Gik9U=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.9 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [BLISS] Welcome! Main question - what services? X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org If you haven't done so already, everyone please take a look at the charter: http://sip101.net/charter.html In my mind, the main question to be answered is what features we want to work on, and in what order. We've chosen four to begin with - BLA, pickup, DND, and CCBS, since these have been reported to be the most problematic. If anyone has comments on different ones they'd like to see worked on, please comment. Especially welcome are examples of REAL interop problems or hacks that have been put into place in real implementations and deployments to make something happen. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Jan 19 17:51:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H82Zq-0003j0-KR; Fri, 19 Jan 2007 17:51:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H82Zp-0003iv-Kv for bliss@ietf.org; Fri, 19 Jan 2007 17:51:17 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H82Zo-00024z-7w for bliss@ietf.org; Fri, 19 Jan 2007 17:51:17 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l0JMpCQ13258; Fri, 19 Jan 2007 17:51:12 -0500 (EST) 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 Subject: RE: [BLISS] Welcome! Main question - what services? Date: Fri, 19 Jan 2007 16:50:56 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0ECF5009@zrc2hxm0.corp.nortel.com> In-Reply-To: <45B142CC.3070508@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Welcome! Main question - what services? Thread-Index: Acc8F0P2VcnoS25SSW+iHY1CyrzVpQABHerg From: "Francois Audet" To: "Jonathan Rosenberg" , X-Spam-Score: 0.9 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Looks good. I'm not sure I like the text for DND equating it to "ingnore an incoming call". In some implementations, "Do Not Disturb", "Ignore" and "Decline" are different concepts. Your=20 description after is good because it hints at what the issues are. I'd suggest item 3 be renamed "Do Not Disturb/Ignore/Decline/Reject" or something along those=20 lines. It's the suttle differences between those that is important. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Friday, January 19, 2007 14:15 > To: bliss@ietf.org > Subject: [BLISS] Welcome! Main question - what services? >=20 > If you haven't done so already, everyone please take a look=20 > at the charter: >=20 > http://sip101.net/charter.html >=20 > In my mind, the main question to be answered is what features=20 > we want to work on, and in what order. We've chosen four to=20 > begin with - BLA, pickup, DND, and CCBS, since these have=20 > been reported to be the most problematic. >=20 > If anyone has comments on different ones they'd like to see=20 > worked on, please comment. Especially welcome are examples of=20 > REAL interop problems or hacks that have been put into place=20 > in real implementations and deployments to make something happen. >=20 > Thanks, > Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Jan 19 17:59:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H82hY-0007QI-Fm; Fri, 19 Jan 2007 17:59:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H82hX-0007NV-KR for bliss@ietf.org; Fri, 19 Jan 2007 17:59:15 -0500 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H82hW-0003Vk-Ce for bliss@ietf.org; Fri, 19 Jan 2007 17:59:15 -0500 Received: from 24-107-197-43.dhcp.stls.mo.charter.com ([24.107.197.43] helo=[192.168.0.40]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1H82hV-000Fc8-Q2; Fri, 19 Jan 2007 17:59:13 -0500 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.197.43 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: digitalari Message-ID: <45B14D41.5010705@sipstation.com> Date: Fri, 19 Jan 2007 16:59:13 -0600 From: Alan Johnston User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [BLISS] Welcome! Main question - what services? References: <45B142CC.3070508@cisco.com> In-Reply-To: <45B142CC.3070508@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Those four are good to start with. I'm hearing a lot of interest in SIP enabling contact centers (or call centers). This requires a few things: 1. A good description of the problem space and the requirements 2. Remote call control capabilities 3. Ability to pass around call related information between elements I have not yet attempted #1 yet, although I do plan to work on it with others who understand the service well (volunteers?) For #2, I think draft-mahy-sip-remote-cc-04 is a very good start. Perhaps this group can demonstrate that there is interest and need for these REFER extensions so they can be worked in the SIP WG. For #3, I wrote a partial solution in draft-johnston-sipping-cc-uui-01. I think if we put effort into #1 it will become clearer what mechanism is best, so I would describe this draft as an example mechanism that is out there rather than the right mechanism. I think this is a very interesting problem to work on. The non-SIP solutions today are completely proprietary, so there is a huge opportunity to make a big impact on the industry if we can deliver the same functionality using open standards and SIP. However, I would expect to spend a good deal of time on requirements and use cases before we even started on mechanisms. Thanks, Alan Jonathan Rosenberg wrote: > If you haven't done so already, everyone please take a look at the > charter: > > http://sip101.net/charter.html > > In my mind, the main question to be answered is what features we want > to work on, and in what order. We've chosen four to begin with - BLA, > pickup, DND, and CCBS, since these have been reported to be the most > problematic. > > If anyone has comments on different ones they'd like to see worked on, > please comment. Especially welcome are examples of REAL interop > problems or hacks that have been put into place in real > implementations and deployments to make something happen. > > Thanks, > Jonathan R. _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Jan 19 18:27:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H838P-0004kt-Au; Fri, 19 Jan 2007 18:27:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H838O-0004ko-CN for bliss@ietf.org; Fri, 19 Jan 2007 18:27:00 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H838N-0007Pi-1K for bliss@ietf.org; Fri, 19 Jan 2007 18:27:00 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l0JNQqQ22837; Fri, 19 Jan 2007 18:26:53 -0500 (EST) 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 Subject: RE: [BLISS] Welcome! Main question - what services? Date: Fri, 19 Jan 2007 17:26:47 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0ECF509B@zrc2hxm0.corp.nortel.com> In-Reply-To: <45B14D41.5010705@sipstation.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Welcome! Main question - what services? Thread-Index: Acc8HXaJUHJA26OWRa6tzKd+uJIjFQAA85nQ From: "Francois Audet" To: "Alan Johnston" , "Jonathan Rosenberg" X-Spam-Score: 0.9 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Sounds reasonable to me.=20 > -----Original Message----- > From: Alan Johnston [mailto:alan@sipstation.com]=20 > Sent: Friday, January 19, 2007 14:59 > To: Jonathan Rosenberg > Cc: bliss@ietf.org > Subject: Re: [BLISS] Welcome! Main question - what services? >=20 > Those four are good to start with. >=20 > I'm hearing a lot of interest in SIP enabling contact centers=20 > (or call centers). This requires a few things: >=20 > 1. A good description of the problem space and the=20 > requirements 2. Remote call control capabilities 3. Ability=20 > to pass around call related information between elements >=20 > I have not yet attempted #1 yet, although I do plan to work=20 > on it with others who understand the service well=20 > (volunteers?) For #2, I think draft-mahy-sip-remote-cc-04 is=20 > a very good start. =20 > Perhaps this group can demonstrate that there is interest and=20 > need for these REFER extensions so they can be worked in the=20 > SIP WG. For #3, I wrote a partial solution in=20 > draft-johnston-sipping-cc-uui-01. I think if we put effort=20 > into #1 it will become clearer what mechanism is best, so I=20 > would describe this draft as an example mechanism that is out=20 > there rather than the right mechanism. >=20 > I think this is a very interesting problem to work on. The=20 > non-SIP solutions today are completely proprietary, so there=20 > is a huge opportunity to make a big impact on the industry if=20 > we can deliver the same functionality using open standards and SIP.=20 >=20 > However, I would expect to spend a good deal of time on=20 > requirements and use cases before we even started on mechanisms. >=20 > Thanks, > Alan >=20 > Jonathan Rosenberg wrote: > > If you haven't done so already, everyone please take a look at the > > charter: > > > > http://sip101.net/charter.html > > > > In my mind, the main question to be answered is what=20 > features we want=20 > > to work on, and in what order. We've chosen four to begin=20 > with - BLA,=20 > > pickup, DND, and CCBS, since these have been reported to be=20 > the most=20 > > problematic. > > > > If anyone has comments on different ones they'd like to see=20 > worked on,=20 > > please comment. Especially welcome are examples of REAL interop=20 > > problems or hacks that have been put into place in real=20 > > implementations and deployments to make something happen. > > > > Thanks, > > Jonathan R. >=20 >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Jan 19 22:43:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H878l-0007pw-Jc; Fri, 19 Jan 2007 22:43:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H878k-0007pR-3A for bliss@ietf.org; Fri, 19 Jan 2007 22:43:38 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H878i-0007Yp-TV for bliss@ietf.org; Fri, 19 Jan 2007 22:43:38 -0500 Received: from s73602 ([72.190.0.23]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20070120034334.QZJH20139.mta9.adelphia.net@s73602> for ; Fri, 19 Jan 2007 22:43:34 -0500 Message-ID: <003001c73c45$2dbc3eb0$6501a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <1ECE0EB50388174790F9694F77522CCF0ECF5009@zrc2hxm0.corp.nortel.com> Subject: Re: [BLISS] Welcome! Main question - what services? Date: Fri, 19 Jan 2007 21:43:41 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.9 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I agree with Francois' suggestion for renaming item 3. If we all agreed on what DND was, we wouldn't be having this conversation :-) Spencer From: "Francois Audet" Looks good. I'm not sure I like the text for DND equating it to "ingnore an incoming call". In some implementations, "Do Not Disturb", "Ignore" and "Decline" are different concepts. Your description after is good because it hints at what the issues are. I'd suggest item 3 be renamed "Do Not Disturb/Ignore/Decline/Reject" or something along those lines. It's the suttle differences between those that is important. _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Sat Jan 20 05:42:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8Dfi-0006ly-TD; Sat, 20 Jan 2007 05:42:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8Dfi-0006lC-2T for bliss@ietf.org; Sat, 20 Jan 2007 05:42:06 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8Dfg-0003bw-6b for bliss@ietf.org; Sat, 20 Jan 2007 05:42:06 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0KAde86009604; Sat, 20 Jan 2007 12:39:41 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 20 Jan 2007 12:41:59 +0200 Received: from [10.162.17.190] ([10.162.17.190]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 20 Jan 2007 12:41:59 +0200 Message-ID: <45B1F1F6.3000002@nokia.com> Date: Sat, 20 Jan 2007 12:41:58 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [BLISS] Welcome! Main question - what services? References: <45B142CC.3070508@cisco.com> In-Reply-To: <45B142CC.3070508@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jan 2007 10:41:59.0551 (UTC) FILETIME=[9CFA48F0:01C73C7F] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070120123941-253B7BB0-66B03C99/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.9 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I think it is reasonable to work on the approach that you propose, Jonathan. I have a couple of questions and comments about the proposed charter. 1) When the charter speaks about heterogeneous networks, does it refer only to SIP networks or does it consider interoperability across, say, the PSTN. I am sure the TISPAN guys will ask this question sooner or later, so better to write the answer, whatever it is, in the charter. 2) About DND. By reading the description I wasn't able to find any interoperability issues. Well, it is later described in the Issue. Perhaps the description should also add "... and associated triggers for other services" or something like that. A 3) A question on DND... I suspect that some people are implementing DND in a server... I think PoC has something similar, so the question is whether this service is going to consider also a "service that allows a callee to provide instructions to a server to ignore certain types of calls" or does it consider only a device centric approach? I am fine with the initial set of proposed services. /Miguel Jonathan Rosenberg wrote: > If you haven't done so already, everyone please take a look at the charter: > > http://sip101.net/charter.html > > In my mind, the main question to be answered is what features we want to > work on, and in what order. We've chosen four to begin with - BLA, > pickup, DND, and CCBS, since these have been reported to be the most > problematic. > > If anyone has comments on different ones they'd like to see worked on, > please comment. Especially welcome are examples of REAL interop problems > or hacks that have been put into place in real implementations and > deployments to make something happen. > > Thanks, > Jonathan R. -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Sun Jan 21 12:32:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8gYE-0006Xq-98; Sun, 21 Jan 2007 12:32:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8gYC-0006Xf-Oq for bliss@ietf.org; Sun, 21 Jan 2007 12:32:16 -0500 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H8gYA-0004Ml-0Z for bliss@ietf.org; Sun, 21 Jan 2007 12:32:16 -0500 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-14.tower-120.messagelabs.com!1169400731!17422557!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 2202 invoked from network); 21 Jan 2007 17:32:12 -0000 Received: from unknown (HELO attrh8i.attrh.att.com) (134.24.146.4) by server-14.tower-120.messagelabs.com with SMTP; 21 Jan 2007 17:32:12 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh8i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l0LHTgUq009432; Sun, 21 Jan 2007 12:29:42 -0500 (EST) Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by attrh8i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l0LHTWOZ009389; Sun, 21 Jan 2007 12:29:32 -0500 (EST) 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 Subject: RE: [BLISS] Welcome! Main question - what services? Date: Sun, 21 Jan 2007 11:32:01 -0600 Message-ID: <28F05913385EAC43AF019413F674A017101B7487@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <45B14D41.5010705@sipstation.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Welcome! Main question - what services? Thread-Index: Acc8HXjFF/nxQA1TTnKPawRqGxp0pwBZEo3Q From: "Dolly, Martin C, ALABS" To: "Alan Johnston" , "Jonathan Rosenberg" X-Spam-Score: 0.9 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org We are very interested in Call Centers and I would be willing to help.=20 -----Original Message----- From: Alan Johnston [mailto:alan@sipstation.com]=20 Sent: Friday, January 19, 2007 5:59 PM To: Jonathan Rosenberg Cc: bliss@ietf.org Subject: Re: [BLISS] Welcome! Main question - what services? Those four are good to start with. I'm hearing a lot of interest in SIP enabling contact centers (or call=20 centers). This requires a few things: 1. A good description of the problem space and the requirements 2. Remote call control capabilities 3. Ability to pass around call related information between elements I have not yet attempted #1 yet, although I do plan to work on it with=20 others who understand the service well (volunteers?) For #2, I think draft-mahy-sip-remote-cc-04 is a very good start. =20 Perhaps this group can demonstrate that there is interest and need for=20 these REFER extensions so they can be worked in the SIP WG. For #3, I=20 wrote a partial solution in draft-johnston-sipping-cc-uui-01. I think=20 if we put effort into #1 it will become clearer what mechanism is best,=20 so I would describe this draft as an example mechanism that is out there rather than the right mechanism. I think this is a very interesting problem to work on. The non-SIP=20 solutions today are completely proprietary, so there is a huge=20 opportunity to make a big impact on the industry if we can deliver the=20 same functionality using open standards and SIP.=20 However, I would expect to spend a good deal of time on requirements and use cases before we even started on mechanisms. Thanks, Alan Jonathan Rosenberg wrote: > If you haven't done so already, everyone please take a look at the=20 > charter: > > http://sip101.net/charter.html > > In my mind, the main question to be answered is what features we want=20 > to work on, and in what order. We've chosen four to begin with - BLA,=20 > pickup, DND, and CCBS, since these have been reported to be the most=20 > problematic. > > If anyone has comments on different ones they'd like to see worked on, > please comment. Especially welcome are examples of REAL interop=20 > problems or hacks that have been put into place in real=20 > implementations and deployments to make something happen. > > Thanks, > Jonathan R. _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Sun Jan 21 13:01:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8h0K-00025i-VR; Sun, 21 Jan 2007 13:01:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8h0J-00025c-Vm for bliss@ietf.org; Sun, 21 Jan 2007 13:01:19 -0500 Received: from plmler8.mail.eds.com ([199.228.142.115]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8h04-0007yM-RH for bliss@ietf.org; Sun, 21 Jan 2007 13:01:19 -0500 Received: from plmlir2.mail.eds.com (plmlir2-2.mail.eds.com [199.228.142.132]) by plmler8.mail.eds.com (8.13.8/8.12.10) with ESMTP id l0LI12se029652 for ; Sun, 21 Jan 2007 12:01:02 -0600 Received: from plmlir2.mail.eds.com (localhost [127.0.0.1]) by plmlir2.mail.eds.com (8.13.8/8.12.10) with ESMTP id l0LI0no3014512 for ; Sun, 21 Jan 2007 12:00:49 -0600 Received: from usut001.3Com.com ([205.142.126.149]) by plmlir2.mail.eds.com (8.13.8/8.12.10) with ESMTP id l0LI0lmY014503 for ; Sun, 21 Jan 2007 12:00:47 -0600 In-Reply-To: <28F05913385EAC43AF019413F674A017101B7487@OCCLUST04EVS1.ugd.att.com> From: Udit_Goyal@3com.com To: bliss@ietf.org Subject: RE: [BLISS] Welcome! Main question - what services? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: Date: Sun, 21 Jan 2007 12:59:57 -0500 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.5.5FP2|October 23, 2006) at 01/21/2007 10:00:48 AM, Serialize complete at 01/21/2007 10:00:48 AM X-Spam-Score: 1.1 (+) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0836036304==" Errors-To: bliss-bounces@ietf.org This is a multipart message in MIME format. --===============0836036304== Content-Type: multipart/alternative; boundary="=_alternative 00638E608525726A_=" This is a multipart message in MIME format. --=_alternative 00638E608525726A_= Content-Type: text/plain; charset="US-ASCII" Hi, It is really a good idea to have well-defined service behaviour for better interoperability among SIP implementation. I think the major problem that has been faced by almost every PBX vendor is how to make particular service working using feature codes. There is no clear method in SIP to communicate feature codes from SIP UA to PBX. Some uses INFO method, some NOTIFY ,and generally proprietary extensions to communicate that information. Since SIP recommends using RFC 2833 for DTMF digits, some guidelines should be provided for SIP UA as well as PBX provider to pass this information. For example, call park and unpark example given simply says call is put on hold and retrieve from nay other extension. But generally service providers ask user to dial particular park extension to park the call and another extension can dial that number to unpark the call. Again question arises how user dial park extension while call is active. If we can resolve this basic issue, it will really interop features easily among PBX vendors. We have mentioned Call park/pickup service, generally it is call park/unpark service. There is another directed pickup service available where user can pickup a call ringing on another extension by dialing pickup code. ACD/HG definitely requires attention as part of call center applications as it is getting more popular because of SIP wifi phones becoming as ACD agents roaming around in office. We are also willing to help for call center applications. What about MWB service (monitor whisper and barge-in)? -Udit "Dolly, Martin C, ALABS" 01/21/2007 12:32 PM To "Alan Johnston" , "Jonathan Rosenberg" cc bliss@ietf.org Subject RE: [BLISS] Welcome! Main question - what services? We are very interested in Call Centers and I would be willing to help. -----Original Message----- From: Alan Johnston [mailto:alan@sipstation.com] Sent: Friday, January 19, 2007 5:59 PM To: Jonathan Rosenberg Cc: bliss@ietf.org Subject: Re: [BLISS] Welcome! Main question - what services? Those four are good to start with. I'm hearing a lot of interest in SIP enabling contact centers (or call centers). This requires a few things: 1. A good description of the problem space and the requirements 2. Remote call control capabilities 3. Ability to pass around call related information between elements I have not yet attempted #1 yet, although I do plan to work on it with others who understand the service well (volunteers?) For #2, I think draft-mahy-sip-remote-cc-04 is a very good start. Perhaps this group can demonstrate that there is interest and need for these REFER extensions so they can be worked in the SIP WG. For #3, I wrote a partial solution in draft-johnston-sipping-cc-uui-01. I think if we put effort into #1 it will become clearer what mechanism is best, so I would describe this draft as an example mechanism that is out there rather than the right mechanism. I think this is a very interesting problem to work on. The non-SIP solutions today are completely proprietary, so there is a huge opportunity to make a big impact on the industry if we can deliver the same functionality using open standards and SIP. However, I would expect to spend a good deal of time on requirements and use cases before we even started on mechanisms. Thanks, Alan Jonathan Rosenberg wrote: > If you haven't done so already, everyone please take a look at the > charter: > > http://sip101.net/charter.html > > In my mind, the main question to be answered is what features we want > to work on, and in what order. We've chosen four to begin with - BLA, > pickup, DND, and CCBS, since these have been reported to be the most > problematic. > > If anyone has comments on different ones they'd like to see worked on, > please comment. Especially welcome are examples of REAL interop > problems or hacks that have been put into place in real > implementations and deployments to make something happen. > > Thanks, > Jonathan R. _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss --=_alternative 00638E608525726A_= Content-Type: text/html; charset="US-ASCII"
Hi,

It is really a good idea to have well-defined service behaviour for better interoperability among SIP implementation.

I think the major problem that has been faced by almost every PBX vendor is how to make particular service working using feature codes. There is no clear method in SIP to communicate feature codes from SIP UA to PBX. Some uses INFO method, some NOTIFY ,and generally proprietary extensions to communicate that information. Since SIP recommends using RFC 2833 for DTMF digits, some guidelines should be provided for SIP UA as well as PBX provider to pass this information.

For example, call park and unpark example given simply says call is put on hold and retrieve from nay other extension. But generally service providers ask user to dial particular park extension to park the call and another extension can dial that number to unpark the call. Again question arises how user dial park extension while call is active. If we can resolve this basic issue, it will really interop features easily among PBX vendors.

We have mentioned Call park/pickup service, generally it is call park/unpark service. There is another directed pickup service available where user can pickup a call ringing on another extension by dialing pickup code.

ACD/HG definitely requires attention as part of call center applications as it is getting more popular because of SIP wifi phones becoming as ACD agents roaming around in office. We are also willing to help for call center applications.

What about MWB service (monitor whisper and barge-in)?

-Udit




"Dolly, Martin C, ALABS" <mdolly@att.com>

01/21/2007 12:32 PM

To
"Alan Johnston" <alan@sipstation.com>, "Jonathan Rosenberg" <jdrosen@cisco.com>
cc
bliss@ietf.org
Subject
RE: [BLISS] Welcome! Main question - what services?





We are very interested in Call Centers and I would be willing to help.
-----Original Message-----
From: Alan Johnston [mailto:alan@sipstation.com]
Sent: Friday, January 19, 2007 5:59 PM
To: Jonathan Rosenberg
Cc: bliss@ietf.org
Subject: Re: [BLISS] Welcome! Main question - what services?
Those four are good to start with.
I'm hearing a lot of interest in SIP enabling contact centers (or call
centers).  This requires a few things:
1. A good description of the problem space and the requirements
2. Remote call control capabilities
3. Ability to pass around call related information between elements
I have not yet attempted #1 yet, although I do plan to work on it with
others who understand the service well (volunteers?)
For #2, I think draft-mahy-sip-remote-cc-04 is a very good start.
Perhaps this group can demonstrate that there is interest and need for
these REFER extensions so they can be worked in the SIP WG.  For #3, I
wrote a partial solution in draft-johnston-sipping-cc-uui-01.  I think
if we put effort into #1 it will become clearer what mechanism is best,
so I would describe this draft as an example mechanism that is out there
rather than the right mechanism.
I think this is a very interesting problem to work on.  The non-SIP
solutions today are completely proprietary, so there is a huge
opportunity to make a big impact on the industry if we can deliver the
same functionality using open standards and SIP.
However, I would expect to spend a good deal of time on requirements and
use cases before we even started on mechanisms.
Thanks,
Alan
Jonathan Rosenberg wrote:
> If you haven't done so already, everyone please take a look at the
> charter:
>
> http://sip101.net/charter.html
>
> In my mind, the main question to be answered is what features we want
> to work on, and in what order. We've chosen four to begin with - BLA,
> pickup, DND, and CCBS, since these have been reported to be the most
> problematic.
>
> If anyone has comments on different ones they'd like to see worked on,
> please comment. Especially welcome are examples of REAL interop
> problems or hacks that have been put into place in real
> implementations and deployments to make something happen.
>
> Thanks,
> Jonathan R.

_______________________________________________
BLISS mailing list
BLISS@ietf.org
https://www1.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
BLISS@ietf.org
https://www1.ietf.org/mailman/listinfo/bliss
--=_alternative 00638E608525726A_=-- --===============0836036304== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss --===============0836036304==-- From bliss-bounces@ietf.org Mon Jan 22 00:24:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8rfS-0007BE-6h; Mon, 22 Jan 2007 00:24:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8rfR-0007B9-Nq for bliss@ietf.org; Mon, 22 Jan 2007 00:24:29 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8rfQ-0000sj-GG for bliss@ietf.org; Mon, 22 Jan 2007 00:24:29 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-6.cisco.com with ESMTP; 21 Jan 2007 21:24:28 -0800 X-IronPort-AV: i="4.13,219,1167638400"; d="scan'208"; a="104022586:sNHT41219676" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l0M5ORZc010694; Sun, 21 Jan 2007 21:24:27 -0800 Received: from [192.168.4.2] (sjc-fluffy-vpn7.cisco.com [10.25.236.88]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l0M5OMnG022599; Sun, 21 Jan 2007 21:24:27 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <383B4627-3B33-40A2-9ACE-C6F0079180F7@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Sun, 21 Jan 2007 09:46:26 -0800 To: bliss@ietf.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=129; t=1169443467; x=1170307467; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Chairs=20for=20BLISS=20BOF |Sender:=20; bh=zxUSnmBZvj+fzUVCbjHpBax0yftntJrwjvW+aIKKE4k=; b=UNWPXqDKjH0VHNJPqojTcEXPT8aDeFDJTw2mJ4Fs7Hto7MSLZG67o4FE9kLVnOR1IrtmBArN WVAAmXyfKjYMUohZBHPkcjUqrnzbm/p8kMmwQ7pe2goTNimH2qJbsGHB; Authentication-Results: sj-dkim-7; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Subject: [BLISS] Chairs for BLISS BOF X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I am very pleased to let folks know that Shida has agreed to co-chair this BOF with Jonathan. Thanks you both, Cullen _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jan 22 10:01:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H90fb-00057L-6j; Mon, 22 Jan 2007 10:01:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H90fa-00056x-1J for bliss@ietf.org; Mon, 22 Jan 2007 10:01:14 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H90fW-0004UQ-K9 for bliss@ietf.org; Mon, 22 Jan 2007 10:01:14 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 22 Jan 2007 10:01:10 -0500 X-IronPort-AV: i="4.13,220,1167627600"; d="scan'208"; a="112212462:sNHT55343484" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0MF1Ajm029351 for ; Mon, 22 Jan 2007 10:01:10 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0MF19OA011963 for ; Mon, 22 Jan 2007 10:01:09 -0500 (EST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Jan 2007 10:01:08 -0500 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 Subject: RE: [BLISS] Welcome! Main question - what services? Date: Mon, 22 Jan 2007 10:01:07 -0500 Message-ID: <47F3B0799A62BB48B096A4DC5BB3B11D02821329@xmb-rtp-20d.amer.cisco.com> In-Reply-To: <45B142CC.3070508@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Welcome! Main question - what services? Thread-Index: Acc8F0J1SI0Tnn3yRJSpiffdO+/xcwCHTFyA From: "Mohammad Al-Taraireh \(maltarai\)" To: "Jonathan Rosenberg \(jdrosen\)" , X-OriginalArrivalTime: 22 Jan 2007 15:01:08.0990 (UTC) FILETIME=[25FDE1E0:01C73E36] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1598; t=1169478070; x=1170342070; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=maltarai@cisco.com; z=From:=20=22Mohammad=20Al-Taraireh=20\(maltarai\)=22=20 |Subject:=20RE=3A=20[BLISS]=20Welcome!=20Main=20question=20-=20what=20ser vices? |Sender:=20 |To:=20=22Jonathan=20Rosenberg=20\(jdrosen\)=22=20, =20 ; bh=WV3MPmFYtFVKLQID3EsXIClP+hQP1h/HZ6LJvhdnbGA=; b=wEukzg3aIKv2r0FmApVUjhsFBx0Jo+aXsi4267ELbCbGmdVHraKYihkrOFZvsgh1nb+9eQar 3WnXjt62g8QAwCuCl1LTSE84TYkLy4e2xD1Qis+cpBDFvI0/DY4AdPhq; Authentication-Results: rtp-dkim-2; header.From=maltarai@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.9 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi Jonathan, The charter looks good, I am wondering if charter should also include identifying the minimum set of primitives, and SIP functionality that a UA must support to build the services that charter highlights. For example the support for basic call using early or delayed offer, Hold/Resume,..etc. Thanks, Mo -----Original Message----- From: Jonathan Rosenberg (jdrosen)=20 Sent: Friday, January 19, 2007 5:15 PM To: bliss@ietf.org Subject: [BLISS] Welcome! Main question - what services? If you haven't done so already, everyone please take a look at the charter: http://sip101.net/charter.html In my mind, the main question to be answered is what features we want to work on, and in what order. We've chosen four to begin with - BLA, pickup, DND, and CCBS, since these have been reported to be the most problematic. If anyone has comments on different ones they'd like to see worked on, please comment. Especially welcome are examples of REAL interop problems or hacks that have been put into place in real implementations and deployments to make something happen. Thanks, Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jan 22 13:00:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H93TG-0007BG-48; Mon, 22 Jan 2007 13:00:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H93TE-00072q-5h for bliss@ietf.org; Mon, 22 Jan 2007 13:00:40 -0500 Received: from smtp.sylantro.com ([65.200.90.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H93TB-0002tD-MC for bliss@ietf.org; Mon, 22 Jan 2007 13:00:40 -0500 Received: from 10.10.5.1 by smtp.sylantro.com with ESMTP (Tumbleweed MMS SMTP Relay (Email Firewall v6.3.0)); Mon, 22 Jan 2007 10:00:20 -0800 X-Server-Uuid: DDDD9A74-C029-464C-AFAE-EB27005E08B4 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [BLISS] Welcome! Main question - what services? Date: Mon, 22 Jan 2007 10:00:26 -0800 Message-ID: <947C2A11297E7B4BB241DBBCE95E34EC01028041@SYLMAIL.sylantro.com> In-Reply-To: <47F3B0799A62BB48B096A4DC5BB3B11D02821329@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Welcome! Main question - what services? Thread-Index: Acc8F0J1SI0Tnn3yRJSpiffdO+/xcwCHTFyAAAW2hiA= From: "Sunil Veluvali" To: "Jonathan Rosenberg (jdrosen)" , bliss@ietf.org X-WSS-ID: 69AA243E29W11016425-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.9 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi, One approach to consider is to discuss a set of core user agent services that can help solve some of the common interoperability issues. This will allow vendors to effectively interoperate and at the same time satisfy their own unique feature variants (which is going to be the case) that their product/solution demands.=20 I see the need for interoperability in the following four broad categories (w/capabilities) that an UA should offer: 1. Dial-Out Services: -- The ability for an UA to place a call from an external agent on behalf of the user. -- An interoperable mechanism to describe local data like redial numbers, last call return, etc.=20 -- An agreed upon approach to hotline or warmline capabilities. -- A common language for describing star codes. They are not going away. 2. "Ring" or Alerting Services: -- An agreed upon way to define and signal "ring types". Other specializations include beep, flash (no ring). -- Intercom/CallCenter type applications would require support for auto-answer. -- DND as already being discussed. If you consider mobile user agents, we might also want to describe an interoperable mechanism for describing an "offline" state. -- A presence mechanism to allow network applications to signal calls routed by the server due to a CPL instruction or other application. =20 3. Digit Collection Services: -- We need a simple mechanism for UAs to collect additional input from the user based on the needs for network applications. Most applications today route the call to a VXML server for additional dialog with the UA. 4. Applications Signaling: -- Shared Line Appearances as discussed in the charter. -- Support for ACD/CallCenter semantics: A common mechanism to log-in/log-out of an ACD and makes oneself available/unavailable to take calls. Thanks, Sunil Veluvali Director of Engineering Sylantro Systems +1-408-626-2309 -----Original Message----- From: Jonathan Rosenberg (jdrosen)=20 Sent: Friday, January 19, 2007 5:15 PM To: bliss@ietf.org Subject: [BLISS] Welcome! Main question - what services? If you haven't done so already, everyone please take a look at the charter: http://sip101.net/charter.html In my mind, the main question to be answered is what features we want to work on, and in what order. We've chosen four to begin with - BLA, pickup, DND, and CCBS, since these have been reported to be the most problematic. If anyone has comments on different ones they'd like to see worked on, please comment. Especially welcome are examples of REAL interop problems or hacks that have been put into place in real implementations and deployments to make something happen. Thanks, Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jan 22 17:00:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H97DP-0005Of-LE; Mon, 22 Jan 2007 17:00:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H97DO-0005OZ-P2 for bliss@ietf.org; Mon, 22 Jan 2007 17:00:34 -0500 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H97DN-0003L6-Ij for bliss@ietf.org; Mon, 22 Jan 2007 17:00:34 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc13) with ESMTP id <2007012222003301300kbhk4e>; Mon, 22 Jan 2007 22:00:33 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l0MM0WVJ014926 for ; Mon, 22 Jan 2007 17:00:32 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0MM0W7k014922; Mon, 22 Jan 2007 17:00:32 -0500 Date: Mon, 22 Jan 2007 17:00:32 -0500 Message-Id: <200701222200.l0MM0W7k014922@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: (Udit_Goyal@3com.com) Subject: Re: [BLISS] Welcome! Main question - what services? References: X-Spam-Score: 1.1 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org From: Udit_Goyal@3com.com I think the major problem that has been faced by almost every PBX vendor is how to make particular service working using feature codes. There is no clear method in SIP to communicate feature codes from SIP UA to PBX. Some uses INFO method, some NOTIFY ,and generally proprietary extensions to communicate that information. Since SIP recommends using RFC 2833 for DTMF digits, some guidelines should be provided for SIP UA as well as PBX provider to pass this information. In the sipX PBX, we haven't had much trouble with this. As long as a call isn't currently active on the phone, anything the user dials is inserted into the outgoing request-URI, which the proxy can interpret as it chooses. For an example of using a dialing prefix (feature code) to perform a call pickup, look at section 7 of draft-worley-sipping-pickup-02. Of course, if there is a call active, a user dial string can't be interpreted by the proxy. But in my experience, using a user dial string to manipulate a current call is uncommon in traditional PBXs as well, probably for the same reason -- the PBX digit listener is not active at that time. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jan 22 18:49:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H98uR-0005Sz-Id; Mon, 22 Jan 2007 18:49:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H98uQ-0005Su-FH for bliss@ietf.org; Mon, 22 Jan 2007 18:49:06 -0500 Received: from ahmler5.mail.eds.com ([192.85.154.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H98uN-0000PZ-VJ for bliss@ietf.org; Mon, 22 Jan 2007 18:49:06 -0500 Received: from ahmlir2.mail.eds.com (ahmlir2-2.mail.eds.com [192.85.154.132]) by ahmler5.mail.eds.com (8.13.8/8.12.10) with ESMTP id l0MNn2JJ007391; Mon, 22 Jan 2007 18:49:02 -0500 Received: from ahmlir2.mail.eds.com (localhost [127.0.0.1]) by ahmlir2.mail.eds.com (8.13.8/8.12.10) with ESMTP id l0MNmfDx017135; Mon, 22 Jan 2007 18:48:41 -0500 Received: from usut001.3Com.com ([205.142.126.149]) by ahmlir2.mail.eds.com (8.13.8/8.12.10) with ESMTP id l0MNmehT017130; Mon, 22 Jan 2007 18:48:40 -0500 In-Reply-To: <200701222200.l0MM0W7k014922@dragon.ariadne.com> From: Udit_Goyal@3com.com To: Dale.Worley@comcast.net Subject: Re: [BLISS] Welcome! Main question - what services? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: Date: Mon, 22 Jan 2007 18:47:51 -0500 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.5.5FP2|October 23, 2006) at 01/22/2007 03:48:41 PM, Serialize complete at 01/22/2007 03:48:41 PM X-Spam-Score: 1.1 (+) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0598012330==" Errors-To: bliss-bounces@ietf.org This is a multipart message in MIME format. --===============0598012330== Content-Type: multipart/alternative; boundary="=_alternative 008367328525726B_=" This is a multipart message in MIME format. --=_alternative 008367328525726B_= Content-Type: text/plain; charset="US-ASCII" Hi Dale, My main concern was for mid-call feature codes only. For example, call park will be done by dialing feature code followed by park extension when call is active, MWB etc. For out of call, it is not a problem since Req-uri can always be used. -Udit Dale.Worley@comcast.net 01/22/2007 05:00 PM To bliss@ietf.org cc Subject Re: [BLISS] Welcome! Main question - what services? From: Udit_Goyal@3com.com I think the major problem that has been faced by almost every PBX vendor is how to make particular service working using feature codes. There is no clear method in SIP to communicate feature codes from SIP UA to PBX. Some uses INFO method, some NOTIFY ,and generally proprietary extensions to communicate that information. Since SIP recommends using RFC 2833 for DTMF digits, some guidelines should be provided for SIP UA as well as PBX provider to pass this information. In the sipX PBX, we haven't had much trouble with this. As long as a call isn't currently active on the phone, anything the user dials is inserted into the outgoing request-URI, which the proxy can interpret as it chooses. For an example of using a dialing prefix (feature code) to perform a call pickup, look at section 7 of draft-worley-sipping-pickup-02. Of course, if there is a call active, a user dial string can't be interpreted by the proxy. But in my experience, using a user dial string to manipulate a current call is uncommon in traditional PBXs as well, probably for the same reason -- the PBX digit listener is not active at that time. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss --=_alternative 008367328525726B_= Content-Type: text/html; charset="US-ASCII"
Hi Dale,

My main concern was for mid-call feature codes only. For example, call park will be done by dialing feature code followed by park extension when call is active, MWB etc.

For out of call, it is not a problem since Req-uri can always be used.

-Udit


Dale.Worley@comcast.net

01/22/2007 05:00 PM

To
bliss@ietf.org
cc
Subject
Re: [BLISS] Welcome! Main question - what services?





From: Udit_Goyal@3com.com
I think the major problem that has been faced by almost every PBX vendor
is how to make particular service working using feature codes. There is no
clear method in SIP to communicate feature codes from SIP UA to PBX. Some
uses INFO method, some NOTIFY ,and generally proprietary extensions to
communicate that information. Since SIP recommends using RFC 2833 for DTMF
digits, some guidelines should be provided for SIP UA as well as PBX
provider to pass this information.

In the sipX PBX, we haven't had much trouble with this.  As long as a
call isn't currently active on the phone, anything the user dials is
inserted into the outgoing request-URI, which the proxy can interpret
as it chooses.  For an example of using a dialing prefix (feature
code) to perform a call pickup, look at section 7 of
draft-worley-sipping-pickup-02.
Of course, if there is a call active, a user dial string can't be
interpreted by the proxy.  But in my experience, using a user dial
string to manipulate a current call is uncommon in traditional PBXs as
well, probably for the same reason -- the PBX digit listener is not
active at that time.
Dale
_______________________________________________
BLISS mailing list
BLISS@ietf.org
https://www1.ietf.org/mailman/listinfo/bliss
--=_alternative 008367328525726B_=-- --===============0598012330== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss --===============0598012330==-- From bliss-bounces@ietf.org Mon Jan 22 23:08:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Cxa-00027m-R2; Mon, 22 Jan 2007 23:08:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H99Su-0003cs-1D for bliss@ietf.org; Mon, 22 Jan 2007 19:24:44 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H99Sr-0000BJ-BP for bliss@ietf.org; Mon, 22 Jan 2007 19:24:43 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 22 Jan 2007 16:24:40 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l0N0Oeb0011164; Mon, 22 Jan 2007 16:24:40 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0N0OBnP020265; Mon, 22 Jan 2007 16:24:40 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Jan 2007 19:24:32 -0500 Received: from [161.44.183.166] ([161.44.183.166]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Jan 2007 19:24:32 -0500 Message-ID: <45B555C0.2030500@cisco.com> Date: Mon, 22 Jan 2007 19:24:32 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Udit_Goyal@3com.com Subject: Re: [BLISS] Welcome! Main question - what services? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jan 2007 00:24:32.0585 (UTC) FILETIME=[DA812390:01C73E84] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2820; t=1169511880; x=1170375880; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20Welcome!=20Main=20question=20-=20what=20ser vices? |Sender:=20; bh=f6lyIaPbF1IcsvRH07q8xfx1Jenxpid3emQuu2YcwOg=; b=DjtLZEjTmU+APmhE+IN+Ww5+DjhflJmaXPTMaCQETiWFnCRyjuZG6lhKuptwOCGebs26qleA pub/MHrN5ptrHEQbUoPkqOvwl+HlEOlPAc4jEB1NlQEb4GeatSgYWA5B; Authentication-Results: sj-dkim-5; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.9 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-Mailman-Approved-At: Mon, 22 Jan 2007 23:08:37 -0500 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Udit_Goyal@3com.com wrote: > > Hi Dale, > > My main concern was for mid-call feature codes only. For example, call > park will be done by dialing feature code followed by park extension > when call is active, MWB etc. Unless you mandate a particular service architecture (e.g. with a B2BUA feature server in every call, that is responsible for carrying out all features), I don't see how you can have a single mechanism for conveying "mid-call feature codes". In general the feature may be: - fully implemented by the UA - mostly implemented by some server in the signaling path, with the UA simply conveying an indication of request - mostly implemented by some server not in the signaling path, with the UA signaling it in some way - some combination of the above. IMO you need an assortment of techniques, and the UA needs to know enough to choose which thing to do. Paul > For out of call, it is not a problem since Req-uri can always be used. > > -Udit > > > *Dale.Worley@comcast.net* > > 01/22/2007 05:00 PM > > > To > bliss@ietf.org > cc > > Subject > Re: [BLISS] Welcome! Main question - what services? > > > > > > > > > From: Udit_Goyal@3com.com > > I think the major problem that has been faced by almost every PBX vendor > is how to make particular service working using feature codes. There is no > clear method in SIP to communicate feature codes from SIP UA to PBX. Some > uses INFO method, some NOTIFY ,and generally proprietary extensions to > communicate that information. Since SIP recommends using RFC 2833 for DTMF > digits, some guidelines should be provided for SIP UA as well as PBX > provider to pass this information. > > In the sipX PBX, we haven't had much trouble with this. As long as a > call isn't currently active on the phone, anything the user dials is > inserted into the outgoing request-URI, which the proxy can interpret > as it chooses. For an example of using a dialing prefix (feature > code) to perform a call pickup, look at section 7 of > draft-worley-sipping-pickup-02. > > Of course, if there is a call active, a user dial string can't be > interpreted by the proxy. But in my experience, using a user dial > string to manipulate a current call is uncommon in traditional PBXs as > well, probably for the same reason -- the PBX digit listener is not > active at that time. > > Dale > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > > > ------------------------------------------------------------------------ > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jan 22 23:08:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Cxa-00027f-NM; Mon, 22 Jan 2007 23:08:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H93Nd-0005Mv-5o for bliss@ietf.org; Mon, 22 Jan 2007 12:54:53 -0500 Received: from smtp.sylantro.com ([65.200.90.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H93Nb-00029J-Nd for bliss@ietf.org; Mon, 22 Jan 2007 12:54:53 -0500 Received: from 10.10.5.1 by smtp.sylantro.com with ESMTP (Tumbleweed MMS SMTP Relay (Email Firewall v6.3.0)); Mon, 22 Jan 2007 09:54:38 -0800 X-Server-Uuid: DDDD9A74-C029-464C-AFAE-EB27005E08B4 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [BLISS] Welcome! Main question - what services? Date: Mon, 22 Jan 2007 09:54:44 -0800 Message-ID: <947C2A11297E7B4BB241DBBCE95E34EC0102803A@SYLMAIL.sylantro.com> In-Reply-To: <47F3B0799A62BB48B096A4DC5BB3B11D02821329@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Welcome! Main question - what services? Thread-Index: Acc8F0J1SI0Tnn3yRJSpiffdO+/xcwCHTFyAAAW2hiA= From: "Sunil Veluvali" To: "Jonathan Rosenberg (jdrosen)" , bliss@ietf.org X-WSS-ID: 69AA25D429W11015620-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.9 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a X-Mailman-Approved-At: Mon, 22 Jan 2007 23:08:37 -0500 Cc: X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi, One approach to consider is to discuss a set of core user agent services that can help solve some of the common interoperability issues. This will allow vendors to effectively interoperate and at the same time satisfy their own unique feature variants (which is going to be the case) that their product/solution demands.=20 I see the need for interoperability in the following four broad categories (w/capabilities) that an UA should offer: 1. Dial-Out Services: -- The ability for an UA to place a call from an external agent on behalf of the user. -- An interoperable mechanism to describe local data like redial numbers, last call return, etc.=20 -- An agreed upon approach to hotline or warmline capabilities. -- A common language for describing star codes. They are not going away. 2. "Ring" or Alerting Services: -- An agreed upon way to define and signal "ring types". Other specializations include beep, flash (no ring). -- Intercom/CallCenter type applications would require support for auto-answer. -- DND as already being discussed. If you consider mobile user agents, we might also want to describe an interoperable mechanism for describing an "offline" state. -- A presence mechanism to allow network applications to signal calls routed by the server due to a CPL instruction or other application. =20 3. Digit Collection Services: -- We need a simple mechanism for UAs to collect additional input from the user based on the needs for network applications. Most applications today route the call to a VXML server for additional dialog with the UA. 4. Applications Signaling: -- Shared Line Appearances as discussed in the charter. -- Support for ACD/CallCenter semantics: A common mechanism to log-in/log-out of an ACD and makes oneself available/unavailable to take calls. Thanks, Sunil Veluvali Director of Engineering Sylantro Systems +1-408-626-2309 -----Original Message----- From: Jonathan Rosenberg (jdrosen)=20 Sent: Friday, January 19, 2007 5:15 PM To: bliss@ietf.org Subject: [BLISS] Welcome! Main question - what services? If you haven't done so already, everyone please take a look at the charter: http://sip101.net/charter.html In my mind, the main question to be answered is what features we want to work on, and in what order. We've chosen four to begin with - BLA, pickup, DND, and CCBS, since these have been reported to be the most problematic. If anyone has comments on different ones they'd like to see worked on, please comment. Especially welcome are examples of REAL interop problems or hacks that have been put into place in real implementations and deployments to make something happen. Thanks, Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jan 22 23:25:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9DDr-0000KM-WC; Mon, 22 Jan 2007 23:25:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9DDq-0000KE-Ho for bliss@ietf.org; Mon, 22 Jan 2007 23:25:26 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9DDo-0006hf-Ec for bliss@ietf.org; Mon, 22 Jan 2007 23:25:26 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCB008M001CZH@szxga04-in.huawei.com> for bliss@ietf.org; Tue, 23 Jan 2007 12:20:01 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCB006Z901BSI@szxga04-in.huawei.com> for bliss@ietf.org; Tue, 23 Jan 2007 12:20:00 +0800 (CST) Received: from JAIMINCL5132 ([10.18.8.82]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCB006VU014BQ@szxml03-in.huawei.com> for bliss@ietf.org; Tue, 23 Jan 2007 12:19:59 +0800 (CST) Date: Tue, 23 Jan 2007 09:49:52 +0530 From: Jaimin Pancholi Subject: RE: [BLISS] Welcome! Main question - what services? In-reply-to: <947C2A11297E7B4BB241DBBCE95E34EC0102803A@SYLMAIL.sylantro.com> To: bliss@ietf.org Message-id: <002b01c73ea5$bb2c0a20$5208120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: Acc8F0J1SI0Tnn3yRJSpiffdO+/xcwCHTFyAAAW2hiAAFmd38A== X-Spam-Score: 0.9 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaiminp@huawei.com List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Some thoughts: I think first we should list the services we need to address as part of this forum ! After which we can divide them based on the Network Entity who need to support the same. i.e. some services can work by UA supporting it, Some services can work by Server supporting it. Once this categorization is done, it should be Okay to define the details. For supporting complex services like IN services, I would prefer a B2BUA with application logic as it gives great freedom. The problem comes in inter-operatibility as the related SIP Signaling and usage of headers / content is not well defined due to which there are lot of proprietary solutions available. Cheers Jaimin System Architect Huawei India R&D Bangalore Email Privacy Declaration **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! >-----Original Message----- >From: Sunil Veluvali [mailto:Sunil.Veluvali@sylantro.com] >Sent: Monday, January 22, 2007 11:25 PM >To: Jonathan Rosenberg (jdrosen); bliss@ietf.org >Subject: RE: [BLISS] Welcome! Main question - what services? > >Hi, > >One approach to consider is to discuss a set of core user >agent services that can help solve some of the common >interoperability issues. This will allow vendors to >effectively interoperate and at the same time satisfy their >own unique feature variants (which is going to be the >case) that their product/solution demands. > >I see the need for interoperability in the following four >broad categories (w/capabilities) that an UA should offer: > >1. Dial-Out Services: > >-- The ability for an UA to place a call from an external >agent on behalf of the user. >-- An interoperable mechanism to describe local data like >redial numbers, last call return, etc. >-- An agreed upon approach to hotline or warmline capabilities. >-- A common language for describing star codes. They are not >going away. > >2. "Ring" or Alerting Services: > >-- An agreed upon way to define and signal "ring types". Other >specializations include beep, flash (no ring). >-- Intercom/CallCenter type applications would require support >for auto-answer. >-- DND as already being discussed. If you consider mobile user >agents, we might also want to describe an interoperable >mechanism for describing an "offline" state. >-- A presence mechanism to allow network applications to >signal calls routed by the server due to a CPL instruction or >other application. > >3. Digit Collection Services: > >-- We need a simple mechanism for UAs to collect additional >input from the user based on the needs for network >applications. Most applications today route the call to a VXML >server for additional dialog with the UA. > > >4. Applications Signaling: > >-- Shared Line Appearances as discussed in the charter. >-- Support for ACD/CallCenter semantics: A common mechanism to >log-in/log-out of an ACD and makes oneself >available/unavailable to take calls. > >Thanks, > >Sunil Veluvali >Director of Engineering >Sylantro Systems >+1-408-626-2309 > >-----Original Message----- >From: Jonathan Rosenberg (jdrosen) >Sent: Friday, January 19, 2007 5:15 PM >To: bliss@ietf.org >Subject: [BLISS] Welcome! Main question - what services? > >If you haven't done so already, everyone please take a look at the >charter: > >http://sip101.net/charter.html > >In my mind, the main question to be answered is what features >we want to work on, and in what order. We've chosen four to >begin with - BLA, pickup, DND, and CCBS, since these have been >reported to be the most problematic. > >If anyone has comments on different ones they'd like to see >worked on, please comment. Especially welcome are examples of >REAL interop problems or hacks that have been put into place >in real implementations and deployments to make something happen. > >Thanks, >Jonathan R. >-- >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Cisco Fellow Parsippany, NJ >07054-2711 >Cisco Systems >jdrosen@cisco.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.cisco.com > >_______________________________________________ >BLISS mailing list >BLISS@ietf.org >https://www1.ietf.org/mailman/listinfo/bliss > >_______________________________________________ >BLISS mailing list >BLISS@ietf.org >https://www1.ietf.org/mailman/listinfo/bliss > > > >_______________________________________________ >BLISS mailing list >BLISS@ietf.org >https://www1.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Jan 23 06:15:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9JcE-0008Mi-0n; Tue, 23 Jan 2007 06:15:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9JcC-0008MY-Ft for bliss@ietf.org; Tue, 23 Jan 2007 06:15:00 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Jc8-0000p7-VQ for bliss@ietf.org; Tue, 23 Jan 2007 06:15:00 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JCB00E50J3A4P@siemenscomms.co.uk> for bliss@ietf.org; Tue, 23 Jan 2007 11:11:34 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 23 Jan 2007 11:11:32 +0000 Content-return: allowed Date: Tue, 23 Jan 2007 11:11:31 +0000 From: "Elwell, John" To: Jonathan Rosenberg , bliss@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670AD8EEBF@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Subject: [BLISS] RE: [RAI] new proposed BoF and mailing list on feature interopera bility X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I think this is a good initiative. Many of the suggestions for services that have been posted in the last couple of days can already be achieved using SIP, but there are different interpretations how to go about it. Therefore BCPs are needed to make clear recommendations. In a few cases, additional syntax may be needed (e.g., for achieving the DND service), but hopefully these will be relatively few. I think we should focus on a fairly small list of services initially and add more as we gain experience. The proposed list is a good start. John > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 19 January 2007 21:03 > To: IETF Sipping List; rai@ietf.org > Subject: [RAI] new proposed BoF and mailing list on feature > interoperability > > Please do not reply to this mail. > > SIP has come a long way in terms of interoperability over the years. > However, there are several places where we still have a poor track > record of interoperability. One of these is in the area of > more advanced > types of features. These include many of the features traditionally > found on enterprise PBXs, such as park/pickup, shared line extension, > and so on. There has been sporadic work on this topic, with > many drafts, > but no real solution yet. > > There is a real need to get these interoperability problems > solved. This > need is coming from the IP PBX/Centrex side and from the > consumer side, > from groups like TISPAN that want some of these features to work. > > The interop problems stem from several root cause issues. One is too > much variety in the way these features can be implemented. > This is good > from a flexibility point of view, but it causes interop problems when > both endpoints do things differently and won't work together as a > consequence. Another problem is lack of sufficient functionality from > the specs, in which cases people turn to proprietary > techniques. Combine > this with the standard "dont want to implement the right > thing because > its too hard" and general bug problems, and its a mess. > > To fix this, I think it makes sense to start a working group thats > formally tasked with the problem. The idea is to take on individual > features, one at a time, figure out the real issues causing interop > problems, and address them by either writing some > requirements for sip > enhancements, or developing some BCPs or informational documents > specifying minimum interop requirements. Its also important > to do this > without trying to formally define what the feature is; we > want to allow > variation as much as possible while preserving interop. > > I've been with Cullen, Shida Schubert and a number of others > on getting > a BoF going in Prague on this. We've got a mailing list that > is now set > up, and a proposed charter, all of which can be found here: > > http://sip101.net/index.html > > Please join the list and participate in the discussions. The > more of it > we can have prior to Prague, the better the chances we can > arrive there > with a charter and deliverables that are on target. > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www1.ietf.org/mailman/listinfo/rai > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Jan 23 12:21:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9PKZ-0005J4-6Q; Tue, 23 Jan 2007 12:21:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9PKX-0005Is-Vg for bliss@ietf.org; Tue, 23 Jan 2007 12:21:09 -0500 Received: from alnrmhc12.comcast.net ([206.18.177.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9PKV-0006vM-Og for bliss@ietf.org; Tue, 23 Jan 2007 12:21:09 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc12) with ESMTP id <20070123172106b1200qgf87e>; Tue, 23 Jan 2007 17:21:07 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l0NHL6VJ002215 for ; Tue, 23 Jan 2007 12:21:06 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0NHL53i002211; Tue, 23 Jan 2007 12:21:05 -0500 Date: Tue, 23 Jan 2007 12:21:05 -0500 Message-Id: <200701231721.l0NHL53i002211@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: (Udit_Goyal@3com.com) Subject: Re: [BLISS] Welcome! Main question - what services? References: X-Spam-Score: 1.1 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org From: Udit_Goyal@3com.com My main concern was for mid-call feature codes only. For example, call park will be done by dialing feature code followed by park extension when call is active, MWB etc. I've never seen a system that did this. What I've seen is systems where you "flash" (thus putting the current call on hold, and getting a dial tone), and then dial a feature code to operate on the call you just put on hold. So in a sense, this is a mid-call feature code, but in another sense (and closer to the protocol question), it's a new call. If one wanted to implement such operations, the central question would be associating the INVITE bearing the feature code as its request-URI with the call on hold at the same UA. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jan 24 10:08:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9jjv-0005Wc-JI; Wed, 24 Jan 2007 10:08:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9jju-0005WI-0S for bliss@ietf.org; Wed, 24 Jan 2007 10:08:42 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H9jjp-0004tL-Fk for bliss@ietf.org; Wed, 24 Jan 2007 10:08:41 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 24 Jan 2007 07:08:37 -0800 X-IronPort-AV: i="4.13,232,1167638400"; d="scan'208"; a="760379851:sNHT48162176" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l0OF8YOq024992; Wed, 24 Jan 2007 07:08:34 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0OF8SDq007841; Wed, 24 Jan 2007 07:08:33 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 07:08:26 -0800 Received: from [10.71.9.227] ([10.21.98.138]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 07:08:26 -0800 Message-ID: <45B7766A.5000503@cisco.com> Date: Wed, 24 Jan 2007 10:08:26 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [BLISS] Welcome! Main question - what services? References: <200701231721.l0NHL53i002211@dragon.ariadne.com> In-Reply-To: <200701231721.l0NHL53i002211@dragon.ariadne.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2007 15:08:26.0445 (UTC) FILETIME=[7F8FB7D0:01C73FC9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2618; t=1169651314; x=1170515314; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BLISS]=20Welcome!=20Main=20question=20-=20what=20ser vices? |Sender:=20; bh=McQqultmN2JNL51HP3nwInU/WyfmfgoCoomFJNBASKM=; b=iCUImRTI2V6MIAkjh2vqSYE8IA19YvvL2hEsNedNKKgBHX5TLfHP69HdV2n2+9vPq1MewAoi amfLK2b/LpMy8t93zo6vi2Z+gmmdBY25W4eXG0kRa3JJFMCIOKcOHEGm; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.9 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I think this discussion is indicative of EXACTLY the problem we are trying to solve. Call park requires some kind of 'indication' to be emitted by the phone that signals a park request. There are many ways to do this: 1. Assuming PBX is a b2bua, the phone emits a DTMF feature code (rfc2833) on the call; this is captured by the PBX, interpreted as an invocation request, mapped to the park feature. The call is then parked at the PBX, and can be picked up elsewhere. I *think* this is the mechanism Udit is talking about. 2. Similar to 1, except invocation is done via some kind of signaling channel mechanism (INFO, proprietary methods, etc.) 3. Phone is a bit more intelligent, and knows the user wants to invoke Park. So, it REFERs to the park server, having it replace its call with the participant (as described in the service-examples draft) 4. conference mechanism; park is implemented by viewing the park server as a conference bridge. So, the invoking UA creates an ad-hoc conference bridge, transfers the correspondent into it. and there are more. I think its easy to see in this case how we have interop failures when a UA assumes one mechanism, and the PBX and other phones assume different ones, we have no hope of interop. -Jonathan R. Dale.Worley@comcast.net wrote: > From: Udit_Goyal@3com.com > > My main concern was for mid-call feature codes only. For example, > call park will be done by dialing feature code followed by park > extension when call is active, MWB etc. > > I've never seen a system that did this. > > What I've seen is systems where you "flash" (thus putting the current > call on hold, and getting a dial tone), and then dial a feature code > to operate on the call you just put on hold. > > So in a sense, this is a mid-call feature code, but in another sense > (and closer to the protocol question), it's a new call. > > If one wanted to implement such operations, the central question would > be associating the INVITE bearing the feature code as its request-URI > with the call on hold at the same UA. > > Dale > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jan 24 10:15:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9jqb-0000lO-Sm; Wed, 24 Jan 2007 10:15:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9jqa-0000je-17 for bliss@ietf.org; Wed, 24 Jan 2007 10:15:36 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9jqX-0005RP-Ro for bliss@ietf.org; Wed, 24 Jan 2007 10:15:36 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 24 Jan 2007 07:15:33 -0800 X-IronPort-AV: i="4.13,232,1167638400"; d="scan'208"; a="760381293:sNHT47301642" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0OFFXst017418; Wed, 24 Jan 2007 07:15:33 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0OFFRDs012864; Wed, 24 Jan 2007 07:15:32 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 07:15:14 -0800 Received: from [10.71.9.227] ([10.21.98.138]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 07:15:13 -0800 Message-ID: <45B777FF.10105@cisco.com> Date: Wed, 24 Jan 2007 10:15:11 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [BLISS] Welcome! Main question - what services? References: <45B142CC.3070508@cisco.com> <45B1F1F6.3000002@nokia.com> In-Reply-To: <45B1F1F6.3000002@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2007 15:15:13.0900 (UTC) FILETIME=[726C6AC0:01C73FCA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3332; t=1169651733; x=1170515733; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BLISS]=20Welcome!=20Main=20question=20-=20what=20ser vices? |Sender:=20 |To:=20Miguel=20Garcia=20 |Content-Type:=20text/plain=3B=20charset=3Dus-ascii=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=J8nDxcX2h4xBye7ruTJhFgFljOnxns7njwFTBziye68=; b=TeGht7R2v6oYFG/OjDcWJR6GwwKuXb2TZNoPpruLqHHMUY6KI2DJzJUZX6XRSTXT9giPhYYq p8y3p/EH0V0T23KlfONNoAjLpcqDTfuzE05LXy9EGgJG80LGHWB9VxZTqaRbYVqAxa7EH0BBr+ pfUDCH7J5o2DiaRVlL+2Hufyw=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.9 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Miguel Garcia wrote: > I think it is reasonable to work on the approach that you propose, > Jonathan. I have a couple of questions and comments about the proposed > charter. > > 1) When the charter speaks about heterogeneous networks, does it refer > only to SIP networks or does it consider interoperability across, say, > the PSTN. I am sure the TISPAN guys will ask this question sooner or > later, so better to write the answer, whatever it is, in the charter. Its referring to SIP neworks. The heterogeneity refers to endpoints, which includes gateways to the PSTN. Thus, the idea was most definitely to take into considerating how a gateway might implement these services due to the fact that it is a gateway, and is trying to interwork to another network. This is captured in the charter already here: "The problem is exacerbated by the desire for these features to work across many types of SIP endpoints, including SIP hardphones, softphones, and gateways to the PSTN and other VoIP networks, and for the desire to work across domain boundaries." Can you suggest some additional text to clarify? > > 2) About DND. By reading the description I wasn't able to find any > interoperability issues. Well, it is later described in the Issue. > Perhaps the description should also add "... and associated triggers for > other services" or something like that. A I don't think the charter needs to review the reaasons for interop failures in detail. DND is problematic in my mind because some devices assume its entirely a UA function, others assume its in the network and invoked in some way, others assume its derived from presence, and invoking it is done by PUBLISH to update your presence status to DND. We need to document the variations that exist in the wild and then figure out what a minimum baseline requirement would be for a UA. > > 3) A question on DND... I suspect that some people are implementing DND > in a server... I think PoC has something similar, so the question is > whether this service is going to consider also a "service that allows a > callee to provide instructions to a server to ignore certain types of > calls" or does it consider only a device centric approach? Right! Exactly the problem. My sense is, the way we get interoperability is to definge minimum requirements for a device. In this particular case, we have several options: 1. mandate that servers always provide DND, but that it can be disabled by configuration. Define a standard invocation mechanism. This way, if a phone connects to it which implements it on the phone, it need not be used in the network. We might need some capability exchanges or something to make this determination. 2. mandate that clients can do it locally, but they also implement a well-defined set of invocation techniques (ideally just one). This allows for variation in the capabilities of the server. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jan 24 10:21:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9jvo-00079a-0k; Wed, 24 Jan 2007 10:21:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9jvm-00079Q-8i for bliss@ietf.org; Wed, 24 Jan 2007 10:20:58 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H9jvb-0006S5-NX for bliss@ietf.org; Wed, 24 Jan 2007 10:20:58 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 24 Jan 2007 07:20:47 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l0OFKkrY023742; Wed, 24 Jan 2007 07:20:46 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0OFKkho016281; Wed, 24 Jan 2007 07:20:46 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 07:20:46 -0800 Received: from [10.71.9.227] ([10.21.98.138]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 07:20:46 -0800 Message-ID: <45B7794D.6000103@cisco.com> Date: Wed, 24 Jan 2007 10:20:45 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jaiminp@huawei.com Subject: Re: [BLISS] Welcome! Main question - what services? References: <002b01c73ea5$bb2c0a20$5208120a@china.huawei.com> In-Reply-To: <002b01c73ea5$bb2c0a20$5208120a@china.huawei.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2007 15:20:46.0034 (UTC) FILETIME=[38640B20:01C73FCB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1803; t=1169652046; x=1170516046; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BLISS]=20Welcome!=20Main=20question=20-=20what=20ser vices? |Sender:=20; bh=bTSzpUislnwG7o52y1m3OKHXgzucTnZzJJI3D9tGX8w=; b=GW9o6UphbaFVIw34KSWcKUUp4ma4tLhzoOYS0CNDMIU6TtQDsjsCVpjHskkhYoWwN++w2eaG AexPYVTjvSMYZeF1DHkRSv+Ea/iTUssojx+RURxyE+sAGW8kaTGODqX3; Authentication-Results: sj-dkim-6; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.9 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Jaimin Pancholi wrote: > Some thoughts: > > I think first we should list the services we need to address as part of this > forum ! Right. The proposed charter identifies four. We can expand this to more later, but I think we need to start with a small number of the highest priority services, and demonstrate that we can usefully solve the problem. Then we can move on to more. > > After which we can divide them based on the Network Entity who need to > support the same. > i.e. some services can work by UA supporting it, Some services can work by > Server supporting it. Right, this is one of the things which leads to interop problems - different solutions for who implements what. As I alluded to in my previous message, there are a few ways one can solve this. One way is to standardize a single approach. Another way, as I suggested in my note, is to allow variation but require some of the participants to support more than one mechanism to support variation in the capabilities of the others. The third is to demonstrate that you can still interoperate successfully even when all of the entities do the service differently. This is why the key part of working on each of these services is to have a section in the document for each that is an EXHAUSTIVE enumeration of the various ways in which the feature has been implemented, so we can figure out what the right path is to take for that feature. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jan 24 10:25:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9jzn-0000ej-9O; Wed, 24 Jan 2007 10:25:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9jzm-0000eY-Dz for bliss@ietf.org; Wed, 24 Jan 2007 10:25:06 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9jzk-00075A-1f for bliss@ietf.org; Wed, 24 Jan 2007 10:25:06 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 24 Jan 2007 07:25:03 -0800 X-IronPort-AV: i="4.13,232,1167638400"; d="scan'208"; a="104980477:sNHT56362347" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l0OFP3cC010848 for ; Wed, 24 Jan 2007 07:25:03 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0OFP3Dk018450 for ; Wed, 24 Jan 2007 07:25:03 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 07:25:03 -0800 Received: from [10.71.9.227] ([10.21.98.138]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 07:25:03 -0800 Message-ID: <45B77A4E.5060407@cisco.com> Date: Wed, 24 Jan 2007 10:25:02 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Mohammad Al-Taraireh (maltarai)" Subject: Re: [BLISS] Welcome! Main question - what services? References: <47F3B0799A62BB48B096A4DC5BB3B11D02821329@xmb-rtp-20d.amer.cisco.com> In-Reply-To: <47F3B0799A62BB48B096A4DC5BB3B11D02821329@xmb-rtp-20d.amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2007 15:25:03.0034 (UTC) FILETIME=[D19321A0:01C73FCB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2045; t=1169652303; x=1170516303; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BLISS]=20Welcome!=20Main=20question=20-=20what=20ser vices? |Sender:=20; bh=vQGgR9/NK4m3g+Hzryxq0qQlhOofaFFY24rp+QYVMoE=; b=jSAL//U5NsOY40q0AovKOxBAiFl4JnqQ9OrPbds7U8xdE9Jw6B1dJHlzZ3718mEO6skrQ/iH 2J0VirxjOmH0TVU78KVobkuzJzR7dpLjQw+QIYIjwFVQHV0faZxKef8V; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.9 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Absolutely. The kind of enumeration of things you have to do is what I had in mind with: "The focus will not be on rigorous definition of what the specific service is and exactly how it works. Rather, the focus will be on definining minimum levels of functionality required to realize a broad class of related services.." i.e., the things you mention below would appear on our list of minimum level of functionality that are required. -Jonathan R. Mohammad Al-Taraireh (maltarai) wrote: > Hi Jonathan, > > The charter looks good, I am wondering if charter should also include > identifying the minimum set of primitives, and SIP functionality that a > UA must support to build the services that charter highlights. For > example the support for basic call using early or delayed offer, > Hold/Resume,..etc. > > Thanks, > > Mo > > -----Original Message----- > From: Jonathan Rosenberg (jdrosen) > Sent: Friday, January 19, 2007 5:15 PM > To: bliss@ietf.org > Subject: [BLISS] Welcome! Main question - what services? > > If you haven't done so already, everyone please take a look at the > charter: > > http://sip101.net/charter.html > > In my mind, the main question to be answered is what features we want to > work on, and in what order. We've chosen four to begin with - BLA, > pickup, DND, and CCBS, since these have been reported to be the most > problematic. > > If anyone has comments on different ones they'd like to see worked on, > please comment. Especially welcome are examples of REAL interop problems > or hacks that have been put into place in real implementations and > deployments to make something happen. > > Thanks, > Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jan 24 10:26:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9k1P-0001Vm-IJ; Wed, 24 Jan 2007 10:26:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9k1O-0001Vc-IR for bliss@ietf.org; Wed, 24 Jan 2007 10:26:46 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9k1M-0007Hy-2U for bliss@ietf.org; Wed, 24 Jan 2007 10:26:46 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 24 Jan 2007 07:26:44 -0800 X-IronPort-AV: i="4.13,232,1167638400"; d="scan'208"; a="459414953:sNHT52434496" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l0OFQhSX032469; Wed, 24 Jan 2007 07:26:43 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0OFQgGo004438; Wed, 24 Jan 2007 07:26:43 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 07:26:43 -0800 Received: from [10.71.9.227] ([10.21.98.138]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 07:26:42 -0800 Message-ID: <45B77AB2.9020104@cisco.com> Date: Wed, 24 Jan 2007 10:26:42 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sunil Veluvali Subject: Re: [BLISS] Welcome! Main question - what services? References: <947C2A11297E7B4BB241DBBCE95E34EC0102803A@SYLMAIL.sylantro.com> In-Reply-To: <947C2A11297E7B4BB241DBBCE95E34EC0102803A@SYLMAIL.sylantro.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2007 15:26:42.0938 (UTC) FILETIME=[0D1F45A0:01C73FCC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4070; t=1169652403; x=1170516403; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BLISS]=20Welcome!=20Main=20question=20-=20what=20ser vices? |Sender:=20; bh=n373/a4zBAYrhaAZ5jFlDUP2QQQ6eLOZO/Bp6593F7Y=; b=oft0j60x0fswjoeZeiix+vODlDH6Ni43EwxcTIngYUzEfEDS7yECUEmFRk/NzVaxp/rPWDTG D3uzpbkZFhKv9c53Zo4ilRnSVZw2ItRuJyC33BbamNPWvEcYI1+RqpZ7; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.9 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I think this is on the right path, and is similar to what Mohammad suggested. We achieve basic levels of interoperability by outlining a set of functions that are required on any UA (and/or other components), which can include specific extensions, oft-overlooked parts of the SIP spec, new extensions that we think need to be defined, and so on. We then make sure there are capability determination exchanges as needed, since we still want to allow variation in how things are done. For example, vendor X could have a proprietary implementation for some feature that adds their special sauce, and also implement the baseline mechanism in the spec. It would use capability discovery mechanisms (OPTIONS, feature tags, Allow, etc.) to determine which one it needs to do for a particular call. -Jonathan R. Sunil Veluvali wrote: > Hi, > > One approach to consider is to discuss a set of core user agent services > that can help solve some of the common interoperability issues. This > will allow vendors to effectively interoperate and at the same time > satisfy their own unique feature variants (which is going to be the > case) that their product/solution demands. > > I see the need for interoperability in the following four broad > categories (w/capabilities) that an UA should offer: > > 1. Dial-Out Services: > > -- The ability for an UA to place a call from an external agent on > behalf of the user. > -- An interoperable mechanism to describe local data like redial > numbers, last call return, etc. > -- An agreed upon approach to hotline or warmline capabilities. > -- A common language for describing star codes. They are not going away. > > 2. "Ring" or Alerting Services: > > -- An agreed upon way to define and signal "ring types". Other > specializations include beep, flash (no ring). > -- Intercom/CallCenter type applications would require support for > auto-answer. > -- DND as already being discussed. If you consider mobile user agents, > we might also want to describe an interoperable mechanism for describing > an "offline" state. > -- A presence mechanism to allow network applications to signal calls > routed by the server due to a CPL instruction or other application. > > 3. Digit Collection Services: > > -- We need a simple mechanism for UAs to collect additional input from > the user based on the needs for network applications. Most applications > today route the call to a VXML server for additional dialog with the UA. > > > 4. Applications Signaling: > > -- Shared Line Appearances as discussed in the charter. > -- Support for ACD/CallCenter semantics: A common mechanism to > log-in/log-out of an ACD and makes oneself available/unavailable to take > calls. > > Thanks, > > Sunil Veluvali > Director of Engineering > Sylantro Systems > +1-408-626-2309 > > -----Original Message----- > From: Jonathan Rosenberg (jdrosen) > Sent: Friday, January 19, 2007 5:15 PM > To: bliss@ietf.org > Subject: [BLISS] Welcome! Main question - what services? > > If you haven't done so already, everyone please take a look at the > charter: > > http://sip101.net/charter.html > > In my mind, the main question to be answered is what features we want to > work on, and in what order. We've chosen four to begin with - BLA, > pickup, DND, and CCBS, since these have been reported to be the most > problematic. > > If anyone has comments on different ones they'd like to see worked on, > please comment. Especially welcome are examples of REAL interop problems > or hacks that have been put into place in real implementations and > deployments to make something happen. > > Thanks, > Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jan 24 10:28:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9k3O-0003XS-2M; Wed, 24 Jan 2007 10:28:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9k3N-0003XN-8y for bliss@ietf.org; Wed, 24 Jan 2007 10:28:49 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9k3L-0007bM-SZ for bliss@ietf.org; Wed, 24 Jan 2007 10:28:49 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 24 Jan 2007 07:28:47 -0800 X-IronPort-AV: i="4.13,232,1167638400"; d="scan'208"; a="104981916:sNHT187267347" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l0OFSkJu014523; Wed, 24 Jan 2007 07:28:46 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0OFSXGo005627; Wed, 24 Jan 2007 07:28:45 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 07:28:38 -0800 Received: from [10.71.9.227] ([10.21.98.138]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 07:28:38 -0800 Message-ID: <45B77B26.1040807@cisco.com> Date: Wed, 24 Jan 2007 10:28:38 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Johnston Subject: Re: [BLISS] Welcome! Main question - what services? References: <45B142CC.3070508@cisco.com> <45B14D41.5010705@sipstation.com> In-Reply-To: <45B14D41.5010705@sipstation.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2007 15:28:38.0282 (UTC) FILETIME=[51DF5EA0:01C73FCC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2943; t=1169652526; x=1170516526; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BLISS]=20Welcome!=20Main=20question=20-=20what=20ser vices? |Sender:=20; bh=X5Kxko3cKIaR+sqVMM5Suv1CwyjHdTCu7CveOJg592A=; b=lwQeGFhxXgw9I+R0IWdb4B4Co4Uchy6QBsmkZ1Cc//qO/hSbGQDbGHxnGl+tzLXgMPzc70WK W+Z0TKGEwWZAI9yyaLlyH+BtZnmFmli8eF1+eijDf9pvcReZUxksOUyp; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.9 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Alan, I agree this would be interesting to work on, and I would support it. However, I think it would be better suited as a set of next-step services after we complete the initial chartered ones. In the meantime if you want to start work on a problem space and requirements doc, that would be great; we can let that bake and gel for a little bit, and then hopefully when we get done with our initial items, that work is solid enough to help us with a recharter. -Jonathan R. Alan Johnston wrote: > Those four are good to start with. > > I'm hearing a lot of interest in SIP enabling contact centers (or call > centers). This requires a few things: > > 1. A good description of the problem space and the requirements > 2. Remote call control capabilities > 3. Ability to pass around call related information between elements > > I have not yet attempted #1 yet, although I do plan to work on it with > others who understand the service well (volunteers?) > For #2, I think draft-mahy-sip-remote-cc-04 is a very good start. > Perhaps this group can demonstrate that there is interest and need for > these REFER extensions so they can be worked in the SIP WG. For #3, I > wrote a partial solution in draft-johnston-sipping-cc-uui-01. I think > if we put effort into #1 it will become clearer what mechanism is best, > so I would describe this draft as an example mechanism that is out there > rather than the right mechanism. > > I think this is a very interesting problem to work on. The non-SIP > solutions today are completely proprietary, so there is a huge > opportunity to make a big impact on the industry if we can deliver the > same functionality using open standards and SIP. > However, I would expect to spend a good deal of time on requirements and > use cases before we even started on mechanisms. > > Thanks, > Alan > > Jonathan Rosenberg wrote: > >> If you haven't done so already, everyone please take a look at the >> charter: >> >> http://sip101.net/charter.html >> >> In my mind, the main question to be answered is what features we want >> to work on, and in what order. We've chosen four to begin with - BLA, >> pickup, DND, and CCBS, since these have been reported to be the most >> problematic. >> >> If anyone has comments on different ones they'd like to see worked on, >> please comment. Especially welcome are examples of REAL interop >> problems or hacks that have been put into place in real >> implementations and deployments to make something happen. >> >> Thanks, >> Jonathan R. > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jan 24 10:36:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9kBF-00055T-Hk; Wed, 24 Jan 2007 10:36:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9kBD-00055K-N2 for bliss@ietf.org; Wed, 24 Jan 2007 10:36:55 -0500 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9kBC-00016v-DQ for bliss@ietf.org; Wed, 24 Jan 2007 10:36:55 -0500 Received: from 24-107-197-43.dhcp.stls.mo.charter.com ([24.107.197.43] helo=[192.168.0.40]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1H9kBB-000PAd-Iq; Wed, 24 Jan 2007 10:36:53 -0500 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.197.43 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: digitalari Message-ID: <45B77D14.8040709@sipstation.com> Date: Wed, 24 Jan 2007 09:36:52 -0600 From: Alan Johnston User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [BLISS] Welcome! Main question - what services? References: <45B142CC.3070508@cisco.com> <45B14D41.5010705@sipstation.com> <45B77B26.1040807@cisco.com> In-Reply-To: <45B77B26.1040807@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Jonathan, I'm fine with leaving it off the charter for now. It would be most useful if we could continue to discuss the preliminary work in this area on this mailing list and even have some time at meetings to help move the work forward to the point where it could be added to the charter. Thanks, Alan Jonathan Rosenberg wrote: > Alan, > > I agree this would be interesting to work on, and I would support it. > However, I think it would be better suited as a set of next-step > services after we complete the initial chartered ones. In the meantime > if you want to start work on a problem space and requirements doc, > that would be great; we can let that bake and gel for a little bit, > and then hopefully when we get done with our initial items, that work > is solid enough to help us with a recharter. > > -Jonathan R. > > Alan Johnston wrote: > >> Those four are good to start with. >> >> I'm hearing a lot of interest in SIP enabling contact centers (or >> call centers). This requires a few things: >> >> 1. A good description of the problem space and the requirements >> 2. Remote call control capabilities >> 3. Ability to pass around call related information between elements >> >> I have not yet attempted #1 yet, although I do plan to work on it >> with others who understand the service well (volunteers?) >> For #2, I think draft-mahy-sip-remote-cc-04 is a very good start. >> Perhaps this group can demonstrate that there is interest and need >> for these REFER extensions so they can be worked in the SIP WG. For >> #3, I wrote a partial solution in draft-johnston-sipping-cc-uui-01. >> I think if we put effort into #1 it will become clearer what >> mechanism is best, so I would describe this draft as an example >> mechanism that is out there rather than the right mechanism. >> >> I think this is a very interesting problem to work on. The non-SIP >> solutions today are completely proprietary, so there is a huge >> opportunity to make a big impact on the industry if we can deliver >> the same functionality using open standards and SIP. >> However, I would expect to spend a good deal of time on requirements >> and use cases before we even started on mechanisms. >> >> Thanks, >> Alan >> >> Jonathan Rosenberg wrote: >> >>> If you haven't done so already, everyone please take a look at the >>> charter: >>> >>> http://sip101.net/charter.html >>> >>> In my mind, the main question to be answered is what features we >>> want to work on, and in what order. We've chosen four to begin with >>> - BLA, pickup, DND, and CCBS, since these have been reported to be >>> the most problematic. >>> >>> If anyone has comments on different ones they'd like to see worked >>> on, please comment. Especially welcome are examples of REAL interop >>> problems or hacks that have been put into place in real >>> implementations and deployments to make something happen. >>> >>> Thanks, >>> Jonathan R. >> >> > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jan 24 10:41:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9kFn-0006dr-GS; Wed, 24 Jan 2007 10:41:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9kFm-0006dc-OW for bliss@ietf.org; Wed, 24 Jan 2007 10:41:38 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9kFl-00024l-G0 for bliss@ietf.org; Wed, 24 Jan 2007 10:41:38 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCD00H8JQ7OJB@usaga01-in.huawei.com> for bliss@ietf.org; Wed, 24 Jan 2007 07:40:37 -0800 (PST) Received: from huawei.com ([172.18.4.47]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCD003FTQ7O2I@usaga01-in.huawei.com> for bliss@ietf.org; Wed, 24 Jan 2007 07:40:36 -0800 (PST) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCD00ATQQPQ8R@usaml03-in.huawei.com> for bliss@ietf.org; Wed, 24 Jan 2007 07:51:33 -0800 (PST) Date: Wed, 24 Jan 2007 09:40:33 -0600 From: Spencer Dawkins Subject: Re: [BLISS] Welcome! Main question - what services? To: bliss@ietf.org Message-id: <009201c73fce$00fb4ab0$6501a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <200701231721.l0NHL53i002211@dragon.ariadne.com> <45B7766A.5000503@cisco.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi, Jonathan, This note was one of the most helpful statements on the general topic I've seen. The example probably doesn't need to go in a proposed charter, but if there is any kind of problem statement draft required, your text is definitely worth preserving there. Thanks, Spencer >I think this discussion is indicative of EXACTLY the problem we are trying >to solve. > > Call park requires some kind of 'indication' to be emitted by the phone > that signals a park request. There are many ways to do this: > > 1. Assuming PBX is a b2bua, the phone emits a DTMF feature code (rfc2833) > on the call; this is captured by the PBX, interpreted as an invocation > request, mapped to the park feature. The call is then parked at the PBX, > and can be picked up elsewhere. I *think* this is the mechanism Udit is > talking about. > > 2. Similar to 1, except invocation is done via some kind of signaling > channel mechanism (INFO, proprietary methods, etc.) > > 3. Phone is a bit more intelligent, and knows the user wants to invoke > Park. So, it REFERs to the park server, having it replace its call with > the participant (as described in the service-examples draft) > > 4. conference mechanism; park is implemented by viewing the park server as > a conference bridge. So, the invoking UA creates an ad-hoc conference > bridge, transfers the correspondent into it. > > > and there are more. > > I think its easy to see in this case how we have interop failures when a > UA assumes one mechanism, and the PBX and other phones assume different > ones, we have no hope of interop. > > -Jonathan R. _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jan 24 23:57:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9wfg-0006CV-Ed; Wed, 24 Jan 2007 23:57:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9wfe-0006CP-Nt for bliss@ietf.org; Wed, 24 Jan 2007 23:57:10 -0500 Received: from corp2.ipunity.com ([65.106.79.133] helo=exchangevm.ipunity.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9wfc-0002g2-B5 for bliss@ietf.org; Wed, 24 Jan 2007 23:57:10 -0500 Received: from BLRPC6 ([10.253.253.150]) by exchangevm.ipunity.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 24 Jan 2007 20:57:05 -0800 From: "Darshan Bildikar" To: "'Jonathan Rosenberg'" , "'Mohammad Al-Taraireh \(maltarai\)'" Subject: RE: [BLISS] Welcome! Main question - what services? Date: Thu, 25 Jan 2007 10:27:00 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <45B77A4E.5060407@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: Acc/zLGqVGyV2itER/KyogMereOkpgAbJAgA Message-ID: X-OriginalArrivalTime: 25 Jan 2007 04:57:06.0237 (UTC) FILETIME=[42DDE6D0:01C7403D] X-Spam-Score: 0.9 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org If the focus is to be on a generic "service" I suggest that we put in some text defining what exactly a "service" is. >From my point of view a "service" will have the following properties 1) It shall conform to a standard interface (draft-rosenberg-sipping-service-identification?) through which it can be invoked 2) It MUST be atomic i.e. it must either succeed or fail. Since we are actually looking at defining how services behave, it would be good to break them down as much as possible. These building blocks could then be used to build "SIP SCE's". For example, "park call" or "create a conference with an initial list of participants (sip-uri-list-conferencing) . 3) It MUST be able to stand completely on its own i.e. can be used "out of the box". 4) It SHOULD be able to integrate seamlessly with other "services" to create new services. What I'm actually trying to say is:- 1) Break down services into as many atomic "sub-services" as possible. 2) Define BCP (normative) flows for these primitives 3) Design such that these sub-services can be strung together to build services like call park or BLA. BR, Darshan -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent: Wednesday, January 24, 2007 8:55 PM To: Mohammad Al-Taraireh (maltarai) Cc: bliss@ietf.org Subject: Re: [BLISS] Welcome! Main question - what services? Absolutely. The kind of enumeration of things you have to do is what I had in mind with: "The focus will not be on rigorous definition of what the specific service is and exactly how it works. Rather, the focus will be on definining minimum levels of functionality required to realize a broad class of related services.." i.e., the things you mention below would appear on our list of minimum level of functionality that are required. -Jonathan R. Mohammad Al-Taraireh (maltarai) wrote: > Hi Jonathan, > > The charter looks good, I am wondering if charter should also include > identifying the minimum set of primitives, and SIP functionality that a > UA must support to build the services that charter highlights. For > example the support for basic call using early or delayed offer, > Hold/Resume,..etc. > > Thanks, > > Mo > > -----Original Message----- > From: Jonathan Rosenberg (jdrosen) > Sent: Friday, January 19, 2007 5:15 PM > To: bliss@ietf.org > Subject: [BLISS] Welcome! Main question - what services? > > If you haven't done so already, everyone please take a look at the > charter: > > http://sip101.net/charter.html > > In my mind, the main question to be answered is what features we want to > work on, and in what order. We've chosen four to begin with - BLA, > pickup, DND, and CCBS, since these have been reported to be the most > problematic. > > If anyone has comments on different ones they'd like to see worked on, > please comment. Especially welcome are examples of REAL interop problems > or hacks that have been put into place in real implementations and > deployments to make something happen. > > Thanks, > Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Jan 25 02:37:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9zAX-0002Wb-7d; Thu, 25 Jan 2007 02:37:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9zAV-0002WW-RL for bliss@ietf.org; Thu, 25 Jan 2007 02:37:11 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9zAU-0007oL-Dt for bliss@ietf.org; Thu, 25 Jan 2007 02:37:11 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0P7Ytsm005385; Thu, 25 Jan 2007 09:35:20 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 09:36:52 +0200 Received: from [172.21.58.172] ([172.21.58.172]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 25 Jan 2007 09:36:52 +0200 Message-ID: <45B85E14.3020100@nokia.com> Date: Thu, 25 Jan 2007 09:36:52 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [BLISS] Welcome! Main question - what services? References: <45B142CC.3070508@cisco.com> <45B1F1F6.3000002@nokia.com> <45B777FF.10105@cisco.com> In-Reply-To: <45B777FF.10105@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jan 2007 07:36:52.0087 (UTC) FILETIME=[947A8870:01C74053] X-Nokia-AV: Clean X-Spam-Score: 0.9 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Jonathan Rosenberg wrote: > > > Miguel Garcia wrote: > >> I think it is reasonable to work on the approach that you propose, >> Jonathan. I have a couple of questions and comments about the proposed >> charter. >> >> 1) When the charter speaks about heterogeneous networks, does it refer >> only to SIP networks or does it consider interoperability across, say, >> the PSTN. I am sure the TISPAN guys will ask this question sooner or >> later, so better to write the answer, whatever it is, in the charter. > > Its referring to SIP neworks. The heterogeneity refers to endpoints, > which includes gateways to the PSTN. Thus, the idea was most definitely > to take into considerating how a gateway might implement these services > due to the fact that it is a gateway, and is trying to interwork to > another network. > > This is captured in the charter already here: > > "The problem is exacerbated by the desire for these features to work > across many types of SIP endpoints, including SIP hardphones, > softphones, and gateways to the PSTN and other VoIP networks, and for > the desire to work across domain boundaries." > > Can you suggest some additional text to clarify? I am satisfied with your explanation. When I read the charter I interpreted "domain boundaries" as in "SIP domain boundaries", but I understand now that you mean crossing to the PSTN, for example. If you want, you could add make the sentence to read "... and for the desire to work across domain boundaries and to seamless interwork with the PSTN, when applicable". /Miguel -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Jan 25 12:45:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA8fF-0001AI-Jv; Thu, 25 Jan 2007 12:45:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA5LF-0000ub-4f for bliss@ietf.org; Thu, 25 Jan 2007 09:12:41 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA5L9-00045u-Uk for bliss@ietf.org; Thu, 25 Jan 2007 09:12:41 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 25 Jan 2007 06:12:31 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l0PECTh5012461; Thu, 25 Jan 2007 06:12:29 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0PEC6nf024394; Thu, 25 Jan 2007 06:12:29 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 09:12:10 -0500 Received: from [161.44.183.166] ([161.44.183.166]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 09:12:10 -0500 Message-ID: <45B8BAB9.7020409@cisco.com> Date: Thu, 25 Jan 2007 09:12:09 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Darshan Bildikar Subject: Re: [BLISS] Welcome! Main question - what services? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jan 2007 14:12:10.0372 (UTC) FILETIME=[CDAD9C40:01C7408A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4449; t=1169734350; x=1170598350; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20Welcome!=20Main=20question=20-=20what=20ser vices? |Sender:=20; bh=FD3poINiFO0aonJzJ5PY0LPBcFXyjg3ichXX0h4cXEY=; b=Pncge6jwliwm27O6JVsTtdJXUEDWNkxT6Shsz18cJEDkk+wGgJM256DKMxRMrypexe/n/vqK SJFdwBTGpFmNUIECJMt18uyaXAINz8LyMgVmqlG2Vlo7fY6rfoVhWhKD; Authentication-Results: sj-dkim-8; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.9 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 X-Mailman-Approved-At: Thu, 25 Jan 2007 12:45:32 -0500 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Darshan Bildikar wrote: > If the focus is to be on a generic "service" I suggest that we put in some > text defining what exactly a "service" is. > >>From my point of view a "service" will have the following properties > > 1) It shall conform to a standard interface > (draft-rosenberg-sipping-service-identification?) through which it can be > invoked Interesting. I was just about to raise a concern that "service" in BLISS and "service" in IMS and draft-rosenberg-sipping-service-identification appeared to me to be considerably different concepts. My understanding of the concept in IMS and draft-rosenberg-sipping-service-identification is that one of several alternative behaviors that might be selected for a call. It is intended to impact the selection of components that are involved in the call - both intermediate nodes, UAS, and application within the UAS. OTOH, I have the impression that the kinds of "services" requiring clarification in BLISS, at least in part, have to do with mid-call behavior, and with state that affects multiple calls. I expect that there may be some degree of overlap between these things. Perhaps something can be learned about both by trying to understand how they are the same and how they differ. E.g. I think an emergency call (911) might be viewed as a service in both the BLISS and IMS sense. Call Park and DND would seem to be services in the BLISS sense, but they don't seem to be in the IMS sense. Paul > 2) It MUST be atomic i.e. it must either succeed or fail. Since we are > actually looking at defining how services behave, it would be good to break > them down as much as possible. These building blocks could then be used to > build "SIP SCE's". For example, "park call" or "create a conference with an > initial list of participants (sip-uri-list-conferencing) . > > 3) It MUST be able to stand completely on its own i.e. can be used "out of > the box". > > 4) It SHOULD be able to integrate seamlessly with other "services" to create > new services. > > > What I'm actually trying to say is:- > > 1) Break down services into as many atomic "sub-services" as possible. > 2) Define BCP (normative) flows for these primitives > 3) Design such that these sub-services can be strung together to build > services like call park or BLA. > > BR, > Darshan > > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Wednesday, January 24, 2007 8:55 PM > To: Mohammad Al-Taraireh (maltarai) > Cc: bliss@ietf.org > Subject: Re: [BLISS] Welcome! Main question - what services? > > Absolutely. The kind of enumeration of things you have to do is what I > had in mind with: > > "The focus will not be on rigorous definition of what the specific > service is and exactly how it works. Rather, the focus will be on > definining minimum levels of functionality required to realize a broad > class of related services.." > > i.e., the things you mention below would appear on our list of minimum > level of functionality that are required. > > -Jonathan R. > > > > Mohammad Al-Taraireh (maltarai) wrote: >> Hi Jonathan, >> >> The charter looks good, I am wondering if charter should also include >> identifying the minimum set of primitives, and SIP functionality that a >> UA must support to build the services that charter highlights. For >> example the support for basic call using early or delayed offer, >> Hold/Resume,..etc. >> >> Thanks, >> >> Mo >> >> -----Original Message----- >> From: Jonathan Rosenberg (jdrosen) >> Sent: Friday, January 19, 2007 5:15 PM >> To: bliss@ietf.org >> Subject: [BLISS] Welcome! Main question - what services? >> >> If you haven't done so already, everyone please take a look at the >> charter: >> >> http://sip101.net/charter.html >> >> In my mind, the main question to be answered is what features we want to >> work on, and in what order. We've chosen four to begin with - BLA, >> pickup, DND, and CCBS, since these have been reported to be the most >> problematic. >> >> If anyone has comments on different ones they'd like to see worked on, >> please comment. Especially welcome are examples of REAL interop problems >> or hacks that have been put into place in real implementations and >> deployments to make something happen. >> >> Thanks, >> Jonathan R. > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Jan 25 15:24:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAB8e-0003m0-BM; Thu, 25 Jan 2007 15:24:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAB8d-0003lr-1y for bliss@ietf.org; Thu, 25 Jan 2007 15:24:03 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAB8Z-000532-PJ for bliss@ietf.org; Thu, 25 Jan 2007 15:24:03 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JCF0032HXZMFQ@siemenscomms.co.uk> for bliss@ietf.org; Thu, 25 Jan 2007 20:23:46 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 25 Jan 2007 20:23:44 +0000 Content-return: allowed Date: Thu, 25 Jan 2007 20:23:43 +0000 From: "Elwell, John" Subject: RE: [BLISS] Welcome! Main question - what services? To: Jonathan Rosenberg , Miguel Garcia Message-id: <50B1CBA96870A34799A506B2313F26670ADD354C@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.9 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org > > > > 2) About DND. By reading the description I wasn't able to find any > > interoperability issues. Well, it is later described in the Issue. > > Perhaps the description should also add "... and associated > triggers for > > other services" or something like that. A > > I don't think the charter needs to review the reaasons for interop > failures in detail. DND is problematic in my mind because > some devices > assume its entirely a UA function, others assume its in the > network and > invoked in some way, others assume its derived from presence, and > invoking it is done by PUBLISH to update your presence status to DND. > > We need to document the variations that exist in the wild and then > figure out what a minimum baseline requirement would be for a UA. > [JRE] Another issue with DND is how to signal that DND has been encountered. RFC 3261 indicates that a 480 response can be used for this purpose, but 480 can be used for other purposes too. Also I don't think 480 is used universally. Other features can occur, triggered by DND (e.g., a UAS could indicate that DND has been encountered, a proxy might then trigger forwarding to voicemail based on that), so a clear indication is essential. John _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Jan 26 00:11:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAJNM-000378-1i; Fri, 26 Jan 2007 00:11:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAJNL-00036z-Lt for bliss@ietf.org; Fri, 26 Jan 2007 00:11:47 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAJNK-0006dH-B6 for bliss@ietf.org; Fri, 26 Jan 2007 00:11:47 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 25 Jan 2007 21:11:45 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l0Q5BiVg021216; Thu, 25 Jan 2007 21:11:44 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0Q5BJhw004257; Thu, 25 Jan 2007 21:11:45 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 21:11:34 -0800 Received: from [10.32.241.149] ([10.32.241.149]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 21:11:33 -0800 Message-ID: <45B951FE.5020409@cisco.com> Date: Thu, 25 Jan 2007 19:57:34 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [BLISS] Welcome! Main question - what services? References: <45B142CC.3070508@cisco.com> <45B1F1F6.3000002@nokia.com> <45B777FF.10105@cisco.com> <45B85E14.3020100@nokia.com> In-Reply-To: <45B85E14.3020100@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jan 2007 05:11:34.0122 (UTC) FILETIME=[729464A0:01C74108] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2107; t=1169788304; x=1170652304; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BLISS]=20Welcome!=20Main=20question=20-=20what=20ser vices? |Sender:=20; bh=gaEY9qrMfnkXLp5owpKnTfiWeCljbv9/Ec+TPMCim/Y=; b=ZTd5MJlAKSHAb9Cmc7NKzA7HS8DwGfqsbYSxSxF3etX+Sq2A392+cZpXG1HHnA5j7PTCRJQ3 1jv0KywkqQzm+AfaUOrj8MnqrZJXXaAJGqbg5Kv2Ax8hFuvQ1Av0u2cv; Authentication-Results: sj-dkim-6; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.9 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org OK, I think this is a reasonable change to the charter. -Jonathan R. Miguel Garcia wrote: > Jonathan Rosenberg wrote: > >> >> >> Miguel Garcia wrote: >> >>> I think it is reasonable to work on the approach that you propose, >>> Jonathan. I have a couple of questions and comments about the >>> proposed charter. >>> >>> 1) When the charter speaks about heterogeneous networks, does it >>> refer only to SIP networks or does it consider interoperability >>> across, say, the PSTN. I am sure the TISPAN guys will ask this >>> question sooner or later, so better to write the answer, whatever it >>> is, in the charter. >> >> >> Its referring to SIP neworks. The heterogeFrom bliss-bounces@ietf.org Fri Jan 26 00:11:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAJNM-000378-1i; Fri, 26 Jan 2007 00:11:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAJNL-00036z-Lt for bliss@ietf.org; Fri, 26 Jan 2007 00:11:47 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAJNK-0006dH-B6 for bliss@ietf.org; Fri, 26 Jan 2007 00:11:47 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 25 Jan 2007 21:11:45 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l0Q5BiVg021216; Thu, 25 Jan 2007 21:11:44 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0Q5BJhw004257; Thu, 25 Jan 2007 21:11:45 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 21:11:34 -0800 Received: from [10.32.241.149] ([10.32.241.149]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 21:11:33 -0800 Message-ID: <45B951FE.5020409@cisco.com> Date: Thu, 25 Jan 2007 19:57:34 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [BLISS] Welcome! Main question - what services? References: <45B142CC.3070508@cisco.com> <45B1F1F6.3000002@nokia.com> <45B777FF.10105@cisco.com> <45B85E14.3020100@nokia.com> In-Reply-To: <45B85E14.3020100@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jan 2007 05:11:34.0122 (UTC) FILETIME=[729464A0:01C74108] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2107; t=1169788304; x=1170652304; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BLISS]=20Welcome!=20Main=20question=20-=20what=20ser vices? |Sender:=20; bh=gaEY9qrMfnkXLp5owpKnTfiWeCljbv9/Ec+TPMCim/Y=; b=ZTd5MJlAKSHAb9Cmc7NKzA7HS8DwGfqsbYSxSxF3etX+Sq2A392+cZpXG1HHnA5j7PTCRJQ3 1jv0KywkqQzm+AfaUOrj8MnqrZJXXaAJGqbg5Kv2Ax8hFuvQ1Av0u2cv; Authentication-Results: sj-dkim-6; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.9 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org OK, I think this is a reasonable change to the charter. -Jonathan R. Miguel Garcia wrote: > Jonathan Rosenberg wrote: > >> >> >> Miguel Garcia wrote: >> >>> I think it is reasonable to work on the approach that you propose, >>> Jonathan. I have a couple of questions and comments about the >>> proposed charter. >>> >>> 1) When the charter speaks about heterogeneous networks, does it >>> refer only to SIP networks or does it consider interoperability >>> across, say, the PSTN. I am sure the TISPAN guys will ask this >>> question sooner or later, so better to write the answer, whatever it >>> is, in the charter. >> >> >> Its referring to SIP neworks. The heterogeneity refers to endpoints, >> which includes gateways to the PSTN. Thus, the idea was most >> definitely to take into considerating how a gateway might implement >> these services due to the fact that it is a gateway, and is trying to >> interwork to another network. >> >> This is captured in the charter already here: >> >> "The problem is exacerbated by the desire for these features to work >> across many types of SIP endpoints, including SIP hardphones, >> softphones, and gateways to the PSTN and other VoIP networks, and for >> the desire to work across domain boundaries." >> >> Can you suggest some additional text to clarify? > > > I am satisfied with your explanation. When I read the charter I > interpreted "domain boundaries" as in "SIP domain boundaries", but I > understand now that you mean crossing to the PSTN, for example. If you > want, you could add make the sentence to read "... and for the desire to > work across domain boundaries and to seamless interwork with the PSTN, > when applicable". > > /Miguel > > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Jan 26 00:11:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAJNB-00034Z-Rl; Fri, 26 Jan 2007 00:11:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAJN9-00034J-UH for bliss@ietf.org; Fri, 26 Jan 2007 00:11:35 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAJN7-0006bP-Hq for bliss@ietf.org; Fri, 26 Jan 2007 00:11:35 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 25 Jan 2007 21:11:33 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l0Q5BWW4018523; Thu, 25 Jan 2007 21:11:32 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0Q5BWho004297; Thu, 25 Jan 2007 21:11:32 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 21:11:32 -0800 Received: from [10.32.241.149] ([10.32.241.149]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 21:11:31 -0800 Message-ID: <45B951D8.8090400@cisco.com> Date: Thu, 25 Jan 2007 19:56:56 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Johnston Subject: Re: [BLISS] Welcome! Main question - what services? References: <45B142CC.3070508@cisco.com> <45B14D41.5010705@sipstation.com> <45B77B26.1040807@cisco.com> <45B77D14.8040709@sipstation.com> In-Reply-To: <45B77D14.8040709@sipstation.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jan 2007 05:11:32.0081 (UTC) FILETIME=[715CF610:01C74108] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3535; t=1169788293; x=1170652293; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BLISS]=20Welcome!=20Main=20question=20-=20what=20ser vices? |Sender:=20; bh=bXLbhK7Rl4wu6n2EALb3P07e+uNgQV1cDucOGsxMKow=; b=P2mSkfD37A7JpbrWqg0DmMns0N5nBO4IW+4pXtfAGJ6LbYZHzsvC1RXjDQ4IljNSVRhX1Nwa nF0QrBi4yNM5NUgTneity refers to endpoints, >> which includes gateways to the PSTN. Thus, the idea was most >> definitely to take into considerating how a gateway might implement >> these services due to the fact that it is a gateway, and is trying to >> interwork to another network. >> >> This is captured in the charter already here: >> >> "The problem is exacerbated by the desire for these features to work >> across many types of SIP endpoints, including SIP hardphones, >> softphones, and gateways to the PSTN and other VoIP networks, and for >> the desire to work across domain boundaries." >> >> Can you suggest some additional text to clarify? > > > I am satisfied with your explanation. When I read the charter I > interpreted "domain boundaries" as in "SIP domain boundaries", but I > understand now that you mean crossing to the PSTN, for example. If you > want, you could add make the sentence to read "... and for the desire to > work across domain boundaries and to seamless interwork with the PSTN, > when applicable". > > /Miguel > > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Jan 26 00:11:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAJNB-00034Z-Rl; Fri, 26 Jan 2007 00:11:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAJN9-00034J-UH for bliss@ietf.org; Fri, 26 Jan 2007 00:11:35 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAJN7-0006bP-Hq for bliss@ietf.org; Fri, 26 Jan 2007 00:11:35 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 25 Jan 2007 21:11:33 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l0Q5BWW4018523; Thu, 25 Jan 2007 21:11:32 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0Q5BWho004297; Thu, 25 Jan 2007 21:11:32 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 21:11:32 -0800 Received: from [10.32.241.149] ([10.32.241.149]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 21:11:31 -0800 Message-ID: <45B951D8.8090400@cisco.com> Date: Thu, 25 Jan 2007 19:56:56 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Johnston Subject: Re: [BLISS] Welcome! Main question - what services? References: <45B142CC.3070508@cisco.com> <45B14D41.5010705@sipstation.com> <45B77B26.1040807@cisco.com> <45B77D14.8040709@sipstation.com> In-Reply-To: <45B77D14.8040709@sipstation.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jan 2007 05:11:32.0081 (UTC) FILETIME=[715CF610:01C74108] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3535; t=1169788293; x=1170652293; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BLISS]=20Welcome!=20Main=20question=20-=20what=20ser vices? |Sender:=20; bh=bXLbhK7Rl4wu6n2EALb3P07e+uNgQV1cDucOGsxMKow=; b=P2mSkfD37A7JpbrWqg0DmMns0N5nBO4IW+4pXtfAGJ6LbYZHzsvC1RXjDQ4IljNSVRhX1Nwa nF0QrBi4yNM5NUgTYyJzX0tyrPQp8t29HqkpSsh6FqzZTAQp17K7zs5V; Authentication-Results: sj-dkim-5; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.9 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Yes, I think that is appropriate. -Jonathan R. Alan Johnston wrote: > Jonathan, > > I'm fine with leaving it off the charter for now. It would be most > useful if we could continue to discuss the preliminary work in this area > on this mailing list and even have some time at meetings to help move > the work forward to the point where it could be added to the charter. > > Thanks, > Alan > > Jonathan Rosenberg wrote: > >> Alan, >> >> I agree this would be interesting to work on, and I would support it. >> However, I think it would be better suited as a set of next-step >> services after we complete the initial chartered ones. In the meantime >> if you want to start work on a problem space and requirements doc, >> that would be great; we can let that bake and gel for a little bit, >> and then hopefully when we get done with our initial items, that work >> is solid enough to help us with a recharter. >> >> -Jonathan R. >> >> Alan Johnston wrote: >> >>> Those four are good to start with. >>> >>> I'm hearing a lot of interest in SIP enabling contact centers (or >>> call centers). This requires a few things: >>> >>> 1. A good description of the problem space and the requirements >>> 2. Remote call control capabilities >>> 3. Ability to pass around call related information between elements >>> >>> I have not yet attempted #1 yet, although I do plan to work on it >>> with others who understand the service well (volunteers?) >>> For #2, I think draft-mahy-sip-remote-cc-04 is a very good start. >>> Perhaps this group can demonstrate that there is interest and need >>> for these REFER extensions so they can be worked in the SIP WG. For >>> #3, I wrote a partial solution in draft-johnston-sipping-cc-uui-01. >>> I think if we put effort into #1 it will become clearer what >>> mechanism is best, so I would describe this draft as an example >>> mechanism that is out there rather than the right mechanism. >>> >>> I think this is a very interesting problem to work on. The non-SIP >>> solutions today are completely proprietary, so there is a huge >>> opportunity to make a big impact on the industry if we can deliver >>> the same functionality using open standards and SIP. >>> However, I would expect to spend a good deal of time on requirements >>> and use cases before we even started on mechanisms. >>> >>> Thanks, >>> Alan >>> >>> Jonathan Rosenberg wrote: >>> >>>> If you haven't done so already, everyone please take a look at the >>>> charter: >>>> >>>> http://sip101.net/charter.html >>>> >>>> In my mind, the main question to be answered is what features we >>>> want to work on, and in what order. We've chosen four to begin with >>>> - BLA, pickup, DND, and CCBS, since these have been reported to be >>>> the most problematic. >>>> >>>> If anyone has comments on different ones they'd like to see worked >>>> on, please comment. Especially welcome are examples of REAL interop >>>> problems or hacks that have been put into place in real >>>> implementations and deployments to make something happen. >>>> >>>> Thanks, >>>> Jonathan R. >>> >>> >>> >> > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-YyJzX0tyrPQp8t29HqkpSsh6FqzZTAQp17K7zs5V; Authentication-Results: sj-dkim-5; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.9 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Yes, I think that is appropriate. -Jonathan R. Alan Johnston wrote: > Jonathan, > > I'm fine with leaving it off the charter for now. It would be most > useful if we could continue to discuss the preliminary work in this area > on this mailing list and even have some time at meetings to help move > the work forward to the point where it could be added to the charter. > > Thanks, > Alan > > Jonathan Rosenberg wrote: > >> Alan, >> >> I agree this would be interesting to work on, and I would support it. >> However, I think it would be better suited as a set of next-step >> services after we complete the initial chartered ones. In the meantime >> if you want to start work on a problem space and requirements doc, >> that would be great; we can let that bake and gel for a little bit, >> and then hopefully when we get done with our initial items, that work >> is solid enough to help us with a recharter. >> >> -Jonathan R. >> >> Alan Johnston wrote: >> >>> Those four are good to start with. >>> >>> I'm hearing a lot of interest in SIP enabling contact centers (or >>> call centers). This requires a few things: >>> >>> 1. A good description of the problem space and the requirements >>> 2. Remote call control capabilities >>> 3. Ability to pass around call related information between elements >>> >>> I have not yet attempted #1 yet, although I do plan to work on it >>> with others who understand the service well (volunteers?) >>> For #2, I think draft-mahy-sip-remote-cc-04 is a very good start. >>> Perhaps this group can demonstrate that there is interest and need >>> for these REFER extensions so they can be worked in the SIP WG. For >>> #3, I wrote a partial solution in draft-johnston-sipping-cc-uui-01. >>> I think if we put effort into #1 it will become clearer what >>> mechanism is best, so I would describe this draft as an example >>> mechanism that is out there rather than the right mechanism. >>> >>> I think this is a very interesting problem to work on. The non-SIP >>> solutions today are completely proprietary, so there is a huge >>> opportunity to make a big impact on the industry if we can deliver >>> the same functionality using open standards and SIP. >>> However, I would expect to spend a good deal of time on requirements >>> and use cases before we even started on mechanisms. >>> >>> Thanks, >>> Alan >>> >>> Jonathan Rosenberg wrote: >>> >>>> If you haven't done so already, everyone please take a look at the >>>> charter: >>>> >>>> http://sip101.net/charter.html >>>> >>>> In my mind, the main question to be answered is what features we >>>> want to work on, and in what order. We've chosen four to begin with >>>> - BLA, pickup, DND, and CCBS, since these have been reported to be >>>> the most problematic. >>>> >>>> If anyone has comments on different ones they'd like to see worked >>>> on, please comment. Especially welcome are examples of REAL interop >>>> problems or hacks that have been put into place in real >>>> implementations and deployments to make something happen. >>>> >>>> Thanks, >>>> Jonathan R. >>> >>> >>> >> > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss 2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Jan 26 00:11:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAJNO-00039e-6g; Fri, 26 Jan 2007 00:11:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAJNM-00037J-Uu for bliss@ietf.org; Fri, 26 Jan 2007 00:11:48 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAJNL-0006dJ-8y for bliss@ietf.org; Fri, 26 Jan 2007 00:11:48 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 25 Jan 2007 21:11:47 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l0Q5Bk2j018632; Thu, 25 Jan 2007 21:11:46 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0Q5BJi0004257; Thu, 25 Jan 2007 21:11:46 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 21:11:43 -0800 Received: from [10.32.241.149] ([10.32.241.149]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 21:11:42 -0800 Message-ID: <45B95686.90208@cisco.com> Date: Thu, 25 Jan 2007 20:16:54 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [BLISS] Welcome! Main question - what services? References: <45B8BAB9.7020409@cisco.com> In-Reply-To: <45B8BAB9.7020409@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jan 2007 05:11:43.0081 (UTC) FILETIME=[77EB6D90:01C74108] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9218; t=1169788306; x=1170652306; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BLISS]=20Welcome!=20Main=20question=20-=20what=20ser vices? |Sender:=20; bh=jEndqXm2650+fZ5Ul2tpFzMdYSfkkYLzcIAsJczY49g=; b=XXpbKAaf6z9cJptUkSRxo3uspVWJy7itwb2jxdvZKyyPaEIGc4qSdcmmgi+NXwvDPLWGhBru DipgHKTfOu+0FTpOnvTz/JBn6ls5f6GpWJuiwwd6DQT4yoVJd/0oWpaf; Authentication-Results: sj-dkim-5; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.9 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I agree with Paul; though both of these things involve 'services' they are quite distinct. I had not even connected BLISS and the service-identification draft in my head until Darshan had suggested it. The option tags in service-identification are puposefully constructed as 'a technique of LAST RESORT' for identifying services, usually at initiation time. As Paul indicates, we are worried about things that I think are better classified as "features", meaning they are smaller bits of functionality that don't represent an entire experience. For example, 'television' is a service and a wireless remote is a 'feature'. 'Telephony' is a service and 'DND' is a feature. Of course everyone has their own definitions of application, service and feature and I don't want to get too wrapped up in their definitions. I have to disagree with some of Darshan's other points here. I don't think we want to define our features here as atomic; I think we need to evaluate that on a case by case basis. For example even with park/pickup, lets say we have an unhappy case where I can park the phone, but can't pickup from some phones since they don't support the required mecahnism. I'd rather park and allow pickup to work where it can, rather than fail the park since a pickup might fail somewhere. Let me explain more what I mean by this: >> "The focus will not be on rigorous definition of what the specific >> service is and exactly how it works. Rather, the focus will be on >> definining minimum levels of functionality required to realize a broad >> class of related services.." Let us take DND. There are really many variants on it: 1. if the user is DND the incoming calls get rejected 2. if the user is DND the incoming calls get sent to voicemail 3. if the user is DND the incoming calls get redirected to voicemail (i.e., 3xx) 4. if the user is DND the incoming calls get sent to IVR jail where the user is told to conitnually wait 5. any one of the above, PLUS the DND status is reflected in presence I don't want to have a spec that rigorously defines all 8 of the above, with specific call flows for each and a name for each. I want vendors to be able to implement any one of these 8 and for it to work. Indeed, any of the above 8 would work as long as we define how the invocation works, since that IMHO is the primary interop problem around this feature. If one phone expects the network to do the DND processing, and the corresponding IP PBX expects the phone to do it, we have a serious interop failure. The above examples also show how partial failures are OK. Lets say user A calls user B. User B invokes DND. Their presence status is updated to say DND as well, but user A doesn't do presence. Thats fine; they don't support presence, they don't get that bit of value add. This is a partial failure but a perfectly acceptable one, IMHO. For this presence enhancement to work, we would need to specify responsibility for PUBLISH (does the UA PUBLISH? Does the UA just invoke and let the IP PBX PUBLISH? Do we negotiate who?) and clarify how it is represented in presence (status of ? new flag?). Once we do that, we enable lots of variations without rigorously identifying the service. This is really important to me since the whole idea with SIP is to enable service innovation. If we rigorously define the call flows and standardize each one, we kill the point of having SIP in the first place. So, this leads me to my thoughts on the structure of our deliverables. Again taking DND as an example, we would have lots of flows in the document that give examples of different implementation techniques, and show how they fail. We'd show failures like the two I describe above (disagreement on invocation, disagreement on who publishes) and also demonstrate some of the variants. The document would then indicate that the bug here is having an agreed upon invocation technique and define what it is, and/or minimal requirements to support interop when it can vary. We'd also have to state guidelines on presence too - who PUBLIShes and what the presence data looks like. Thanks, Jonathan R. Paul Kyzivat wrote: > > > Darshan Bildikar wrote: > >> If the focus is to be on a generic "service" I suggest that we put in >> some >> text defining what exactly a "service" is. >> >>> From my point of view a "service" will have the following properties >> >> >> 1) It shall conform to a standard interface >> (draft-rosenberg-sipping-service-identification?) through which it can be >> invoked > > > Interesting. I was just about to raise a concern that "service" in BLISS > and "service" in IMS and draft-rosenberg-sipping-service-identification > appeared to me to be considerably different concepts. > > My understanding of the concept in IMS and > draft-rosenberg-sipping-service-identification is that one of several > alternative behaviors that might be selected for a call. It is intended > to impact the selection of components that are involved in the call - > both intermediate nodes, UAS, and application within the UAS. > > OTOH, I have the impression that the kinds of "services" requiring > clarification in BLISS, at least in part, have to do with mid-call > behavior, and with state that affects multiple calls. > > I expect that there may be some degree of overlap between these things. > Perhaps something can be learned about both by trying to understand how > they are the same and how they differ. > > E.g. I think an emergency call (911) might be viewed as a service in > both the BLISS and IMS sense. Call Park and DND would seem to be > services in the BLISS sense, but they don't seem to be in the IMS sense. > > Paul > >> 2) It MUST be atomic i.e. it must either succeed or fail. Since we are >> actually looking at defining how services behave, it would be good to >> break >> them down as much as possible. These building blocks could then be >> used to >> build "SIP SCE's". For example, "park call" or "create a conference >> with an >> initial list of participants (sip-uri-list-conferencing) . >> 3) It MUST be able to stand completely on its own i.e. can be used >> "out of >> the box". >> 4) It SHOULD be able to integrate seamlessly with other "services" to >> create >> new services. >> >> What I'm actually trying to say is:- >> >> 1) Break down services into as many atomic "sub-services" as possible. >> 2) Define BCP (normative) flows for these primitives >> 3) Design such that these sub-services can be strung together to build >> services like call park or BLA. >> >> BR, >> Darshan >> >> >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent: Wednesday, >> January 24, 2007 8:55 PM >> To: Mohammad Al-Taraireh (maltarai) >> Cc: bliss@ietf.org >> Subject: Re: [BLISS] Welcome! Main question - what services? >> >> Absolutely. The kind of enumeration of things you have to do is what I >> had in mind with: >> >> "The focus will not be on rigorous definition of what the specific >> service is and exactly how it works. Rather, the focus will be on >> definining minimum levels of functionality required to realize a broad >> class of related services.." >> >> i.e., the things you mention below would appear on our list of minimum >> level of functionality that are required. >> >> -Jonathan R. >> >> >> >> Mohammad Al-Taraireh (maltarai) wrote: >> >>> Hi Jonathan, >>> >>> The charter looks good, I am wondering if charter should also include >>> identifying the minimum set of primitives, and SIP functionality that a >>> UA must support to build the services that charter highlights. For >>> example the support for basic call using early or delayed offer, >>> Hold/Resume,..etc. >>> >>> Thanks, >>> >>> Mo >>> >>> -----Original Message----- >>> From: Jonathan Rosenberg (jdrosen) Sent: Friday, January 19, 2007 >>> 5:15 PM >>> To: bliss@ietf.org >>> Subject: [BLISS] Welcome! Main question - what services? >>> >>> If you haven't done so already, everyone please take a look at the >>> charter: >>> >>> http://sip101.net/charter.html >>> >>> In my mind, the main question to be answered is what features we want to >>> work on, and in what order. We've chosen four to begin with - BLA, >>> pickup, DND, and CCBS, since these have been reported to be the most >>> problematic. >>> >>> If anyone has comments on different ones they'd like to see worked on, >>> please comment. Especially welcome are examples of REAL interop problems >>> or hacks that have been put into place in real implementations and >>> deployments to make something happen. >>> >>> Thanks, >>> Jonathan R. >> >> > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Jan 26 06:29:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAPGM-0008Bk-66; Fri, 26 Jan 2007 06:28:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAPGK-0008Be-Fk for bliss@ietf.org; Fri, 26 Jan 2007 06:28:56 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAPGG-0000DA-0t for bliss@ietf.org; Fri, 26 Jan 2007 06:28:56 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Fri, 26 Jan 2007 12:28:50 +0100 Received: from S4DE8PSAAGO.mitte.t-com.de ([10.151.180.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 12:28:50 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [BLISS] Welcome! Main question - what services? Date: Fri, 26 Jan 2007 12:28:49 +0100 Message-Id: <85108216918A984C8C60172D7C84770A56F9A2@S4DE8PSAAGO.mitte.t-com.de> In-Reply-To: <45B951D8.8090400@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Welcome! Main question - what services? Thread-Index: AcdBCIDxlOSRWE4KTUq7vqUnpedZbwAM7yqQ From: "Jesske, R" To: , X-OriginalArrivalTime: 26 Jan 2007 11:28:50.0553 (UTC) FILETIME=[26F1A690:01C7413D] X-Spam-Score: 0.9 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org What we need from operator point of view are services that are running within SIP and has their interoperability with the existing legacy networks. Here are some issues: CCBS/CCNR COLP/COLR =3D TIP/TIR =3D 2nd untrusted identity in a normal response (needed for interoperability and to have combined PSTNM/SIP PBX services) CPC parameter issue where we need to signal a network provided category of the user within SIP=20 transfer for interoperability reasons release cause values within SIP (not only in Requests also in Responses) to process announcements Perhaps some future issues like Closed User Group Not covered issues in the draft-jesske-sipping-tispan-requirements. That are my ideas what comes out of myself thinking on issues for BLISS. Thanks Roland > >>> > >>> Jonathan Rosenberg wrote: > >>> > >>>> If you haven't done so already, everyone please take a=20 > look at the=20 > >>>> charter: > >>>> > >>>> http://sip101.net/charter.html > >>>> > >>>> In my mind, the main question to be answered is what features we=20 > >>>> want to work on, and in what order. We've chosen four to=20 > begin with=20 > >>>> - BLA, pickup, DND, and CCBS, since these have been=20 > reported to be=20 > >>>> the most problematic. > >>>> > >>>> If anyone has comments on different ones they'd like to=20 > see worked=20 > >>>> on, please comment. Especially welcome are examples of=20 > REAL interop=20 > >>>> problems or hacks that have been put into place in real=20 > >>>> implementations and deployments to make something happen. > >>>> > >>>> Thanks, > >>>> Jonathan R. > >>> > >>> > >>> > >> > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Jan 26 13:28:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVol-0007y3-W5; Fri, 26 Jan 2007 13:28:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVok-0007xt-9A for bliss@ietf.org; Fri, 26 Jan 2007 13:28:54 -0500 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAVoe-00086E-L5 for bliss@ietf.org; Fri, 26 Jan 2007 13:28:54 -0500 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l0QISggm017470; Fri, 26 Jan 2007 11:28:43 -0700 Message-ID: <45BA485D.4000502@ntt-at.com> Date: Fri, 26 Jan 2007 10:28:45 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [BLISS] Welcome! Main question - what services? References: <45B142CC.3070508@cisco.com> <45B1F1F6.3000002@nokia.com> <45B777FF.10105@cisco.com> <45B85E14.3020100@nokia.com> <45B951FE.5020409@cisco.com> In-Reply-To: <45B951FE.5020409@cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Miguel Garcia , bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I tried to incorporate some of the comments provided in the last week including the one below to the charter. Updated charter is available at http://www.bliss-ietf.org/charter.html diff is available at http://www.bliss-ietf.org/diff1.html Shida Jonathan Rosenberg wrote: > OK, I think this is a reasonable change to the charter. > > -Jonathan R. > > Miguel Garcia wrote: > >> Jonathan Rosenberg wrote: >> >>> >>> >>> Miguel Garcia wrote: >>> >>>> I think it is reasonable to work on the approach that you propose, >>>> Jonathan. I have a couple of questions and comments about the >>>> proposed charter. >>>> >>>> 1) When the charter speaks about heterogeneous networks, does it >>>> refer only to SIP networks or does it consider interoperability >>>> across, say, the PSTN. I am sure the TISPAN guys will ask this >>>> question sooner or later, so better to write the answer, whatever >>>> it is, in the charter. >>> >>> >>> Its referring to SIP neworks. The heterogeneity refers to endpoints, >>> which includes gateways to the PSTN. Thus, the idea was most >>> definitely to take into considerating how a gateway might implement >>> these services due to the fact that it is a gateway, and is trying >>> to interwork to another network. >>> >>> This is captured in the charter already here: >>> >>> "The problem is exacerbated by the desire for these features to work >>> across many types of SIP endpoints, including SIP hardphones, >>> softphones, and gateways to the PSTN and other VoIP networks, and >>> for the desire to work across domain boundaries." >>> >>> Can you suggest some additional text to clarify? >> >> >> I am satisfied with your explanation. When I read the charter I >> interpreted "domain boundaries" as in "SIP domain boundaries", but I >> understand now that you mean crossing to the PSTN, for example. If >> you want, you could add make the sentence to read "... and for the >> desire to work across domain boundaries and to seamless interwork >> with the PSTN, when applicable". >> >> /Miguel >> >> >> > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Sun Jan 28 18:36:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBJZK-0005n5-3S; Sun, 28 Jan 2007 18:36:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBJZI-0005jg-5o for bliss@ietf.org; Sun, 28 Jan 2007 18:36:16 -0500 Received: from alnrmhc15.comcast.net ([204.127.225.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBJZG-0005pZ-UZ for bliss@ietf.org; Sun, 28 Jan 2007 18:36:16 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc15) with ESMTP id <20070128233614b1500krduse>; Sun, 28 Jan 2007 23:36:14 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l0SNaDVJ013779 for ; Sun, 28 Jan 2007 18:36:13 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0SNaD49013775; Sun, 28 Jan 2007 18:36:13 -0500 Date: Sun, 28 Jan 2007 18:36:13 -0500 Message-Id: <200701282336.l0SNaD49013775@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <45B95686.90208@cisco.com> (jdrosen@cisco.com) Subject: Re: [BLISS] Welcome! Main question - what services? References: <45B8BAB9.7020409@cisco.com> <45B95686.90208@cisco.com> X-Spam-Score: 1.1 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org From: Jonathan Rosenberg I don't want to have a spec that rigorously defines all 8 of the above, with specific call flows for each and a name for each. I want vendors to be able to implement any one of these 8 and for it to work. Indeed, any of the above 8 would work as long as we define how the invocation works, since that IMHO is the primary interop problem around this feature. If one phone expects the network to do the DND processing, and the corresponding IP PBX expects the phone to do it, we have a serious interop failure. Yes, I think that at this point in the discussion, we want to avoid trying to be too exact about what "services" are. Really, exploring the meaning of any given named "service" is part of our charter. Ideally, the endpoint will be a clear understanding of what services can be provided, and what the building blocks of the services are, and how those building blocks interact to provide services, and consequently, what users need to do to obtain a service. As an example, the sipX call pick-up operation involves 3 phones: A phone A makes a call to a phone B. From a phone C, intercept the ringing call and talk to A. To do this requires: phone A implements INVITE-with-Replaces, phone B implements the dialog event package, and either: phone C implements the pick-up operation natively, or the proxy implements a "call pick-up agent" (like sipX does) to perform the operation But it was the result of a lot of analysis to discern that that is what is needed for call pick-up. And that has left out a number of interesting questions in regard to operation across SIP administrative domains. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jan 31 05:18:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCCY6-0007fd-H4; Wed, 31 Jan 2007 05:18:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCCY5-0007fL-Mi for bliss@ietf.org; Wed, 31 Jan 2007 05:18:41 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCCY0-0004uk-Sl for bliss@ietf.org; Wed, 31 Jan 2007 05:18:41 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCQ004629W412@szxga04-in.huawei.com> for bliss@ietf.org; Wed, 31 Jan 2007 18:16:52 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCQ001I89W3VN@szxga04-in.huawei.com> for bliss@ietf.org; Wed, 31 Jan 2007 18:16:52 +0800 (CST) Received: from x18916 ([10.85.204.154]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCQ00GBR9W1LH@szxml03-in.huawei.com> for bliss@ietf.org; Wed, 31 Jan 2007 18:16:51 +0800 (CST) Date: Wed, 31 Jan 2007 18:16:48 +0800 From: Peili Xu Subject: RE: [BLISS] Welcome! Main question - what services? In-reply-to: <45BA485D.4000502@ntt-at.com> To: shida@ntt-at.com, 'Jonathan Rosenberg' Message-id: <024701c74520$eb25edf0$9acc550a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcdBd+J7UGpwRItWTbafrJqu65ssRADprtOQ X-Spam-Score: 0.9 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org After looking at the following sentences in the draft charger "The difference between SIPPING and BLISS, is that BLISS is focused on a particular type of SIP application - call features, and in particular, advanced call features requiring non-trivial call control. SIP applications such as configuration, presence and IM, and session policy are clearly out of scope for BLISS and remain the sole province of SIPPING. " It seems the WG will actually focus on features initiated by INVITE and these features are more or less related to traditional PSTN/ISDN supplementary services. If I am correct, what about session mode messaging service which is also a call initiated by INVITE? thanks Peili -----Original Message----- From: Shida Schubert [mailto:shida@ntt-at.com] Sent: Saturday, January 27, 2007 2:29 AM To: Jonathan Rosenberg Cc: Miguel Garcia; bliss@ietf.org Subject: Re: [BLISS] Welcome! Main question - what services? I tried to incorporate some of the comments provided in the last week including the one below to the charter. Updated charter is available at http://www.bliss-ietf.org/charter.html diff is available at http://www.bliss-ietf.org/diff1.html Shida Jonathan Rosenberg wrote: > OK, I think this is a reasonable change to the charter. > > -Jonathan R. > > Miguel Garcia wrote: > >> Jonathan Rosenberg wrote: >> >>> >>> >>> Miguel Garcia wrote: >>> >>>> I think it is reasonable to work on the approach that you propose, >>>> Jonathan. I have a couple of questions and comments about the >>>> proposed charter. >>>> >>>> 1) When the charter speaks about heterogeneous networks, does it >>>> refer only to SIP networks or does it consider interoperability >>>> across, say, the PSTN. I am sure the TISPAN guys will ask this >>>> question sooner or later, so better to write the answer, whatever >>>> it is, in the charter. >>> >>> >>> Its referring to SIP neworks. The heterogeneity refers to endpoints, >>> which includes gateways to the PSTN. Thus, the idea was most >>> definitely to take into considerating how a gateway might implement >>> these services due to the fact that it is a gateway, and is trying >>> to interwork to another network. >>> >>> This is captured in the charter already here: >>> >>> "The problem is exacerbated by the desire for these features to work >>> across many types of SIP endpoints, including SIP hardphones, >>> softphones, and gateways to the PSTN and other VoIP networks, and >>> for the desire to work across domain boundaries." >>> >>> Can you suggest some additional text to clarify? >> >> >> I am satisfied with your explanation. When I read the charter I >> interpreted "domain boundaries" as in "SIP domain boundaries", but I >> understand now that you mean crossing to the PSTN, for example. If >> you want, you could add make the sentence to read "... and for the >> desire to work across domain boundaries and to seamless interwork >> with the PSTN, when applicable". >> >> /Miguel >> >> >> > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jan 31 13:58:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCKeW-0002B0-5h; Wed, 31 Jan 2007 13:57:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCKeV-0002Av-QY for bliss@ietf.org; Wed, 31 Jan 2007 13:57:51 -0500 Received: from rwcrmhc12.comcast.net ([204.127.192.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCKeU-0002Oo-J4 for bliss@ietf.org; Wed, 31 Jan 2007 13:57:51 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc12) with ESMTP id <20070131185749m120033t7qe>; Wed, 31 Jan 2007 18:57:49 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l0VIvl98004118 for ; Wed, 31 Jan 2007 13:57:47 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0VIvlnO004114; Wed, 31 Jan 2007 13:57:47 -0500 Date: Wed, 31 Jan 2007 13:57:47 -0500 Message-Id: <200701311857.l0VIvlnO004114@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <024701c74520$eb25edf0$9acc550a@china.huawei.com> (xupeili@huawei.com) Subject: Re: [BLISS] Welcome! Main question - what services? References: <024701c74520$eb25edf0$9acc550a@china.huawei.com> X-Spam-Score: 1.1 (+) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org From: Peili Xu If I am correct, what about session mode messaging service which is also a call initiated by INVITE? Looking at the charter, it seems to me that all of the services mentioned are applicable to messaging sessions in the same way as audio calls. Indeed, for the deaf community, I can see all of these services being useful. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jan 31 15:29:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCM5F-0007ER-EE; Wed, 31 Jan 2007 15:29:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCM5E-0007E5-T9 for bliss@ietf.org; Wed, 31 Jan 2007 15:29:32 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCM4t-0003RS-MT for bliss@ietf.org; Wed, 31 Jan 2007 15:29:19 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCR00MHE28LSL@usaga01-in.huawei.com> for bliss@ietf.org; Wed, 31 Jan 2007 12:29:09 -0800 (PST) Received: from huawei.com ([172.18.4.47]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCR008FD28KAC@usaga01-in.huawei.com> for bliss@ietf.org; Wed, 31 Jan 2007 12:29:09 -0800 (PST) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCR00AIU2QYM9@usaml03-in.huawei.com> for bliss@ietf.org; Wed, 31 Jan 2007 12:40:11 -0800 (PST) Date: Wed, 31 Jan 2007 14:29:07 -0600 From: Spencer Dawkins Subject: Fw: [BLISS] Welcome! Main question - what services? To: bliss@ietf.org Message-id: <015901c74576$75c85830$6501a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.9 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi, Jonathan and Shida, And now that Peili jogged me to read the actual words in the charter, isn't presence the sole province of SIMPLE? Thanks, Spencer > After looking at the following sentences in the draft charger "The > difference between SIPPING and BLISS, is that BLISS is focused on a > particular type of SIP application - call features, and in particular, > advanced call features requiring non-trivial call control. SIP > applications > such as configuration, presence and IM, and session policy are clearly out > of scope for BLISS and remain the sole province of SIPPING. " > > It seems the WG will actually focus on features initiated by INVITE and > these features are more or less related to traditional PSTN/ISDN > supplementary services. > If I am correct, what about session mode messaging service which is also a > call initiated by INVITE? > > thanks > Peili _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jan 31 16:34:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCN5l-0000kl-1d; Wed, 31 Jan 2007 16:34:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCN5k-0000ke-Ee for bliss@ietf.org; Wed, 31 Jan 2007 16:34:08 -0500 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCN5j-0007It-3I for bliss@ietf.org; Wed, 31 Jan 2007 16:34:08 -0500 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l0VLXo4j004465; Wed, 31 Jan 2007 14:33:50 -0700 Message-ID: <45C10B3F.4070507@ntt-at.com> Date: Wed, 31 Jan 2007 13:33:51 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Spencer Dawkins Subject: Re: Fw: [BLISS] Welcome! Main question - what services? References: <015901c74576$75c85830$6501a8c0@china.huawei.com> In-Reply-To: <015901c74576$75c85830$6501a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi Spencer; Yes you are right. I will change the text to say.. "SIP applications such as configuration, presence and IM, and session policy are clearly out of scope for BLISS and remain the sole province of SIPPING and SIMPLE." Thanks Shida Spencer Dawkins wrote: > Hi, Jonathan and Shida, > > And now that Peili jogged me to read the actual words in the charter, > isn't presence the sole province of SIMPLE? > > Thanks, > > Spencer > > >> After looking at the following sentences in the draft charger "The >> difference between SIPPING and BLISS, is that BLISS is focused on a >> particular type of SIP application - call features, and in particular, >> advanced call features requiring non-trivial call control. SIP >> applications >> such as configuration, presence and IM, and session policy are >> clearly out >> of scope for BLISS and remain the sole province of SIPPING. " >> >> It seems the WG will actually focus on features initiated by INVITE and >> these features are more or less related to traditional PSTN/ISDN >> supplementary services. >> If I am correct, what about session mode messaging service which is >> also a >> call initiated by INVITE? >> >> thanks >> Peili > > > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jan 31 16:48:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCNJE-0000m8-Hv; Wed, 31 Jan 2007 16:48:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCNJD-0000m3-UD for bliss@ietf.org; Wed, 31 Jan 2007 16:48:03 -0500 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCNJ9-0001lf-HY for bliss@ietf.org; Wed, 31 Jan 2007 16:48:03 -0500 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l0VLlmpD014747; Wed, 31 Jan 2007 14:47:49 -0700 Message-ID: <45C10E86.3010006@ntt-at.com> Date: Wed, 31 Jan 2007 13:47:50 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Peili Xu Subject: Re: [BLISS] Welcome! Main question - what services? References: <024701c74520$eb25edf0$9acc550a@china.huawei.com> In-Reply-To: <024701c74520$eb25edf0$9acc550a@china.huawei.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi Peili; Session mode messaging service as I mentioned in the response to Spencer is not in scope of BLISS. I will modify the text that raised this question. Thanks. Shida Peili Xu wrote: > After looking at the following sentences in the draft charger "The > difference between SIPPING and BLISS, is that BLISS is focused on a > particular type of SIP application - call features, and in particular, > advanced call features requiring non-trivial call control. SIP applications > such as configuration, presence and IM, and session policy are clearly out > of scope for BLISS and remain the sole province of SIPPING. " > > It seems the WG will actually focus on features initiated by INVITE and > these features are more or less related to traditional PSTN/ISDN > supplementary services. > If I am correct, what about session mode messaging service which is also a > call initiated by INVITE? > > thanks > Peili > > -----Original Message----- > From: Shida Schubert [mailto:shida@ntt-at.com] > Sent: Saturday, January 27, 2007 2:29 AM > To: Jonathan Rosenberg > Cc: Miguel Garcia; bliss@ietf.org > Subject: Re: [BLISS] Welcome! Main question - what services? > > > I tried to incorporate some of the comments provided in the last week > including the one below to the charter. > Updated charter is available at > > http://www.bliss-ietf.org/charter.html > > diff is available at http://www.bliss-ietf.org/diff1.html > > Shida > > > Jonathan Rosenberg wrote: > >> OK, I think this is a reasonable change to the charter. >> >> -Jonathan R. >> >> Miguel Garcia wrote: >> >> >>> Jonathan Rosenberg wrote: >>> >>> >>>> Miguel Garcia wrote: >>>> >>>> >>>>> I think it is reasonable to work on the approach that you propose, >>>>> Jonathan. I have a couple of questions and comments about the >>>>> proposed charter. >>>>> >>>>> 1) When the charter speaks about heterogeneous networks, does it >>>>> refer only to SIP networks or does it consider interoperability >>>>> across, say, the PSTN. I am sure the TISPAN guys will ask this >>>>> question sooner or later, so better to write the answer, whatever >>>>> it is, in the charter. >>>>> >>>> Its referring to SIP neworks. The heterogeneity refers to endpoints, >>>> which includes gateways to the PSTN. Thus, the idea was most >>>> definitely to take into considerating how a gateway might implement >>>> these services due to the fact that it is a gateway, and is trying >>>> to interwork to another network. >>>> >>>> This is captured in the charter already here: >>>> >>>> "The problem is exacerbated by the desire for these features to work >>>> across many types of SIP endpoints, including SIP hardphones, >>>> softphones, and gateways to the PSTN and other VoIP networks, and >>>> for the desire to work across domain boundaries." >>>> >>>> Can you suggest some additional text to clarify? >>>> >>> I am satisfied with your explanation. When I read the charter I >>> interpreted "domain boundaries" as in "SIP domain boundaries", but I >>> understand now that you mean crossing to the PSTN, for example. If >>> you want, you could add make the sentence to read "... and for the >>> desire to work across domain boundaries and to seamless interwork >>> with the PSTN, when applicable". >>> >>> /Miguel >>> >>> >>> >>> > > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > > > > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jan 31 22:15:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCSQ1-0004ON-CM; Wed, 31 Jan 2007 22:15:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCLnf-0007av-Ox for bliss@ietf.org; Wed, 31 Jan 2007 15:11:23 -0500 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HCLne-0005f0-CM for bliss@ietf.org; Wed, 31 Jan 2007 15:11:23 -0500 Received: from source ([192.150.11.134]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Wed, 31 Jan 2007 12:11:21 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l0VK7xvV015795; Wed, 31 Jan 2007 12:08:04 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l0VKBFeA019014; Wed, 31 Jan 2007 12:11:15 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 12:11:07 -0800 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 Subject: RE: [BLISS] Welcome! Main question - what services? Date: Wed, 31 Jan 2007 12:11:02 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223ADE6B@namail5.corp.adobe.com> In-Reply-To: <200701311857.l0VIvlnO004114@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Welcome! Main question - what services? Thread-Index: AcdFadQlk7qTAsinSvynUS3ceBenrAACP8Ow References: <024701c74520$eb25edf0$9acc550a@china.huawei.com> <200701311857.l0VIvlnO004114@dragon.ariadne.com> From: "Henry Sinnreich" To: , X-OriginalArrivalTime: 31 Jan 2007 20:11:07.0492 (UTC) FILETIME=[F147D240:01C74573] X-Spam-Score: 0.9 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-Mailman-Approved-At: Wed, 31 Jan 2007 22:15:25 -0500 Cc: X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org > it seems to me that all of the services mentioned are applicable=20 > to messaging sessions in the same way as audio calls Thanks for bringing this up. Using SIP for voice only seems a crippled approach, since everyone is also using presence and IM.=20 Moreover, presence, IM, and voice must be usable on mobile devices that are part and parcel of enterprise communications. Not to mention video that is such an important part in many business and consumer communications. Besides, the same people on this list are also in the SIMPLE WG. I hope the energy from SIMPLE is not leaking over to Jabber, since that would be a sad precedent for BLISS. Thanks again, Henry =20 -----Original Message----- From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]=20 Sent: Wednesday, January 31, 2007 12:58 PM To: bliss@ietf.org Subject: Re: [BLISS] Welcome! Main question - what services? From: Peili Xu If I am correct, what about session mode messaging service which is also a call initiated by INVITE? Looking at the charter, it seems to me that all of the services mentioned are applicable to messaging sessions in the same way as audio calls. Indeed, for the deaf community, I can see all of these services being useful. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jan 31 23:16:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCTNL-00028H-93; Wed, 31 Jan 2007 23:16:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCTNK-000285-5P for bliss@ietf.org; Wed, 31 Jan 2007 23:16:42 -0500 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCTNF-0008Ai-Nw for bliss@ietf.org; Wed, 31 Jan 2007 23:16:42 -0500 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l114GN6h005582; Wed, 31 Jan 2007 21:16:23 -0700 Message-ID: <45C16998.4030704@ntt-at.com> Date: Wed, 31 Jan 2007 20:16:24 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: shida@ntt-at.com Subject: Re: [BLISS] Welcome! Main question - what services? References: <024701c74520$eb25edf0$9acc550a@china.huawei.com> <45C10E86.3010006@ntt-at.com> In-Reply-To: <45C10E86.3010006@ntt-at.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: bliss@ietf.org, hsinnrei@adobe.com X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I really don't like sending comment to something I sent myself, but here it is. I thought about this a bit more, as SIMPLE is aiming to close in August, by what's advocated by few to include session mode messaging service may be a reasonable things to do. As Jonathan mentioned somewhere, we are hoping that when the output of this group goes out, it would allow variation(more advanced features). The spec possibly provides a hooks to realize those variations but may not define the variations in itself. The session mode messaging service may be one of the variation. AFAIK, most of the services we listed as a potential milestones are facing interop problems right now. I personally like to get out remedies out there soon, before the problems worsen. To ensure this, I want to avoid broadening the scope for "nice to have", which may hinder the remedies from getting out there. As for considering session mode messaging, unless we are thinking of using session mode messaging for service invocation, I don't think there is really anything we need to consider differently for the session mode messaging service.. Anyhow, I personally like to see solutions based on tool-sets that are regularly implemented, so wider use of our documents are possible which I believe would lead to less interop problems which I believe is the core objective of this group. If you see that the session mode messaging service is mandatory, I would appreciate it if you can provide some text for the draft charter. Thanks & Regards Shida Shida Schubert wrote: > Hi Peili; > > Session mode messaging service as I mentioned in the > response to Spencer is not in scope of BLISS. I will modify > the text that raised this question. > > Thanks. > Shida > > Peili Xu wrote: > >> After looking at the following sentences in the draft charger "The >> difference between SIPPING and BLISS, is that BLISS is focused on a >> particular type of SIP application - call features, and in particular, >> advanced call features requiring non-trivial call control. SIP applications >> such as configuration, presence and IM, and session policy are clearly out >> of scope for BLISS and remain the sole province of SIPPING. " >> >> It seems the WG will actually focus on features initiated by INVITE and >> these features are more or less related to traditional PSTN/ISDN >> supplementary services. >> If I am correct, what about session mode messaging service which is also a >> call initiated by INVITE? >> >> thanks >> Peili >> >> -----Original Message----- >> From: Shida Schubert [mailto:shida@ntt-at.com] >> Sent: Saturday, January 27, 2007 2:29 AM >> To: Jonathan Rosenberg >> Cc: Miguel Garcia; bliss@ietf.org >> Subject: Re: [BLISS] Welcome! Main question - what services? >> >> >> I tried to incorporate some of the comments provided in the last week >> including the one below to the charter. >> Updated charter is available at >> >> http://www.bliss-ietf.org/charter.html >> >> diff is available at http://www.bliss-ietf.org/diff1.html >> >> Shida >> >> >> Jonathan Rosenberg wrote: >> >> >>> OK, I think this is a reasonable change to the charter. >>> >>> -Jonathan R. >>> >>> Miguel Garcia wrote: >>> >>> >>> >>>> Jonathan Rosenberg wrote: >>>> >>>> >>>> >>>>> Miguel Garcia wrote: >>>>> >>>>> >>>>> >>>>>> I think it is reasonable to work on the approach that you propose, >>>>>> Jonathan. I have a couple of questions and comments about the >>>>>> proposed charter. >>>>>> >>>>>> 1) When the charter speaks about heterogeneous networks, does it >>>>>> refer only to SIP networks or does it consider interoperability >>>>>> across, say, the PSTN. I am sure the TISPAN guys will ask this >>>>>> question sooner or later, so better to write the answer, whatever >>>>>> it is, in the charter. >>>>>> >>>>>> >>>>> Its referring to SIP neworks. The heterogeneity refers to endpoints, >>>>> which includes gateways to the PSTN. Thus, the idea was most >>>>> definitely to take into considerating how a gateway might implement >>>>> these services due to the fact that it is a gateway, and is trying >>>>> to interwork to another network. >>>>> >>>>> This is captured in the charter already here: >>>>> >>>>> "The problem is exacerbated by the desire for these features to work >>>>> across many types of SIP endpoints, including SIP hardphones, >>>>> softphones, and gateways to the PSTN and other VoIP networks, and >>>>> for the desire to work across domain boundaries." >>>>> >>>>> Can you suggest some additional text to clarify? >>>>> >>>>> >>>> I am satisfied with your explanation. When I read the charter I >>>> interpreted "domain boundaries" as in "SIP domain boundaries", but I >>>> understand now that you mean crossing to the PSTN, for example. If >>>> you want, you could add make the sentence to read "... and for the >>>> desire to work across domain boundaries and to seamless interwork >>>> with the PSTN, when applicable". >>>> >>>> /Miguel >>>> >>>> >>>> >>>> >>>> >> _______________________________________________ >> BLISS mailing list >> BLISS@ietf.org >> https://www1.ietf.org/mailman/listinfo/bliss >> >> >> >> >> > > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > > > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss