Do we think that having asymmetric RTP will be ok? A lot of = implementation have worked toward symmetric RTP (and some will only play RT= P arriving from the place they are sending to! [1 implementation at SIPIT28= , 3 at SIPIT27 - so maybe not worth worrying about]). Are there any issues = with ZRTP or use of ICE? [I am not an ICE expert so I can't recall if s= ymmetric RTP was baked into ICE, umm "frozen in" to ICE maybe?]

Regards,=A0

Peter

On Mon, Jun 6, 2011 at 5:45 PM, Alan Johnston <alan.b.johnston@gmail.c= om> wrote:

But isn't the INVITE Join received at A= lice's Desk Phone? =A0If so, then
a normal Join will result in Alice's Desk Phone performing mixing of audio streams from Alice's PC, Alice's Desk Phone, and Bob. =A0I th= ought
what was desired (and shown by Rifaat's flow) was that Alice's Desk=
phone did not mix the media, but instead inserted/spliced the media
from Alice's PC into the dialog with Bob, resulting in a re-INVITE to Bob with two m=3D lines.

- Alan -

On Mon, Jun 6, 2011 at 4:15 PM, Worley, Dale R (Dale) <dworley@avaya.com> wrote:
> No, surely it is an ordinary join. =A0At the far UA, there are two inc= oming dialogs, each with one audio m=3D line. =A0The only oddity is that on= e dialog is recvonly (at the far UA), and so is never sent media. =A0The ot= her dialog is sendonly (at the far UA) and so never provides audio to the m= ixing, but is only sent the result of the mixing. =A0The effect is that the= far UA's input audio is sent only to the second dialog, and the far UA= 's output audio is driven only by the first dialog.
>
> Dale
>
_______________________________________________
splices mailing list
splices@ietf.org
https://www.ietf.org/mailman/listinfo/splices

--0023545309701df23c04a513744a-- From pkyzivat@cisco.com Mon Jun 6 16:45: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 5422121F84BE for ; Mon, 6 Jun 2011 16:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_18=0.6, 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 LYCR5sVWEi5K for ; Mon, 6 Jun 2011 16:45:50 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8B80121F84B9 for ; Mon, 6 Jun 2011 16:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=3237; q=dns/txt; s=iport; t=1307403950; x=1308613550; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=ktJuQZHjXQgvmwJ+54WMa/OXS0+h/253OsfLYlXPgSE=; b=c5yshYJ9grwHl6hKMS8r7vKpynM2yKDQ/cdK/QK+V1V0cH2JgvZB1K6x HuEJ6J8FNwFc12PDaHwEm765TFzsUL8oWW6CbjNNUQYj4+Zsb8wEf8XT6 WD56qye8b3HXPxn7kcrPeXp9DkMp0dwuXyfs9YOXHdp2NiBfGknBkSlys M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIhl7U2rRDoJ/2dsb2JhbABTphd3rCqeFYYhBJEDhEyEM4Zf X-IronPort-AV: E=Sophos;i="4.65,328,1304294400"; d="scan'208";a="460747263" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 06 Jun 2011 23:45:50 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p56Njnl3021291 for ; Mon, 6 Jun 2011 23:45:49 GMT Message-ID: <4DED66AD.6080701@cisco.com> Date: Mon, 06 Jun 2011 19:45:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 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>

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: Mon, 06 Jun 2011 23:45:51 -0000 I suspect asymmetric rtp *won't* work a lot of the time, for many reasons, whether we think they are reasonable or not. Maybe this is just an unreasonable use case. I can't really imagine wanting to do this. If I have a handset, or headset, with a mic, it probably has a "speaker" too, and it would seem weird using the mic and not its speaker too. And when they are separate there is likely to be problems with echos. Thanks, Paul On 6/6/2011 7:27 PM, Peter Musgrave wrote: > Hi all, > > My assumptions were that: > - Alice's desk phone is doing the media aggregation and creating a > reINVITE for Bob with a=sendrecv and asymmetric media: > * media is sent from Bob to Alice desk phone > * media is sent from Alice Computer to Bob > > As far as Bob knows this is a dialog only with Alice's deskphone. Bob > does not have to support SPLICES or do anything special. > > Bob must handle asymmetric RTP from Alice. > > Ok? > > I agree that requiring media relay does become a bad idea when the > relaying element is e.g a cellphone. > > Do we think that having asymmetric RTP will be ok? A lot of > implementation have worked toward symmetric RTP (and some will only play > RTP arriving from the place they are sending to! [1 implementation at > SIPIT28, 3 at SIPIT27 - so maybe not worth worrying about]). Are there > any issues with ZRTP or use of ICE? [I am not an ICE expert so I can't > recall if symmetric RTP was baked into ICE, umm "frozen in" to ICE maybe?] > > Regards, > > Peter > > > > > > On Mon, Jun 6, 2011 at 5:45 PM, Alan Johnston > wrote: > > But isn't the INVITE Join received at Alice's Desk Phone? If so, then > a normal Join will result in Alice's Desk Phone performing mixing of > audio streams from Alice's PC, Alice's Desk Phone, and Bob. I thought > what was desired (and shown by Rifaat's flow) was that Alice's Desk > phone did not mix the media, but instead inserted/spliced the media > from Alice's PC into the dialog with Bob, resulting in a re-INVITE to > Bob with two m= lines. > > - Alan - > > On Mon, Jun 6, 2011 at 4:15 PM, Worley, Dale R (Dale) > > wrote: > > No, surely it is an ordinary join. At the far UA, there are two > incoming dialogs, each with one audio m= line. The only oddity is > that one dialog is recvonly (at the far UA), and so is never sent > media. The other dialog is sendonly (at the far UA) and so never > provides audio to the mixing, but is only sent the result of the > mixing. The effect is that the far UA's input audio is sent only to > the second dialog, and the far UA's output audio is driven only by > the first dialog. > > > > Dale > > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices > > > > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices From rifatyu@avaya.com Mon Jun 6 19:02: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 ADFF821F85D3 for ; Mon, 6 Jun 2011 19:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_18=0.6, 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 hWEvDP6XaLrp for ; Mon, 6 Jun 2011 19:02:57 -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 733C421F85D2 for ; Mon, 6 Jun 2011 19:02:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgBAIOF7U2HCzI1/2dsb2JhbABTly+DR4sid64rAptUhiEElWyEFoZf X-IronPort-AV: E=Sophos;i="4.65,329,1304308800"; d="scan'208";a="250073537" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 06 Jun 2011 22:02:54 -0400 X-IronPort-AV: E=Sophos;i="4.65,329,1304308800"; d="scan'208";a="660131788" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 06 Jun 2011 22:02:53 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Mon, 6 Jun 2011 22:02:53 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Paul Kyzivat , "splices@ietf.org" Date: Mon, 6 Jun 2011 22:02:52 -0400 Thread-Topic: [splices] Using Two Separate Devices to Start a Conversation proposal Thread-Index: Acwko+APei7hPso6SoSQ3NW3OJy6FwAEUttc Message-ID: <6369CB70BFD88942B9705AC1E639A33822CC7FB9A8@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822CCE270F5@DC-US1MBEX4.global.avaya.com>

<1C6C5AB3-6085-4CCA-9F1D-8BA5D98ED651@gmail.com> <4DED2EFA.20004@cisco.com>

, <4DED66AD.6080701@cisco.com> In-Reply-To: <4DED66AD.6080701@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: Tue, 07 Jun 2011 02:02:57 -0000 Hi All, Very interesting discussion. What I had in mind is what Peter described below, but you guys came up with= very interesting new ideas that can be used to address this scenario. The scenario is technically an interesting and challenging one, but I tend = to agree with Paul that it is not really a use case that will likely be use= d and maybe we should spend our time addressing other more likely to be use= d uses case. Regards, Rifaat ________________________________________ From: splices-bounces@ietf.org [splices-bounces@ietf.org] On Behalf Of Paul= Kyzivat [pkyzivat@cisco.com] Sent: Monday, June 06, 2011 7:45 PM To: splices@ietf.org Subject: Re: [splices] Using Two Separate Devices to Start a Conversation p= roposal I suspect asymmetric rtp *won't* work a lot of the time, for many reasons, whether we think they are reasonable or not. Maybe this is just an unreasonable use case. I can't really imagine wanting to do this. If I have a handset, or headset, with a mic, it probably has a "speaker" too, and it would seem weird using the mic and not its speaker too. And when they are separate there is likely to be problems with echos. Thanks, Paul On 6/6/2011 7:27 PM, Peter Musgrave wrote: > Hi all, > > My assumptions were that: > - Alice's desk phone is doing the media aggregation and creating a > reINVITE for Bob with a=3Dsendrecv and asymmetric media: > * media is sent from Bob to Alice desk phone > * media is sent from Alice Computer to Bob > > As far as Bob knows this is a dialog only with Alice's deskphone. Bob > does not have to support SPLICES or do anything special. > > Bob must handle asymmetric RTP from Alice. > > Ok? > > I agree that requiring media relay does become a bad idea when the > relaying element is e.g a cellphone. > > Do we think that having asymmetric RTP will be ok? A lot of > implementation have worked toward symmetric RTP (and some will only play > RTP arriving from the place they are sending to! [1 implementation at > SIPIT28, 3 at SIPIT27 - so maybe not worth worrying about]). Are there > any issues with ZRTP or use of ICE? [I am not an ICE expert so I can't > recall if symmetric RTP was baked into ICE, umm "frozen in" to ICE maybe?= ] > > Regards, > > Peter > > > > > > On Mon, Jun 6, 2011 at 5:45 PM, Alan Johnston > wrote: > > But isn't the INVITE Join received at Alice's Desk Phone? If so, the= n > a normal Join will result in Alice's Desk Phone performing mixing of > audio streams from Alice's PC, Alice's Desk Phone, and Bob. I though= t > what was desired (and shown by Rifaat's flow) was that Alice's Desk > phone did not mix the media, but instead inserted/spliced the media > from Alice's PC into the dialog with Bob, resulting in a re-INVITE to > Bob with two m=3D lines. > > - Alan - > > On Mon, Jun 6, 2011 at 4:15 PM, Worley, Dale R (Dale) > > wrote: > > No, surely it is an ordinary join. At the far UA, there are two > incoming dialogs, each with one audio m=3D line. The only oddity is > that one dialog is recvonly (at the far UA), and so is never sent > media. The other dialog is sendonly (at the far UA) and so never > provides audio to the mixing, but is only sent the result of the > mixing. The effect is that the far UA's input audio is sent only to > the second dialog, and the far UA's output audio is driven only by > the first dialog. > > > > Dale > > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices > > > > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices _______________________________________________ splices mailing list splices@ietf.org https://www.ietf.org/mailman/listinfo/splices= From musgravepj@gmail.com Tue Jun 7 03:18: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 3D3DB11E80E5 for ; Tue, 7 Jun 2011 03:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.603 X-Spam-Level: X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_18=0.6, MIME_QP_LONG_LINE=1.396, 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 hVzSTJPWHz+7 for ; Tue, 7 Jun 2011 03:17:59 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB7011E80D0 for ; Tue, 7 Jun 2011 03:17:59 -0700 (PDT) Received: by iwn39 with SMTP id 39so5720585iwn.31 for ; Tue, 07 Jun 2011 03:17:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=bzBAcX2IFlzQGQxgct/0uBv87Tz2c5TXd6V+euPfD84=; b=M7jPGjx5fRjDfe9x/5AA9R7dBKSoDArkyjFSYM9rjEzZtzJHyXoHZBzdwubXt/Bnb4 mrgvgMQmjy250AYOC+2nI9T5vpBmptwm9kS8YsT7zd6DOkS63I5zXW2RrFo2U4xMUuE8 o85dEDfXJImf3r6TOT65PL6jBSMK7gw9t3Q4c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=tN8lDjDXdFIx4Rnq45boX/o5gkCjKSOknDs5rG36taFiuQVpFiwrbEFM6HHjqQ2ReY lMDiFRUmFV21TTzjUX4ygItQkkSI0jiPn7os8u+l6FGQDT7fwmBRBGo/0c/vOIzuqTlO aWMdb/aVYzFm0/fjuHdbEzUiAXpcfDAQnZPm8= Received: by 10.42.83.194 with SMTP id i2mr10392239icl.305.1307441877237; Tue, 07 Jun 2011 03:17:57 -0700 (PDT) Received: from [192.168.1.101] ([204.237.32.134]) by mx.google.com with ESMTPS id gb8sm2087816ibb.60.2011.06.07.03.17.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Jun 2011 03:17:56 -0700 (PDT) References: <6369CB70BFD88942B9705AC1E639A33822CCE270F5@DC-US1MBEX4.global.avaya.com>

<1C6C5AB3-6085-4CCA-9F1D-8BA5D98ED651@gmail.com> <4DED2EFA.20004@cisco.com>

<4DED66AD.6080701@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FB9A8@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CC7FB9A8@DC-US1MBEX4.global.avaya.com> Mime-Version: 1.0 (iPad Mail 8J3) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <4484FAFB-D1FA-4BD4-94DB-529B9D83F74C@gmail.com> X-Mailer: iPad Mail (8J3) From: Peter Musgrave Date: Tue, 7 Jun 2011 06:19:10 -0400 To: "Shekh-Yusef, Rifaat (Rifaat)" Cc: "splices@ietf.org" 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: Tue, 07 Jun 2011 10:18:00 -0000 I agree this can be dropped. Peter Sent from my iPad On 2011-06-06, at 10:02 PM, "Shekh-Yusef, Rifaat (Rifaat)" wrote: > Hi All, >=20 > Very interesting discussion. >=20 > What I had in mind is what Peter described below, but you guys came up wit= h very interesting new ideas that can be used to address this scenario. > The scenario is technically an interesting and challenging one, but I tend= to agree with Paul that it is not really a use case that will likely be use= d and maybe we should spend our time addressing other more likely to be used= uses case. >=20 > Regards, > Rifaat >=20 >=20 >=20 > ________________________________________ > From: splices-bounces@ietf.org [splices-bounces@ietf.org] On Behalf Of Pau= l Kyzivat [pkyzivat@cisco.com] > Sent: Monday, June 06, 2011 7:45 PM > To: splices@ietf.org > Subject: Re: [splices] Using Two Separate Devices to Start a Conversation p= roposal >=20 > I suspect asymmetric rtp *won't* work a lot of the time, for many > reasons, whether we think they are reasonable or not. >=20 > Maybe this is just an unreasonable use case. I can't really imagine > wanting to do this. If I have a handset, or headset, with a mic, it > probably has a "speaker" too, and it would seem weird using the mic and > not its speaker too. And when they are separate there is likely to be > problems with echos. >=20 > Thanks, > Paul >=20 > On 6/6/2011 7:27 PM, Peter Musgrave wrote: >> Hi all, >>=20 >> My assumptions were that: >> - Alice's desk phone is doing the media aggregation and creating a >> reINVITE for Bob with a=3Dsendrecv and asymmetric media: >> * media is sent from Bob to Alice desk phone >> * media is sent from Alice Computer to Bob >>=20 >> As far as Bob knows this is a dialog only with Alice's deskphone. Bob >> does not have to support SPLICES or do anything special. >>=20 >> Bob must handle asymmetric RTP from Alice. >>=20 >> Ok? >>=20 >> I agree that requiring media relay does become a bad idea when the >> relaying element is e.g a cellphone. >>=20 >> Do we think that having asymmetric RTP will be ok? A lot of >> implementation have worked toward symmetric RTP (and some will only play >> RTP arriving from the place they are sending to! [1 implementation at >> SIPIT28, 3 at SIPIT27 - so maybe not worth worrying about]). Are there >> any issues with ZRTP or use of ICE? [I am not an ICE expert so I can't >> recall if symmetric RTP was baked into ICE, umm "frozen in" to ICE maybe?= ] >>=20 >> Regards, >>=20 >> Peter >>=20 >>=20 >>=20 >>=20 >>=20 >> On Mon, Jun 6, 2011 at 5:45 PM, Alan Johnston > > wrote: >>=20 >> But isn't the INVITE Join received at Alice's Desk Phone? If so, then= >> a normal Join will result in Alice's Desk Phone performing mixing of >> audio streams from Alice's PC, Alice's Desk Phone, and Bob. I thought= >> what was desired (and shown by Rifaat's flow) was that Alice's Desk >> phone did not mix the media, but instead inserted/spliced the media >> from Alice's PC into the dialog with Bob, resulting in a re-INVITE to >> Bob with two m=3D lines. >>=20 >> - Alan - >>=20 >> On Mon, Jun 6, 2011 at 4:15 PM, Worley, Dale R (Dale) >> > wrote: >>> No, surely it is an ordinary join. At the far UA, there are two >> incoming dialogs, each with one audio m=3D line. The only oddity is >> that one dialog is recvonly (at the far UA), and so is never sent >> media. The other dialog is sendonly (at the far UA) and so never >> provides audio to the mixing, but is only sent the result of the >> mixing. The effect is that the far UA's input audio is sent only to >> the second dialog, and the far UA's output audio is driven only by >> the first dialog. >>>=20 >>> Dale >>>=20 >> _______________________________________________ >> splices mailing list >> splices@ietf.org >> https://www.ietf.org/mailman/listinfo/splices >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> splices mailing list >> splices@ietf.org >> https://www.ietf.org/mailman/listinfo/splices > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices From dworley@avaya.com Tue Jun 7 08:56:30 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 C505111E815A for ; Tue, 7 Jun 2011 08:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, 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 H5A1iy3oKYKv for ; Tue, 7 Jun 2011 08:56:30 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0F57A11E818E for ; Tue, 7 Jun 2011 08:56:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPZJ7k3GmAcF/2dsb2JhbABSph53rloCm2eGIQSVc4p4 X-IronPort-AV: E=Sophos;i="4.65,333,1304308800"; d="scan'208";a="192187406" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 07 Jun 2011 11:56:07 -0400 X-IronPort-AV: E=Sophos;i="4.65,333,1304308800"; d="scan'208";a="630276487" 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; 07 Jun 2011 11:56:07 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Tue, 7 Jun 2011 11:56:06 -0400 From: "Worley, Dale R (Dale)" To: "Shekh-Yusef, Rifaat (Rifaat)" , "splices@ietf.org" Date: Tue, 7 Jun 2011 11:56:06 -0400 Thread-Topic: [splices] Initiate an A/V Call Using Two Separate Devices proposal Thread-Index: AcwcA9ICWlHJ0iFSQrC3DgLgYMzGCQJJsIlI Message-ID: References: <6369CB70BFD88942B9705AC1E639A33822CCE270ED@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CCE270ED@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] Initiate an A/V Call Using Two Separate Devices 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: Tue, 07 Jun 2011 15:56:30 -0000 These are interesting call flows, and seem to be based on the idea of havin= g a 3PCC-style aggregation controller in the call. I think that the INVOKE URNs could be made simpler and more systematic. Th= e problem with the ones shown is that they depend on particular media types= implicitly triggering the desired behavior; I envision an ever-expanding l= ist of URNs for specific circumstances. Instead, how about constructing on= e URN whose purpose is to tell the target to initiate a call, but to specif= y one or more other UAs as "aggregation slaves": . Or we may want to add a = parameter meaning "only accept a particular media type from this aggregatio= n slave": . Both of the given examples seem to have the same pattern: The device from = which the user is initiating the call isn't the one that is the aggregation= controller. Shouldn't there be one example where it is and one where it i= sn't? Dale From rifatyu@avaya.com Fri Jun 10 06:53: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 3432A11E8135 for ; Fri, 10 Jun 2011 06:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599] 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 28g3eu6yUOmY for ; Fri, 10 Jun 2011 06:53:10 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0D99B11E817F for ; Fri, 10 Jun 2011 06:53:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwBACkh8k2HCzI1/2dsb2JhbABSl1GOdHeqNQKbQYYjBJYWiwg X-IronPort-AV: E=Sophos;i="4.65,347,1304308800"; d="scan'208";a="192814480" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 10 Jun 2011 09:53:06 -0400 X-IronPort-AV: E=Sophos;i="4.65,347,1304308800"; d="scan'208";a="661705958" Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 10 Jun 2011 09:53:05 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Fri, 10 Jun 2011 09:53:05 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: "Worley, Dale R (Dale)" , "splices@ietf.org" Date: Fri, 10 Jun 2011 09:52:46 -0400 Thread-Topic: [splices] Initiate an A/V Call Using Two Separate Devices proposal Thread-Index: AcwcA9ICWlHJ0iFSQrC3DgLgYMzGCQJJsIlIAJJeOSA= Message-ID: <6369CB70BFD88942B9705AC1E639A33822CD81336C@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822CCE270ED@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] Initiate an A/V Call Using Two Separate Devices 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, 10 Jun 2011 13:53:11 -0000 Dale, Can you provide an example use case for these new actions you mentioned bel= ow? Are these to replace or in addition to the ones we have been using so far? For the second part of you comment below, take a look at the following flow= s. The INVOKE method approach is flexible enough to allow any party to take th= e role of the Controller. Regards, Rifaat Alice Alice Proxy Bob PC Desk Phone =20 | | | | | | | | Both Alice's devices subscribe to the reg event package, which allows each = device to=20 discover the capabilities of the other device based on the feature tags pro= vided by each device. The Desk Phone knows that the PC supports Video, while the PC knows that th= e Desk Phone only supports audio. | | | | | | SUBSCRIBE reg | | | |-------------------->| | | | 200 OK | | | |<--------------------| | | | | | | SUBSCRIBE reg | | | |------------------------------------------>| | | 200 OK | | | |<------------------------------------------| | | | | | | | | | The two devices also subscribe to the dialog of each other. | | | | | | | | | SUBSCRIBE dialog | | | |-------------------->| | | | 200 OK | | | |<--------------------| | | | | | | | SUBSCRIBE dialog | | | |<--------------------| | | | 200 OK | | | |-------------------->| | | | | | | | | | | Alice wants to use her PC to initiate an A/V call to Bob. The PC instructs the phone to initiate an audio call, but does not provide = a target,=20 which indicates to the phone to send it to the PC. When the PC gets the audio offer from the phone it sends an A/V offer to th= e remote=20 party and when it gets the A/V answer it sends an audio answer to the phone= . | | | | | | | | | INVOKE Action: urn:invoke:call:initiate;media=3Daudio |-------------------->| | | | 200 OK | | | |<--------------------| | | | | | | | INVITE [Audio] | | | |<--------------------| | | | | | | | INVITE [A/V] | | | |------------------------------------------>| | | | | INVITE [A/V] | | | |-------------------->| | | | 180 | | 180 | |<--------------------| |<------------------------------------------| | | 180 | | | |-------------------->| | | | | | 200 OK [A/V] | | 200 OK [A/V] | |<--------------------| |<------------------------------------------| | | | | | | 200 OK [Audio] | | | |-------------------->| | | | | | | | | | | |<-------------------------dialog1------------------------------->| |<----dialog2-------->| | | | | | | | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | Alice wants to use her phone to initiate an A/V call to Bob. The phone knows it cannot handle video, but it know that the PC can.=20 The phone sends an INVOKE request to instruct the PC to initiate a vidoe ca= ll.=20 Because the Action does not have a target parameter, this indicates to the = PC to send the INVITE to the phone. | | | | | INVOKE Action: urn:invoke:call:initiate;media=3Dvideo |<--------------------| | | | 200 OK | | | |-------------------->| | | | | | | | INVITE [Video] | | | |-------------------->| | | | 100 | | | |<--------------------| | | | | INVITE [A/V] | | | |-------------------->| | | | | INVITE [A/V] | | | |-------------------->| | | | 180 | | | 180 |<--------------------| | |<--------------------| | | 180 | | | |<--------------------| | 200 OK [A/V] | | | 200 OK [A/V] |<--------------------| | |<--------------------| | | ACK [Video] | | | |<--------------------| | | | | ACK | | | |-------------------->| | | | | ACK | | | |-------------------->| | | | | |<----dialog2-------->|<---dialog1------------------------------->| | | | | | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | > -----Original Message----- > From: Worley, Dale R (Dale) > Sent: Tuesday, June 07, 2011 11:56 AM > To: Shekh-Yusef, Rifaat (Rifaat); splices@ietf.org > Subject: RE: [splices] Initiate an A/V Call Using Two Separate Devices > proposal >=20 > These are interesting call flows, and seem to be based on the idea of hav= ing a > 3PCC-style aggregation controller in the call. >=20 > I think that the INVOKE URNs could be made simpler and more systematic. = The > problem with the ones shown is that they depend on particular media types > implicitly triggering the desired behavior; I envision an ever-expanding = list > of URNs for specific circumstances. Instead, how about constructing one = URN > whose purpose is to tell the target to initiate a call, but to specify on= e or > more other UAs as "aggregation slaves": > = . Or we > may want to add a parameter meaning "only accept a particular media type = from > this aggregation slave": URI];media=3Dvideo;target=3Dsip:bob@whatever>. >=20 > Both of the given examples seem to have the same pattern: The device fro= m > which the user is initiating the call isn't the one that is the aggregati= on > controller. Shouldn't there be one example where it is and one where it > isn't? >=20 > Dale From rifatyu@avaya.com Fri Jun 10 12:08:37 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 8505611E81AA for ; Fri, 10 Jun 2011 12:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 qFePuto01p0u for ; Fri, 10 Jun 2011 12:08:37 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id D536211E8122 for ; Fri, 10 Jun 2011 12:08:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAARr8k2HCzI1/2dsb2JhbABSglGjCnJwB6lSAps4hiMElhaLCA X-IronPort-AV: E=Sophos;i="4.65,348,1304308800"; d="scan'208,217";a="192876723" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 10 Jun 2011 15:08:35 -0400 X-IronPort-AV: E=Sophos;i="4.65,348,1304308800"; d="scan'208,217";a="662031973" 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; 10 Jun 2011 15:08:35 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Fri, 10 Jun 2011 15:08:35 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: "splices@ietf.org" Date: Fri, 10 Jun 2011 15:08:22 -0400 Thread-Topic: SIP INVOKE method v1 Thread-Index: AcwnocRQrnbFG//qQT2Hod0ECTp4Kw== Message-ID: <6369CB70BFD88942B9705AC1E639A33822CD81384C@DC-US1MBEX4.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Axx3 Bh6I D+fb ICM2 KumT Lgot MBk+ No/B Od+L TaLS UYKs Z+NN cTRX csFY i8GP qw3w; 4; YQBsAGEAbgAuAGIALgBqAG8AaABuAHMAdABvAG4AQABnAG0AYQBpAGwALgBjAG8AbQA7AGYAbAB1AGYAZgB5AEAAYwBpAHMAYwBvAC4AYwBvAG0AOwBmAHIAYQBuAGMAbwBpAHMALgBhAHUAZABlAHQAQABzAGsAeQBwAGUALgBuAGUAdAA7AHMAcABsAGkAYwBlAHMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {07FFF4D2-D4DE-4E81-8DFD-A1F292CA1567}; cgBpAGYAYQB0AHkAdQBAAGEAdgBhAHkAYQAuAGMAbwBtAA==; Fri, 10 Jun 2011 19:08:22 GMT;UwBJAFAAIABJAE4AVgBPAEsARQAgAG0AZQB0AGgAbwBkACAAdgAxAA== x-cr-puzzleid: {07FFF4D2-D4DE-4E81-8DFD-A1F292CA1567} acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6369CB70BFD88942B9705AC1E639A33822CD81384CDCUS1MBEX4glo_" MIME-Version: 1.0 Subject: [splices] SIP INVOKE method v1 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, 10 Jun 2011 19:08:37 -0000 --_000_6369CB70BFD88942B9705AC1E639A33822CD81384CDCUS1MBEX4glo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have just submitted a new version of the SIP INVOKE method draft that do= es not include implicit subscription. https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/ We would appreciate it if you review the document and provide us with your = feedback. Thanks, Rifaat --_000_6369CB70BFD88942B9705AC1E639A33822CD81384CDCUS1MBEX4glo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We have ju= st submitted a new version of the SIP INVOKE method draft that does not inc= lude implicit subscription.

https://datatr= acker.ietf.org/doc/draft-yusef-splices-invoke/

We would appreciate = it if you review the document and provide us with your feedback.=

Thanks,<= o:p>

Rifaat

= --_000_6369CB70BFD88942B9705AC1E639A33822CD81384CDCUS1MBEX4glo_-- From pkyzivat@cisco.com Fri Jun 10 12:45:41 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 5342F11E8113 for ; Fri, 10 Jun 2011 12:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.354 X-Spam-Level: X-Spam-Status: No, score=-110.354 tagged_above=-999 required=5 tests=[AWL=0.245, 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 8h7I+jTg8ZcY for ; Fri, 10 Jun 2011 12:45:39 -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 E2A2B11E80B7 for ; Fri, 10 Jun 2011 12:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=3982; q=dns/txt; s=iport; t=1307735139; x=1308944739; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=aEDbIzgjmKDRglp53kXF0xk9rXq68YuKvoEIXZBrDPc=; b=Gw3DSRbpm35nSSyoxqJDsdPpNDbMwcEr1oCE/qC7WJ/gxlPD44J5/J/1 wa+PV/96ak1J049D6UTy4wD3ndDpxVKP3nNwJmRK2fJ4y3G8w3Th7K1c5 lUo172AyJKp8Fvecv9DGAxnG94QGYE/kTD68NLj8UwLL13ar4RGVY+Ugm s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABB08k2tJV2c/2dsb2JhbABSpk13pw6eCYYjBJErhE6LJQ X-IronPort-AV: E=Sophos;i="4.65,348,1304294400"; d="scan'208";a="287059860" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-4.cisco.com with ESMTP; 10 Jun 2011 19:45:38 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p5AJjbUD027213 for ; Fri, 10 Jun 2011 19:45:38 GMT Message-ID: <4DF27461.8060204@cisco.com> Date: Fri, 10 Jun 2011 15:45:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: splices@ietf.org References: <6369CB70BFD88942B9705AC1E639A33822CD81384C@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CD81384C@DC-US1MBEX4.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [splices] SIP INVOKE method v1 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, 10 Jun 2011 19:45:41 -0000 This is getting better with age! Splitting off the subscription is good. An area that still needs work is in the semantics of the urns. Some of them are more clear than others. Some are "limited" in ways that might not matter to some but that could prove a problem in the end. Specifically: o Answer call - urn:invoke:call:answer o Terminate call - urn:invoke:call:terminate o Decline call - urn:invoke:call:decline o Ignore call - urn:invoke:call:ignore The above need some elaboration, but I think its just work - probably anybody who does it will end up with an equivalent result. o Send call to VM - urn:invoke:call:sendvm VM is a "feature", and we haven't standardized features much, except for bliss. How does one know if the recipient understands VM and what to do to send a call there? What if there are multiple VM options (e.g. what to say, etc.) And what if the call isn't a voice call. (Maybe VM now means voice/video mail. But the "call" could be IM.) o Hold call - urn:invoke:call:hold o Unhold call - urn:invoke:call:unhold o Mute call - urn:invoke:call:mute o Unmute call - urn:invoke:call:unmute Similarly these are all "features" that we all have some expectations about, but that are not rigorously defined. (But perhaps Mute/Unmute could be formalized by using the 'transducer' option. (Transducer=none?) My concern with all these "features" is that we are being put into a box where we must either: - define them with sufficient rigor - fall back on "do what I mean", which has proved to be a bad idea, because not everybody has the same notion of what they mean. o Conference - urn:invoke:conference:add - urn:invoke:conference:remove This one may be clearer due to the existence of xcon specs. Regarding action parameters: o media=audio|video|audvid I'm troubled by audvid. I would rather see "audio,video". Specifically, what is the namespace here, and what does specifying it mean? I think the namespace could be: one or more values allowable as the parameter in the m-line in SDP. Defining exactly what it means when present is a little harder. When answering a call that has an offer, I guess it could mean: refuse any m-lines with media type that doesn't match one of these, and accept as many of the remaining as you can. For answering an offerless invite, I guess it could mean: offer whatever media you are capable of offering that match one of these, but don't offer anything that doesn't match. Is there likely to be a need to get more specific? E.g. about what codecs to use? (Hopefully not - that could get very messy.) o transducer=speaker|headset My deskphone has three possibilities: speaker|headset|handset. And I'm far from certain this is exhaustive. (The clue wg is defining a much more complex environment.) This at least needs to be extensible. We may need some sort of extended model of a UA that includes this sort of stuff. o target= o direction=recvonly|sendonly|sendrecv o abort None of this is intended as objection to the work so far. Its just a start at identifying what else there is to do. The whole notion of naming features to invoke causes me the most concern. Thanks, Paul On 6/10/2011 3:08 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > Hi, > > We have just submitted a new version of the SIP INVOKE method draft that > does not include implicit subscription. > > https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/ > > We would appreciate it if you review the document and provide us with > your feedback. > > Thanks, > > Rifaat > > > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices From andrew.hutton@siemens-enterprise.com Mon Jun 13 07:04: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 A563D9E800B for ; Mon, 13 Jun 2011 07:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-9-taAVbySG for ; Mon, 13 Jun 2011 07:04:07 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 559699E8009 for ; Mon, 13 Jun 2011 07:04:07 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: andrew.hutton@siemens-enterprise.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1307973846!16938016!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 14180 invoked from network); 13 Jun 2011 14:04:06 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-9.tower-174.messagelabs.com with SMTP; 13 Jun 2011 14:04:06 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 08CF41EB83D3; Mon, 13 Jun 2011 16:04:06 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 13 Jun 2011 16:04:06 +0200 From: "Hutton, Andrew" To: Paul Kyzivat , "splices@ietf.org" Date: Mon, 13 Jun 2011 16:04:03 +0200 Thread-Topic: [splices] SIP INVOKE method v1 Thread-Index: AcwnpwHyWdPZ0GtcQdet0Lc+UVQPIgCJvnyQ Message-ID: <101C6067BEC68246B0C3F6843BCCC1E30C22977E6A@MCHP058A.global-ad.net> References: <6369CB70BFD88942B9705AC1E639A33822CD81384C@DC-US1MBEX4.global.avaya.com> <4DF27461.8060204@cisco.com> In-Reply-To: <4DF27461.8060204@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] SIP INVOKE method v1 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, 13 Jun 2011 14:04:08 -0000 Hi All, Whilst I still question whether the mechanism described in this draft actua= lly falls within the SPLICES WG charter as it defines new mechanism I have = a few comments. I tend to agree with Paul's comments below but would go further to say that= even some of the supposedly simply actions such as "decline" & "ignore" ar= e also features which will be difficult to agree the semantics for. All of = the actions will need to be specified rigorously a quick look at ECMA-269 w= hich specifies these kind of services for CSTA will give you an idea of wha= t would need to be done. I don't believe that even in the CSTA world which = defines a very large number of services the services "ignore" or "decline" = were specified. With regard to the discussion on headers vs body the draft states. "There has been some discussion on the list on the question of header field= vs message body. This is not the real issue, as either could conceivably = be used. Instead, the main issue is what is being invoked: is it a named = feature/action/event, or is it a script". I must have missed the discussion about scripting but I don't think this is= the issue. The issue is I believe extensibility which any mechanism for in= voking services will need and this is the reason why an XML body would be b= etter than using SIP headers. =20 Regards Andy > -----Original Message----- > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 10 June 2011 20:46 > To: splices@ietf.org > Subject: Re: [splices] SIP INVOKE method v1 >=20 > This is getting better with age! >=20 > Splitting off the subscription is good. >=20 > An area that still needs work is in the semantics of the urns. > Some of them are more clear than others. Some are "limited" in ways > that > might not matter to some but that could prove a problem in the end. > Specifically: >=20 > o Answer call - urn:invoke:call:answer > o Terminate call - urn:invoke:call:terminate > o Decline call - urn:invoke:call:decline > o Ignore call - urn:invoke:call:ignore >=20 > The above need some elaboration, but I think its just work - probably > anybody who does it will end up with an equivalent result. >=20 > o Send call to VM - urn:invoke:call:sendvm >=20 > VM is a "feature", and we haven't standardized features much, except > for > bliss. How does one know if the recipient understands VM and what to do > to send a call there? What if there are multiple VM options (e.g. what > to say, etc.) And what if the call isn't a voice call. (Maybe VM now > means voice/video mail. But the "call" could be IM.) >=20 > o Hold call - urn:invoke:call:hold > o Unhold call - urn:invoke:call:unhold > o Mute call - urn:invoke:call:mute > o Unmute call - urn:invoke:call:unmute >=20 > Similarly these are all "features" that we all have some expectations > about, but that are not rigorously defined. (But perhaps Mute/Unmute > could be formalized by using the 'transducer' option. > (Transducer=3Dnone?) >=20 > My concern with all these "features" is that we are being put into a > box > where we must either: > - define them with sufficient rigor > - fall back on "do what I mean", which has proved to be a bad idea, > because not everybody has the same notion of what they mean. >=20 > o Conference - urn:invoke:conference:add > - urn:invoke:conference:remove >=20 > This one may be clearer due to the existence of xcon specs. >=20 > Regarding action parameters: >=20 > o media=3Daudio|video|audvid >=20 > I'm troubled by audvid. I would rather see "audio,video". Specifically, > what is the namespace here, and what does specifying it mean? I think > the namespace could be: one or more values allowable as the > parameter in the m-line in SDP. >=20 > Defining exactly what it means when present is a little harder. When > answering a call that has an offer, I guess it could mean: refuse any > m-lines with media type that doesn't match one of these, and accept as > many of the remaining as you can. >=20 > For answering an offerless invite, I guess it could mean: offer > whatever > media you are capable of offering that match one of these, but don't > offer anything that doesn't match. >=20 > Is there likely to be a need to get more specific? E.g. about what > codecs to use? (Hopefully not - that could get very messy.) >=20 > o transducer=3Dspeaker|headset >=20 > My deskphone has three possibilities: speaker|headset|handset. > And I'm far from certain this is exhaustive. (The clue wg is defining a > much more complex environment.) This at least needs to be extensible. > We > may need some sort of extended model of a UA that includes this sort of > stuff. >=20 > o target=3D > o direction=3Drecvonly|sendonly|sendrecv > o abort >=20 > None of this is intended as objection to the work so far. Its just a > start at identifying what else there is to do. The whole notion of > naming features to invoke causes me the most concern. >=20 > Thanks, > Paul >=20 > On 6/10/2011 3:08 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > Hi, > > > > We have just submitted a new version of the SIP INVOKE method draft > that > > does not include implicit subscription. > > > > https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/ > > > > We would appreciate it if you review the document and provide us with > > your feedback. > > > > Thanks, > > > > Rifaat > > > > > > > > _______________________________________________ > > splices mailing list > > splices@ietf.org > > https://www.ietf.org/mailman/listinfo/splices > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices From rifatyu@avaya.com Tue Jun 14 09:30: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 57B1311E80C9 for ; Tue, 14 Jun 2011 09:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.165 X-Spam-Level: X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=0.434, 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 49ZxGAlbGMYo for ; Tue, 14 Jun 2011 09:30:37 -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 F205511E8096 for ; Tue, 14 Jun 2011 09:30:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsBADWM903GmAcF/2dsb2JhbABSl0yOdXetcAKcEIYkBJY8iw8 X-IronPort-AV: E=Sophos;i="4.65,365,1304308800"; d="scan'208";a="251323266" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Jun 2011 12:30:18 -0400 X-IronPort-AV: E=Sophos;i="4.65,365,1304308800"; d="scan'208";a="632401398" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Jun 2011 12:30:17 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Tue, 14 Jun 2011 12:30:17 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Paul Kyzivat , "splices@ietf.org" Date: Tue, 14 Jun 2011 12:30:15 -0400 Thread-Topic: [splices] SIP INVOKE method v1 Thread-Index: AcwnpwcQzAQM1kbgRte4gzk3XtCf/wDCGArg Message-ID: <6369CB70BFD88942B9705AC1E639A33822CDA812B8@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822CD81384C@DC-US1MBEX4.global.avaya.com> <4DF27461.8060204@cisco.com> In-Reply-To: <4DF27461.8060204@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] SIP INVOKE method v1 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, 14 Jun 2011 16:30:38 -0000 Hi Paul, Thanks for the detailed review and feedback. I agree with you that this is the next thing that we need to describe in de= tails. I will be working on providing more details to explain our thinking around = the various actions and parameters. Regards, Rifaat > -----Original Message----- > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behal= f Of > Paul Kyzivat > Sent: Friday, June 10, 2011 3:46 PM > To: splices@ietf.org > Subject: Re: [splices] SIP INVOKE method v1 >=20 > This is getting better with age! >=20 > Splitting off the subscription is good. >=20 > An area that still needs work is in the semantics of the urns. > Some of them are more clear than others. Some are "limited" in ways that > might not matter to some but that could prove a problem in the end. > Specifically: >=20 > o Answer call - urn:invoke:call:answer > o Terminate call - urn:invoke:call:terminate > o Decline call - urn:invoke:call:decline > o Ignore call - urn:invoke:call:ignore >=20 > The above need some elaboration, but I think its just work - probably > anybody who does it will end up with an equivalent result. >=20 > o Send call to VM - urn:invoke:call:sendvm >=20 > VM is a "feature", and we haven't standardized features much, except for > bliss. How does one know if the recipient understands VM and what to do > to send a call there? What if there are multiple VM options (e.g. what > to say, etc.) And what if the call isn't a voice call. (Maybe VM now > means voice/video mail. But the "call" could be IM.) >=20 > o Hold call - urn:invoke:call:hold > o Unhold call - urn:invoke:call:unhold > o Mute call - urn:invoke:call:mute > o Unmute call - urn:invoke:call:unmute >=20 > Similarly these are all "features" that we all have some expectations > about, but that are not rigorously defined. (But perhaps Mute/Unmute > could be formalized by using the 'transducer' option. (Transducer=3Dnone?= ) >=20 > My concern with all these "features" is that we are being put into a box > where we must either: > - define them with sufficient rigor > - fall back on "do what I mean", which has proved to be a bad idea, > because not everybody has the same notion of what they mean. >=20 > o Conference - urn:invoke:conference:add > - urn:invoke:conference:remove >=20 > This one may be clearer due to the existence of xcon specs. >=20 > Regarding action parameters: >=20 > o media=3Daudio|video|audvid >=20 > I'm troubled by audvid. I would rather see "audio,video". Specifically, > what is the namespace here, and what does specifying it mean? I think > the namespace could be: one or more values allowable as the > parameter in the m-line in SDP. >=20 > Defining exactly what it means when present is a little harder. When > answering a call that has an offer, I guess it could mean: refuse any > m-lines with media type that doesn't match one of these, and accept as > many of the remaining as you can. >=20 > For answering an offerless invite, I guess it could mean: offer whatever > media you are capable of offering that match one of these, but don't > offer anything that doesn't match. >=20 > Is there likely to be a need to get more specific? E.g. about what > codecs to use? (Hopefully not - that could get very messy.) >=20 > o transducer=3Dspeaker|headset >=20 > My deskphone has three possibilities: speaker|headset|handset. > And I'm far from certain this is exhaustive. (The clue wg is defining a > much more complex environment.) This at least needs to be extensible. We > may need some sort of extended model of a UA that includes this sort of > stuff. >=20 > o target=3D > o direction=3Drecvonly|sendonly|sendrecv > o abort >=20 > None of this is intended as objection to the work so far. Its just a > start at identifying what else there is to do. The whole notion of > naming features to invoke causes me the most concern. >=20 > Thanks, > Paul >=20 > On 6/10/2011 3:08 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > Hi, > > > > We have just submitted a new version of the SIP INVOKE method draft tha= t > > does not include implicit subscription. > > > > https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/ > > > > We would appreciate it if you review the document and provide us with > > your feedback. > > > > Thanks, > > > > Rifaat > > > > > > > > _______________________________________________ > > splices mailing list > > splices@ietf.org > > https://www.ietf.org/mailman/listinfo/splices > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices From rifatyu@avaya.com Tue Jun 14 09:32: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 4C48811E809A for ; Tue, 14 Jun 2011 09:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.757 X-Spam-Level: X-Spam-Status: No, score=-1.757 tagged_above=-999 required=5 tests=[AWL=-1.191, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_XBL=3.033] 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 jBGm20zX5nID for ; Tue, 14 Jun 2011 09:32:15 -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 5D8ED11E8098 for ; Tue, 14 Jun 2011 09:32:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsBAHiM903GmAcF/2dsb2JhbABSl0yOdXeIc6R9ApwQhiQEljyLDw X-IronPort-AV: E=Sophos;i="4.65,365,1304308800"; d="scan'208";a="284963124" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Jun 2011 12:32:14 -0400 X-IronPort-AV: E=Sophos;i="4.65,365,1304308800"; d="scan'208";a="632402007" Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Jun 2011 12:32:14 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Tue, 14 Jun 2011 12:32:14 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: "Hutton, Andrew" , Paul Kyzivat , "splices@ietf.org" Date: Tue, 14 Jun 2011 12:32:13 -0400 Thread-Topic: [splices] SIP INVOKE method v1 Thread-Index: AcwnpwHyWdPZ0GtcQdet0Lc+UVQPIgCJvnyQADiYGNA= Message-ID: <6369CB70BFD88942B9705AC1E639A33822CDA812C4@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822CD81384C@DC-US1MBEX4.global.avaya.com> <4DF27461.8060204@cisco.com> <101C6067BEC68246B0C3F6843BCCC1E30C22977E6A@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E30C22977E6A@MCHP058A.global-ad.net> 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 v1 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, 14 Jun 2011 16:32:16 -0000 Andy, > The issue is I believe extensibility which any mechanism for > invoking services will need and this is the reason why an XML body would = be > better than using SIP headers. What makes you think that the current proposal is not extensible? Regards, Rifaat > -----Original Message----- > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behal= f Of > Hutton, Andrew > Sent: Monday, June 13, 2011 10:04 AM > To: Paul Kyzivat; splices@ietf.org > Subject: Re: [splices] SIP INVOKE method v1 >=20 > Hi All, >=20 > Whilst I still question whether the mechanism described in this draft act= ually > falls within the SPLICES WG charter as it defines new mechanism I have a = few > comments. >=20 > I tend to agree with Paul's comments below but would go further to say th= at > even some of the supposedly simply actions such as "decline" & "ignore" a= re > also features which will be difficult to agree the semantics for. All of = the > actions will need to be specified rigorously a quick look at ECMA-269 whi= ch > specifies these kind of services for CSTA will give you an idea of what w= ould > need to be done. I don't believe that even in the CSTA world which define= s a > very large number of services the services "ignore" or "decline" were > specified. >=20 > With regard to the discussion on headers vs body the draft states. >=20 > "There has been some discussion on the list on the question of header fie= ld vs > message body. This is not the real issue, as either could conceivably be > used. Instead, the main issue is what is being invoked: is it a named > feature/action/event, or is it a script". >=20 > I must have missed the discussion about scripting but I don't think this = is > the issue. The issue is I believe extensibility which any mechanism for > invoking services will need and this is the reason why an XML body would = be > better than using SIP headers. >=20 > Regards > Andy >=20 >=20 > > -----Original Message----- > > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: 10 June 2011 20:46 > > To: splices@ietf.org > > Subject: Re: [splices] SIP INVOKE method v1 > > > > This is getting better with age! > > > > Splitting off the subscription is good. > > > > An area that still needs work is in the semantics of the urns. > > Some of them are more clear than others. Some are "limited" in ways > > that > > might not matter to some but that could prove a problem in the end. > > Specifically: > > > > o Answer call - urn:invoke:call:answer > > o Terminate call - urn:invoke:call:terminate > > o Decline call - urn:invoke:call:decline > > o Ignore call - urn:invoke:call:ignore > > > > The above need some elaboration, but I think its just work - probably > > anybody who does it will end up with an equivalent result. > > > > o Send call to VM - urn:invoke:call:sendvm > > > > VM is a "feature", and we haven't standardized features much, except > > for > > bliss. How does one know if the recipient understands VM and what to do > > to send a call there? What if there are multiple VM options (e.g. what > > to say, etc.) And what if the call isn't a voice call. (Maybe VM now > > means voice/video mail. But the "call" could be IM.) > > > > o Hold call - urn:invoke:call:hold > > o Unhold call - urn:invoke:call:unhold > > o Mute call - urn:invoke:call:mute > > o Unmute call - urn:invoke:call:unmute > > > > Similarly these are all "features" that we all have some expectations > > about, but that are not rigorously defined. (But perhaps Mute/Unmute > > could be formalized by using the 'transducer' option. > > (Transducer=3Dnone?) > > > > My concern with all these "features" is that we are being put into a > > box > > where we must either: > > - define them with sufficient rigor > > - fall back on "do what I mean", which has proved to be a bad idea, > > because not everybody has the same notion of what they mean. > > > > o Conference - urn:invoke:conference:add > > - urn:invoke:conference:remove > > > > This one may be clearer due to the existence of xcon specs. > > > > Regarding action parameters: > > > > o media=3Daudio|video|audvid > > > > I'm troubled by audvid. I would rather see "audio,video". Specifically, > > what is the namespace here, and what does specifying it mean? I think > > the namespace could be: one or more values allowable as the > > parameter in the m-line in SDP. > > > > Defining exactly what it means when present is a little harder. When > > answering a call that has an offer, I guess it could mean: refuse any > > m-lines with media type that doesn't match one of these, and accept as > > many of the remaining as you can. > > > > For answering an offerless invite, I guess it could mean: offer > > whatever > > media you are capable of offering that match one of these, but don't > > offer anything that doesn't match. > > > > Is there likely to be a need to get more specific? E.g. about what > > codecs to use? (Hopefully not - that could get very messy.) > > > > o transducer=3Dspeaker|headset > > > > My deskphone has three possibilities: speaker|headset|handset. > > And I'm far from certain this is exhaustive. (The clue wg is defining a > > much more complex environment.) This at least needs to be extensible. > > We > > may need some sort of extended model of a UA that includes this sort of > > stuff. > > > > o target=3D > > o direction=3Drecvonly|sendonly|sendrecv > > o abort > > > > None of this is intended as objection to the work so far. Its just a > > start at identifying what else there is to do. The whole notion of > > naming features to invoke causes me the most concern. > > > > Thanks, > > Paul > > > > On 6/10/2011 3:08 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > > Hi, > > > > > > We have just submitted a new version of the SIP INVOKE method draft > > that > > > does not include implicit subscription. > > > > > > https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/ > > > > > > We would appreciate it if you review the document and provide us with > > > your feedback. > > > > > > Thanks, > > > > > > Rifaat > > > > > > > > > > > > _______________________________________________ > > > splices mailing list > > > splices@ietf.org > > > https://www.ietf.org/mailman/listinfo/splices > > _______________________________________________ > > splices mailing list > > splices@ietf.org > > https://www.ietf.org/mailman/listinfo/splices > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices From andrew.hutton@siemens-enterprise.com Tue Jun 14 10:18: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 556BE11E8148 for ; Tue, 14 Jun 2011 10:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jguvq2wH6ySM for ; Tue, 14 Jun 2011 10:18:32 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 87A5E11E8143 for ; Tue, 14 Jun 2011 10:18:31 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: andrew.hutton@siemens-enterprise.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1308071910!9063531!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 19611 invoked from network); 14 Jun 2011 17:18:30 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-14.tower-182.messagelabs.com with SMTP; 14 Jun 2011 17:18:30 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id E9E501EB83ED; Tue, 14 Jun 2011 19:18:29 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 14 Jun 2011 19:18:29 +0200 From: "Hutton, Andrew" To: "Shekh-Yusef, Rifaat (Rifaat)" , Paul Kyzivat , "splices@ietf.org" Date: Tue, 14 Jun 2011 19:18:28 +0200 Thread-Topic: [splices] SIP INVOKE method v1 Thread-Index: AcwnpwHyWdPZ0GtcQdet0Lc+UVQPIgCJvnyQADiYGNAAANdDQA== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E30C229785C2@MCHP058A.global-ad.net> References: <6369CB70BFD88942B9705AC1E639A33822CD81384C@DC-US1MBEX4.global.avaya.com> <4DF27461.8060204@cisco.com> <101C6067BEC68246B0C3F6843BCCC1E30C22977E6A@MCHP058A.global-ad.net> <6369CB70BFD88942B9705AC1E639A33822CDA812C4@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CDA812C4@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 v1 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, 14 Jun 2011 17:18:33 -0000 Hi Rifaat, I am not saying that the current proposal is not extensible but I believe t= hat an XML body would be a much better solution to the extensibility proble= m that using a SIP header. The list of potential actions and associated parameters is huge and for thi= s kind of problem I believe that an XML body would be a much better solutio= n. I guess I much prefer XML to BNF. There is also an architectural issue as the actions don't relate directly t= o the management of the SIP session and therefore most likely need to passe= d to the application layer in the SIP UA to handle. It is much cleaner arch= itecturally if the body can simply be removed and passed to the responsible= component in the UA rather than the SIP component having to extract the in= formation from SIP headers. Regards Andy > -----Original Message----- > From: Shekh-Yusef, Rifaat (Rifaat) [mailto:rifatyu@avaya.com] > Sent: 14 June 2011 17:32 > To: Hutton, Andrew; Paul Kyzivat; splices@ietf.org > Subject: RE: [splices] SIP INVOKE method v1 >=20 > Andy, >=20 > > The issue is I believe extensibility which any mechanism for > > invoking services will need and this is the reason why an XML body > would be > > better than using SIP headers. >=20 > What makes you think that the current proposal is not extensible? >=20 > Regards, > Rifaat >=20 >=20 > > -----Original Message----- > > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On > Behalf Of > > Hutton, Andrew > > Sent: Monday, June 13, 2011 10:04 AM > > To: Paul Kyzivat; splices@ietf.org > > Subject: Re: [splices] SIP INVOKE method v1 > > > > Hi All, > > > > Whilst I still question whether the mechanism described in this draft > actually > > falls within the SPLICES WG charter as it defines new mechanism I > have a few > > comments. > > > > I tend to agree with Paul's comments below but would go further to > say that > > even some of the supposedly simply actions such as "decline" & > "ignore" are > > also features which will be difficult to agree the semantics for. All > of the > > actions will need to be specified rigorously a quick look at ECMA-269 > which > > specifies these kind of services for CSTA will give you an idea of > what would > > need to be done. I don't believe that even in the CSTA world which > defines a > > very large number of services the services "ignore" or "decline" were > > specified. > > > > With regard to the discussion on headers vs body the draft states. > > > > "There has been some discussion on the list on the question of header > field vs > > message body. This is not the real issue, as either could > conceivably be > > used. Instead, the main issue is what is being invoked: is it a > named > > feature/action/event, or is it a script". > > > > I must have missed the discussion about scripting but I don't think > this is > > the issue. The issue is I believe extensibility which any mechanism > for > > invoking services will need and this is the reason why an XML body > would be > > better than using SIP headers. > > > > Regards > > Andy > > > > > > > -----Original Message----- > > > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On > > > Behalf Of Paul Kyzivat > > > Sent: 10 June 2011 20:46 > > > To: splices@ietf.org > > > Subject: Re: [splices] SIP INVOKE method v1 > > > > > > This is getting better with age! > > > > > > Splitting off the subscription is good. > > > > > > An area that still needs work is in the semantics of the urns. > > > Some of them are more clear than others. Some are "limited" in ways > > > that > > > might not matter to some but that could prove a problem in the end. > > > Specifically: > > > > > > o Answer call - urn:invoke:call:answer > > > o Terminate call - urn:invoke:call:terminate > > > o Decline call - urn:invoke:call:decline > > > o Ignore call - urn:invoke:call:ignore > > > > > > The above need some elaboration, but I think its just work - > probably > > > anybody who does it will end up with an equivalent result. > > > > > > o Send call to VM - urn:invoke:call:sendvm > > > > > > VM is a "feature", and we haven't standardized features much, > except > > > for > > > bliss. How does one know if the recipient understands VM and what > to do > > > to send a call there? What if there are multiple VM options (e.g. > what > > > to say, etc.) And what if the call isn't a voice call. (Maybe VM > now > > > means voice/video mail. But the "call" could be IM.) > > > > > > o Hold call - urn:invoke:call:hold > > > o Unhold call - urn:invoke:call:unhold > > > o Mute call - urn:invoke:call:mute > > > o Unmute call - urn:invoke:call:unmute > > > > > > Similarly these are all "features" that we all have some > expectations > > > about, but that are not rigorously defined. (But perhaps > Mute/Unmute > > > could be formalized by using the 'transducer' option. > > > (Transducer=3Dnone?) > > > > > > My concern with all these "features" is that we are being put into > a > > > box > > > where we must either: > > > - define them with sufficient rigor > > > - fall back on "do what I mean", which has proved to be a bad idea, > > > because not everybody has the same notion of what they mean. > > > > > > o Conference - urn:invoke:conference:add > > > - urn:invoke:conference:remove > > > > > > This one may be clearer due to the existence of xcon specs. > > > > > > Regarding action parameters: > > > > > > o media=3Daudio|video|audvid > > > > > > I'm troubled by audvid. I would rather see "audio,video". > Specifically, > > > what is the namespace here, and what does specifying it mean? I > think > > > the namespace could be: one or more values allowable as the > > > parameter in the m-line in SDP. > > > > > > Defining exactly what it means when present is a little harder. > When > > > answering a call that has an offer, I guess it could mean: refuse > any > > > m-lines with media type that doesn't match one of these, and accept > as > > > many of the remaining as you can. > > > > > > For answering an offerless invite, I guess it could mean: offer > > > whatever > > > media you are capable of offering that match one of these, but > don't > > > offer anything that doesn't match. > > > > > > Is there likely to be a need to get more specific? E.g. about what > > > codecs to use? (Hopefully not - that could get very messy.) > > > > > > o transducer=3Dspeaker|headset > > > > > > My deskphone has three possibilities: speaker|headset|handset. > > > And I'm far from certain this is exhaustive. (The clue wg is > defining a > > > much more complex environment.) This at least needs to be > extensible. > > > We > > > may need some sort of extended model of a UA that includes this > sort of > > > stuff. > > > > > > o target=3D > > > o direction=3Drecvonly|sendonly|sendrecv > > > o abort > > > > > > None of this is intended as objection to the work so far. Its just > a > > > start at identifying what else there is to do. The whole notion of > > > naming features to invoke causes me the most concern. > > > > > > Thanks, > > > Paul > > > > > > On 6/10/2011 3:08 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > > > Hi, > > > > > > > > We have just submitted a new version of the SIP INVOKE method > draft > > > that > > > > does not include implicit subscription. > > > > > > > > https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/ > > > > > > > > We would appreciate it if you review the document and provide us > with > > > > your feedback. > > > > > > > > Thanks, > > > > > > > > Rifaat > > > > > > > > > > > > > > > > _______________________________________________ > > > > splices mailing list > > > > splices@ietf.org > > > > https://www.ietf.org/mailman/listinfo/splices > > > _______________________________________________ > > > splices mailing list > > > splices@ietf.org > > > https://www.ietf.org/mailman/listinfo/splices > > _______________________________________________ > > splices mailing list > > splices@ietf.org > > https://www.ietf.org/mailman/listinfo/splices From dworley@avaya.com Tue Jun 14 10:36: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 7AD2311E80C6 for ; Tue, 14 Jun 2011 10:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.037 X-Spam-Level: X-Spam-Status: No, score=-102.037 tagged_above=-999 required=5 tests=[AWL=-1.471, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_XBL=3.033, 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 OomdmzAFTthk for ; Tue, 14 Jun 2011 10:36:13 -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 DF43011E818B for ; Tue, 14 Jun 2011 10:36:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALea903GmAcF/2dsb2JhbABSplN3iHOkWAKcBIYkBJY8iw8 X-IronPort-AV: E=Sophos;i="4.65,365,1304308800"; d="scan'208";a="284977083" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Jun 2011 13:36:11 -0400 X-IronPort-AV: E=Sophos;i="4.65,365,1304308800"; d="scan'208";a="632423671" 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; 14 Jun 2011 13:36:11 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Tue, 14 Jun 2011 13:36:10 -0400 From: "Worley, Dale R (Dale)" To: "Hutton, Andrew" , "Shekh-Yusef, Rifaat (Rifaat)" , Paul Kyzivat , "splices@ietf.org" Date: Tue, 14 Jun 2011 13:32:59 -0400 Thread-Topic: [splices] SIP INVOKE method v1 Thread-Index: AcwnpwHyWdPZ0GtcQdet0Lc+UVQPIgCJvnyQADiYGNAAANdDQAABWEfr Message-ID: References: <6369CB70BFD88942B9705AC1E639A33822CD81384C@DC-US1MBEX4.global.avaya.com> <4DF27461.8060204@cisco.com> <101C6067BEC68246B0C3F6843BCCC1E30C22977E6A@MCHP058A.global-ad.net> <6369CB70BFD88942B9705AC1E639A33822CDA812C4@DC-US1MBEX4.global.avaya.com>, <101C6067BEC68246B0C3F6843BCCC1E30C229785C2@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E30C229785C2@MCHP058A.global-ad.net> 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 v1 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, 14 Jun 2011 17:36:13 -0000 > From: Hutton, Andrew [andrew.hutton@siemens-enterprise.com] >=20 > The list of potential actions and associated parameters is huge and > for this kind of problem I believe that an XML body would be a much > better solution. I guess I much prefer XML to BNF. I'd feel much more comfortable if we settled on either: 1) a small number of actions 2) to use an appropriate subset of an existing CTI standard In the latter case, could someone provide a pointer to the standard? Essentially, INVOKE is to provide an interface to a command set, and we need to have some idea what the outer limits of the command set will be. Only then can we choose a good way to represent the commands within a SIP request. Dale From rifatyu@avaya.com Tue Jun 14 10:42: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 CDAB411E8192 for ; Tue, 14 Jun 2011 10:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.036 X-Spam-Level: X-Spam-Status: No, score=-3.036 tagged_above=-999 required=5 tests=[AWL=0.563, 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 N-iRBuuSqN4E for ; Tue, 14 Jun 2011 10:42: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 504AD11E8195 for ; Tue, 14 Jun 2011 10:42:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BAGKc902HCzI1/2dsb2JhbABSl0yPB3eIc6RQApwEhiQEljyLDw X-IronPort-AV: E=Sophos;i="4.65,365,1304308800"; d="scan'208";a="251336987" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Jun 2011 13:42:10 -0400 X-IronPort-AV: E=Sophos;i="4.65,365,1304308800"; d="scan'208";a="666075107" 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; 14 Jun 2011 13:42:09 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Tue, 14 Jun 2011 13:42:08 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: "Hutton, Andrew" , Paul Kyzivat , "splices@ietf.org" Date: Tue, 14 Jun 2011 13:42:08 -0400 Thread-Topic: [splices] SIP INVOKE method v1 Thread-Index: AcwnpwHyWdPZ0GtcQdet0Lc+UVQPIgCJvnyQADiYGNAAANdDQAABoVVg Message-ID: <6369CB70BFD88942B9705AC1E639A33822CDA8144A@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822CD81384C@DC-US1MBEX4.global.avaya.com> <4DF27461.8060204@cisco.com> <101C6067BEC68246B0C3F6843BCCC1E30C22977E6A@MCHP058A.global-ad.net> <6369CB70BFD88942B9705AC1E639A33822CDA812C4@DC-US1MBEX4.global.avaya.com> <101C6067BEC68246B0C3F6843BCCC1E30C229785C2@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E30C229785C2@MCHP058A.global-ad.net> 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 v1 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, 14 Jun 2011 17:42:13 -0000 Andy, > The list of potential actions and associated parameters is huge and for t= his > kind of problem I believe that an XML body would be a much better solutio= n. I > guess I much prefer XML to BNF. >=20 This actually calls for a header rather than an XML body, because the idea = is to control what get standardized and what not and clearly define the act= ions that get standardized. With an XML body you actually create a tunnel o= ver SIP and you lose control over what get defined. Regards, Rifaat > -----Original Message----- > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > Sent: Tuesday, June 14, 2011 1:18 PM > To: Shekh-Yusef, Rifaat (Rifaat); Paul Kyzivat; splices@ietf.org > Subject: RE: [splices] SIP INVOKE method v1 >=20 > Hi Rifaat, >=20 > I am not saying that the current proposal is not extensible but I believe= that > an XML body would be a much better solution to the extensibility problem = that > using a SIP header. >=20 > The list of potential actions and associated parameters is huge and for t= his > kind of problem I believe that an XML body would be a much better solutio= n. I > guess I much prefer XML to BNF. >=20 > There is also an architectural issue as the actions don't relate directly= to > the management of the SIP session and therefore most likely need to passe= d to > the application layer in the SIP UA to handle. It is much cleaner > architecturally if the body can simply be removed and passed to the > responsible component in the UA rather than the SIP component having to > extract the information from SIP headers. >=20 > Regards > Andy >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Shekh-Yusef, Rifaat (Rifaat) [mailto:rifatyu@avaya.com] > > Sent: 14 June 2011 17:32 > > To: Hutton, Andrew; Paul Kyzivat; splices@ietf.org > > Subject: RE: [splices] SIP INVOKE method v1 > > > > Andy, > > > > > The issue is I believe extensibility which any mechanism for > > > invoking services will need and this is the reason why an XML body > > would be > > > better than using SIP headers. > > > > What makes you think that the current proposal is not extensible? > > > > Regards, > > Rifaat > > > > > > > -----Original Message----- > > > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On > > Behalf Of > > > Hutton, Andrew > > > Sent: Monday, June 13, 2011 10:04 AM > > > To: Paul Kyzivat; splices@ietf.org > > > Subject: Re: [splices] SIP INVOKE method v1 > > > > > > Hi All, > > > > > > Whilst I still question whether the mechanism described in this draft > > actually > > > falls within the SPLICES WG charter as it defines new mechanism I > > have a few > > > comments. > > > > > > I tend to agree with Paul's comments below but would go further to > > say that > > > even some of the supposedly simply actions such as "decline" & > > "ignore" are > > > also features which will be difficult to agree the semantics for. All > > of the > > > actions will need to be specified rigorously a quick look at ECMA-269 > > which > > > specifies these kind of services for CSTA will give you an idea of > > what would > > > need to be done. I don't believe that even in the CSTA world which > > defines a > > > very large number of services the services "ignore" or "decline" were > > > specified. > > > > > > With regard to the discussion on headers vs body the draft states. > > > > > > "There has been some discussion on the list on the question of header > > field vs > > > message body. This is not the real issue, as either could > > conceivably be > > > used. Instead, the main issue is what is being invoked: is it a > > named > > > feature/action/event, or is it a script". > > > > > > I must have missed the discussion about scripting but I don't think > > this is > > > the issue. The issue is I believe extensibility which any mechanism > > for > > > invoking services will need and this is the reason why an XML body > > would be > > > better than using SIP headers. > > > > > > Regards > > > Andy > > > > > > > > > > -----Original Message----- > > > > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On > > > > Behalf Of Paul Kyzivat > > > > Sent: 10 June 2011 20:46 > > > > To: splices@ietf.org > > > > Subject: Re: [splices] SIP INVOKE method v1 > > > > > > > > This is getting better with age! > > > > > > > > Splitting off the subscription is good. > > > > > > > > An area that still needs work is in the semantics of the urns. > > > > Some of them are more clear than others. Some are "limited" in ways > > > > that > > > > might not matter to some but that could prove a problem in the end. > > > > Specifically: > > > > > > > > o Answer call - urn:invoke:call:answer > > > > o Terminate call - urn:invoke:call:terminate > > > > o Decline call - urn:invoke:call:decline > > > > o Ignore call - urn:invoke:call:ignore > > > > > > > > The above need some elaboration, but I think its just work - > > probably > > > > anybody who does it will end up with an equivalent result. > > > > > > > > o Send call to VM - urn:invoke:call:sendvm > > > > > > > > VM is a "feature", and we haven't standardized features much, > > except > > > > for > > > > bliss. How does one know if the recipient understands VM and what > > to do > > > > to send a call there? What if there are multiple VM options (e.g. > > what > > > > to say, etc.) And what if the call isn't a voice call. (Maybe VM > > now > > > > means voice/video mail. But the "call" could be IM.) > > > > > > > > o Hold call - urn:invoke:call:hold > > > > o Unhold call - urn:invoke:call:unhold > > > > o Mute call - urn:invoke:call:mute > > > > o Unmute call - urn:invoke:call:unmute > > > > > > > > Similarly these are all "features" that we all have some > > expectations > > > > about, but that are not rigorously defined. (But perhaps > > Mute/Unmute > > > > could be formalized by using the 'transducer' option. > > > > (Transducer=3Dnone?) > > > > > > > > My concern with all these "features" is that we are being put into > > a > > > > box > > > > where we must either: > > > > - define them with sufficient rigor > > > > - fall back on "do what I mean", which has proved to be a bad idea, > > > > because not everybody has the same notion of what they mean. > > > > > > > > o Conference - urn:invoke:conference:add > > > > - urn:invoke:conference:remove > > > > > > > > This one may be clearer due to the existence of xcon specs. > > > > > > > > Regarding action parameters: > > > > > > > > o media=3Daudio|video|audvid > > > > > > > > I'm troubled by audvid. I would rather see "audio,video". > > Specifically, > > > > what is the namespace here, and what does specifying it mean? I > > think > > > > the namespace could be: one or more values allowable as the > > > > parameter in the m-line in SDP. > > > > > > > > Defining exactly what it means when present is a little harder. > > When > > > > answering a call that has an offer, I guess it could mean: refuse > > any > > > > m-lines with media type that doesn't match one of these, and accept > > as > > > > many of the remaining as you can. > > > > > > > > For answering an offerless invite, I guess it could mean: offer > > > > whatever > > > > media you are capable of offering that match one of these, but > > don't > > > > offer anything that doesn't match. > > > > > > > > Is there likely to be a need to get more specific? E.g. about what > > > > codecs to use? (Hopefully not - that could get very messy.) > > > > > > > > o transducer=3Dspeaker|headset > > > > > > > > My deskphone has three possibilities: speaker|headset|handset. > > > > And I'm far from certain this is exhaustive. (The clue wg is > > defining a > > > > much more complex environment.) This at least needs to be > > extensible. > > > > We > > > > may need some sort of extended model of a UA that includes this > > sort of > > > > stuff. > > > > > > > > o target=3D > > > > o direction=3Drecvonly|sendonly|sendrecv > > > > o abort > > > > > > > > None of this is intended as objection to the work so far. Its just > > a > > > > start at identifying what else there is to do. The whole notion of > > > > naming features to invoke causes me the most concern. > > > > > > > > Thanks, > > > > Paul > > > > > > > > On 6/10/2011 3:08 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > > > > Hi, > > > > > > > > > > We have just submitted a new version of the SIP INVOKE method > > draft > > > > that > > > > > does not include implicit subscription. > > > > > > > > > > https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/ > > > > > > > > > > We would appreciate it if you review the document and provide us > > with > > > > > your feedback. > > > > > > > > > > Thanks, > > > > > > > > > > Rifaat > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > splices mailing list > > > > > splices@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/splices > > > > _______________________________________________ > > > > splices mailing list > > > > splices@ietf.org > > > > https://www.ietf.org/mailman/listinfo/splices > > > _______________________________________________ > > > splices mailing list > > > splices@ietf.org > > > https://www.ietf.org/mailman/listinfo/splices From alan.b.johnston@gmail.com Tue Jun 14 10:45:42 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 B1D1411E8192 for ; Tue, 14 Jun 2011 10:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 s0iZrX2YBmPY for ; Tue, 14 Jun 2011 10:45:42 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2A40711E8140 for ; Tue, 14 Jun 2011 10:45:41 -0700 (PDT) Received: by yie30 with SMTP id 30so2186851yie.31 for ; Tue, 14 Jun 2011 10:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sc/g9ouVnG3O3I23+SLL4DV5gSBOYoAsKPg4kna9R8g=; b=rS7Lj+D03vmrG/LwQofSJq1OJqy4tsPN8Wb1DTgOLzl4cdjzWD+94OLYnaz+fpCiLm FfKRZacj3M248+A4nUWr+AZZf0Z1GcyRqbJFvy8BNCde0x+BvJcAX0ryVZylf/5E7Npi CpBev8c/Hexq9TaVhYimeS7gLs3oOc0AgLQdg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Wpm8NPPD0+h04O6VUuvGOUoEYCTnWGof9hEdH1g/A9SSnJ7GRgECE9iUI4EOQTSUxp PNeVaHgjZybwG12q3YvVZkLlyyVbBPspW0kfjx5wRcRR5w9FQgGncUvax8jw/R1JYnxA 53JF8WcpVSAOj+e5nSwk53gmnyi7JzvCbns/0= MIME-Version: 1.0 Received: by 10.150.61.8 with SMTP id j8mr7867318yba.219.1308073541246; Tue, 14 Jun 2011 10:45:41 -0700 (PDT) Received: by 10.151.79.8 with HTTP; Tue, 14 Jun 2011 10:45:41 -0700 (PDT) In-Reply-To: References: <6369CB70BFD88942B9705AC1E639A33822CD81384C@DC-US1MBEX4.global.avaya.com> <4DF27461.8060204@cisco.com> <101C6067BEC68246B0C3F6843BCCC1E30C22977E6A@MCHP058A.global-ad.net> <6369CB70BFD88942B9705AC1E639A33822CDA812C4@DC-US1MBEX4.global.avaya.com> <101C6067BEC68246B0C3F6843BCCC1E30C229785C2@MCHP058A.global-ad.net> Date: Tue, 14 Jun 2011 12:45:41 -0500 Message-ID: From: Alan Johnston To: "Worley, Dale R (Dale)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "splices@ietf.org" Subject: Re: [splices] SIP INVOKE method v1 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, 14 Jun 2011 17:45:42 -0000 Andy, I agree with Dale that the set of actions should be small, otherwise, we are doing something else. Also, the set of parameters needs to be small. In fact, I think most actions won't have any parameters at all. This is why we are using URNs, just names, for the actions. To do otherwise is to introduce complex actions or scripts, and I don't want this mechanism to be used for that. There are other mechanisms (e.g. CPL) that allows a script to be uploaded or downloaded to control a UA or proxy operation, but that is very different from what we are talking about here. I agree that we could discuss BNF vs XML, but if we agree that we really are dealing with URNs, then a header makes more sense than a body. - Alan - On Tue, Jun 14, 2011 at 12:32 PM, Worley, Dale R (Dale) wrote: >> From: Hutton, Andrew [andrew.hutton@siemens-enterprise.com] >> >> The list of potential actions and associated parameters is huge and >> for this kind of problem I believe that an XML body would be a much >> better solution. I guess I much prefer XML to BNF. > > I'd feel much more comfortable if we settled on either: > > 1) a small number of actions > > 2) to use an appropriate subset of an existing CTI standard > > In the latter case, could someone provide a pointer to the standard? > > Essentially, INVOKE is to provide an interface to a command set, and > we need to have some idea what the outer limits of the command set > will be. =A0Only then can we choose a good way to represent the commands > within a SIP request. > > Dale > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices > From andrew.hutton@siemens-enterprise.com Tue Jun 14 11:13: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 92C0921F8541 for ; Tue, 14 Jun 2011 11:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDd5dyAAKuaT for ; Tue, 14 Jun 2011 11:13:16 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id F159F21F8540 for ; Tue, 14 Jun 2011 11:13:15 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: andrew.hutton@siemens-enterprise.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1308075186!43421876!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 26042 invoked from network); 14 Jun 2011 18:13:06 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-10.tower-21.messagelabs.com with SMTP; 14 Jun 2011 18:13:06 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 4C70623F03E6; Tue, 14 Jun 2011 20:13:14 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 14 Jun 2011 20:13:14 +0200 From: "Hutton, Andrew" To: "Worley, Dale R (Dale)" , "Shekh-Yusef, Rifaat (Rifaat)" , Paul Kyzivat , "splices@ietf.org" Date: Tue, 14 Jun 2011 20:13:12 +0200 Thread-Topic: [splices] SIP INVOKE method v1 Thread-Index: AcwnpwHyWdPZ0GtcQdet0Lc+UVQPIgCJvnyQADiYGNAAANdDQAABWEfrAAFc1lA= Message-ID: <101C6067BEC68246B0C3F6843BCCC1E30C229785F5@MCHP058A.global-ad.net> References: <6369CB70BFD88942B9705AC1E639A33822CD81384C@DC-US1MBEX4.global.avaya.com> <4DF27461.8060204@cisco.com> <101C6067BEC68246B0C3F6843BCCC1E30C22977E6A@MCHP058A.global-ad.net> <6369CB70BFD88942B9705AC1E639A33822CDA812C4@DC-US1MBEX4.global.avaya.com>, <101C6067BEC68246B0C3F6843BCCC1E30C229785C2@MCHP058A.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [splices] SIP INVOKE method v1 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, 14 Jun 2011 18:13:17 -0000 Hi Dale, I think the problem is that we don't have any specified requirements so we = don't know what the boundaries are.=20 What has been specified so far already looks like it is trying to do CTI ty= pe things and for that we know the list of possible services is endless. Th= e most relevant standards would probably be ECMA-269 and ECMA-323 (http://w= ww.ecma-international.org/publications/standards/Ecma-323.htm) if you want = to see the XML for this. I don't see how it is really possibly to limit this to a small set of actio= ns as once the mechanism is implemented there will always be requirements t= o add more actions. Regards Andy > -----Original Message----- > From: Worley, Dale R (Dale) [mailto:dworley@avaya.com] > Sent: 14 June 2011 18:33 > To: Hutton, Andrew; Shekh-Yusef, Rifaat (Rifaat); Paul Kyzivat; > splices@ietf.org > Subject: RE: [splices] SIP INVOKE method v1 >=20 > > From: Hutton, Andrew [andrew.hutton@siemens-enterprise.com] > > > > The list of potential actions and associated parameters is huge and > > for this kind of problem I believe that an XML body would be a much > > better solution. I guess I much prefer XML to BNF. >=20 > I'd feel much more comfortable if we settled on either: >=20 > 1) a small number of actions >=20 > 2) to use an appropriate subset of an existing CTI standard >=20 > In the latter case, could someone provide a pointer to the standard? >=20 > Essentially, INVOKE is to provide an interface to a command set, and > we need to have some idea what the outer limits of the command set > will be. Only then can we choose a good way to represent the commands > within a SIP request. >=20 > Dale From andrew.hutton@siemens-enterprise.com Tue Jun 14 11:25:47 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 22B8211E8173 for ; Tue, 14 Jun 2011 11:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRgCnFENQleT for ; Tue, 14 Jun 2011 11:25:46 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 894BB11E8161 for ; Tue, 14 Jun 2011 11:25:45 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: andrew.hutton@siemens-enterprise.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1308075942!23126004!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 9776 invoked from network); 14 Jun 2011 18:25:42 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-7.tower-174.messagelabs.com with SMTP; 14 Jun 2011 18:25:42 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 6BEA223F03E6; Tue, 14 Jun 2011 20:25:42 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 14 Jun 2011 20:25:42 +0200 From: "Hutton, Andrew" To: Alan Johnston , "Worley, Dale R (Dale)" Date: Tue, 14 Jun 2011 20:25:41 +0200 Thread-Topic: [splices] SIP INVOKE method v1 Thread-Index: AcwquuIIfJIWYY42QEKXIUwHId5ynQAA4lkw Message-ID: <101C6067BEC68246B0C3F6843BCCC1E30C229785FF@MCHP058A.global-ad.net> References: <6369CB70BFD88942B9705AC1E639A33822CD81384C@DC-US1MBEX4.global.avaya.com> <4DF27461.8060204@cisco.com> <101C6067BEC68246B0C3F6843BCCC1E30C22977E6A@MCHP058A.global-ad.net> <6369CB70BFD88942B9705AC1E639A33822CDA812C4@DC-US1MBEX4.global.avaya.com> <101C6067BEC68246B0C3F6843BCCC1E30C229785C2@MCHP058A.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "splices@ietf.org" Subject: Re: [splices] SIP INVOKE method v1 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, 14 Jun 2011 18:25:47 -0000 Hi Alan, Might be nice to keep it to a small set but I an not convinced it is possib= le and most actions will need parameters when you consider different media = types, audio devices etc. and even simple actions like call terminate will = almost certainly need a reason code. Regards Andy > -----Original Message----- > From: Alan Johnston [mailto:alan.b.johnston@gmail.com] > Sent: 14 June 2011 18:46 > To: Worley, Dale R (Dale) > Cc: Hutton, Andrew; Shekh-Yusef, Rifaat (Rifaat); Paul Kyzivat; > splices@ietf.org > Subject: Re: [splices] SIP INVOKE method v1 >=20 > Andy, >=20 > I agree with Dale that the set of actions should be small, otherwise, > we are doing something else. Also, the set of parameters needs to be > small. In fact, I think most actions won't have any parameters at > all. This is why we are using URNs, just names, for the actions. >=20 > To do otherwise is to introduce complex actions or scripts, and I > don't want this mechanism to be used for that. There are other > mechanisms (e.g. CPL) that allows a script to be uploaded or > downloaded to control a UA or proxy operation, but that is very > different from what we are talking about here. >=20 > I agree that we could discuss BNF vs XML, but if we agree that we > really are dealing with URNs, then a header makes more sense than a > body. >=20 > - Alan - >=20 > On Tue, Jun 14, 2011 at 12:32 PM, Worley, Dale R (Dale) > wrote: > >> From: Hutton, Andrew [andrew.hutton@siemens-enterprise.com] > >> > >> The list of potential actions and associated parameters is huge and > >> for this kind of problem I believe that an XML body would be a much > >> better solution. I guess I much prefer XML to BNF. > > > > I'd feel much more comfortable if we settled on either: > > > > 1) a small number of actions > > > > 2) to use an appropriate subset of an existing CTI standard > > > > In the latter case, could someone provide a pointer to the standard? > > > > Essentially, INVOKE is to provide an interface to a command set, and > > we need to have some idea what the outer limits of the command set > > will be. =A0Only then can we choose a good way to represent the > commands > > within a SIP request. > > > > Dale > > _______________________________________________ > > splices mailing list > > splices@ietf.org > > https://www.ietf.org/mailman/listinfo/splices > > From dworley@avaya.com Tue Jun 14 11:39:15 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 6DCC511E812E for ; Tue, 14 Jun 2011 11:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.931 X-Spam-Level: X-Spam-Status: No, score=-102.931 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, 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 BwsjmRaGxxov for ; Tue, 14 Jun 2011 11:39:14 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD4211E8072 for ; Tue, 14 Jun 2011 11:39:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOqp902HCzI1/2dsb2JhbABSplN3rVwCm32GJASWPIsP X-IronPort-AV: E=Sophos;i="4.65,366,1304308800"; d="scan'208";a="193426600" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 14 Jun 2011 14:39:05 -0400 X-IronPort-AV: E=Sophos;i="4.65,366,1304308800"; d="scan'208";a="666095061" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 14 Jun 2011 14:38:45 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Tue, 14 Jun 2011 14:38:44 -0400 From: "Worley, Dale R (Dale)" To: "Hutton, Andrew" , "Shekh-Yusef, Rifaat (Rifaat)" , Paul Kyzivat , "splices@ietf.org" Date: Tue, 14 Jun 2011 14:35:48 -0400 Thread-Topic: [splices] SIP INVOKE method v1 Thread-Index: AcwnpwHyWdPZ0GtcQdet0Lc+UVQPIgCJvnyQADiYGNAAANdDQAABWEfrAAFc1lAAANTSAw== Message-ID: References: <6369CB70BFD88942B9705AC1E639A33822CD81384C@DC-US1MBEX4.global.avaya.com> <4DF27461.8060204@cisco.com> <101C6067BEC68246B0C3F6843BCCC1E30C22977E6A@MCHP058A.global-ad.net> <6369CB70BFD88942B9705AC1E639A33822CDA812C4@DC-US1MBEX4.global.avaya.com>, <101C6067BEC68246B0C3F6843BCCC1E30C229785C2@MCHP058A.global-ad.net> , <101C6067BEC68246B0C3F6843BCCC1E30C229785F5@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E30C229785F5@MCHP058A.global-ad.net> 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 v1 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, 14 Jun 2011 18:39:15 -0000 ________________________________________ From: Hutton, Andrew [andrew.hutton@siemens-enterprise.com] I think the problem is that we don't have any specified requirements so we = don't know what the boundaries are. What has been specified so far already looks like it is trying to do CTI ty= pe things and for that we know the list of possible services is endless. Th= e most relevant standards would probably be ECMA-269 and ECMA-323 (http://w= ww.ecma-international.org/publications/standards/Ecma-323.htm) if you want = to see the XML for this. I don't see how it is really possibly to limit this to a small set of actio= ns as once the mechanism is implemented there will always be requirements t= o add more actions. ________________________________________ Thanks for those references! Yes, there is a real scope-creep problem. Looking at ECMA-323, I see 45 "C= all control services and events", and that is not the majority of the defin= ed operations. One possibility would be to define INVOKE as a carrier for ECMA-323 operati= ons. But even then, a lot of care needs to be taken to see how to embed th= e dataflow model of ECMA-323 into the SIP request/response structure. If w= e define our own CTI set, we have to create our own dataflow model. Dale From pkyzivat@cisco.com Tue Jun 14 12:56:07 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 152BE1F0C56 for ; Tue, 14 Jun 2011 12:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.404 X-Spam-Level: X-Spam-Status: No, score=-110.404 tagged_above=-999 required=5 tests=[AWL=0.195, 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 l8nUo18VlyLj for ; Tue, 14 Jun 2011 12:56:06 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by ietfa.amsl.com (Postfix) with ESMTP id DB0281F0C55 for ; Tue, 14 Jun 2011 12:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=4071; q=dns/txt; s=iport; t=1308081365; x=1309290965; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=JQ1naa317M/+TBoM1NmvOR2v8Xg2wMjB6LkoQmvI/UA=; b=KKbJSUVDA2Ixl6X4jAwlyWeMxFRKHvd9OX9GZgMTbqH4VAMgWvtVHZG9 H9k0YAA9xgNQUcJZCdhqoiPcO6eEVHO/+GBevsy6RGESS9XPiTtbeWq3U 2jezidZASgKwrgcSg12SDXc+rhqYP0H1bz7ydfTl5pnkfCU2opEzyt0/n k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADW8902tJV2c/2dsb2JhbABSplR3qmyeQ4YkBJFIhFeEQYZr X-IronPort-AV: E=Sophos;i="4.65,366,1304294400"; d="scan'208";a="236355709" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 14 Jun 2011 19:56:04 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p5EJu3Kx023338; Tue, 14 Jun 2011 19:56:04 GMT Message-ID: <4DF7BCD3.7050804@cisco.com> Date: Tue, 14 Jun 2011 15:56:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Hutton, Andrew" References: <6369CB70BFD88942B9705AC1E639A33822CD81384C@DC-US1MBEX4.global.avaya.com> <4DF27461.8060204@cisco.com> <101C6067BEC68246B0C3F6843BCCC1E30C22977E6A@MCHP058A.global-ad.net> <6369CB70BFD88942B9705AC1E639A33822CDA812C4@DC-US1MBEX4.global.avaya.com> <101C6067BEC68246B0C3F6843BCCC1E30C229785C2@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E30C229785FF@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E30C229785FF@MCHP058A.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "splices@ietf.org" Subject: Re: [splices] SIP INVOKE method v1 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, 14 Jun 2011 19:56:07 -0000 I'm with Dale that we need to scope the command set, or equivalently, scope the environment that is being manipulated and the degrees of freedom that it has. If it isn't "small" then it at least needs to be characterized. And the larger it is the bigger a deal the work is. So its important to figure it out. The mechanism to convey the commands is secondary to that. For instance (as I have mentioned before in passing), if the scope includes "call control" in the sip sense, including o/a, then it becomes a very big deal unless we can reuse sip for it. We really don't want to define something new and different from sip that is functionally equivalent to sip. My expectation is that we are talking about something at a higher level of abstraction than SIP. But being at a higher level doesn't mean "vague". And while it almost certainly needs to be extensible for things we don't consider at first, IMO that doesn't mean we should define a mechanism with no intrinsic functionality, just an extension mechanism. That is a guarantee we will get it wrong. We can look to CSTA or one or more definitions of CTI. I did investigate CSTA once, and didn't love it. But if it comes close to the needs here we might consider adopting it. I don't know much about CTI, but my impression is that it is a buzz word with many only loosely related instantiations, and is predicated on different architectural models than will work for us. (But I'll be pleased to be educated by somebody who really knows.) Thanks, Paul On 6/14/2011 2:25 PM, Hutton, Andrew wrote: > Hi Alan, > > Might be nice to keep it to a small set but I an not convinced it is possible and most actions will need parameters when you consider different media types, audio devices etc. and even simple actions like call terminate will almost certainly need a reason code. > > Regards > Andy > > >> -----Original Message----- >> From: Alan Johnston [mailto:alan.b.johnston@gmail.com] >> Sent: 14 June 2011 18:46 >> To: Worley, Dale R (Dale) >> Cc: Hutton, Andrew; Shekh-Yusef, Rifaat (Rifaat); Paul Kyzivat; >> splices@ietf.org >> Subject: Re: [splices] SIP INVOKE method v1 >> >> Andy, >> >> I agree with Dale that the set of actions should be small, otherwise, >> we are doing something else. Also, the set of parameters needs to be >> small. In fact, I think most actions won't have any parameters at >> all. This is why we are using URNs, just names, for the actions. >> >> To do otherwise is to introduce complex actions or scripts, and I >> don't want this mechanism to be used for that. There are other >> mechanisms (e.g. CPL) that allows a script to be uploaded or >> downloaded to control a UA or proxy operation, but that is very >> different from what we are talking about here. >> >> I agree that we could discuss BNF vs XML, but if we agree that we >> really are dealing with URNs, then a header makes more sense than a >> body. >> >> - Alan - >> >> On Tue, Jun 14, 2011 at 12:32 PM, Worley, Dale R (Dale) >> wrote: >>>> From: Hutton, Andrew [andrew.hutton@siemens-enterprise.com] >>>> >>>> The list of potential actions and associated parameters is huge and >>>> for this kind of problem I believe that an XML body would be a much >>>> better solution. I guess I much prefer XML to BNF. >>> >>> I'd feel much more comfortable if we settled on either: >>> >>> 1) a small number of actions >>> >>> 2) to use an appropriate subset of an existing CTI standard >>> >>> In the latter case, could someone provide a pointer to the standard? >>> >>> Essentially, INVOKE is to provide an interface to a command set, and >>> we need to have some idea what the outer limits of the command set >>> will be. Only then can we choose a good way to represent the >> commands >>> within a SIP request. >>> >>> Dale >>> _______________________________________________ >>> splices mailing list >>> splices@ietf.org >>> https://www.ietf.org/mailman/listinfo/splices >>> > From musgravepj@gmail.com Tue Jun 14 15:31:22 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 99C661F0C6B for ; Tue, 14 Jun 2011 15:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 1nNcohGYSlrD for ; Tue, 14 Jun 2011 15:31:22 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA4A21F0C61 for ; Tue, 14 Jun 2011 15:31:21 -0700 (PDT) Received: by vxg33 with SMTP id 33so6990373vxg.31 for ; Tue, 14 Jun 2011 15:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=cnGA556OCTATnbusm++P1ovNHkQtcKXWukld1f8cPB4=; b=rRexzhm0+jaTX/DemyhxXXgsANcT/QpDTb9JYx7gu2NTa5YBWNF1AXqHbOlfjt2wLm MheyDkvZGRbCyvYflMf3fqDTb36z6Iyw2L0nSZ/MSLCOayYFfrrVN8pZbY29J8f+0+7z 2slP2TboeF/Un25OGXGMqzPZIxa9vOSlyTR6o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=qlmSXNYR9kbyiL4/E0xIMgafZP+2OpOPQI/BQVTmZyOWEdgOKFd3SDI0ahrfOZFBpI wY31okoaHGXTFG2lv+esJDTa2JNM6ISvWVi8ES4SXn2kPn/7ion2EkSsvILYsOOAfabY TMhGAVaQYwjiAlf0rpcrJQEXbAJGkKNFfu2o8= Received: by 10.52.73.9 with SMTP id h9mr528950vdv.208.1308090680099; Tue, 14 Jun 2011 15:31:20 -0700 (PDT) Received: from [192.168.1.101] ([204.237.32.134]) by mx.google.com with ESMTPS id du6sm1109286vdb.21.2011.06.14.15.31.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Jun 2011 15:31:19 -0700 (PDT) References: <6369CB70BFD88942B9705AC1E639A33822CD81384C@DC-US1MBEX4.global.avaya.com> <4DF27461.8060204@cisco.com> <101C6067BEC68246B0C3F6843BCCC1E30C22977E6A@MCHP058A.global-ad.net> <6369CB70BFD88942B9705AC1E639A33822CDA812C4@DC-US1MBEX4.global.avaya.com> <101C6067BEC68246B0C3F6843BCCC1E30C229785C2@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E30C229785FF@MCHP058A.global-ad.net> <4DF7BCD3.7050804@cisco.com> In-Reply-To: <4DF7BCD3.7050804@cisco.com> Mime-Version: 1.0 (iPad Mail 8J3) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (8J3) From: Peter Musgrave Date: Tue, 14 Jun 2011 18:31:07 -0400 To: Paul Kyzivat Cc: "splices@ietf.org" Subject: Re: [splices] SIP INVOKE method v1 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, 14 Jun 2011 22:31:22 -0000 I agree too. I also thought CSTA was a bit too "kitchen sink" when I looked at it years a= go. But perhaps we can use it to guide a very modest subset? It has at least= looked at a very similar problem space so there should be lessens learned t= here... Peter Sent from my iPad On 2011-06-14, at 3:56 PM, Paul Kyzivat wrote: > I'm with Dale that we need to scope the command set, > or equivalently, scope the environment that is being manipulated and the d= egrees of freedom that it has. >=20 > If it isn't "small" then it at least needs to be characterized. And the la= rger it is the bigger a deal the work is. So its important to figure it out.= The mechanism to convey the commands is secondary to that. >=20 > For instance (as I have mentioned before in passing), if the scope include= s "call control" in the sip sense, including o/a, then it becomes a very big= deal unless we can reuse sip for it. We really don't want to define somethi= ng new and different from sip that is functionally equivalent to sip. >=20 > My expectation is that we are talking about something at a higher level of= abstraction than SIP. But being at a higher level doesn't mean "vague". And= while it almost certainly needs to be extensible for things we don't consid= er at first, IMO that doesn't mean we should define a mechanism with no intr= insic functionality, just an extension mechanism. That is a guarantee we wil= l get it wrong. >=20 > We can look to CSTA or one or more definitions of CTI. I did investigate C= STA once, and didn't love it. But if it comes close to the needs here we mig= ht consider adopting it. I don't know much about CTI, but my impression is t= hat it is a buzz word with many only loosely related instantiations, and is p= redicated on different architectural models than will work for us. (But I'll= be pleased to be educated by somebody who really knows.) >=20 > Thanks, > Paul >=20 > On 6/14/2011 2:25 PM, Hutton, Andrew wrote: >> Hi Alan, >>=20 >> Might be nice to keep it to a small set but I an not convinced it is poss= ible and most actions will need parameters when you consider different media= types, audio devices etc. and even simple actions like call terminate will a= lmost certainly need a reason code. >>=20 >> Regards >> Andy >>=20 >>=20 >>> -----Original Message----- >>> From: Alan Johnston [mailto:alan.b.johnston@gmail.com] >>> Sent: 14 June 2011 18:46 >>> To: Worley, Dale R (Dale) >>> Cc: Hutton, Andrew; Shekh-Yusef, Rifaat (Rifaat); Paul Kyzivat; >>> splices@ietf.org >>> Subject: Re: [splices] SIP INVOKE method v1 >>>=20 >>> Andy, >>>=20 >>> I agree with Dale that the set of actions should be small, otherwise, >>> we are doing something else. Also, the set of parameters needs to be >>> small. In fact, I think most actions won't have any parameters at >>> all. This is why we are using URNs, just names, for the actions. >>>=20 >>> To do otherwise is to introduce complex actions or scripts, and I >>> don't want this mechanism to be used for that. There are other >>> mechanisms (e.g. CPL) that allows a script to be uploaded or >>> downloaded to control a UA or proxy operation, but that is very >>> different from what we are talking about here. >>>=20 >>> I agree that we could discuss BNF vs XML, but if we agree that we >>> really are dealing with URNs, then a header makes more sense than a >>> body. >>>=20 >>> - Alan - >>>=20 >>> On Tue, Jun 14, 2011 at 12:32 PM, Worley, Dale R (Dale) >>> wrote: >>>>> From: Hutton, Andrew [andrew.hutton@siemens-enterprise.com] >>>>>=20 >>>>> The list of potential actions and associated parameters is huge and >>>>> for this kind of problem I believe that an XML body would be a much >>>>> better solution. I guess I much prefer XML to BNF. >>>>=20 >>>> I'd feel much more comfortable if we settled on either: >>>>=20 >>>> 1) a small number of actions >>>>=20 >>>> 2) to use an appropriate subset of an existing CTI standard >>>>=20 >>>> In the latter case, could someone provide a pointer to the standard? >>>>=20 >>>> Essentially, INVOKE is to provide an interface to a command set, and >>>> we need to have some idea what the outer limits of the command set >>>> will be. Only then can we choose a good way to represent the >>> commands >>>> within a SIP request. >>>>=20 >>>> Dale >>>> _______________________________________________ >>>> splices mailing list >>>> splices@ietf.org >>>> https://www.ietf.org/mailman/listinfo/splices >>>>=20 >>=20 > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices From andrew.hutton@siemens-enterprise.com Wed Jun 15 02:01:45 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 06E081F0C40 for ; Wed, 15 Jun 2011 02:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvryfSWL5MgU for ; Wed, 15 Jun 2011 02:01:44 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 4C8ED1F0C35 for ; Wed, 15 Jun 2011 02:01:43 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: andrew.hutton@siemens-enterprise.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1308128492!34971616!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 15919 invoked from network); 15 Jun 2011 09:01:32 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-5.tower-27.messagelabs.com with SMTP; 15 Jun 2011 09:01:32 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 0708023F03E6; Wed, 15 Jun 2011 11:01:42 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 15 Jun 2011 11:01:42 +0200 From: "Hutton, Andrew" To: "Shekh-Yusef, Rifaat (Rifaat)" , Paul Kyzivat , "splices@ietf.org" Date: Wed, 15 Jun 2011 11:01:38 +0200 Thread-Topic: [splices] SIP INVOKE method v1 Thread-Index: AcwnpwHyWdPZ0GtcQdet0Lc+UVQPIgCJvnyQADiYGNAAANdDQAABoVVgAB/pxSA= Message-ID: <101C6067BEC68246B0C3F6843BCCC1E30C22978813@MCHP058A.global-ad.net> References: <6369CB70BFD88942B9705AC1E639A33822CD81384C@DC-US1MBEX4.global.avaya.com> <4DF27461.8060204@cisco.com> <101C6067BEC68246B0C3F6843BCCC1E30C22977E6A@MCHP058A.global-ad.net> <6369CB70BFD88942B9705AC1E639A33822CDA812C4@DC-US1MBEX4.global.avaya.com> <101C6067BEC68246B0C3F6843BCCC1E30C229785C2@MCHP058A.global-ad.net> <6369CB70BFD88942B9705AC1E639A33822CDA8144A@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CDA8144A@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 v1 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, 15 Jun 2011 09:01:45 -0000 Hi Rifaat, I don't understand the argument as the header/body issue makes no differenc= e to what gets standardized and architecturally it is much cleaner to tunne= l the non SIP related application stuff in a body that to use a SIP header = for the same purpose. Having said that I still don't think that either mechanism would fall withi= n the SPLICES charter. Regards Andy > -----Original Message----- > From: Shekh-Yusef, Rifaat (Rifaat) [mailto:rifatyu@avaya.com] > Sent: 14 June 2011 18:42 > To: Hutton, Andrew; Paul Kyzivat; splices@ietf.org > Subject: RE: [splices] SIP INVOKE method v1 >=20 > Andy, >=20 > > The list of potential actions and associated parameters is huge and > for this > > kind of problem I believe that an XML body would be a much better > solution. I > > guess I much prefer XML to BNF. > > > This actually calls for a header rather than an XML body, because the > idea is to control what get standardized and what not and clearly > define the actions that get standardized. With an XML body you actually > create a tunnel over SIP and you lose control over what get defined. >=20 > Regards, > Rifaat >=20 >=20 > > -----Original Message----- > > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > > Sent: Tuesday, June 14, 2011 1:18 PM > > To: Shekh-Yusef, Rifaat (Rifaat); Paul Kyzivat; splices@ietf.org > > Subject: RE: [splices] SIP INVOKE method v1 > > > > Hi Rifaat, > > > > I am not saying that the current proposal is not extensible but I > believe that > > an XML body would be a much better solution to the extensibility > problem that > > using a SIP header. > > > > The list of potential actions and associated parameters is huge and > for this > > kind of problem I believe that an XML body would be a much better > solution. I > > guess I much prefer XML to BNF. > > > > There is also an architectural issue as the actions don't relate > directly to > > the management of the SIP session and therefore most likely need to > passed to > > the application layer in the SIP UA to handle. It is much cleaner > > architecturally if the body can simply be removed and passed to the > > responsible component in the UA rather than the SIP component having > to > > extract the information from SIP headers. > > > > Regards > > Andy > > > > > > > > > > > -----Original Message----- > > > From: Shekh-Yusef, Rifaat (Rifaat) [mailto:rifatyu@avaya.com] > > > Sent: 14 June 2011 17:32 > > > To: Hutton, Andrew; Paul Kyzivat; splices@ietf.org > > > Subject: RE: [splices] SIP INVOKE method v1 > > > > > > Andy, > > > > > > > The issue is I believe extensibility which any mechanism for > > > > invoking services will need and this is the reason why an XML > body > > > would be > > > > better than using SIP headers. > > > > > > What makes you think that the current proposal is not extensible? > > > > > > Regards, > > > Rifaat > > > > > > > > > > -----Original Message----- > > > > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] > On > > > Behalf Of > > > > Hutton, Andrew > > > > Sent: Monday, June 13, 2011 10:04 AM > > > > To: Paul Kyzivat; splices@ietf.org > > > > Subject: Re: [splices] SIP INVOKE method v1 > > > > > > > > Hi All, > > > > > > > > Whilst I still question whether the mechanism described in this > draft > > > actually > > > > falls within the SPLICES WG charter as it defines new mechanism I > > > have a few > > > > comments. > > > > > > > > I tend to agree with Paul's comments below but would go further > to > > > say that > > > > even some of the supposedly simply actions such as "decline" & > > > "ignore" are > > > > also features which will be difficult to agree the semantics for. > All > > > of the > > > > actions will need to be specified rigorously a quick look at > ECMA-269 > > > which > > > > specifies these kind of services for CSTA will give you an idea > of > > > what would > > > > need to be done. I don't believe that even in the CSTA world > which > > > defines a > > > > very large number of services the services "ignore" or "decline" > were > > > > specified. > > > > > > > > With regard to the discussion on headers vs body the draft > states. > > > > > > > > "There has been some discussion on the list on the question of > header > > > field vs > > > > message body. This is not the real issue, as either could > > > conceivably be > > > > used. Instead, the main issue is what is being invoked: is it a > > > named > > > > feature/action/event, or is it a script". > > > > > > > > I must have missed the discussion about scripting but I don't > think > > > this is > > > > the issue. The issue is I believe extensibility which any > mechanism > > > for > > > > invoking services will need and this is the reason why an XML > body > > > would be > > > > better than using SIP headers. > > > > > > > > Regards > > > > Andy > > > > > > > > > > > > > -----Original Message----- > > > > > From: splices-bounces@ietf.org [mailto:splices- > bounces@ietf.org] On > > > > > Behalf Of Paul Kyzivat > > > > > Sent: 10 June 2011 20:46 > > > > > To: splices@ietf.org > > > > > Subject: Re: [splices] SIP INVOKE method v1 > > > > > > > > > > This is getting better with age! > > > > > > > > > > Splitting off the subscription is good. > > > > > > > > > > An area that still needs work is in the semantics of the urns. > > > > > Some of them are more clear than others. Some are "limited" in > ways > > > > > that > > > > > might not matter to some but that could prove a problem in the > end. > > > > > Specifically: > > > > > > > > > > o Answer call - urn:invoke:call:answer > > > > > o Terminate call - urn:invoke:call:terminate > > > > > o Decline call - urn:invoke:call:decline > > > > > o Ignore call - urn:invoke:call:ignore > > > > > > > > > > The above need some elaboration, but I think its just work - > > > probably > > > > > anybody who does it will end up with an equivalent result. > > > > > > > > > > o Send call to VM - urn:invoke:call:sendvm > > > > > > > > > > VM is a "feature", and we haven't standardized features much, > > > except > > > > > for > > > > > bliss. How does one know if the recipient understands VM and > what > > > to do > > > > > to send a call there? What if there are multiple VM options > (e.g. > > > what > > > > > to say, etc.) And what if the call isn't a voice call. (Maybe > VM > > > now > > > > > means voice/video mail. But the "call" could be IM.) > > > > > > > > > > o Hold call - urn:invoke:call:hold > > > > > o Unhold call - urn:invoke:call:unhold > > > > > o Mute call - urn:invoke:call:mute > > > > > o Unmute call - urn:invoke:call:unmute > > > > > > > > > > Similarly these are all "features" that we all have some > > > expectations > > > > > about, but that are not rigorously defined. (But perhaps > > > Mute/Unmute > > > > > could be formalized by using the 'transducer' option. > > > > > (Transducer=3Dnone?) > > > > > > > > > > My concern with all these "features" is that we are being put > into > > > a > > > > > box > > > > > where we must either: > > > > > - define them with sufficient rigor > > > > > - fall back on "do what I mean", which has proved to be a bad > idea, > > > > > because not everybody has the same notion of what they mean. > > > > > > > > > > o Conference - urn:invoke:conference:add > > > > > - urn:invoke:conference:remove > > > > > > > > > > This one may be clearer due to the existence of xcon specs. > > > > > > > > > > Regarding action parameters: > > > > > > > > > > o media=3Daudio|video|audvid > > > > > > > > > > I'm troubled by audvid. I would rather see "audio,video". > > > Specifically, > > > > > what is the namespace here, and what does specifying it mean? I > > > think > > > > > the namespace could be: one or more values allowable as the > > > > > > parameter in the m-line in SDP. > > > > > > > > > > Defining exactly what it means when present is a little harder. > > > When > > > > > answering a call that has an offer, I guess it could mean: > refuse > > > any > > > > > m-lines with media type that doesn't match one of these, and > accept > > > as > > > > > many of the remaining as you can. > > > > > > > > > > For answering an offerless invite, I guess it could mean: offer > > > > > whatever > > > > > media you are capable of offering that match one of these, but > > > don't > > > > > offer anything that doesn't match. > > > > > > > > > > Is there likely to be a need to get more specific? E.g. about > what > > > > > codecs to use? (Hopefully not - that could get very messy.) > > > > > > > > > > o transducer=3Dspeaker|headset > > > > > > > > > > My deskphone has three possibilities: speaker|headset|handset. > > > > > And I'm far from certain this is exhaustive. (The clue wg is > > > defining a > > > > > much more complex environment.) This at least needs to be > > > extensible. > > > > > We > > > > > may need some sort of extended model of a UA that includes this > > > sort of > > > > > stuff. > > > > > > > > > > o target=3D > > > > > o direction=3Drecvonly|sendonly|sendrecv > > > > > o abort > > > > > > > > > > None of this is intended as objection to the work so far. Its > just > > > a > > > > > start at identifying what else there is to do. The whole notion > of > > > > > naming features to invoke causes me the most concern. > > > > > > > > > > Thanks, > > > > > Paul > > > > > > > > > > On 6/10/2011 3:08 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > > > > > Hi, > > > > > > > > > > > > We have just submitted a new version of the SIP INVOKE method > > > draft > > > > > that > > > > > > does not include implicit subscription. > > > > > > > > > > > > https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/ > > > > > > > > > > > > We would appreciate it if you review the document and provide > us > > > with > > > > > > your feedback. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Rifaat > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > splices mailing list > > > > > > splices@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/splices > > > > > _______________________________________________ > > > > > splices mailing list > > > > > splices@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/splices > > > > _______________________________________________ > > > > splices mailing list > > > > splices@ietf.org > > > > https://www.ietf.org/mailman/listinfo/splices From R.Jesske@telekom.de Thu Jun 16 01:52: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 CB99211E818F for ; Thu, 16 Jun 2011 01:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 QnmXxHE8MwwT for ; Thu, 16 Jun 2011 01:52:10 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 6637611E8184 for ; Thu, 16 Jun 2011 01:52:09 -0700 (PDT) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 16 Jun 2011 10:50:51 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.233]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 16 Jun 2011 10:50:51 +0200 From: To: , , , , Date: Thu, 16 Jun 2011 10:50:50 +0200 Thread-Topic: [splices] SIP INVOKE method v1 Thread-Index: AcwnpwHyWdPZ0GtcQdet0Lc+UVQPIgCJvnyQADiYGNAAANdDQAABWEfrAAFc1lAAANTSAwBPvZmg Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADCD25EA@HE111648.emea1.cds.t-internal.com> References: <6369CB70BFD88942B9705AC1E639A33822CD81384C@DC-US1MBEX4.global.avaya.com> <4DF27461.8060204@cisco.com> <101C6067BEC68246B0C3F6843BCCC1E30C22977E6A@MCHP058A.global-ad.net> <6369CB70BFD88942B9705AC1E639A33822CDA812C4@DC-US1MBEX4.global.avaya.com>, <101C6067BEC68246B0C3F6843BCCC1E30C229785C2@MCHP058A.global-ad.net> , <101C6067BEC68246B0C3F6843BCCC1E30C229785F5@MCHP058A.global-ad.net> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [splices] SIP INVOKE method v1 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: ,