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

[Dean Willis <[e-mail]>]

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:
>
>
>>   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.
>

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

>>  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.
>

It's in there.

>
>>  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.
>

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.

>
>>  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

good catch, thanks.

>
>>  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.

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

>
>>    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.

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.

>
>>  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?

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.

>
>>  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.
>

So what does that mean?

>
>>  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.

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

>
>>   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.
>

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.


>>   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.
>

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.

>>  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?
>

That makes 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.
>

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.

>
>>    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.

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

>
>> 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.

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.
>
> Furthermore, the behavior of the UAS and proxy for authentication and 
> authorization cannot only be documented in the security considerations 
> section.
>

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.

> 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?
>

Yes, there appears to be a typo.

To quote,

4.1.1  All Requests

    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.

and

5.1.1  All Requests

    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.

5.1.1 should say "alertmode".


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

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

> 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
>

ok

>>   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.
>

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.

>> 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."
>

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.

>> 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.

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

--
Dean


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip