Subject: [Sip] comments on willis-sip-answeralert

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 02 Aug 2005 06:34:23 -0400

I've only followed some of the threads on this, so my apologies if some 
of this is redundant. I did a detailed read of the doc, here are my 
comments:

>   The syntax for the header fields defined in this document is:
>       Answer-Mode = "Answer-Mode" HCOLON answer-mode
>       answer-mode = "Manual" / "ManualReq" / "Auto" / "AutoReq"
>       Alert-Mode = "Alert-Mode" HCOLON alert-mode
>       alert-mode = "Normal" / "Null"

these are not extensible. I think you should make the list extensible.

>  A UAC supporting this specification indicates its support for this
>    extension by including an option tag of "answermode" in the Supported
>    header field of all requests it sends.

having a tag called "answermode" which indicates support for an 
extension that defines BOTH an answer mode and an alert mode seems 
confusing. Unless you plan on also defining an "alertmode" option tag, 
you should come up with a different name.

>  UA includes a SIP extension feature tag of "answermode" in the
>    Contact: header field of its REGISTER requests.  This usage of
>    feature tags is described in [5].

I don't understand why a new media feature tag is needed. It seems that 
you could do this with the existing "extensions" feature tag.

>  To require that the UAS either support this extension or reject the
>    request, the UAC includes a Required: header field having the value
>    "answermode".  Note that this does not actually force the UAS to

s/Required/Require

>  To request that retargeting proxies in the path preferentially select
>    targets that have indicated support for this extension in their
>    registration, a UAC includes an Accept-Contact header field having a
>    parameter of "answermode".  This usage of Accept-Contact is described
>    in [6].

I'd suggest better guidance on usage of caller prefs here. You list all 
of the combinations of require and explicit. I think its easier; if the 
request has a Require header field for answermode, you would use the 
"require" parameter. If not, then nothing.

>    existing header field in accord with local policy.  Note that this
>    may result in behavior that is inconsistent with user expectations,
>    such as having a call that was intended to be a diagnostic loopback
>    answered by a human, and consequently must be done very carefully.

why are we allowing this? as you say it seems like a recipe for trouble.

>  For a request having an Answer-Mode value of "Manual", the UAS SHOULD
>    defer accepting the request until the user of the UAS has confirmed
>    willingness to accept the request.  This behavior MAY be altered as
>    needed for unattended UAS or other local characteristics or policy.
>    For example, an auto-attendant system that always answers
>    automatically would go ahead and answer, despite the presence of the
>    "Manual" Answer-Mode header field value.

what about a pstn gateway?

>  unwilling to do so, it SHOULD reject the request with a "403
>    Forbidden" response and MAY include a Reason [7] header field value
>    of:
> 
>    Reason: SIP ;cause=403 ;text="manual answer forbidden"

well, folks know my opinion on this. See RFC3326:

2. The Reason Header Field

    The Reason header field MAY appear in any request within a dialog, in
    any CANCEL request and in any response whose status code explicitly
    allows the presence of this header field.

>  For a request having an Answer-Mode value of "Auto", the UAS SHOULD,
>    if the calling party is authenticated and authorized for automatic
>    answering, accept the request without further user input.  The UAS
>    MAY, according to local policy or user preferences, treat this
>    request as it would treat a request having a Answer-Mode with a value
>    of "Manual" or having no Answer-Mode header field.  If the calling

I am very uncomfortable with this wording. I think authorization is a 
MUST, and the text here doesnt make that clear.

>   this aspect into consideration.  In general, auto-answer is probably
>    NOT RECOMMENDED in environments that include forking.

What?? I disagree. I think it makes a ton of sense. The typical 
walkkie-talkie experience would result in a conference - thats the 
desired behavior we should specify.

>   Another alternative would be to use dynamic conferencing instead of
>    forking.  In this approach, instead of forking the request, a
>    conference would be initiated and all UAs invited into that
>    conference.  The mixer attached to the conference would then mediate
>    traffic flows appropriately.

These are not mutually exclusive; if a request forks, and you get 
multiple 200 OK - thats fine. The UAC would create a conference 
immediately, either through endpoint mixing or pushing everyone into a 
conference server.

>  Normal: The UAS is asked to treat the request as it normally would in
>       the absence of this specification and exercise whatever alerting
>       mechanism it might have and be configured to use.
>    Null: The UAS is asked to not alert its user to the request.

I think its worthwhile documenting somewhere the interactions of alert 
and answer modes - in particular, what combinations make sense?

 >  If the conclusion is to alert the user, the UAS invokes its preferred
 >    alerting mechanism.  If the conclusion is to not alert the user, the
 >    UAS proceeds to process the request.  Note that the decision of
 >    whether to accept the request is independent of the alerting
 >    decision, but one can generally not expect the user to make this
 >    decision unless the user has been alerted to the request.

I think you need more discussion of what a UAS does if it doesnt alert 
the user; how can it proceed with the call? Answermode is one thing, 
diagnostics are another, etc.

>    A UAS supporting this specification inserts a Answer-Mode header
>    field into the 200 OK response to an INVITE request when it wishes to
>    inform the UAC as to whether the request was answered manually or
>    automatically.  The full rationale for including or not including
>    this header field in a response is outside of the scope of this
>    specification.

I think you need to discuss it.

> Consequently, the UAS generally or its supporting proxy MUST
>    authenticate the sender of such requests, using mechanisms such as

If you are allowing proxies to do the authorization, you need a way to 
securely inform the UAS that it has been done. Otherwise, 
misconfiguration (proxy thinks UAS is authorizing, UAS thinks proxy is 
authorizing) can introduce attacks. I think we should strive for safety 
here; misconfiguration cannot easily cause an attack.

As you know, these attacks have been a MAJOR issue in bluetooth - let us 
be extremely cautious here.

Furthermore, the behavior of the UAS and proxy for authentication and 
authorization cannot only be documented in the security considerations 
section.

 From the IANA considerations:

>  The following rows shall be added to the "Option Tags" section of the
>    SIP Parameters registry:
> 
>    +----------------------+----------------------+---------------------+
>    | Name                 | Description          | Reference           |
>    +----------------------+----------------------+---------------------+
>    | answermode           | This option tag is   | [RFCXXXX]           |
>    |                      | used in a Requires   |                     |
>    |                      | header field to      |                     |
>    |                      | indicate that the    |                     |
>    |                      | UAS must support     |                     |
>    |                      | negotiation of       |                     |
>    |                      | answer mode.         |                     |
>    | alertmode            | This option tag is   | [RFCXXXX]           |
>    |                      | used in a Requires   |                     |

ok - so you have two option tags here. The doc only talks about one. 
Maybe a typo?

Also, no IANA registration for media feature tags, though I dont think 
you need them anyway.

minor things

>  SDP usage for this sort of flow is described in [11].  In this sort
>    of application, it may not be needful that the human using the node

may not be necessary

>   Req-5: It MUST be possible for UAC to indicate at least two different
>       priority levels for the desired answer mode.  We refer to these as
>       "normal" and "override" priorities.  In normal usage, we expect
>       that "normal" priority would be used in a user-to-user fashion,
>       whereas "override" priorities would be used for diagnostic
>       procedures or some sorts of emergency session establishment. 

this requirement says how priorities get used, but doesnt define what 
their semantics are.

> Req-8: It MUST be possible for the UAC to construct the request in
>       such a way that the routing proxy infrastructure, if present, will
>       select only contacts supporting the selection of answer modes.

This is clearly alluding to caller prefs. Its important to note that 
caller prefs genreally prefers to try a contact, even if you are unusure 
it supports a capability, rather than reject one you're not sure about. 
In this particular case, avoiding ringing these devices is an 
optimization. Thus, I think the requirement here is better worded as:

"...will prefer contacts supporting the selection of answer modes."

> Req-19: UAS SHOULD accurately represent the answering mode that was
>       applied, but MAY either not include this information or MAY
>       misinform UAC in order to maintain the privacy expectations of
>       UAS-user.  Consequently, applications MUST NOT rely on the
>       veracity of this information.

this seems like a requirement in the protocol itself, rather than a 
requirement for building a protocol.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Aug 2005 02:37:35 -0400

Further comments inline.

	Paul

> "require" parameter. If not, then nothing.

Of course the callerprefs could be used in more complex ways to achieve 
a variety of objectives, and there is no reason to restrict that. But I 
agree it would be good to call out the cases of primary interest and 
give explicit guidance on how to achieve those.

Since this is intended for an IMS/OMA environment, there may be 
additional questions about how callerprefs apply to selection of 
application servers in that environment. (Where those servers typically 
aren't registered.) But that is perhaps out of scope here.

> immediately, either through endpoint mixing or pushing everyone into a 

It isn't even necessary to create a full conference here. It would be 
possible to just accept both calls, send to both, and receive from both.

> diagnostics are another, etc.

Yes. I think there are some major security concerns here. I think there 
are major questions whether it is ever safe to answer automatically if 
that would result in becoming a monitoring device. Diagnostic loopback 
mode is safer because the caller isn't getting anything remarkable from 
the environment of the callee. And PTT is safe because the callee is 
receive-only when it answers. (The callee has to do something overt to 
transmit.) In the case of autoanswer on a traditional audio call it 
would be safer if the device answered in receiveonly (muted) mode, and 
again had to take some overt action to transmit.

There are of course exceptions to this: automatons may answer 
automatically even without being asked. And in some cases (such as an 
agent phone in a call center) it is appropriate to do a brief alert and 
then answer automatically in sendrecv mode.

Because of the exceptions I think it is hard to do much except provide 
guidelines, but even that would be helpful.

---

From: Dean Willis <[email-masked]>
Date: Wed, 3 Aug 2005 10:10:34 +0200

Thanks for the detailed response. I'll respond point-by-point.

On Aug 2, 2005, at 12:34 PM, Jonathan Rosenberg wrote:

> I've only followed some of the threads on this, so my apologies if 
> some of this is redundant. I did a detailed read of the doc, here are 
> my comments:
>
>

ok. Do we need to IANA register extensions, and if so, what should the 
IANA admissions requirement be?

> you should come up with a different name.

It's in there.

> I don't understand why a new media feature tag is needed. It seems 
> that you could do this with the existing "extensions" feature tag.
>

Might work. I'm afraid I don't understand the caller preferences stuff 
at all, despite numerous re-readings. Paul K provided the initial 
"callerprefs" review on the draft. Please send text.

>>    "answermode".  Note that this does not actually force the UAS to

good catch, thanks.

> I'd suggest better guidance on usage of caller prefs here. You list 
> all of the combinations of require and explicit. I think its easier; 
> if the request has a Require header field for answermode, you would 
> use the "require" parameter. If not, then nothing.

That's the proposal we made during the discussion in the SIP meeting.

> why are we allowing this? as you say it seems like a recipe for 

There seems to be a use case for "polite" feature filtering at 
intermediate proxies, where (based on receiving user profile at the 
proxy), said proxy compensates for limitations in the authorization 
model of the called device by filtering out or changing alerting and 
answering mode settings.

> what about a pstn gateway?

Not sure I understand this question. PSTN gateways don't normally send 
a 200 OK until they've received an "answer" message from the PSTN side 
indicating that some user-entity has accepted the request.

I suppose a plain analog gateway might auto-answer, then out-tone the 
dialed digits.

>    allows the presence of this header field.

So what does that mean?

> MUST, and the text here doesnt make that clear.

OMA wishes to control authorization in the intervening network 
elements, not in the terminal node.

> desired behavior we should specify.

This would provide a "conference" only if the call was placed through a 
conference bridge. In the typical case, devices cannot do N-way mixing, 
both because of device capabilities and network characteristics. If you 
want to require all calls to go through a conference-SBC, then I 
suppose your approach would work. I suppose another alternative would 
be to reINVITE to a conference server if one received multiple 200OKs, 
but the functionality should be useful even if a user does not have a 
conference bridge available -- and here, forking would kill them.

> immediately, either through endpoint mixing or pushing everyone into a 

Again, that means that any UAC whose request might fork has to have a 
conference server available for every call for which they request 
auto-answer. That's just not realistic.

> and answer modes - in particular, what combinations make sense?

That makes sense.

> diagnostics are another, etc.

If the UAS doesn't alert the user, then it proceeds just as it would if 
it had alerted the user. If it auto-answers, it proceeds with an 
answer, typically a 200 OK. If it does not auto-answer, it behaves just 
as it would in the case where a user is alerted -- typically, by timing 
out, responding with a 302, or whatever. This seems quite obvious to 
me. Negotiation of diagnostic modes is entirely an SDP problem and is 
out of scope here.

> I think you need to discuss it.

That's probably an NP-complete problem. Are you SURE you want it 
discussed?

> authorizing) can introduce attacks. I think we should strive for 
> safety here; misconfiguration cannot easily cause an attack.

The OMA use case assumes IMS authorization -- that is, if a request 
shows up at the client, it did so because it was authorized "by the 
network". Clients that work this way effectively have a "contract" with 
their proxies to provide this service. I'm not about to do a detailed 
analysis of the IMS authorization model here. About all we can do here 
is describe the risk and state the requirement for reducing it.

> As you know, these attacks have been a MAJOR issue in bluetooth - let 
> us be extremely cautious here.
>

As I said, I'm not about to do a detailed analysis of the IMS 
authorization model here -- it's simply not appropriate in a document 
of this sort.

>>    |                      | header field to      |                    
>>  |
>>    |                      | indicate that the    |                    
>>  |
>>    |                      | UAS must support     |                    
>>  |
>>    |                      | negotiation of       |                    
>>  |
>>    |                      | answer mode.         |                    
>>  |

Yes, there appears to be a typo.

To quote,

4.1.1  All Requests

and

5.1.1  All Requests

5.1.1 should say "alertmode".

> Also, no IANA registration for media feature tags, though I dont think 

err, it's in the xml2rfc source. Dunno what happened. Perhaps xml2rfc 
read your mind and deleted the registration.

>>    of application, it may not be needful that the human using the node

ok

> this requirement says how priorities get used, but doesnt define what 

That's true. It doesn't.

Sectyion 4, however, says:

    The Answer-Mode header field is used by a UAC to request specific
    handling of an INVITE request by the responding UAS related to
    "automatic answering" functionality.  If no Answer-Mode header field
    is included in the request, answering behavior is at the discretion
    of the UAS, as it would be in the absence of this specification.  The
    desired handling is indicated by the the value of the Answer-Mode
    header field, as follows:

    Manual: The UAS is asked to not accept the request (send a 200 OK)
       until the user of the UAS has interacted with the user interface
       (UI) of the UAS in such a way as to indicate that the user desires
       the UAS to accept the request.
    ManualReq: The UAS is strongly asked to accept the request manually,
       as in "Manual".  Further, the UAS is asked to override local user
       preferences relating to automatic answer, and answer manually even
       if the user preferences are to automatically answer requests
       having a Answer-Mode header field value of "Manual".  The UAS is
       also asked NOT to answer automatically, and to reject the request
       if it is unwilling to answer manually.
    Auto: The UAS is asked to accept the request automatically, without
       waiting for the user of the UAS to interact with the UI of the UAS
       in such a way as to indicate that the user desires the UAS to
       accept the request.
    AutoReq: The UAS is strongly asked to accept the request
       automatically, as in "Auto".  Further, the UAS is asked to
       override local user preferences relating to automatic answer, and
       answer automatically even if the user preferences are to not
       automatically answer requests having a Answer-Mode header field
       value of "Auto".  The UAS is also asked NOT to answer manually,
       and to reject the request if it is unwilling to answer
       automatically.

> caller prefs genreally prefers to try a contact, even if you are 
> unusure it supports a capability, rather than reject one you're not 
> sure about. In this particular case, avoiding ringing these devices is 
> an optimization. Thus, I think the requirement here is better worded 
> as:
>

That's a different requirement, and it's my error that they aren't both 
included. This was present for alertmode:

    Req-15: It MUST be possible for UAS to indicate its support for the
       selection of alerting modes in a REGISTER request so that that the
       routing proxy can selectively route requests requiring the
       selection of alerting mode to UAS.  This supports the
       functionality described in the following requirement.
    Req-16: It MUST be possible for UAC to construct the request in such
       a way that the routing proxy infrastructure, if present, will
       select only contacts supporting the selection of alerting modes.
       This allows the proxy network to efficiently avoid sending the
       request to nodes that do not support this extension.

> requirement for building a protocol.

Huh? Seems more like a requirement on implementations to me.

--
Dean