comments on willis-sip-answeralert
Jonathan Rosenberg <jdrosen <at> cisco.com>
2005-08-02 10:34:23 GMT
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
jdrosen <at> cisco.com 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 sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
RSS Feed