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

From: Kelley Sean-Q12059 <[email-masked]>
Date: Mon, 1 Aug 2005 11:21:54 -0500

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 thei!
 r 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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 2 Aug 2005 05:26:31 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Kelley Sean-Q12059
Sent: Monday, August 01, 2005 09:22
To: [email-masked]
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".

---

From: "Zisimopoulos, Haris, VF-Group" <[email-masked]>
Date: Tue, 2 Aug 2005 15:41:57 +0100

The point is that the description of ManualReq states :
 
"The UAS is also asked NOT to answer automatically, and to reject the
request
if it is unwilling to answer manually."

This is exactly similar to this of AutoReq but when it comes to the
description of the procedures of UAS for the AutoReq it is stated that: 

"The UAS MUST NOT allow "manual" answer of this request, but MAY reject
it."

But for the ManualReq it is stated: 

"If the UAS is not capable of answering the request in this "Manual"
mode or is
   unwilling to do so, it SHOULD reject the request with a "403
   Forbidden" response..."

So the normative behaviour of the UAS when it comes to processing
ManualReq and AutoReq is not similar, which from protocol point of view
does not make sense given that these header fields convey exactly the
same "meaning": 

If the terminating point cannot answer the request either manually or
auto (depending if ManualReq or AutoReq is used) then reject it. 

AutoReq and ManualReq needs to be mandatory in order to make sense for
the UAC to use it for any usage (PoC or not) and be different from
Manual and Auto. I cannot understand where it helps if it is
wishy-washy.

Best regards,
Haris 

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Francois Audet
	Sent: 02 August 2005 11:27
	To: Kelley Sean-Q12059; [email-masked]
	Subject: RE: [Sip] Comment on willis-sip-answeralert-00

	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: [email-masked] [mailto:[email-masked]]
On Behalf Of Kelley Sean-Q12059
		Sent: Monday, August 01, 2005 09:22
		To: [email-masked]
		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".