Re: [splices] Answering an A/V Call Using Two Separate Devices proposal

Peter Musgrave <musgravepj@gmail.com> Tue, 24 May 2011 12:41 UTC

Return-Path: <musgravepj@gmail.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 70F02E06E9 for <splices@ietfa.amsl.com>; Tue, 24 May 2011 05:41:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.722
X-Spam-Level:
X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 WJjOFfB2+YCN for <splices@ietfa.amsl.com>; Tue, 24 May 2011 05:41:53 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2E370E068C for <splices@ietf.org>; Tue, 24 May 2011 05:41:53 -0700 (PDT)
Received: by fxm15 with SMTP id 15so5196277fxm.31 for <splices@ietf.org>; Tue, 24 May 2011 05:41:52 -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; bh=GrB0P4UhpQ35wOWHTnC00mpIp18WzIma9kq4nV5rOzc=; b=aKmvEmiXyGX/pPie7u/OUwls7P6+eZ2BZotCMFFLcmrN4406jdyuP0uvDNSYqDGkt2 TrFa/x6hwF18LFdmWPTXP2PUhclD8W7pj5QEGsrXXmmrLFhaNt11bJYnYoH9hbKd+Jxf d2o5EASBGBu5TBPY2lzMSMClid/0DK7nJc44w=
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; b=Hq7/ps0vXnIgj4MMo4r8UI9WWKJx7d0Z4GWCDHIPrBwhABAskXw8nOWaF3/uJuqO2G TkD07QaMPj7rxnfjtU/J8TzsOavK6QEPgNV/dmTwCRg5dNldlegp1z1NjBrc7p6mqTQ7 5sc6Mc3PA6JvC88siPXPRCT/oxo662zM9RzQA=
MIME-Version: 1.0
Received: by 10.223.33.6 with SMTP id f6mr3685994fad.85.1306240912226; Tue, 24 May 2011 05:41:52 -0700 (PDT)
Received: by 10.223.116.209 with HTTP; Tue, 24 May 2011 05:41:52 -0700 (PDT)
In-Reply-To: <4DDA5C19.5040405@cisco.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>
Date: Tue, 24 May 2011 08:41:52 -0400
Message-ID: <BANLkTik09_aC9L+mrM5NJuJsDkZ-fOU5LQ@mail.gmail.com>
From: Peter Musgrave <musgravepj@gmail.com>
To: Paul Kyzivat <pkyzivat@cisco.com>
Content-Type: multipart/alternative; boundary=0015174780bc90785a04a404e914
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 12:41:55 -0000

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>; 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]
>> Sent: Sunday, May 22, 2011 11:03 PM
>> To: Shekh-Yusef, Rifaat (Rifaat)
>> Cc: 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]
>>>> Sent: Sunday, May 22, 2011 5:09 PM
>>>> To: Shekh-Yusef, Rifaat (Rifaat)
>>>> Cc: 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] On
>>>>>> Behalf
>>>>>>
>>>>> Of
>>>>
>>>>> Paul Kyzivat
>>>>>> Sent: Saturday, May 21, 2011 11:15 PM
>>>>>> To: 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
>>>>>>> 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
>