Re: [splices] Answering an A/V Call Using Two Separate Devices proposal
Paul Kyzivat <pkyzivat@cisco.com> Tue, 24 May 2011 13:11 UTC
Return-Path: <pkyzivat@cisco.com>
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 95EE4E06BA for <splices@ietfa.amsl.com>; Tue, 24 May 2011 06:11:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.254
X-Spam-Level:
X-Spam-Status: No, score=-110.254 tagged_above=-999 required=5 tests=[AWL=0.345, 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 Pt0zAPrUDdDr for <splices@ietfa.amsl.com>; Tue, 24 May 2011 06:11:16 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFDCE06A8 for <splices@ietf.org>; Tue, 24 May 2011 06:11:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=28202; q=dns/txt; s=iport; t=1306242676; x=1307452276; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=u6uzD9eqIWVpR2mlhZ7cGlvN7yUmmXIhp3V+culEnuo=; b=NaIHsOhRsAyRR0as5J1uI15PhxVhdqode28AOZ/T86xnjOW2ctlVIJpL mcbmHN2ilOlQJeUI6ZEg+9nmcGOhL1H4b15kz5qeYo8EYQJ5+XhyvocU9 734NaKE4kbZ/3dV/fy96EV+oCfHN+tQk3Qz1YhjzITQw166CPQdhtSqpu w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhABAA2u202tJXG8/2dsb2JhbACXZY5Ed6s0nXyGGwSQH4Q0imk
X-IronPort-AV: E=Sophos;i="4.65,261,1304294400"; d="scan'208";a="363162279"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-2.cisco.com with ESMTP; 24 May 2011 13:11:15 +0000
Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4ODBEba026037; Tue, 24 May 2011 13:11:15 GMT
Message-ID: <4DDBAE72.2020003@cisco.com>
Date: Tue, 24 May 2011 09:11:14 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
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: Peter Musgrave <musgravepj@gmail.com>
References: <6369CB70BFD88942B9705AC1E639A33822CC01E548@DC-US1MBEX4.global.avaya.com> <4DD87FBF.5010504@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FCE3E@DC-US1MBEX4.global.avaya.com> <4DD97B5D.7040404@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FCE75@DC-US1MBEX4.global.avaya.com> <4DD9CE66.8010204@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FB9A1@DC-US1MBEX4.global.avaya.com> <4DDA5C19.5040405@cisco.com> <BANLkTik09_aC9L+mrM5NJuJsDkZ-fOU5LQ@mail.gmail.com>
In-Reply-To: <BANLkTik09_aC9L+mrM5NJuJsDkZ-fOU5LQ@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "splices@ietf.org" <splices@ietf.org>
Subject: Re: [splices] Answering 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" <splices.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/splices>, <mailto:splices-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/splices>
List-Post: <mailto:splices@ietf.org>
List-Help: <mailto:splices-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/splices>, <mailto:splices-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 May 2011 13:11:21 -0000
Peter, IMO the "action mechanism" will be controversial regardless of how it is encoded. And it will have largely the same impact on implementations. (It is a significant extension of the scope of SIP.) I don't think that trying to "hide" it will make things better. And as best I understand it doesn't fit the semantics of PUBLISH. (Publish is intimately tied to the state model of an event package. Maybe if the event package is carefully designed you could make a case for this. But I'm dubious.) I think the kind of use cases that Rifaat is posing are good as a starting point. But after some of that I think one of the next steps must be carefully defining the scope of this new action mechanism. And I expect that to be difficult. Right now it seems to be a pot into which you can put *anything*. I think we need to get to the point where it is clear what sorts of things are valid actions, and which are not. I expect this will involve defining an extended environment for a UA, of things it needs to manipulate. (Stuff like speakers, microphones, displays, buttons, multiple dialogs, ...) We might get a head start by exploring what CTI features are defined in other protocols. Thanks, Paul On 5/24/2011 8:41 AM, Peter Musgrave wrote: > I agree with Paul that: > 1) This works ok. > 2) INVOKE is more mechanism than a new header. [A method is a bigger > deal than a header] > > I'd also observe in a "real politik" sense that the potential energy > barrier to geting a new SIP method in place will likely be significant. > I would expect it would have to be a dispatch-ed WG all on it's own. > People will decide to either use it to solve world hunger - or decide > that it is the root of all evil. > > Under "out there" ideas - would it be possible to put the Action header > in a PUBLISH? Would this allow the same signalling semantics as INVOKE > without the need for a new method? > > Peter Musgrave > > On Mon, May 23, 2011 at 9:07 AM, Paul Kyzivat <pkyzivat@cisco.com > <mailto:pkyzivat@cisco.com>> wrote: > > > > On 5/23/2011 8:56 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > I do not see how this proposal is "less mechanism" than the > original proposal, but I tend to agree with you that this might > be "a matter of taste". > > > The devil is in the details here, and we don't have enough details. > So its all in the set of assumptions one is making. > > In the end we probably aren't going to standardize services - just > mechanisms for creating services. But perhaps we will have an > "examples" doc that shows how the mechanisms might be used to create > a range of interesting services such as these. If so, I would think > we would need to work through each one in detail, carefully defining > all the assumptions about the environment. > > And that is really what it takes to decide on each particular > "action", because those seem to be rather specialized. At the moment > I don't have a vision of a clear and obvious set of actions that > enable all the interesting services. Its more a matter of crafting > an action to support one or a few services. I wish it was more clear > cut than that. Maybe it will become so with more study. > > Thanks, > Paul > > > Regards, > Rifaat > > > > ________________________________________ > From: Paul Kyzivat [pkyzivat@cisco.com <mailto:pkyzivat@cisco.com>] > Sent: Sunday, May 22, 2011 11:03 PM > To: Shekh-Yusef, Rifaat (Rifaat) > Cc: splices@ietf.org <mailto:splices@ietf.org> > Subject: Re: [splices] Answering an A/V Call Using Two Separate > Devices proposal > > On 5/22/2011 8:49 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > > You are then proposing the following: > > > Alice used her *phone* to answer the incoming call > | | | > | > | | 200 OK [Audio] | > | > | |-------------------->| > | > | | | 200 OK > [Audio] | > | | > |-------------------->| > | CANCEL | | > | > |<------------------------------------------| > | > | | | > | > | > |<---dialog1------------------------------->| > | > |<======audio==============================>| > | | | > | > | INVITE Alert-Info and [Video] | > | > |<--------------------| | > | > > What happens here? > Will the user be required to take an action on the PC to > accept the INVITE? > Or you are expecting the PC to provide an answer without > user intervention? > > > Could be handled various ways. > > The alert-info could suggest auto-answer. (The PC *honoring* such a > request might be conditional on who it comes. But even if not > honored > for auto-answer it might still alert *differently*.) If it wasn't > auto-answered, and returned 180, it could be followed up with an > INVOKE > to force the answer. > > Thanks, > Paul > > | 200 OK [Video] | | > | > |<--------------------| | > | > | | re-INVITE [A/V] | > | > | |-------------------->| > | > | | | > re-INVITE [A/V] | > | | > |-------------------->| > | | | 200 OK > [A/V] | > | | 200 OK [A/V] > |<--------------------| > | |<--------------------| > | > | ACK | | > | > |<--------------------| | > | > | | | > | > > |<------dialog2------>|<---dialog1------------------------------->| > | | | > | > | > |<======audio==============================>| > > |<============================video==============================>| > | | | > | > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com > <mailto:pkyzivat@cisco.com>] > Sent: Sunday, May 22, 2011 5:09 PM > To: Shekh-Yusef, Rifaat (Rifaat) > Cc: splices@ietf.org <mailto:splices@ietf.org> > Subject: Re: [splices] Answering an A/V Call Using Two > Separate Devices > proposal > > > > On 5/22/2011 2:40 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > Because a new INVITE will probably cause the PC to > present the user with a > > UI component and wait for the users input. > > Well, I suppose you would want the PC to indicate what > is going on in > the UI in *some* way. But probably not exactly the same > as getting a new > call. > > That could be handled via appropriate Alert-Info. To > some extent this is > a matter of taste. I am inclined to prefer an economy of > mechanism, and > I think the alert-info feels like less mechanism than > the particular > INVOKE mechanism used in this scenario. (The invoke > mechanism used here > requires the phone to assume that the PC is aware of the > dialog, and > able to associate it with the appropriate contact > address for doing the > invite.) > > Thanks, > Paul > > Regards, > Rifaat > > > -----Original Message----- > From: splices-bounces@ietf.org > <mailto:splices-bounces@ietf.org> > [mailto:splices-bounces@ietf.org > <mailto:splices-bounces@ietf.org>] On Behalf > > Of > > Paul Kyzivat > Sent: Saturday, May 21, 2011 11:15 PM > To: splices@ietf.org <mailto:splices@ietf.org> > Subject: Re: [splices] Answering an A/V Call > Using Two Separate Devices > proposal > > I guess all of that can work. But for the last > part, if the phone knows > enough to send the invoke to the pc, why can't > it just send an INVITE to > the pc? > > Thanks, > Paul > > On 5/21/2011 8:56 AM, Shekh-Yusef, Rifaat > (Rifaat) wrote: > > Hi, > > We are still working on a new version of the > INVOKE document that removes > > the implicit subscription. > > > Meanwhile I would like to continue the > discussion of the various possible > > uses cases. > > The following is a proposal for Answering an > A/V Call Using Two Separate > > Devices. > > > Regards, > Rifaat > > > > Alice Alice > Proxy Bob > PC Desk Phone > | | > | | > | | > | | > Both Alice's devices subscribe to the reg > event package, which allows each > > device to > > discover the capabilities of the other > device based on the feature tags > > provided by each device. > > The Desk Phone knows that the PC supports > Video, while the PC knows that > > the > > 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 | > | | > |-------------------->| > | | > | | > | | > | | > | | > The scenario starts with an A/V call from > Bob to Alice > | | > | | > | | > | INVITE Alice [A/V] | > | | > |<--------------------| > | | INVITE Alice > [A/V] | | > | > |<--------------------| | > | INVITE Alice [A/V] | > | | > > |<------------------------------------------| | > | | > | | > > > (*) > > > Let's assume that Alice used her PC to > answer the incoming call > The PC instructs the phone to answer the > audio call > | | > | | > | INVOKE Action: > > urn:invoke:call:answer;media=audio;transducer=speaker|headset > > |-------------------->| > | | > | 200 OK | > | | > |<--------------------| > | | > | | > | | > | | 200 OK > [Audio] | | > | > |-------------------->| | > | | > | 200 OK [Audio] | > | | > |-------------------->| > | CANCEL | > | | > > |<------------------------------------------| | > | | > | | > | > |<---dialog1------------------------------->| > | | > | | > | > |<======audio==============================>| > | | > | | > | | > | | > The PC then adds Video to the existing audio > call. > | | > | | > | INVITE with Join [Video] > | | > |-------------------->| > | | > | 100 | > | | > |<--------------------| > | | > | | re-INVITE > [A/V] | | > | > |-------------------->| | > | | > | re-INVITE [A/V] | > | | > |-------------------->| > | | > | 200 OK [A/V] | > | | 200 OK [A/V] > |<--------------------| > | > |<--------------------| | > | 200 OK [Video] | > | | > |<--------------------| > | | > | | > | | > > |<------dialog2------>|<---dialog1------------------------------->| > | | > | | > | > |<======audio==============================>| > > |<============================video==============================>| > | | > | | > | | > | | > > > > The scenario continues after the (*) above > Let's assume that Alice used her phone to > answer the incoming call. > The phone answers the audio call > | | > | | > | | 200 OK > [Audio] | | > | > |-------------------->| | > | | > | 200 OK [Audio] | > | | > |-------------------->| > | CANCEL | > | | > > |<------------------------------------------| | > | | > | | > | > |<---dialog1------------------------------->| > | | > | | > | > |<======audio==============================>| > | | > | | > | | > | | > The phone then instructs the PC to initiate > a video call to join the > > existing call > > | | > | | > | INVOKE Action: > urn:invoke:call:join;media=video;dialog=dialog1 > |<--------------------| > | | > | 200 OK | > | | > |-------------------->| > | | > | | > | | > The PC then adds Video to the existing audio > call. > | | > | | > | INVITE with Join [Video] > | | > |-------------------->| > | | > | 100 | > | | > |<--------------------| > | | > | | re-INVITE > [A/V] | | > | > |-------------------->| | > | | > | re-INVITE [A/V] | > | | > |-------------------->| > | | > | 200 OK [A/V] | > | | 200 OK [A/V] > |<--------------------| > | > |<--------------------| | > | 200 OK [Video] | > | | > |<--------------------| > | | > | | > | | > > |<------dialog2------>|<---dialog1------------------------------->| > | | > | | > | > |<======audio==============================>| > > |<============================video==============================>| > | | > | | > > > > _______________________________________________ > splices mailing list > splices@ietf.org <mailto:splices@ietf.org> > https://www.ietf.org/mailman/listinfo/splices > > _______________________________________________ > splices mailing list > splices@ietf.org <mailto:splices@ietf.org> > https://www.ietf.org/mailman/listinfo/splices > > > > > _______________________________________________ > splices mailing list > splices@ietf.org <mailto:splices@ietf.org> > https://www.ietf.org/mailman/listinfo/splices > >
- [splices] Answering an A/V Call Using Two Separat… Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] Answering an A/V Call Using Two Sep… Paul Kyzivat
- Re: [splices] Answering an A/V Call Using Two Sep… Paul Kyzivat
- Re: [splices] Answering an A/V Call Using Two Sep… Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] Answering an A/V Call Using Two Sep… Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] Answering an A/V Call Using Two Sep… Paul Kyzivat
- Re: [splices] Answering an A/V Call Using Two Sep… Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] Answering an A/V Call Using Two Sep… Paul Kyzivat
- Re: [splices] Answering an A/V Call Using Two Sep… Peter Musgrave
- Re: [splices] Answering an A/V Call Using Two Sep… Paul Kyzivat
- Re: [splices] Answering an A/V Call Using Two Sep… Peter Musgrave
- Re: [splices] Answering an A/V Call Using Two Sep… Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] Answering an A/V Call Using Two Sep… Simon Pietro Romano