From pkyzivat@cisco.com Fri Jul 1 05:37:38 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0723A11E880D for ; Fri, 1 Jul 2011 05:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cp7Q58Ajt7hz for ; Fri, 1 Jul 2011 05:37:37 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id C5A8311E882F for ; Fri, 1 Jul 2011 05:13:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2232; q=dns/txt; s=iport; t=1309522437; x=1310732037; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Nx/hXFrgX4yaJUXOzlXqsXptJq/yQ6J5hE94MO6b7e0=; b=XHt4g/BMMsrhlPdj1woo1Hi0EpSG969NjetQ+RpTX6PD8VZWPtOt5pjr v4kWyBo7uzWjQolaXZK/ojk8GC45OWed9/xnHx0YTjS3U0oBtPEnmitGP DNZn/B1XUqjLGoCUjTnnG2Y8RIUihJ2twO9UODlulub9x4848FbIuyppq M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMIAKW5DU6tJXHA/2dsb2JhbABSmG2Oc3erEp1/hjIEkjKEdotX X-IronPort-AV: E=Sophos;i="4.65,458,1304294400"; d="scan'208";a="288705518" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-4.cisco.com with ESMTP; 01 Jul 2011 12:13:56 +0000 Received: from [10.86.252.117] ([10.86.252.117]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p61CDtDe023041 for ; Fri, 1 Jul 2011 12:13:56 GMT Message-ID: <4E0DBA02.4040309@cisco.com> Date: Fri, 01 Jul 2011 08:13:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: splices@ietf.org References: <6369CB70BFD88942B9705AC1E639A33822CCE270F5@DC-US1MBEX4.global.avaya.com> <1C6C5AB3-6085-4CCA-9F1D-8BA5D98ED651@gmail.com> <4DED2EFA.20004@cisco.com> , <4E0051B1.1030007@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [splices] Using Two Separate Devices to Start a Conversation proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 12:37:38 -0000 On 6/30/2011 6:06 PM, Worley, Dale R (Dale) wrote: >>> As Dale mentioned, this also depends on the other end doing the "right >>> thing" with this case. It is a leap of faith to assume it will realize it >>> should accept both streams and use one for input and the other for output. >>> >>> ISTM its at least as likely that it would accept the first stream, reject >>> the second, and then have only a one-way "conversation". >> >> OK, I understand the problem right now. The problem is that this is a >> special kind of "Join" operation. It is kind of a join, but not >> quite. >> >> The operation we are after is perhaps similar to 3.3.8 Far-Fork in RFC 5850: >> >> I suspect instead of Join, we need a new primitive, lets call it >> Splice or Merge which requests the UAS to add the media in the INVITE >> into the dialog that is referenced. > > OK, now I see the problem with using Join. > > UA A1 sends an INVITE (requesting only audio) to UA B (which supports > both audio and video). > > UA A2 sends an INVITE (requesting only video) to UA B (which supports > both audio and video), with Join to the first dialog. > > Then we should expect that UA B will send its audio to A1 and its > video to A2, within the semantics of Join. > > The difficulty is that UA B still sees the situation as two different > dialogs. E.g., if A1 sends a REFER/Refer-To: C to B, the A1-B dialog > will be replaced by the C-B dialog, but the A2-B dialog will be > undisturbed. > > Which is not the behavior we want if we are trying to logically bond > A1 and A2 to act as a single UA. > > Using Join would have been convenient as it is already defined, and > theoretically, UAs already support it. That would be the problem if the user at A orchestrates A1 and A1 to establish a "call" to B. This is once again a problem because there is no one UA acting on behalf of A and holding the complete dialog to B. It would not be a problem if you had A1 holding one audio/video dialog with B, doing the audio itself and having another dialog with A2 for video. That would be true regardless of how the dialog with A2 was established - even if it was a join from A2 to A1. Thanks, Paul From dworley@avaya.com Fri Jul 1 12:26:51 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4D49E800B for ; Fri, 1 Jul 2011 12:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.37 X-Spam-Level: X-Spam-Status: No, score=-103.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hv4rZ5Cy3cov for ; Fri, 1 Jul 2011 12:26:51 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id C36859E8008 for ; Fri, 1 Jul 2011 12:26:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALodDk7GmAcF/2dsb2JhbABSqAF3rnkCmw+GMgSXRYs6 X-IronPort-AV: E=Sophos;i="4.65,460,1304308800"; d="scan'208";a="254485564" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Jul 2011 15:26:48 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Jul 2011 15:25:51 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Fri, 1 Jul 2011 15:26:47 -0400 From: "Worley, Dale R (Dale)" To: Paul Kyzivat , "splices@ietf.org" Date: Fri, 1 Jul 2011 15:26:09 -0400 Thread-Topic: [splices] Using Two Separate Devices to Start a Conversation proposal Thread-Index: Acw37nvelmMKoMQRT4Kjlrzzi4C+EwANj6/3 Message-ID: References: <6369CB70BFD88942B9705AC1E639A33822CCE270F5@DC-US1MBEX4.global.avaya.com> <1C6C5AB3-6085-4CCA-9F1D-8BA5D98ED651@gmail.com> <4DED2EFA.20004@cisco.com> , <4E0051B1.1030007@ericsson.com> , <4E0DBA02.4040309@cisco.com> In-Reply-To: <4E0DBA02.4040309@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [splices] Using Two Separate Devices to Start a Conversation proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 19:26:51 -0000 Which reminds me of a requirement that should be in the draft: The mechani= sm should work even if both endpoints are using it at the same time. Dale From dworley@avaya.com Wed Jul 6 11:45:13 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F11D21F88F6 for ; Wed, 6 Jul 2011 11:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.482 X-Spam-Level: X-Spam-Status: No, score=-103.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPVs5dlKsLaP for ; Wed, 6 Jul 2011 11:45:12 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 8670A21F889E for ; Wed, 6 Jul 2011 11:45:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABisFE7GmAcF/2dsb2JhbABTqAZ3sGoCk1OGNwSXWItC X-IronPort-AV: E=Sophos;i="4.65,488,1304308800"; d="scan'208";a="255193157" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 06 Jul 2011 14:45:11 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 Jul 2011 14:43:57 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Wed, 6 Jul 2011 14:45:10 -0400 From: "Worley, Dale R (Dale)" To: "Shekh-Yusef, Rifaat (Rifaat)" , "splices@ietf.org" Date: Wed, 6 Jul 2011 14:43:58 -0400 Thread-Topic: [splices] FW: New Version Notification for draft-loreto-splices-disaggregated-media-02.txt Thread-Index: AQHMMzqBy1sccPwpBkmAYEmBU4E3tJTfst5C Message-ID: References: <6369CB70BFD88942B9705AC1E639A33822CE7CF83F@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CE7CF83F@DC-US1MBEX4.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [splices] FW: New Version Notification for draft-loreto-splices-disaggregated-media-02.txt X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 18:45:13 -0000 ________________________________________ From: splices-bounces@ietf.org [splices-bounces@ietf.org] On Behalf Of Shek= h-Yusef, Rifaat (Rifaat) [rifatyu@avaya.com] We have just submitted a new version for the draft-loreto-splices-disaggreg= ated-media draft. https://datatracker.ietf.org/doc/draft-loreto-splices-disaggregated-media/ ________________________________________ If I understand the document correctly, it's a use-cases document, not a re= quirements document, or a solution document. One use case I don't see is where both ends of the call are using disaggreg= ation (or should it be aggregation?) simultaneously. Dale From salvatore.loreto@ericsson.com Wed Jul 6 12:05:21 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E7F21F8A8B for ; Wed, 6 Jul 2011 12:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMyFOtmng8Pp for ; Wed, 6 Jul 2011 12:05:20 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 132EB21F8A81 for ; Wed, 6 Jul 2011 12:05:19 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-1f-4e14b1ee3313 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C8.87.20773.EE1B41E4; Wed, 6 Jul 2011 21:05:19 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Wed, 6 Jul 2011 21:05:18 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 81C01245D for ; Wed, 6 Jul 2011 22:05:18 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3A728511F6 for ; Wed, 6 Jul 2011 22:05:18 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E9FC7510CE for ; Wed, 6 Jul 2011 22:05:17 +0300 (EEST) Message-ID: <4E14B1ED.6070900@ericsson.com> Date: Wed, 6 Jul 2011 22:05:17 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: splices@ietf.org References: <6369CB70BFD88942B9705AC1E639A33822CE7CF83F@DC-US1MBEX4.global.avaya.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [splices] FW: New Version Notification for draft-loreto-splices-disaggregated-media-02.txt X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 19:05:21 -0000 On 7/6/11 9:43 PM, Worley, Dale R (Dale) wrote: > ________________________________________ > From: splices-bounces@ietf.org [splices-bounces@ietf.org] On Behalf Of Shekh-Yusef, Rifaat (Rifaat) [rifatyu@avaya.com] > > We have just submitted a new version for the draft-loreto-splices-disaggregated-media draft. > https://datatracker.ietf.org/doc/draft-loreto-splices-disaggregated-media/ > ________________________________________ > > If I understand the document correctly, it's a use-cases document, not a requirements document, > or a solution document. Hi Dale you are right, this is a use-cases documents > One use case I don't see is where both ends of the call are using disaggregation (or should it be > aggregation?) simultaneously. well that use case would be really interesting in the case of disaggregation, not so sure if for the aggregation one, that the wg is now investigating, would add anything cheers /Sal -- Salvatore Loreto www.sloreto.com From dworley@avaya.com Wed Jul 6 12:09:08 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0197321F8ACE for ; Wed, 6 Jul 2011 12:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.49 X-Spam-Level: X-Spam-Status: No, score=-103.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dA4TCGxuaKRP for ; Wed, 6 Jul 2011 12:09:07 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 1659E21F8ACD for ; Wed, 6 Jul 2011 12:09:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPixFE6HCzI1/2dsb2JhbABTqAh3sQ0CmzeGNwSXWItC X-IronPort-AV: E=Sophos;i="4.65,488,1304308800"; d="scan'208";a="289135923" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Jul 2011 15:09:04 -0400 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 06 Jul 2011 15:02:15 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Wed, 6 Jul 2011 15:09:03 -0400 From: "Worley, Dale R (Dale)" To: Salvatore Loreto , "splices@ietf.org" Date: Wed, 6 Jul 2011 15:07:00 -0400 Thread-Topic: [splices] FW: New Version Notification for draft-loreto-splices-disaggregated-media-02.txt Thread-Index: Acw8D6mLf1iksMsUROab7DeAn1kfHQAADfx8 Message-ID: References: <6369CB70BFD88942B9705AC1E639A33822CE7CF83F@DC-US1MBEX4.global.avaya.com> , <4E14B1ED.6070900@ericsson.com> In-Reply-To: <4E14B1ED.6070900@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [splices] FW: New Version Notification for draft-loreto-splices-disaggregated-media-02.txt X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 19:09:08 -0000 Here are diagrams of both ends using disaggregated media, with 2 UAs each, = each UA handling two media streams. The first diagram is "near-end managed= ", where each end has a UA managing all of its UAs. The second diagram is = "far-end managed", where the far-end UAs are aware of the aggregation. (This is fixed-width ASCII art. You may have to copy it to another tool to= see it correctly.) "near-end managed": ---- ---- | UA |\\ //| UA | ---- \\ stream 1 stream 1 // ---- stream 2 \\ // stream 3 \---- ............. ----/ =20 | UA |.............| UA | =20 /---- ............. ----\ =20 stream 3 // ............. \\ stream 2 ---- // stream 4 stream 4 \\ ---- | UA |// \\| UA | ---- ---- Alice Bob "far-end managed": /------------\ stream 1 /------------\=20 | ---- ____|________________|____ ---- | | | UA |____|______ ______|____| UA | | | ---- stream 2 \ / | ---- | | | \/ | | | | /\ | | | stream 3 / \ | | | ---- ____|_____/ \_____|____ ---- | | | UA |____|________________|____| UA | | | ---- | stream 4 | ---- | \------------/ \------------/=20 Alice Bob =20 Dale From salvatore.loreto@ericsson.com Thu Jul 7 09:04:36 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9025311E8081 for ; Thu, 7 Jul 2011 09:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzYzBuhlo8WL for ; Thu, 7 Jul 2011 09:04:36 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id ABDE111E807A for ; Thu, 7 Jul 2011 09:04:35 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-cc-4e15d91255d6 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id BC.F0.09774.219D51E4; Thu, 7 Jul 2011 18:04:34 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Thu, 7 Jul 2011 18:04:34 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4ADD2245F; Thu, 7 Jul 2011 19:04:34 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0484A511AC; Thu, 7 Jul 2011 19:04:34 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 991E851016; Thu, 7 Jul 2011 19:04:33 +0300 (EEST) Message-ID: <4E15D911.2050402@ericsson.com> Date: Thu, 7 Jul 2011 19:04:33 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" References: <6369CB70BFD88942B9705AC1E639A33822CE7CF83F@DC-US1MBEX4.global.avaya.com> , <4E14B1ED.6070900@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: "splices@ietf.org" Subject: Re: [splices] FW: New Version Notification for draft-loreto-splices-disaggregated-media-02.txt X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 16:04:36 -0000 Hi Dale, what you show in the below diagrams are media streams not dialog, isn't it? if so, the "near-end managed" is not really clear to me: what the UA, the one managing all of its UAs, is supposed to do with the media streams that passes trough it? /Sal On 7/6/11 10:07 PM, Worley, Dale R (Dale) wrote: > Here are diagrams of both ends using disaggregated media, with 2 UAs each, each UA handling two media streams. The first diagram is "near-end managed", where each end has a UA managing all of its UAs. The second diagram is "far-end managed", where the far-end UAs are aware of the aggregation. > > (This is fixed-width ASCII art. You may have to copy it to another tool to see it correctly.) > > "near-end managed": > > ---- ---- > | UA |\\ //| UA | > ---- \\ stream 1 stream 1 // ---- > stream 2 \\ // stream 3 > \---- ............. ----/ > | UA |.............| UA | > /---- ............. ----\ > stream 3 // ............. \\ stream 2 > ---- // stream 4 stream 4 \\ ---- > | UA |// \\| UA | > ---- ---- > Alice Bob > > > > "far-end managed": > > /------------\ stream 1 /------------\ > | ---- ____|________________|____ ---- | > | | UA |____|______ ______|____| UA | | > | ---- stream 2 \ / | ---- | > | | \/ | | > | | /\ | | > | stream 3 / \ | | > | ---- ____|_____/ \_____|____ ---- | > | | UA |____|________________|____| UA | | > | ---- | stream 4 | ---- | > \------------/ \------------/ > Alice Bob > > Dale From dworley@avaya.com Thu Jul 7 11:56:00 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71C01F0CAF for ; Thu, 7 Jul 2011 11:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.501 X-Spam-Level: X-Spam-Status: No, score=-103.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIIT62ovVJ0e for ; Thu, 7 Jul 2011 11:56:00 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 69B4D1F0CAE for ; Thu, 7 Jul 2011 11:56:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGgAFk7GmAcF/2dsb2JhbABTpzZ3sCMCmx6GOASXYYtC X-IronPort-AV: E=Sophos;i="4.65,494,1304308800"; d="scan'208";a="289392646" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 07 Jul 2011 14:55:59 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Jul 2011 14:54:43 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Thu, 7 Jul 2011 14:55:59 -0400 From: "Worley, Dale R (Dale)" To: Salvatore Loreto Date: Thu, 7 Jul 2011 14:56:00 -0400 Thread-Topic: [splices] FW: New Version Notification for draft-loreto-splices-disaggregated-media-02.txt Thread-Index: Acw8v5R5jk7sM3ZLTjS2H6Zlgg1brgAFxEUy Message-ID: References: <6369CB70BFD88942B9705AC1E639A33822CE7CF83F@DC-US1MBEX4.global.avaya.com> , <4E14B1ED.6070900@ericsson.com> , <4E15D911.2050402@ericsson.com> In-Reply-To: <4E15D911.2050402@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "splices@ietf.org" Subject: Re: [splices] FW: New Version Notification for draft-loreto-splices-disaggregated-media-02.txt X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 18:56:01 -0000 ________________________________________ From: Salvatore Loreto [salvatore.loreto@ericsson.com] what you show in the below diagrams are media streams not dialog, isn't it? if so, the "near-end managed" is not really clear to me: what the UA, the one managing all of its UAs, is supposed to do with the media streams that passes trough it? ________________________________________ The drawings are taken from your draft, and yes, they aren't truly parallel= to each other. In the "near-end managed" version, called "Centralized scenario" in fig. 2,= the bundles of lines represent SIP dialogs, the individual lines are the media = streams as represented in the SDP carries in the dialogs. In that sense, all 4 str= eams go "though" the two coordinating UAs, in that those UAs pass through the SDP l= ines that describe them. Of course, the media packets themselves go directly fr= om one endpoint UA to another. In the "far-end managed" version, called "distributed scenario" near fig. 9= , there are two groups of UAs, and there are 4 SIP dialogs between them, each dialo= g responsible for one of the 4 media streams. So the lines represent SIP dialogs as well= as media streams. The overall idea though, is that disaggregation (or aggregation, if you wan= t to describe it) is being done at both ends; both Alice and Bob have multiple UA devices the= y wish to operate as if they were single UAs. Having a mechanism that works in this situation should be a requirement, IM= O. Dale From rifatyu@avaya.com Wed Jul 13 08:13:16 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC9E21F876F for ; Wed, 13 Jul 2011 08:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.229 X-Spam-Level: X-Spam-Status: No, score=-3.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EziSUbFLU9id for ; Wed, 13 Jul 2011 08:13:11 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id A40D311E80F8 for ; Wed, 13 Jul 2011 08:13:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAH21HU6HCzI1/2dsb2JhbABTl36PPnexHQKbVoVbXwSXfYtM X-IronPort-AV: E=Sophos;i="4.65,525,1304308800"; d="scan'208";a="256387340" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 13 Jul 2011 11:12:46 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 13 Jul 2011 11:05:43 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Wed, 13 Jul 2011 11:12:45 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Cullen Jennings , "splices@ietf.org" Date: Wed, 13 Jul 2011 11:12:43 -0400 Thread-Topic: [splices] INVOKE Actions Scope Thread-Index: Acww/2lIInU16D1MQoqzcynyzVKFbgQbxviA Message-ID: <6369CB70BFD88942B9705AC1E639A33822CF6DED91@DC-US1MBEX4.global.avaya.com> References: <4CA2C4386DB56F4589D436E1C3C86F752230509C3B@DC-US1MBEX4.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [splices] INVOKE Actions Scope X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 15:13:16 -0000 Hi, The following is the authors attempt to clearly define the scope of the INV= OKE actions. We would appreciate any comments. Regards, Rifaat An action can manipulate the state of an INVITE-based dialog. The following= are the only allowed actions: 1) Initiate:=20 This action instructs the UA to send an INVITE with specific character= istics to a specific target. i. Target: ii. Media: audio, video, or both iii. Direction: recvonly, sendonly, sendrecv 2) Answer:=20 This action instructs the UA to answer a call by sending a 200 OK with= specific characteristics i. Media: audio, video, or both ii. Direction: recvonly, sendonly, sendrecv 3) Join:=20 This action instructs the UA to join an existing dialog by sending an = INVITE with Join header and with specific characteristics i. Media: audio, video, or both ii. Direction: recvonly, sendonly, sendrecv 4) Terminate:=20 This action instructs the UA to terminate a dialog of an outgoing call= .=20 If the dialog is in an early state, then the UA must send a CANCEL req= uest.=20 If the dialog is in an active state, then the UA must send a BYE reque= st. 5) Decline:=20 This action instructs the UA to decline an incoming call by sending a = 603 response 6) Send to VM:=20 This action instructs the UA to stop ringing and send the incoming cal= l to the VM system by sending a 302 response. 7) Hold/Unhold:=20 This action instructs the UA to hold/unhold a call by sending a re-INV= ITE with the characteristics of the new state of the session.=20 The action allows for hold/unhold of audio, video, or both. 8) Conference: Add/Remove This action instructs the UA to create a local conference and add or r= emove parties as needed.=20 To add a party, the UA sends a REFER request to that party with the lo= cal focus. The UA can remove a party by sending a BYE request to that party= . =20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Wednesday, June 22, 2011 1:11 PM > To: splices@ietf.org > Cc: Shekh-Yusef, Rifaat (Rifaat) > Subject: Re: [splices] INVOKE Actions Scope >=20 >=20 > There are a few features that most PBX can do today there is no standardi= zed > way to use SIP to signal the changes to sip dialog state needed to implem= ent > these features. I think we should pick an initial small set of features = that > are often used and supported and do theses - that was what I hoped this d= raft > did. It proposes a few things, probably some need to be specified in more > detail, perhaps there are a few more that people think should be added, > perhaps a few proposed should be removed. >=20 > So my proposal for scope is just the scope we have in this draft which I = would > argue is a subset of the "An Action can manipulate a dialog or a multimed= ia > session." I view all the action here as changing the SIP dialog state and= what > changes happen to the multimedia session being a side effect of that. >=20 > On Jun 18, 2011, at 6:37 , Shekh-Yusef, Rifaat (Rifaat) wrote: >=20 > > Hi, > > > > I would like to start a discussion that I hope would allow us to conver= ge on > an approriate scope for the first release of this draft. > > The following is my first attempt at defining this scope: > > > > 1. An Action can manipulate a dialog or a multimedia session. > > 2. An Action can manipulate one or more dialogs or sessions at the same > time. > > 3. An Action can manipulate the state of a physical "feature" of a devi= ce, > e.g. transducer. > > 4. An Action can invoke a well-defined telephony "feature" on the UA, > e.g.hold. > > 5. An Action cannot replace an existing SIP mechanism, e.g. offer/answe= r. > > 6. An Action cannot dictate the UI behavior of the target UA. > > > > Any thoughts? > > > > Thanks, > > Rifaat > > _______________________________________________ > > splices mailing list > > splices@ietf.org > > https://www.ietf.org/mailman/listinfo/splices >=20 >=20 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 From musgravepj@gmail.com Thu Jul 14 10:52:14 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D84F11E80B2 for ; Thu, 14 Jul 2011 10:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gt4xIDvFOmrw for ; Thu, 14 Jul 2011 10:52:13 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9A511E80B8 for ; Thu, 14 Jul 2011 10:52:08 -0700 (PDT) Received: by fxe4 with SMTP id 4so1644521fxe.27 for ; Thu, 14 Jul 2011 10:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+3PEXjN13hCDuOGY2yr0vMvtuaEhWauTTNSgkub00Pk=; b=PKg0CxV15igxgkxMPYr5NOYVJbRk3UAdvqBn1M9/BNoW0mtkekhNW0PmJEprZ16wZ2 CI3otPC9BrXnmC8sLnlP/jKwJG2KklAj+TMWBY5Sr7S2xqdw0RjIsBJ+DAGp4qQsmDz3 9IETj1eNQpM7lWVz/0djCuRNq9xvk9xcK0m+A= MIME-Version: 1.0 Received: by 10.223.144.140 with SMTP id z12mr3871724fau.147.1310665928118; Thu, 14 Jul 2011 10:52:08 -0700 (PDT) Received: by 10.223.103.71 with HTTP; Thu, 14 Jul 2011 10:52:07 -0700 (PDT) In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CF6DED91@DC-US1MBEX4.global.avaya.com> References: <4CA2C4386DB56F4589D436E1C3C86F752230509C3B@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CF6DED91@DC-US1MBEX4.global.avaya.com> Date: Thu, 14 Jul 2011 13:52:07 -0400 Message-ID: From: Peter Musgrave To: "Shekh-Yusef, Rifaat (Rifaat)" Content-Type: multipart/alternative; boundary=0023545bddec10926904a80b31a4 Cc: "splices@ietf.org" Subject: Re: [splices] INVOKE Actions Scope X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 17:52:14 -0000 --0023545bddec10926904a80b31a4 Content-Type: text/plain; charset=ISO-8859-1 Hi Rifaat, This is a good start. I think there is an implicit set of assumptions about some of these. In (4) there are conditions applied to what the UA does based on it's dialog state - but this will need to be generalized to all states. e.g. action Initiate sent to a UA which has decided on it's own to start a call (or has received a call) does what? (Or, the flip - "only applies if UA is IDLE, otherwise rejected") etc. Also in the case of initiate a more general offer may be needed (i.e. 2nd video line for presentation, multiple video lines for continuous presence mult-streams etc. etc. ) Peter On Wed, Jul 13, 2011 at 11:12 AM, Shekh-Yusef, Rifaat (Rifaat) < rifatyu@avaya.com> wrote: > Hi, > > The following is the authors attempt to clearly define the scope of the > INVOKE actions. > We would appreciate any comments. > > Regards, > Rifaat > > > An action can manipulate the state of an INVITE-based dialog. The following > are the only allowed actions: > > 1) Initiate: > This action instructs the UA to send an INVITE with specific > characteristics to a specific target. > i. Target: > ii. Media: audio, video, or both > iii. Direction: recvonly, sendonly, sendrecv > > 2) Answer: > This action instructs the UA to answer a call by sending a 200 OK with > specific characteristics > i. Media: audio, video, or both > ii. Direction: recvonly, sendonly, sendrecv > > 3) Join: > This action instructs the UA to join an existing dialog by sending an > INVITE with Join header and with specific characteristics > i. Media: audio, video, or both > ii. Direction: recvonly, sendonly, sendrecv > > 4) Terminate: > This action instructs the UA to terminate a dialog of an outgoing call. > If the dialog is in an early state, then the UA must send a CANCEL > request. > If the dialog is in an active state, then the UA must send a BYE > request. > > 5) Decline: > This action instructs the UA to decline an incoming call by sending a > 603 response > > 6) Send to VM: > This action instructs the UA to stop ringing and send the incoming call > to the VM system by sending a 302 response. > > 7) Hold/Unhold: > This action instructs the UA to hold/unhold a call by sending a > re-INVITE with the characteristics of the new state of the session. > The action allows for hold/unhold of audio, video, or both. > > 8) Conference: Add/Remove > This action instructs the UA to create a local conference and add or > remove parties as needed. > To add a party, the UA sends a REFER request to that party with the > local focus. The UA can remove a party by sending a BYE request to that > party. > > > > > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: Wednesday, June 22, 2011 1:11 PM > > To: splices@ietf.org > > Cc: Shekh-Yusef, Rifaat (Rifaat) > > Subject: Re: [splices] INVOKE Actions Scope > > > > > > There are a few features that most PBX can do today there is no > standardized > > way to use SIP to signal the changes to sip dialog state needed to > implement > > these features. I think we should pick an initial small set of features > that > > are often used and supported and do theses - that was what I hoped this > draft > > did. It proposes a few things, probably some need to be specified in more > > detail, perhaps there are a few more that people think should be added, > > perhaps a few proposed should be removed. > > > > So my proposal for scope is just the scope we have in this draft which I > would > > argue is a subset of the "An Action can manipulate a dialog or a > multimedia > > session." I view all the action here as changing the SIP dialog state and > what > > changes happen to the multimedia session being a side effect of that. > > > > On Jun 18, 2011, at 6:37 , Shekh-Yusef, Rifaat (Rifaat) wrote: > > > > > Hi, > > > > > > I would like to start a discussion that I hope would allow us to > converge on > > an approriate scope for the first release of this draft. > > > The following is my first attempt at defining this scope: > > > > > > 1. An Action can manipulate a dialog or a multimedia session. > > > 2. An Action can manipulate one or more dialogs or sessions at the same > > time. > > > 3. An Action can manipulate the state of a physical "feature" of a > device, > > e.g. transducer. > > > 4. An Action can invoke a well-defined telephony "feature" on the UA, > > e.g.hold. > > > 5. An Action cannot replace an existing SIP mechanism, e.g. > offer/answer. > > > 6. An Action cannot dictate the UI behavior of the target UA. > > > > > > Any thoughts? > > > > > > Thanks, > > > Rifaat > > > _______________________________________________ > > > splices mailing list > > > splices@ietf.org > > > https://www.ietf.org/mailman/listinfo/splices > > > > > > Cullen Jennings > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices > --0023545bddec10926904a80b31a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Rifaat,=A0

This is a good start. I think there is an = implicit set of=A0assumptions=A0about some of these. In (4) there are condi= tions applied to what the UA does based on it's dialog state - but this= will need to be generalized to all states.=A0

e.g. action Initiate sent to a UA which has decided on = it's own to start a call (or has received a call) does what? (Or, the f= lip - "only applies if UA is IDLE, otherwise rejected") etc.=A0

Also in the case of initiate a more general offer may b= e needed (i.e. 2nd video line for presentation, multiple video lines for=A0= continuous=A0presence mult-streams etc. etc. )=A0

= Peter

On Wed, Jul 13, 2011 at 11:12 AM, Shekh-Yuse= f, Rifaat (Rifaat) <rifatyu@avaya.com> wrote:
Hi,

The following is the authors attempt to clearly define the scope of the INV= OKE actions.
We would appreciate any comments.

Regards,
=A0Rifaat


An action can manipulate the state of an INVITE-based dialog. The following= are the only allowed actions:

=A01) Initiate:
=A0 =A0 This action instructs the UA to send an INVITE with specific chara= cteristics to a specific target.
=A0 =A0 i. =A0 Target: <AOR>
=A0 =A0 ii. =A0Media: audio, video, or both
=A0 =A0 iii. Direction: recvonly, sendonly, sendrecv

=A02) Answer:
=A0 =A0 This action instructs the UA to answer a call by sending a 200 OK = with specific characteristics
=A0 =A0 i. =A0Media: audio, video, or both
=A0 =A0 ii. Direction: recvonly, sendonly, sendrecv

=A03) Join:
=A0 =A0 This action instructs the UA to join an existing dialog by sending= an INVITE with Join header and with specific characteristics
=A0 =A0 i. =A0Media: audio, video, or both
=A0 =A0 ii. Direction: recvonly, sendonly, sendrecv

=A04) Terminate:
=A0 =A0 This action instructs the UA to terminate a dialog of an outgoing = call.
=A0 =A0 If the dialog is in an early state, then the UA must send a CANCEL= request.
=A0 =A0 If the dialog is in an active state, then the UA must send a BYE r= equest.

=A05) Decline:
=A0 =A0 This action instructs the UA to decline an incoming call by sendin= g a 603 response

=A06) Send to VM:
=A0 =A0 This action instructs the UA to stop ringing and send the incoming= call to the VM system by sending a 302 response.

=A07) Hold/Unhold:
=A0 =A0 This action instructs the UA to hold/unhold a call by sending a re= -INVITE with the characteristics of the new state of the session.
=A0 =A0 The action allows for hold/unhold of audio, video, or both.

=A08) Conference: Add/Remove
=A0 =A0 This action instructs the UA to create a local conference and add = or remove parties as needed.
=A0 =A0 To add a party, the UA sends a REFER request to that party with th= e local focus. The UA can remove a party by sending a BYE request to that p= arty.




> -----Original Message-----
> From: Cullen Jennings [mailto:fluf= fy@cisco.com]
> Sent: Wednesday, June 22, 2011 1:11 PM
> To: splices@ietf.org
> Cc: Shekh-Yusef, Rifaat (Rifaat)
> Subject: Re: [splices] INVOKE Actions Scope
>
>
> There are a few features that most PBX can do today there is no standa= rdized
> way to use SIP to signal the changes to sip dialog state needed to imp= lement
> these features. =A0I think we should pick an initial small set of feat= ures that
> are often used and supported and do theses - that was what I hoped thi= s draft
> did. It proposes a few things, probably some need to be specified in m= ore
> detail, perhaps there are a few more that people think should be added= ,
> perhaps a few proposed should be removed.
>
> So my proposal for scope is just the scope we have in this draft which= I would
> argue is a subset of the "An Action can manipulate a dialog or a = multimedia
> session." I view all the action here as changing the SIP dialog s= tate and what
> changes happen to the multimedia session being a side effect of that.<= br> >
> On Jun 18, 2011, at 6:37 , Shekh-Yusef, Rifaat (Rifaat) wrote:
>
> > Hi,
> >
> > I would like to start a discussion that I hope would allow us to = converge on
> an approriate scope for the first release of this draft.
> > The following is my first attempt at defining this scope:
> >
> > 1. An Action can manipulate a dialog or a multimedia session.
> > 2. An Action can manipulate one or more dialogs or sessions at th= e same
> time.
> > 3. An Action can manipulate the state of a physical "feature= " of a device,
> e.g. transducer.
> > 4. An Action can invoke a well-defined telephony "feature&qu= ot; on the UA,
> e.g.hold.
> > 5. An Action cannot replace an existing SIP mechanism, e.g. offer= /answer.
> > 6. An Action cannot dictate the UI behavior of the target UA.
> >
> > Any thoughts?
> >
> > Thanks,
> > Rifaat
> > _______________________________________________
> > splices mailing list
> > splices@ietf.org
> > https://www.ietf.org/mailman/listinfo/splices
>
>
> Cullen Jennings
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/le= gal/cri/index.html
>

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

--0023545bddec10926904a80b31a4-- From dworley@avaya.com Fri Jul 15 10:03:20 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A99B21F887C for ; Fri, 15 Jul 2011 10:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.293 X-Spam-Level: X-Spam-Status: No, score=-103.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gVLpxpa8Af2 for ; Fri, 15 Jul 2011 10:03:19 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id B07CD21F8868 for ; Fri, 15 Jul 2011 10:03:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALFxIE7GmAcF/2dsb2JhbABUp2d3iHqmRwKbVIVbXwSYBItR X-IronPort-AV: E=Sophos;i="4.67,209,1309752000"; d="scan'208";a="290972313" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 Jul 2011 13:03:18 -0400 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 15 Jul 2011 13:01:35 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 15 Jul 2011 13:03:18 -0400 From: "Worley, Dale R (Dale)" To: "Shekh-Yusef, Rifaat (Rifaat)" , Cullen Jennings , "splices@ietf.org" Date: Fri, 15 Jul 2011 13:03:16 -0400 Thread-Topic: [splices] INVOKE Actions Scope Thread-Index: Acww/2lIInU16D1MQoqzcynyzVKFbgQbxviAAGhnjjc= Message-ID: References: <4CA2C4386DB56F4589D436E1C3C86F752230509C3B@DC-US1MBEX4.global.avaya.com> , <6369CB70BFD88942B9705AC1E639A33822CF6DED91@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CF6DED91@DC-US1MBEX4.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [splices] INVOKE Actions Scope X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 17:03:20 -0000 > From: Shekh-Yusef, Rifaat (Rifaat) [rifatyu@avaya.com] >=20 > An action can manipulate the state of an INVITE-based dialog. The > following are the only allowed actions: >=20 > 1) Initiate: > This action instructs the UA to send an INVITE with specific > characteristics to a specific target. > i. Target: > ii. Media: audio, video, or both > iii. Direction: recvonly, sendonly, sendrecv There are probably two flavors of Initiate: One where the INVOKE specifies a dial string and one where it specifies a URI. > 3) Join: > This action instructs the UA to join an existing dialog by > sending an INVITE with Join header and with specific > characteristics > i. Media: audio, video, or both > ii. Direction: recvonly, sendonly, sendrecv I don't think this is a separate operation. If the intention is to join *at a remote UA*, then this is just an Initiate where the request-URI is "sip:foo@bar?Join=3Dxyz". If the intention is to initiate a new dialog, but have it joined *at this UA* with an existing dialog, it is a form of the Conference operation. > 5) Decline: > This action instructs the UA to decline an incoming call by > sending a 603 response Please use a 4xx response! See http://tools.ietf.org/id/draft-worley-6xx-considered-harmful-00.txt > 6) Send to VM: > This action instructs the UA to stop ringing and send the > incoming call to the VM system by sending a 302 response. This assumes that the phone knows the proper VM URI. It also assumes the user is configured so that the next destination of the call is a voicemail system. Aren't "Decline" and "Send to VM" related to the ACH proposals? Dale From rifatyu@avaya.com Sun Jul 17 10:44:28 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7304D21F85E1 for ; Sun, 17 Jul 2011 10:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.321 X-Spam-Level: X-Spam-Status: No, score=-3.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbEsq8w3XZiM for ; Sun, 17 Jul 2011 10:44:27 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFBD21F85B5 for ; Sun, 17 Jul 2011 10:44:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikBAD8fI07GmAcF/2dsb2JhbABSmC6DWYtrd4h8pn4Cmj+FXV8EhyWQX4RChxE X-IronPort-AV: E=Sophos;i="4.67,218,1309752000"; d="scan'208";a="291213196" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Jul 2011 13:44:24 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 Jul 2011 13:42:34 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Sun, 17 Jul 2011 13:44:23 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Peter Musgrave Date: Sun, 17 Jul 2011 13:44:21 -0400 Thread-Topic: [splices] INVOKE Actions Scope Thread-Index: AcxCTsIZNX7Z9Z1aQ4OkJd/Vfv87sQCWPe/g Message-ID: <6369CB70BFD88942B9705AC1E639A33822CF878BA3@DC-US1MBEX4.global.avaya.com> References: <4CA2C4386DB56F4589D436E1C3C86F752230509C3B@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CF6DED91@DC-US1MBEX4.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "splices@ietf.org" Subject: Re: [splices] INVOKE Actions Scope X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 17:44:28 -0000 > -----Original Message----- > From: Peter Musgrave [mailto:musgravepj@gmail.com] > Sent: Thursday, July 14, 2011 1:52 PM > To: Shekh-Yusef, Rifaat (Rifaat) > Cc: Cullen Jennings; splices@ietf.org > Subject: Re: [splices] INVOKE Actions Scope >=20 > Hi Rifaat, >=20 > This is a good start. I think there is an implicit set of=A0assumptions= =A0about > some of these. In (4) there are conditions applied to what the UA does ba= sed > on it's dialog state - but this will need to be generalized to all states= . >=20 > e.g. action Initiate sent to a UA which has decided on it's own to start = a > call (or has received a call) does what? (Or, the flip - "only applies if= UA > is IDLE, otherwise rejected") etc. >=20 I would think that this would be a local policy and has nothing to do with = the fact that the action was invoked locally or remotely. For example, one device might force the user to first handle the incoming c= all before initiating an outgoing call, while another device might allow th= e user to ignore the incoming call and initiate an outgoing. > Also in the case of initiate a more general offer may be needed (i.e. 2nd > video line for presentation, multiple video lines for=A0continuous=A0pres= ence > mult-streams etc. etc. ) >=20 Good point. > Peter > On Wed, Jul 13, 2011 at 11:12 AM, Shekh-Yusef, Rifaat (Rifaat) > wrote: > Hi, >=20 > The following is the authors attempt to clearly define the scope of the I= NVOKE > actions. > We would appreciate any comments. >=20 > Regards, > =A0Rifaat >=20 >=20 > An action can manipulate the state of an INVITE-based dialog. The followi= ng > are the only allowed actions: >=20 > =A01) Initiate: > =A0 =A0 This action instructs the UA to send an INVITE with specific > characteristics to a specific target. > =A0 =A0 i. =A0 Target: > =A0 =A0 ii. =A0Media: audio, video, or both > =A0 =A0 iii. Direction: recvonly, sendonly, sendrecv >=20 > =A02) Answer: > =A0 =A0 This action instructs the UA to answer a call by sending a 200 OK= with > specific characteristics > =A0 =A0 i. =A0Media: audio, video, or both > =A0 =A0 ii. Direction: recvonly, sendonly, sendrecv >=20 > =A03) Join: > =A0 =A0 This action instructs the UA to join an existing dialog by sendin= g an > INVITE with Join header and with specific characteristics > =A0 =A0 i. =A0Media: audio, video, or both > =A0 =A0 ii. Direction: recvonly, sendonly, sendrecv >=20 > =A04) Terminate: > =A0 =A0 This action instructs the UA to terminate a dialog of an outgoing= call. > =A0 =A0 If the dialog is in an early state, then the UA must send a CANCE= L > request. > =A0 =A0 If the dialog is in an active state, then the UA must send a BYE = request. >=20 > =A05) Decline: > =A0 =A0 This action instructs the UA to decline an incoming call by sendi= ng a 603 > response >=20 > =A06) Send to VM: > =A0 =A0 This action instructs the UA to stop ringing and send the incomin= g call to > the VM system by sending a 302 response. >=20 > =A07) Hold/Unhold: > =A0 =A0 This action instructs the UA to hold/unhold a call by sending a r= e-INVITE > with the characteristics of the new state of the session. > =A0 =A0 The action allows for hold/unhold of audio, video, or both. >=20 > =A08) Conference: Add/Remove > =A0 =A0 This action instructs the UA to create a local conference and add= or > remove parties as needed. > =A0 =A0 To add a party, the UA sends a REFER request to that party with t= he local > focus. The UA can remove a party by sending a BYE request to that party. >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: Wednesday, June 22, 2011 1:11 PM > > To: splices@ietf.org > > Cc: Shekh-Yusef, Rifaat (Rifaat) > > Subject: Re: [splices] INVOKE Actions Scope > > > > > > There are a few features that most PBX can do today there is no standar= dized > > way to use SIP to signal the changes to sip dialog state needed to impl= ement > > these features. =A0I think we should pick an initial small set of featu= res > that > > are often used and supported and do theses - that was what I hoped this > draft > > did. It proposes a few things, probably some need to be specified in mo= re > > detail, perhaps there are a few more that people think should be added, > > perhaps a few proposed should be removed. > > > > So my proposal for scope is just the scope we have in this draft which = I > would > > argue is a subset of the "An Action can manipulate a dialog or a multim= edia > > session." I view all the action here as changing the SIP dialog state a= nd > what > > changes happen to the multimedia session being a side effect of that. > > > > On Jun 18, 2011, at 6:37 , Shekh-Yusef, Rifaat (Rifaat) wrote: > > > > > Hi, > > > > > > I would like to start a discussion that I hope would allow us to conv= erge > on > > an approriate scope for the first release of this draft. > > > The following is my first attempt at defining this scope: > > > > > > 1. An Action can manipulate a dialog or a multimedia session. > > > 2. An Action can manipulate one or more dialogs or sessions at the sa= me > > time. > > > 3. An Action can manipulate the state of a physical "feature" of a de= vice, > > e.g. transducer. > > > 4. An Action can invoke a well-defined telephony "feature" on the UA, > > e.g.hold. > > > 5. An Action cannot replace an existing SIP mechanism, e.g. offer/ans= wer. > > > 6. An Action cannot dictate the UI behavior of the target UA. > > > > > > Any thoughts? > > > > > > Thanks, > > > Rifaat > > > _______________________________________________ > > > splices mailing list > > > splices@ietf.org > > > https://www.ietf.org/mailman/listinfo/splices > > > > > > Cullen Jennings > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > >=20 > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices From rifatyu@avaya.com Sun Jul 17 11:14:31 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F411F21F85E2 for ; Sun, 17 Jul 2011 11:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.377 X-Spam-Level: X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eW3AlAC09Cnw for ; Sun, 17 Jul 2011 11:14:30 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1AD21F85E0 for ; Sun, 17 Jul 2011 11:14:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAAEUmI07GmAcF/2dsb2JhbABSmC6PRHeIfKZ4AppBhV1fBJgEi1M X-IronPort-AV: E=Sophos;i="4.67,218,1309752000"; d="scan'208";a="291214923" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Jul 2011 14:14:29 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 Jul 2011 14:12:39 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Sun, 17 Jul 2011 14:14:28 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: "Worley, Dale R (Dale)" , Cullen Jennings , "splices@ietf.org" Date: Sun, 17 Jul 2011 14:14:27 -0400 Thread-Topic: [splices] INVOKE Actions Scope Thread-Index: Acww/2lIInU16D1MQoqzcynyzVKFbgQbxviAAGhnjjcAZ0TGcA== Message-ID: <6369CB70BFD88942B9705AC1E639A33822CF878BAB@DC-US1MBEX4.global.avaya.com> References: <4CA2C4386DB56F4589D436E1C3C86F752230509C3B@DC-US1MBEX4.global.avaya.com> , <6369CB70BFD88942B9705AC1E639A33822CF6DED91@DC-US1MBEX4.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [splices] INVOKE Actions Scope X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 18:14:31 -0000 > -----Original Message----- > From: Worley, Dale R (Dale) > Sent: Friday, July 15, 2011 1:03 PM > To: Shekh-Yusef, Rifaat (Rifaat); Cullen Jennings; splices@ietf.org > Subject: RE: [splices] INVOKE Actions Scope >=20 > > From: Shekh-Yusef, Rifaat (Rifaat) [rifatyu@avaya.com] > > > > An action can manipulate the state of an INVITE-based dialog. The=20 > > following are the only allowed actions: > > > > 1) Initiate: > > This action instructs the UA to send an INVITE with specific > > characteristics to a specific target. > > i. Target: > > ii. Media: audio, video, or both > > iii. Direction: recvonly, sendonly, sendrecv >=20 > There are probably two flavors of Initiate: One where the INVOKE=20 > specifies a dial string and one where it specifies a URI. >=20 > > 3) Join: > > This action instructs the UA to join an existing dialog by > > sending an INVITE with Join header and with specific > > characteristics > > i. Media: audio, video, or both > > ii. Direction: recvonly, sendonly, sendrecv >=20 > I don't think this is a separate operation. > If the intention is to join *at a remote UA*, then this is just an=20 > Initiate where the request-URI is "sip:foo@bar?Join=3Dxyz". > If the intention is to initiate a new dialog, but have it joined *at=20 > this UA* with an existing dialog, it is a form of the Conference=20 > operation. >=20 What I had in mind for join is described in the following example: http://www.ietf.org/mail-archive/web/splices/current/msg00049.html > > 5) Decline: > > This action instructs the UA to decline an incoming call by > > sending a 603 response >=20 > Please use a 4xx response! >=20 > See=20 > http://tools.ietf.org/id/draft-worley-6xx-considered-harmful-00.txt >=20 "A response of this type [6xx] not only rejects the call but also requires the termination of all attempts to route the call to alternative destinations " If a telemarketer is calling me and I want to decline his call, then this i= s exactly what I want. Why do you think that this is a bad thing to do? > > 6) Send to VM: > > This action instructs the UA to stop ringing and send the > > incoming call to the VM system by sending a 302 response. >=20 > This assumes that the phone knows the proper VM URI. It also assumes=20 > the user is configured so that the next destination of the call is a=20 > voicemail system. >=20 Yeah, I need to add some parameters here. > Aren't "Decline" and "Send to VM" related to the ACH proposals? >=20 ACH is to affect the proxy handling of these features, while this is for ha= ndling of these features on the phone. Does this answer your comment? > Dale From dworley@avaya.com Sun Jul 17 18:17:13 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A0D21F8804 for ; Sun, 17 Jul 2011 18:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.342 X-Spam-Level: X-Spam-Status: No, score=-103.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEUgotTVtO-Y for ; Sun, 17 Jul 2011 18:17:12 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 71FE821F87FA for ; Sun, 17 Jul 2011 18:17:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADeII06HCzI1/2dsb2JhbABSp3J3sDkCmjKFXV8EmASLUw X-IronPort-AV: E=Sophos;i="4.67,219,1309752000"; d="scan'208";a="291240787" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Jul 2011 21:17:11 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 17 Jul 2011 21:10:00 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Sun, 17 Jul 2011 21:17:11 -0400 From: "Worley, Dale R (Dale)" To: "Shekh-Yusef, Rifaat (Rifaat)" , Cullen Jennings , "splices@ietf.org" Date: Sun, 17 Jul 2011 21:12:40 -0400 Thread-Topic: [splices] INVOKE Actions Scope Thread-Index: Acww/2lIInU16D1MQoqzcynyzVKFbgQbxviAAGhnjjcAZ0TGcAAOpRfs Message-ID: References: <4CA2C4386DB56F4589D436E1C3C86F752230509C3B@DC-US1MBEX4.global.avaya.com> , <6369CB70BFD88942B9705AC1E639A33822CF6DED91@DC-US1MBEX4.global.avaya.com> , <6369CB70BFD88942B9705AC1E639A33822CF878BAB@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CF878BAB@DC-US1MBEX4.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [splices] INVOKE Actions Scope X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 01:17:13 -0000 ________________________________________ From: Shekh-Yusef, Rifaat (Rifaat) "A response of this type [6xx] not only rejects the call but also requires the termination of all attempts to route the call to alternative destinations " If a telemarketer is calling me and I want to decline his call, then this i= s exactly what I want. Why do you think that this is a bad thing to do? ________________________________________ If a telemarketer is calling, what you *really* want is response "1313 Make= Caller's Head Explode". But in the case where what you want to communicate is that *you* don't want to handle the call. As there may be forks upstream of your UA and your PBX= , all you can know is that there are no destinations *within your PBX* that s= hould not take the call. It is impossible for you to know that there are *no* approp= riate destinations anywhere upstream, as you don't know what all the upstream forks are (absen= t History-Info). In practice, the situation is even worse, as many phones have a "Decline Ca= ll" button that sends a 603 response. But if voicemail is implemented by the sensible means of h= aving the VM system be a lower-priority fork, the 603 prevents the call from going to voicemail= . Dale From dworley@avaya.com Sun Jul 17 18:18:32 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC6721F880C for ; Sun, 17 Jul 2011 18:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.35 X-Spam-Level: X-Spam-Status: No, score=-103.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHlqBNt2O4oL for ; Sun, 17 Jul 2011 18:18:31 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4DC21F87FA for ; Sun, 17 Jul 2011 18:18:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACyJI07GmAcF/2dsb2JhbABSp3J3sC4CmjKFXV8EmASLUw X-IronPort-AV: E=Sophos;i="4.67,219,1309752000"; d="scan'208";a="257070418" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 17 Jul 2011 21:18:08 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 Jul 2011 21:16:17 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Sun, 17 Jul 2011 21:18:08 -0400 From: "Worley, Dale R (Dale)" To: "Shekh-Yusef, Rifaat (Rifaat)" , "splices@ietf.org" Date: Sun, 17 Jul 2011 21:17:16 -0400 Thread-Topic: [splices] INVOKE Actions Scope Thread-Index: Acww/2lIInU16D1MQoqzcynyzVKFbgQbxviAAGhnjjcAZ0TGcAAOzjPh Message-ID: References: <4CA2C4386DB56F4589D436E1C3C86F752230509C3B@DC-US1MBEX4.global.avaya.com> , <6369CB70BFD88942B9705AC1E639A33822CF6DED91@DC-US1MBEX4.global.avaya.com> , <6369CB70BFD88942B9705AC1E639A33822CF878BAB@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CF878BAB@DC-US1MBEX4.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [splices] INVOKE Actions Scope X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 01:18:32 -0000 ________________________________________ From: Shekh-Yusef, Rifaat (Rifaat) What I had in mind for join is described in the following example: http://www.ietf.org/mail-archive/web/splices/current/msg00049.html ________________________________________ That makes sense, but I suggest you give it a different name than just "join" to avoid confusion. Dale From rifatyu@avaya.com Thu Jul 21 04:53:33 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D0221F891D for ; Thu, 21 Jul 2011 04:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.413 X-Spam-Level: X-Spam-Status: No, score=-3.413 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQ1v+LitOMe9 for ; Thu, 21 Jul 2011 04:53:32 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 1132721F87A4 for ; Thu, 21 Jul 2011 04:53:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwHAM0RKE7GmAcF/2dsb2JhbABUglOlF3AHpTODdwKbToVfXwSHJpBti1Q X-IronPort-AV: E=Sophos;i="4.67,240,1309752000"; d="scan'208,217";a="257823768" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 21 Jul 2011 07:53:28 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Jul 2011 07:51:24 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 21 Jul 2011 07:53:26 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: "splices@ietf.org" Date: Thu, 21 Jul 2011 07:53:27 -0400 Thread-Topic: [splices] SIP INVOKE Method - The Model Thread-Index: AQHMR5zMV8XdbHIJK0ubqLU/U/pXlQ== Message-ID: <6369CB70BFD88942B9705AC1E639A33822CE7CF856@DC-US1MBEX4.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6369CB70BFD88942B9705AC1E639A33822CE7CF856DCUS1MBEX4glo_" MIME-Version: 1.0 Subject: [splices] SIP INVOKE Method - The Model X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 11:53:33 -0000 --_000_6369CB70BFD88942B9705AC1E639A33822CE7CF856DCUS1MBEX4glo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The following is the model definition for the SIP INVOKE method: The SIP INVOKE method is modeled as a Call Control method that allows one U= A to manipulate the state of an INVITE-based dialog on a remote UA. The following diagram captures the INVITE-based dialog FSM and how the INVO= KE actions fit into that FSM. The left part of the diagram covers the UAC a= ctions, while the right part covers the UAS actions. The actions that applicable to both are in the middle. e.g. Hold/Unhold. UAC Actions : UAS Actions ----------- : ----------- : : : +-----------+ | | | IDLE | | | +-----------+ | INVITE/1xx | (Initiate) | | | V +-----------+ | | +---------| EARLY |---------+ | | | | CANCEL | +-----------+ | 302 (Terminate) | | | (Send to VM) | | OK/ACK | | | (Answer) | 603 [441?] | | | (Decline) | | | | V | | +-----------+ | | | | | | | ACTIVE | | | | | | | +-----------+ | | ^ | | | | | | | | | Re-INVITE/OK | | (Hold/Unhold) | | | | | | | +---|---+ | | | | | | | | BYE/OK | | (Terminate) | | | | | | | | V | | +-----------+ | | | | | +-------->|TERMINATED |<--------+ | | +-----------+ : : : : : We would appreciate any comments. Thanks, Rifaat --_000_6369CB70BFD88942B9705AC1E639A33822CE7CF856DCUS1MBEX4glo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

<= span style=3D"FONT-FAMILY: 'Times New Roman','serif'">Hi,

<= span style=3D"FONT-FAMILY: 'Times New Roman','serif'"> 

<= span style=3D"FONT-FAMILY: 'Times New Roman','serif'">The = following is the model definition for the SIP INVOKE method:

<= span style=3D"FONT-FAMILY: 'Times New Roman','serif'"> 

The SIP INVOKE method is modeled as a Call Control method that allows one UA to manipulate the s= tate of an INVITE-based dialog on a remote UA.

<= span style=3D"FONT-FAMILY: 'Times New Roman','serif'"> 

<= span style=3D"FONT-FAMILY: 'Times New Roman','serif'">The = following diagram captures the INVITE-based dialog FSM and how the INVOKE a= ctions fit into that FSM. The left part of the diagram covers the UAC actions, while the right part covers the UAS= actions.

<= span style=3D"FONT-FAMILY: 'Times New Roman','serif'">The = actions that applicable to both are in the middle. e.g. Hold/Unhold.=

<= span style=3D"FONT-FAMILY: 'Times New Roman','serif'"> 

<= font size=3D"3" face=3D"Calibri"> 

 

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =          UAC Actions    :   = UAS Actions

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =          -----------    :   = -----------

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =             &nb= sp;           :      

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =             &nb= sp;           :      

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =             &nb= sp;           :       

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =             &nb= sp;     +-----------+

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =             &nb= sp;     |           = |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;                  &n= bsp;           |   IDLE    |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =             &nb= sp;     |           = |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =             &nb= sp;     +-----------+

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =             &nb= sp;           |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =              INVITE/1xx |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =              (Initiate) |

<= span style=3D"FONT-FAMILY: Consolas">             &n= bsp;            = ;            &n= bsp;|

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =             &nb= sp;           |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =             &nb= sp;           V

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =             &nb= sp;     +-----------+

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =             &nb= sp;     |           = |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =         +---------|   EARLY   |---------+

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =         |         |           |         |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;        CANCEL      |  = ;       +-----------+&nb= sp;        | 302

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;        (Terminate) |        &= nbsp;      |    &= nbsp;          | (Send = to VM)

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;                 &n= bsp;  |       &nb= sp;       | OK/ACK  &n= bsp;     |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =         |          &= nbsp;    | (Answer)    &nbs= p; | 603 [441?]

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =         |          &= nbsp;    |      &= nbsp;        | (Decline)

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =         |          &= nbsp;    |      &= nbsp;        |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;                &n= bsp;   |      &nb= sp;        V  &nb= sp;            |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =         |         += -----------+         |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =         |         |           |         |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =         |         |  ACTIVE   |   &n= bsp;     |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =         |         |           = ;|         |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =         |         += -----------+         |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =         |           = ^   |   | &= nbsp;         |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =         |           = |   |   | &= nbsp;         |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =         |          Re-INVITE/OK         = |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;             &n= bsp;      |   &nb= sp;      (Hold/Unhold)  &nb= sp;     |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =         |           = |   |   | &= nbsp;         |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =         |           = +---|---+       &nb= sp;   |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =         |          &= nbsp;    |      &= nbsp;        |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =         |         = ;      |    =            |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =         |          &= nbsp;  BYE/OK       &n= bsp;    |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =         |          (Terminate)          |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =         |          &= nbsp;    |      &= nbsp;        |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =         |          &= nbsp;    |      &= nbsp;        |

<= span style=3D"FONT-FAMILY: Consolas">             = ;          |          &= nbsp;    V      &= nbsp;        |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =         |         += -----------+         |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =         |         |           |         |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =         +-------->|TERMINATED |<--------+

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =             &nb= sp;     |           = |

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =             &nb= sp;     +-----------+

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =             &nb= sp;           :      

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =             &nb= sp;           :      

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =             &nb= sp;           :      

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =              &n= bsp;          :      

<= span style=3D"FONT-FAMILY: Consolas">  &nb= sp;            =             &nb= sp;           :       

<= span style=3D"FONT-FAMILY: Consolas"> 

<= span style=3D"FONT-FAMILY: Consolas"> 

<= span style=3D"FONT-FAMILY: 'Times New Roman','serif'">We w= ould appreciate any comments.

<= span style=3D"FONT-FAMILY: 'Times New Roman','serif'"> 

<= span style=3D"FONT-FAMILY: 'Times New Roman','serif'">

<= span style=3D"FONT-FAMILY: 'Times New Roman','serif'">Than= ks,

<= font size=3D"3">Rifaat

--_000_6369CB70BFD88942B9705AC1E639A33822CE7CF856DCUS1MBEX4glo_-- From pkyzivat@alum.mit.edu Thu Jul 21 07:19:17 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FED521F87C6 for ; Thu, 21 Jul 2011 07:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SN1aVPqh0ik2 for ; Thu, 21 Jul 2011 07:19:13 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id C716421F87C3 for ; Thu, 21 Jul 2011 07:19:12 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta05.westchester.pa.mail.comcast.net with comcast id AeJQ1h0060QuhwU55eKDNi; Thu, 21 Jul 2011 14:19:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta02.westchester.pa.mail.comcast.net with comcast id AeKB1h0020tdiYw3NeKBXW; Thu, 21 Jul 2011 14:19:12 +0000 Message-ID: <4E28355D.5040205@alum.mit.edu> Date: Thu, 21 Jul 2011 10:19:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: splices@ietf.org References: <6369CB70BFD88942B9705AC1E639A33822CE7CF856@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CE7CF856@DC-US1MBEX4.global.avaya.com> Content-Type: multipart/alternative; boundary="------------000104050504010005040607" Subject: Re: [splices] SIP INVOKE Method - The Model X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 14:19:17 -0000 This is a multi-part message in MIME format. --------------000104050504010005040607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Its not evident to me that this model includes device control such as selecting handset/headset/speakerphone, control of lights/buttons, etc.. Yet that seems to be an important part of what we want this for. The difference is that what you have included is what fits within the existing state model for dialogs, while that other stuff requires a more extensive model of the device. So, if we want this mechanism to be able to select media sources and sinks on the device, then the model needs to encompass media sources and sinks on the device. If we want to control or be conditional on lights/buttons then lights and buttons need to be part of the model, ... Thanks, Paul On 7/21/11 7:53 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > Hi, > > The following is the model definition for the SIP INVOKE method: > > The SIP INVOKE method is modeled as a *Call Control* method that > allows one UA to manipulate the state of an *INVITE-based dialog *on a > remote UA. > > The following diagram captures the INVITE-based dialog FSM and how the > INVOKE actions fit into that FSM. The left part of the diagram covers > the UAC actions, while the right part covers the UAS actions. > > The actions that applicable to both are in the middle. e.g. Hold/Unhold. > > UAC Actions:UAS Actions > > -----------:----------- > > : > > : > > : > > +-----------+ > > || > > |IDLE| > > || > > +-----------+ > > | > > INVITE/1xx | > > (Initiate) | > > | > > | > > V > > +-----------+ > > || > > +---------|EARLY|---------+ > > |||| > > CANCEL|+-----------+| 302 > > (Terminate) ||| (Send to VM) > > || OK/ACK| > > || (Answer)| 603 [441?] > > ||| (Decline) > > ||| > > |V| > > |+-----------+| > > |||| > > ||ACTIVE|| > > |||| > > |+-----------+| > > |^||| > > ||||| > > |Re-INVITE/OK| > > |(Hold/Unhold)| > > ||||| > > |+---|---+| > > ||| > > ||| > > |BYE/OK| > > |(Terminate)| > > ||| > > ||| > > |V| > > |+-----------+| > > |||| > > +-------->|TERMINATED |<--------+ > > || > > +-----------+ > > : > > : > > : > > : > > : > > We would appreciate any comments. > > Thanks, > > Rifaat > > > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices --------------000104050504010005040607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Its not evident to me that this model includes device control such as selecting handset/headset/speakerphone, control of lights/buttons, etc.. Yet that seems to be an important part of what we want this for.

The difference is that what you have included is what fits within the existing state model for dialogs, while that other stuff requires a more extensive model of the device.

So, if we want this mechanism to be able to select media sources and sinks on the device, then the model needs to encompass media sources and sinks on the device. If we want to control or be conditional on lights/buttons then lights and buttons need to be part of the model, ...

    Thanks,
    Paul

On 7/21/11 7:53 AM, Shekh-Yusef, Rifaat (Rifaat) wrote:

Hi,

 

The following is the model definition for the SIP INVOKE method:

 

The SIP INVOKE method is modeled as a Call Control method that allows one UA to manipulate the state of an INVITE-based dialog on a remote UA.

 

The following diagram captures the INVITE-based dialog FSM and how the INVOKE actions fit into that FSM. The left part of the diagram covers the UAC actions, while the right part covers the UAS actions.

The actions that applicable to both are in the middle. e.g. Hold/Unhold.

 

 

 

                        UAC Actions    :    UAS Actions

                        -----------    :    -----------

                                       :      

                                       :      

                                       :       

                                 +-----------+

                                 |           |

                                 |   IDLE    |

                                 |           |

                                 +-----------+

                                       |

                            INVITE/1xx |

                            (Initiate) |

                                       |

                                       |

                                       V

                                 +-----------+

                                 |           |

                       +---------|   EARLY   |---------+

                       |         |           |         |

           CANCEL      |         +-----------+         | 302

           (Terminate) |               |               | (Send to VM)

                       |               | OK/ACK        |

                       |               | (Answer)      | 603 [441?]

                       |               |               | (Decline)

                       |               |               |

                       |               V               |

                       |         +-----------+         |

                       |         |           |         |

                       |         |  ACTIVE   |         |

                       |         |           |         |

                       |         +-----------+         |

                       |           ^   |   |           |

                       |           |   |   |           |

                       |          Re-INVITE/OK         |

                       |          (Hold/Unhold)        |

                       |           |   |   |           |

                       |           +---|---+           |

                       |               |               |

                       |               |               |

                       |             BYE/OK            |

                       |          (Terminate)          |

                       |               |               |

                       |               |               |

                       |               V               |

                       |         +-----------+         |

                       |         |           |         |

                       +-------->|TERMINATED |<--------+

                                 |           |

                                 +-----------+

                                       :      

                                       :      

                                       :      

                                       :      

                                       :       

 

 

We would appreciate any comments.

 

Thanks,

Rifaat



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

--------------000104050504010005040607-- From dworley@avaya.com Mon Jul 25 13:01:58 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A925021F8BAB for ; Mon, 25 Jul 2011 13:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.457 X-Spam-Level: X-Spam-Status: No, score=-103.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AElbpTkTTOtV for ; Mon, 25 Jul 2011 13:01:58 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 26B8521F8B9F for ; Mon, 25 Jul 2011 13:01:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACrLLU6HCzI1/2dsb2JhbAA0AQEBAQMULFYCAQkNNRAUIy4CBQEiG6czd60AAptdhWBfBJgVi1c X-IronPort-AV: E=Sophos;i="4.67,264,1309752000"; d="scan'208";a="292924841" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 25 Jul 2011 16:01:54 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 25 Jul 2011 15:54:26 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Mon, 25 Jul 2011 16:01:53 -0400 From: "Worley, Dale R (Dale)" To: "Shekh-Yusef, Rifaat (Rifaat)" , "splices@ietf.org" Date: Mon, 25 Jul 2011 16:01:06 -0400 Thread-Topic: [splices] SIP INVOKE Method - The Model Thread-Index: AQHMR5zMV8XdbHIJK0ubqLU/U/pXlZT9e/Mf Message-ID: References: <6369CB70BFD88942B9705AC1E639A33822CE7CF856@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CE7CF856@DC-US1MBEX4.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [splices] SIP INVOKE Method - The Model X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 20:01:58 -0000 What do people who work with "call centers" and other CTI applications say = they need as a command set? Dale From gonzalo.camarillo@ericsson.com Mon Jul 25 14:41:20 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8614511E80BA for ; Mon, 25 Jul 2011 14:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.606 X-Spam-Level: X-Spam-Status: No, score=-106.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmLtFpNGJi19 for ; Mon, 25 Jul 2011 14:41:20 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C576921F8BD3 for ; Mon, 25 Jul 2011 14:41:19 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-9f-4e2de2fe4076 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DB.57.20773.EF2ED2E4; Mon, 25 Jul 2011 23:41:19 +0200 (CEST) Received: from [131.160.126.141] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Mon, 25 Jul 2011 23:41:18 +0200 Message-ID: <4E2DE2FC.1050900@ericsson.com> Date: Mon, 25 Jul 2011 17:41:16 -0400 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: splices@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [splices] Fwd: Progressing the INVOKE-related work X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 21:41:20 -0000 FYI. -------- Original Message -------- Subject: Progressing the INVOKE-related work Date: Mon, 25 Jul 2011 17:35:38 -0400 From: Gonzalo Camarillo To: rai@ietf.org Folks, as you know, the following draft has lately been discussed in the SPLICES and RAI area mailing lists: https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/ >From all the discussions, there seems to be interest in working on a call/device control mechanism. In order to do that, we need to clearly define the scope of such an effort (i.e., which types of primitives would be in scope and which ones wouldn't). In addition to defining the scope, there are open issues related to how to model the mechanism (i.e., using SIP directly vs. using SIP to establish a control channel). They will need to be resolved at some point as well. As some people have pointed out, the charter of SPLICES excludes working on such a mechanism. Therefore, the next step is to have DISPATCH work on a charter proposal for this effort. Nevertheless, we want to take advantage of the current momentum behind this effort. So, this topic will be discussed in SPLICES, as planned, during the IETF. Cheers, Gonzalo From spromano@unina.it Mon Jul 25 16:05:25 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C233C11E80E3 for ; Mon, 25 Jul 2011 16:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.719 X-Spam-Level: X-Spam-Status: No, score=-100.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXD-qkt38pUb for ; Mon, 25 Jul 2011 16:05:25 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id C29E911E80D7 for ; Mon, 25 Jul 2011 16:05:24 -0700 (PDT) Received: from [130.129.20.10] (dhcp-140a.meeting.ietf.org [130.129.20.10]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id p6PN5JIZ013432 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 01:05:21 +0200 Message-ID: <4E2DF6AF.80805@unina.it> Date: Tue, 26 Jul 2011 01:05:19 +0200 From: Simon Pietro Romano User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Gonzalo Camarillo References: <4E2DE2FC.1050900@ericsson.com> In-Reply-To: <4E2DE2FC.1050900@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: splices@ietf.org Subject: Re: [splices] Fwd: Progressing the INVOKE-related work X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 23:05:25 -0000 Dear Gonzalo and all, my *individual* opinion is that we might simply re-charter SPLICES in order to allow it to proceed with the (finally) proficuous work we are doing. What's the alternative? We might just close SPLICES as soon as we're done with the framework (aka "use-cases") document and immediately thereafter go to DISPATCH and ask for the creation of SPLICES-2 as the right venue where to carry out the INVOKE-related work. My 2 cents, Simon Il 25/07/2011 23:41, Gonzalo Camarillo ha scritto: > FYI. > > -------- Original Message -------- > Subject: Progressing the INVOKE-related work > Date: Mon, 25 Jul 2011 17:35:38 -0400 > From: Gonzalo Camarillo > To: rai@ietf.org > > Folks, > > as you know, the following draft has lately been discussed in the > SPLICES and RAI area mailing lists: > > https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/ > > > From all the discussions, there seems to be interest in working on a > call/device control mechanism. In order to do that, we need to clearly > define the scope of such an effort (i.e., which types of primitives > would be in scope and which ones wouldn't). > > In addition to defining the scope, there are open issues related to how > to model the mechanism (i.e., using SIP directly vs. using SIP to > establish a control channel). They will need to be resolved at some > point as well. > > As some people have pointed out, the charter of SPLICES excludes working > on such a mechanism. Therefore, the next step is to have DISPATCH work > on a charter proposal for this effort. Nevertheless, we want to take > advantage of the current momentum behind this effort. So, this topic > will be discussed in SPLICES, as planned, during the IETF. > > Cheers, > > Gonzalo > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices > -- _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ From gonzalo.camarillo@ericsson.com Mon Jul 25 18:52:29 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3E811E80DF for ; Mon, 25 Jul 2011 18:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.605 X-Spam-Level: X-Spam-Status: No, score=-106.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vq793TirDQxc for ; Mon, 25 Jul 2011 18:52:28 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 23E5311E807D for ; Mon, 25 Jul 2011 18:52:27 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-41-4e2e1ddbc3c6 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 32.70.20773.BDD1E2E4; Tue, 26 Jul 2011 03:52:27 +0200 (CEST) Received: from [131.160.126.141] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Tue, 26 Jul 2011 03:52:26 +0200 Message-ID: <4E2E1DD9.105@ericsson.com> Date: Mon, 25 Jul 2011 21:52:25 -0400 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Simon Pietro Romano References: <4E2DE2FC.1050900@ericsson.com> <4E2DF6AF.80805@unina.it> In-Reply-To: <4E2DF6AF.80805@unina.it> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "splices@ietf.org" Subject: Re: [splices] Fwd: Progressing the INVOKE-related work X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 01:52:29 -0000 Hi Simon Pietro, yes, that is one of the first options we considered. However, while this work will need to take into consideration all the requirements derived from the SPLICES use cases, its scope seems to be somewhat wider. For example, there have been discussions about PBXs needing an INVOKE-like mechanism but not using disaggregated media. Cheers, Gonzalo On 25/07/2011 7:05 PM, Simon Pietro Romano wrote: > Dear Gonzalo and all, > > my *individual* opinion is that we might simply re-charter SPLICES in > order to allow it to proceed with the (finally) proficuous work we are > doing. What's the alternative? We might just close SPLICES as soon as > we're done with the framework (aka "use-cases") document and > immediately thereafter go to DISPATCH and ask for the creation of > SPLICES-2 as the right venue where to carry out the INVOKE-related work. > > My 2 cents, > > Simon > > Il 25/07/2011 23:41, Gonzalo Camarillo ha scritto: >> FYI. >> >> -------- Original Message -------- >> Subject: Progressing the INVOKE-related work >> Date: Mon, 25 Jul 2011 17:35:38 -0400 >> From: Gonzalo Camarillo >> To: rai@ietf.org >> >> Folks, >> >> as you know, the following draft has lately been discussed in the >> SPLICES and RAI area mailing lists: >> >> https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/ >> >>> From all the discussions, there seems to be interest in working on a >> call/device control mechanism. In order to do that, we need to clearly >> define the scope of such an effort (i.e., which types of primitives >> would be in scope and which ones wouldn't). >> >> In addition to defining the scope, there are open issues related to how >> to model the mechanism (i.e., using SIP directly vs. using SIP to >> establish a control channel). They will need to be resolved at some >> point as well. >> >> As some people have pointed out, the charter of SPLICES excludes working >> on such a mechanism. Therefore, the next step is to have DISPATCH work >> on a charter proposal for this effort. Nevertheless, we want to take >> advantage of the current momentum behind this effort. So, this topic >> will be discussed in SPLICES, as planned, during the IETF. >> >> Cheers, >> >> Gonzalo >> >> _______________________________________________ >> splices mailing list >> splices@ietf.org >> https://www.ietf.org/mailman/listinfo/splices >> > From adam@nostrum.com Tue Jul 26 10:54:11 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8416721F8ACC for ; Tue, 26 Jul 2011 10:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.59 X-Spam-Level: X-Spam-Status: No, score=-101.59 tagged_above=-999 required=5 tests=[AWL=-1.010, BAYES_00=-2.599, LOCALPART_IN_SUBJECT=2.02, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRKCPGJakwbt for ; Tue, 26 Jul 2011 10:54:11 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B847521F8AB8 for ; Tue, 26 Jul 2011 10:54:10 -0700 (PDT) Received: from dhcp-1418.meeting.ietf.org ([130.129.20.24]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p6QHs7J8027280 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 12:54:08 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4E2EFF3F.7020300@nostrum.com> Date: Tue, 26 Jul 2011 13:54:07 -0400 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: draft-yusef-splices-invoke@tools.ietf.org, splices@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 130.129.20.24 is authenticated by a trusted mechanism) Subject: [splices] draft-yusef-splices-invoke: Digest auth? X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 17:54:11 -0000 I'm not commenting on the larger issue of whether INVOKE is an appropriate means to accomplish what it intends in this email, as that's a far broader conversation. However, one thing that jumped out at me in the current version of draft-yusef-splices-invoke is the following normative requirement: In most cases, the same user will be logged in to the different devices using the same credentials provided in the REGISTER requests. In this case, all INVOKE requests MUST be challenged using the digest authentication mechanism described by [RFC3261]. In practice, Digest was barely passable when we specified it in RFC 3261, and we knew it. In the 15 years since we first did that, additional cracks have been made in the façade of MD5 that make Digest an even worse idea. The only real reason it's there is because there wasn't anything better available at the time. In fact, MD5-based Digest is so bad, you have protocols already deprecating it altogether (see RFC 6331, for example). At the same time, we do have additional means of authentication (mTLS, SIP Identity, and SIP Certs with S/MIME come to mind) that can be employed in certain architectures, and with far better security properties than Digest ever did (even back when MD5 was considered a good crypto algorithm). With any luck, one or more of these will become somewhat more widespread in the future. So, if we *are* going to specify something in this area, I think that requiring Digest -- or, really, even suggesting it as a preferred mechanism -- are somewhat misguided. Yes, we need authentication for these types of operations. But Digest isn't a reasonable way to do it. /a From adam@nostrum.com Tue Jul 26 11:26:32 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5591E11E8082 for ; Tue, 26 Jul 2011 11:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.263 X-Spam-Level: X-Spam-Status: No, score=-102.263 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCOrU6BjQmeN for ; Tue, 26 Jul 2011 11:26:31 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 663465E8001 for ; Tue, 26 Jul 2011 11:26:30 -0700 (PDT) Received: from dhcp-1418.meeting.ietf.org ([130.129.20.24]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p6QIQNR9030458 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 13:26:24 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4E2F06CF.4080403@nostrum.com> Date: Tue, 26 Jul 2011 14:26:23 -0400 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: draft-loreto-splices-disaggregated-media@tools.ietf.org, splices@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.20.24 is authenticated by a trusted mechanism) Subject: [splices] draft-loreto-splices-disaggregated-media-02: competing protocol analysis X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 18:26:32 -0000 Section 4.1.4 of draft-loreto-splices-disaggregated-media-02 currently describes a (rather clever) way to move a SIP session from one client in a disaggregated system to another, so as to allow the device that owns the SIP association with the far-end to be removed from the call. I like it. It actually does a good job of showing that the system in question actually isn't an all-entities-are-equal federation of peer devices. In fact, it *does* have a critical central controller of sorts, and we need to be able to take steps to move that critical central controller functionality around. (This is inherent in any system that requires no support from the far end, since someone needs to own the SIP session). However, then we get into section 5. I'm not sure what section 5 is trying to talk about, since it discusses a model that is not relevant to any of the described solutions. Even the INVOKE-based one being proposed by this document. Even more interestingly, I note that the transfer-of-control approach in section 4.1.4 can be applied equally well to any central-control model. MBUS, for example. Or MEGACO. So the statement "transferring the SIP dialog from a controller to a new one using REFER and Replaces is complex and requires support from the far end" isn't really true -- everyone can use the section 4.1.4 INVITE/Replaces approach to move control around. The INVOKE-based approach described in this document is hardly unique in this respect. On top of this, the analysis in section 3.1.1 and 3.2.1 both have the rather gonzo "issue" of "you need to implement the protocol." That's true of *any* solution -- INVOKE included -- so it's hardly a distinguishing factor. If you want to try to quantify the ease of implementation, that might be a useful discussion. But simply saying "you have to implement something" is always, always, always true for a new mechanism. So, once you make a more honest analysis of the other protocols, section 3.1.1 actually ends up looking like this: The Mbus protocol introduces the following issue: Local network: Mbus uses multicast with a limited scope for message transport. The multicast limits the coordination mechanism only to groups of devices that are connected to a local network. So Mbus can be used in a disaggregated media scenario only if all the different devices under the user control, or at least the one the user wants to involve in the communication, are attached to the same local network. And section 3.2.1 looks like this: The Megaco protocol introduces the following issues: None. /a From dworley@avaya.com Tue Jul 26 14:37:02 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F3311E809B for ; Tue, 26 Jul 2011 14:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.46 X-Spam-Level: X-Spam-Status: No, score=-103.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gr8ofypbfmsq for ; Tue, 26 Jul 2011 14:37:01 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 26E7D11E8097 for ; Tue, 26 Jul 2011 14:37:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMHAL4yL07GmAcF/2dsb2JhbAA1AQEBAQIBFCxKDAIBCQ0FAy0QFCMbEwEBBQsMDBQHpypwB4h8phwCm32FYV8EmBeLVw X-IronPort-AV: E=Sophos;i="4.67,271,1309752000"; d="scan'208";a="258842606" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Jul 2011 17:36:59 -0400 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Jul 2011 17:34:37 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Tue, 26 Jul 2011 17:36:58 -0400 From: "Worley, Dale R (Dale)" To: "splices@ietf.org" Date: Tue, 26 Jul 2011 17:36:02 -0400 Thread-Topic: [splices] draft-loreto-splices-disaggregated-media-02: competing protocol analysis Thread-Index: AcxLwZIl6Rr8MlFjSVud73O038up0QAGnK9X Message-ID: References: <4E2F06CF.4080403@nostrum.com> In-Reply-To: <4E2F06CF.4080403@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [splices] draft-loreto-splices-disaggregated-media-02: competing protocol analysis X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 21:37:02 -0000 > From: Adam Roach [adam@nostrum.com] >=20 > Section 4.1.4 of draft-loreto-splices-disaggregated-media-02 currently > describes a (rather clever) way to move a SIP session from one client in > a disaggregated system to another, so as to allow the device that owns > the SIP association with the far-end to be removed from the call. >=20 > I like it. It actually does a good job of showing that the system in > question actually isn't an all-entities-are-equal federation of peer > devices. In fact, it *does* have a critical central controller of sorts, > and we need to be able to take steps to move that critical central > controller functionality around. (This is inherent in any system that > requires no support from the far end, since someone needs to own the SIP > session). And the method generalizes: A new controller can replace an old controller by sending an INVITE-with-Replaces to both the far end of the call and to all the UA participants on controller's end of the call. As section 4.1.4 notes, this can be done even if the old controller has died, as long as the new controller has obtained all the dialog identifiers beforehand. (Although the dialog event package does not have any way of indicating "This dialog is to control an additional UA for dialog XXX." -- We should define appropriate extensions.) We don't have any mechanism for one controller to tell another controller to take over the coordination role. We should define that. Section 3.1.1 says: Central point: Because the Controller has a complete control over the call, it needs to be involved during the whole duration of the session. It cannot leave the session before the whole session ends (unless it transfers the controller role to one of the other user's devices). User experience: 3ppc results in a suboptimal user experience because the slave phones are not aware that they are involved in a disaggregated media call scenario. Indeed, the slave phones behave as they were just involved in a normal call with the Controller. Moreover the slave phones will be alerted without any media having been established yet. SDP manipulation: the Controller cannot "proxy" the SIP messages received from one of the parties. In many cases, it is required to modify the SDP exchanged between the participants in order to affect the changes. "Central point" is clear and accurate. I'm not sure I fully understand "User experience". The secondary UAs don't have to be aware that they're part of an aggregation, yes, but presumably they could be made aware of it if they implemented suitable extensions to INVITE. The complaint about being altered is not clear to me -- of course, to add a UA into a call, it has to be alerted somehow, or the user has to cause it to initiate a call, or some remote-control mechanism has to cause it to initiate a call. This is unavoidable, but also shared by every other SIP-based mechanism. In regard to "SDP manipulation", the controller does have to manipulate SDP. But in any possible mechanism, some device must take the descriptions of the media available from the the UAs and combine them into an understanding of all the available media. (Even in the architecture of section 5, where the far-end UA is controlling the aggregation, the far-end UA must integrate the SDPs provided by the aggregated UAs in order to determine how to connect the avaialble media streams to its rendering facilities.) Once that is done, expressing that understanding in, e.g., an SDP offer, is not particularly difficult. > However, then we get into section 5. I'm not sure what section 5 is > trying to talk about, since it discusses a model that is not relevant to > any of the described solutions. Even the INVOKE-based one being proposed > by this document. I think the key is "Scenarios not covered by existing mechanisms include those where none of the nodes can act as a controller because it does not support the necessary functionality" -- the envisioned architecture of section 5 puts the work of coordination on the far-end UA, which is necessary if none of the aggregated UAs is capable of being a controller. IMO, section 5 lacks detail on how an additional UA is recruited into the aggregation; in the other 3 scenarios, the user activates some special function of the controlling UA. Dale From jlaurens@cisco.com Thu Jul 28 18:17:57 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F8E21F8B2D for ; Thu, 28 Jul 2011 18:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.864 X-Spam-Level: X-Spam-Status: No, score=0.864 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fhkNizrB5zt for ; Thu, 28 Jul 2011 18:17:56 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2CC21F8B29 for ; Thu, 28 Jul 2011 18:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jlaurens@cisco.com; l=428; q=dns/txt; s=iport; t=1311902276; x=1313111876; h=subject:from:message-id:date:to: content-transfer-encoding:mime-version; bh=s3fZ99bLEAoJcglrEMaujMt94I3pPs5W05W+l6e2idg=; b=AmuKVzdgHr6VTrEDZmzMec03ednmyn6BJYKwpgFR49SarBus2TDIfF5V ii3qyxiD2FzAxjIxEXhxhl7aZoAB1OL3LKcDztSnBeLy4iLUfu780srFV KFQf9Hp7UkTK5QyRZvJhTZC6AQ6D+nyBmIahKmTM3MBc1RWZWcuJrw0Iz o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcJAPgIMk6tJV2b/2dsb2JhbAA3AQEDFAErWAFvUgEFPoh3jzmOImMCd6sSgSOeR4ViXwSHWosghQ+Lcg X-IronPort-AV: E=Sophos;i="4.67,285,1309737600"; d="scan'208";a="7604127" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 29 Jul 2011 01:17:56 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6T1Hurk019945 for ; Fri, 29 Jul 2011 01:17:56 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 20:17:55 -0500 Received: from 72.163.62.204 ([72.163.62.204]) by XMB-RCD-109.cisco.com ([72.163.62.151]) with Microsoft Exchange Server HTTP-DAV ; Fri, 29 Jul 2011 01:17:54 +0000 From: "Jeremy Laurenson (jlaurens)" Content-Type: text/plain; charset="us-ascii" Message-ID: <6A06244A-A3A2-45E1-BBFC-BD7CE981C69D@cisco.com> Date: Thu, 28 Jul 2011 20:17:46 -0500 To: Thread-Topic: Regarding draft-yusef-splices-invoke-01 Thread-Index: AcxNjVg58trC/P9lTGqAPoMAz0jUkQ== Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 (iPad Mail 8L1) X-OriginalArrivalTime: 29 Jul 2011 01:17:56.0143 (UTC) FILETIME=[58BD4BF0:01CC4D8D] Subject: [splices] Regarding draft-yusef-splices-invoke-01 X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 01:17:57 -0000 As per section 2, "There is no way for the REFER-issuer to ask the REFER-rec= ipient to keep the dialog after the refer event.", yet we specifically omit t= he "very important" urn:invoke:call:initiate functionality since the REFER m= ethod already provides for this. I may be missing something (likely this wee= k) but that seems like it may have consequences down the road terms of keepi= ng the dialog open, no? J= From ietf@meetecho.com Thu Jul 28 22:57:09 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF5521F886A for ; Thu, 28 Jul 2011 22:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.569 X-Spam-Level: X-Spam-Status: No, score=-0.569 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTFmewG-6UOV for ; Thu, 28 Jul 2011 22:57:09 -0700 (PDT) Received: from smtplqs01.aruba.it (smtplqs-out17.aruba.it [62.149.158.57]) by ietfa.amsl.com (Postfix) with SMTP id 80BFD21F86D2 for ; Thu, 28 Jul 2011 22:57:07 -0700 (PDT) Received: (qmail 27470 invoked by uid 89); 29 Jul 2011 05:57:03 -0000 Received: from unknown (HELO smtpw2.aruba.it) (62.149.128.188) by smtplqs01.aruba.it with SMTP; 29 Jul 2011 05:57:03 -0000 Received: (qmail 3662 invoked by uid 89); 29 Jul 2011 05:57:03 -0000 Received: from unknown (HELO aruba.it) (62.149.158.90) by smtpw2.ad.aruba.it with SMTP; 29 Jul 2011 05:57:03 -0000 Date: Fri, 29 Jul 2011 07:57:03 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: "Meetecho IETF support" To: splices@ietf.org X-XaM3-API-Version: V3(R2) X-SenderIP: 70.81.226.194 X-Spam-Rating: smtpw2.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplqs01.aruba.it 1.6.2 0/1000/N Subject: [splices] Meetecho supporto for SPLICES WG meeting session X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 05:57:09 -0000 Hi all,=0A=0Aa virtual room has been reserved on the Meetecho system. =0A= =0AAccess to the on-line session (including audio and video streams) will= be available from 14:10.=0ATo get into the room, just click on the prope= r link on the remote participation page:=0Ahttp://www.ietf.org/meeting/81= /remote-participation.html#Meetecho=0A=0AThe Meetecho session automatical= ly logs you into the standard IETF jabber room. So, from there, you can h= ave an integrated experience involving all media and allowing you to inte= ract with the room.=0A=0AA tutorial of interactivity features of the tool= can be found at:=0Ahttp://www.meetecho.com/ietf81/tutorials=0A=0AFor fur= ther information you can contact us at ietf-support@meetecho.com.=0A=0ACh= eers,=0Athe Meetecho Team From dworley@avaya.com Fri Jul 29 10:02:04 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F47321F8AA8 for ; Fri, 29 Jul 2011 10:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.462 X-Spam-Level: X-Spam-Status: No, score=-103.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11PRIGlrR0HD for ; Fri, 29 Jul 2011 10:02:03 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAEE21F8A80 for ; Fri, 29 Jul 2011 10:02:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANLmMk7GmAcF/2dsb2JhbAA0AQEBAQIBFCxKDAIBCQ0ILRAUIy4BAQUBFgwbp0V3iHyjTgKbU4ViXwSYHotb X-IronPort-AV: E=Sophos;i="4.67,288,1309752000"; d="scan'208";a="259470967" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 29 Jul 2011 13:02:01 -0400 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 29 Jul 2011 12:59:30 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 29 Jul 2011 13:02:00 -0400 From: "Worley, Dale R (Dale)" To: "Jeremy Laurenson (jlaurens)" , "splices@ietf.org" Date: Fri, 29 Jul 2011 13:00:23 -0400 Thread-Topic: Regarding draft-yusef-splices-invoke-01 Thread-Index: AcxNjVg58trC/P9lTGqAPoMAz0jUkQAg6k6i Message-ID: References: <6A06244A-A3A2-45E1-BBFC-BD7CE981C69D@cisco.com> In-Reply-To: <6A06244A-A3A2-45E1-BBFC-BD7CE981C69D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [splices] Regarding draft-yusef-splices-invoke-01 X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 17:02:04 -0000 > From: Jeremy Laurenson (jlaurens) [jlaurens@cisco.com] >=20 > As per section 2, "There is no way for the REFER-issuer to ask the > REFER-recipient to keep the dialog after the refer event.", yet we > specifically omit the "very important" urn:invoke:call:initiate > functionality since the REFER method already provides for this. I may > be missing something (likely this week) but that seems like it may > have consequences down the road terms of keeping the dialog open, no? I'm not exactly sure what you're objecting to. But it seems to me that out= -of-dialog REFER might give you the functionality you are looking for. Dale From ietf@meetecho.com Fri Jul 29 15:11:26 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F4821F8B6D for ; Fri, 29 Jul 2011 15:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBhItg6BiEuR for ; Fri, 29 Jul 2011 15:11:20 -0700 (PDT) Received: from smtplqs01.aruba.it (smtplqs-out17.aruba.it [62.149.158.57]) by ietfa.amsl.com (Postfix) with SMTP id C8B2021F8B53 for ; Fri, 29 Jul 2011 15:11:19 -0700 (PDT) Received: (qmail 31766 invoked by uid 89); 29 Jul 2011 22:10:47 -0000 Received: from unknown (HELO smtpw1.aruba.it) (62.149.128.188) by smtplqs01.aruba.it with SMTP; 29 Jul 2011 22:10:47 -0000 Received: (qmail 8317 invoked by uid 89); 29 Jul 2011 22:10:47 -0000 Received: from unknown (HELO aruba.it) (62.149.158.90) by smtpw1.ad.aruba.it with SMTP; 29 Jul 2011 22:10:47 -0000 Date: Sat, 30 Jul 2011 00:10:47 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: "Meetecho IETF support" To: splices@ietf.org X-XaM3-API-Version: V3(R2) X-SenderIP: 64.235.195.26 X-Spam-Rating: smtpw1.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplqs01.aruba.it 1.6.2 0/1000/N Subject: [splices] SPLICES recording available X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 22:11:26 -0000 Dear all,=0A=0Athe full recording (synchronized video, audio, slides and = jabber room) =0Aof today's SPLICES session is available.=0A=0AYou can wat= ch it by either clicking the proper link on the remote participation page= (http://www.ietf.org/meeting/81/remote-participation.html#Meetecho), or = by directly accessing the following URL:=0Ahttp://www.meetecho.com/ietf81= /recordings=0A=0AFor the chair(s): please feel free to put the link to th= e recording in the minutes, if you think this might be useful.=0A=0AIn ca= se of problems with the playout, just drop an e-mail to =0Aietf-support a= t meetecho.com.=0A=0ACheers,=0Athe Meetecho Team