RE: [Sip] Comment on willis-sip-answeralert-00

"Francois Audet" <audet@nortel.com> Tue, 02 August 2005 10:26 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dztz7-0005fv-Bq; Tue, 02 Aug 2005 06:26:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dztz5-0005ff-5l for sip@megatron.ietf.org; Tue, 02 Aug 2005 06:26:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05987 for <sip@ietf.org>; Tue, 2 Aug 2005 06:26:52 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzuVX-0007Vb-O8 for sip@ietf.org; Tue, 02 Aug 2005 07:00:28 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j72AQYb09407; Tue, 2 Aug 2005 06:26:34 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Sip] Comment on willis-sip-answeralert-00
Date: Tue, 02 Aug 2005 05:26:31 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF03905E5B@zrc2hxm0.corp.nortel.com>
Thread-Topic: [Sip] Comment on willis-sip-answeralert-00
Thread-Index: AcWWtaA8ZWA3ZYfeQi++HeWDEaqgiQAloYgg
From: Francois Audet <audet@nortel.com>
To: Kelley Sean-Q12059 <seankelley@motorola.com>, sip@ietf.org
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576
Cc:
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1621927570=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

I think we have to distinguish what the IETF produces, i.e., a protocol,
versus the service requirement from OMA or whoever wants to use that
protocol.
 
I think what we need is an explicit indication similar to Required and
Supported that gives no ambiguity to the behavior. (I think the current
wording with "SHOULD" is too wishy-washy.)
 
Then, OMA can decides that they support one or the other behavior or
both for their own application.
 
 

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
Kelley Sean-Q12059
Sent: Monday, August 01, 2005 09:22
To: sip@ietf.org
Subject: [Sip] Comment on willis-sip-answeralert-00


Regarding the UAS procedures for handling the Answer-Mode value of
"ManualReq", the draft indicates that the UAS SHOULD answer in manual
mode, and the UAS SHOULD reject the request if it is unwilling or
incapable of answering in manual mode.
 
However, there is a use case for Push to Talk (as it is being specified
in OMA) that might justify changing these SHOULDs to SHALLs (similar to
how the UAS procedures for handling AutoReq are currently defined).  The
requesting user may not want their initial talk burst to be
automatically played out from the called UA's speaker phone, due to
privacy concerns of the calling user.  The common example is a mistress
who does not want the call to be auto answered, for fear that the wife
is present.  Another example is when the requesting user is concerned
that he/she might be interupting the called user (i.e. calling user
suspects that the called user is having lunch with a customer, or is in
a meeting) and therefore wants to "politely" alert the user prior to the
initial talk burst being played out, in order to giving the called user
an opportunity to reject the call.  In each of these cases, the calling
user's behavior is based upon a "guarantee" from the PoC service that
their initial talk burst will only be played out if the called user
manually accepts the call.
 
It also would seem more logical to have the semantics of "ManualReq" be
truly "manual mode required", rather than the current "manual mode
strongly recommended".

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip