I've finally gotten the cycles to go over
draft-ietf-bliss-shared-appearances-07. We consider this work to be seriously
important for the use of SIP in the business telecom market, and want to see
Shared Appearances standardized. Unfortunately, I'm too pressed for time to
have examined these items a second time, so please forgive the mistakes in my
queries.
Dale
----------------------------------------------------------------------
section 1:
This paragraph is awkward:
This document looks at how this feature can be implemented using
standard SIP [RFC3261] in conjunction with SIP events
[I-D.ietf-sipcore-rfc3265bis] and publication [RFC3903] for
exchanging status among user agents, and the SIP dialog state event
package [RFC4235] to exchange dialog state information to achieve the
same.
Perhaps:
This document looks at how this feature can be implemented using
standard SIP [RFC3261] in conjunction with SIP events
[I-D.ietf-sipcore-rfc3265bis] and publication [RFC3903]
(carrying the SIP dialog state event package [RFC4235])
for exchanging status among user agents.
section 1:
The appearance number relates to the
user interface for the telephone - typically each appearance of an
AOR has a visual display (lamp that can change color or blink or a
screen icon) and a button (used to select the appearance).
Might be better as:
The appearance number relates to the
user interface for the telephone - typically each appearance of an
AOR has a visual display (lamp that can change color or blink or a
screen icon) and a button (used to select the appearance) - where
each appearance number is associated with a different dialog to/from
the AOR.
section 1:
If a telephone has enough buttons/lamps, calls could be
presented on the nth button.
Would be clearer as:
If a telephone has enough buttons/lamps, the appearance number could be
the positional sequence number of the button.
section 4.1, REQ-14:
Exclusivity means that the UA
requesting it desires to have a private conversation with the
external party and other UAs must not be allowed to be joined or
taken.
is not correctly phrased. Correct to:
Exclusivity means that the UA
requesting it desires to have a private conversation with the
external party and other UAs must not be allowed to joined or
take the call.
section 4.2:
While an Appearance Agent can be
part of a centralized server, it could also be co-resident in a
member User Agent who has taken on this functionality for a group.
"who" should be "which".
section 4.2, step 5:
For outgoing calls, the operation depends on the implementation.
If the user seizes a particular appearance number for the call,
the UA publishes the 100 Trying state dialog information without
an appearance number and waits for a 200 OK before sending the
INVITE.
This appears to be incorrect. I think the correct version is:
For outgoing calls, the operation depends on the implementation.
If the user seizes a particular appearance number for the call,
the UA publishes the >>"trying"<< state dialog information >>with
the<< appearance number and waits for a >>2xx<< before sending the
INVITE.
section 4.2, step 7:
For outgoing calls, if the user does not wish to seize an
appearance (such as during a consultation call or if a UA is
fetching 'service media' such as music on hold
[I-D.worley-service-example]), the UA also publishes this prior
to sending the INVITE.
"this" should be clarified (what exactly is published to indicate lack
of interest in receiving an appearance number?)
And I think that the question is not "does not wish to seize an
appearance" but rather "does not want an appearance number assigned",
as a UA can make a call without "seizing" (as defined in section 5),
but will have a number assigned automatically.
section 4.2, step 9:
The Appearance Agent may not have full access to the complete
dialog state of some or all of the UAs in the group. If this is
the case, the Appearance Agent will subscribe to the dialog state
of individual UAs in the group to obtain this information.
Normal notifications will be sent every time the dialog state
changes, including calls placed, answered, placed on and off
hold, and hangups.
This is hard to read until you realize that "may not have full access"
means "may not have back-door access". A better phrasing would be:
The Appearance Agent may not have direct access to the
complete dialog state of some or all of the UAs in the group.
If this is the case, the Appearance Agent will subscribe to the
dialog state of individual UAs in the group to obtain this
information. In any case, the Appearance Agent will send
normal notifications (via the subscriptions established by the
UAs in step 1) every time the aggregate dialog state of the AOR
changes, including when calls are placed, answered, placed on
and off hold, and hung up.
section 5:
Somewhere near the beginning of section 5, it seems like a description
of the intended properties of appearance numbers is needed. In
particular:
Appearance numbers are non-negative integers.
When an appearance number is requested to be assigned, generally
the assigned number is the smallest nonnegative integer that is
not currently assigned as an appearance number to a dialog for
this AOR.
This rules out, e.g., having the appearance numbers be a dialog
sequence number that increments throughout the history of the AOR.
BTW, is the latest decision that appearance numbers start with 0,
rather than 1?
A word seems to be missing:
[...] initiating a dialog, in order to appear as >>if<< it was
already initiating a dialog.
The following sentence uses "confirmed", and several later sentences
use "confirmed by the Appearance Agent". But there is no definition
of this "confirming" operation:
The appearance number is confirmed prior to sending the INVITE.
The import of this sentence is unclear:
This is a user interface only issue.
The sentence is also awkwardly phrased, as one would probably want to
construct "user-interface-only issue". Less awkward would be:
This is an issue only for the user interface.
or
This is only a user interface issue.
But given that there are protocol actions involved, it's not clear why
that sentence is stated, or even exactly what "this" refers to.
section 5.2.1:
There is a lot that is not clear in this paragraph, and also a lot of
stealthy description of protocol actions hidden in a paragraph that is
ostensibly about a data item. In addition, it does not state that
every <appearance> element is the child of a <dialog> element (nor
does the schema).
The <appearance> element is used to convey the appearance number.
The appearance number is a positive integer. When sent in a
publication in state Trying to the Appearance Agent, it is used to
request an appearance number. When sent by the Appearance Agent, it
indicates that the appearance number is associated with a dialog.
The UA generating the to-tag and from-tag parameters treats them from
a local perspective. In other words, if the UA sent out a request
within the dialog, the to-tag parameter would match the remote tag,
and the from-tag parameter would match the local tag.
Better would be:
The <appearance> element is used to convey the appearance number of
the dialog described by the <dialog> element which is its parent,
on the UA(s) [for the AOR?] specified by the "entity" attribute.
The appearance
number is a positive integer. When sent in a PUBLISH with parent
<dialog> with state attribute "trying" by a UA to the Appearance
Agent, the UA is requesting assignment of the given appearance
number to the current or future dialog with the given dialog
identifiers. When an <appearance> element is sent by the
Appearance Agent in a NOTIFY, it indicates that the appearance
number has been assigned to the specified dialog.
Note that a <dialog-info> element describes the contained <dialog>s
"from the point of view of the UA" (named by the "entity" attribute),
regardless of whether the containing request is sent by the UA or
the Appearance Agent. In particular, if the UA sent a request
within the described dialog, the "To" header URI would match the
<remote> <identity> value and the to-tag parameter would match the
remote-tag attribute. Similarly, the "From" header URI would match
the <local> <identity> value and the from-tag parameter would match
the local-tag attribute.
But this leads to the point that there is no clear, separate
description of the fundamental protocol action, viz., the UA sends a
PUBLISH to the Appearance Agent to request an appearance assignment
and the Appearance Agent sends a NOTIFY back to the UA with the final
assignment.
Also, this says that the appearance number is a "positive integer"
whereas appearance numbers are non-negative integers.
section 5.2.2:
The <exclusive> element is a boolean used to indicate whether the UA
will accept Join or Replaces INVITEs for this dialog. For example,
some shared appearance systems only allow call pickup when the call
is on hold. In this case, the <exclusive> element should be used to
explicitly indicate this, rather than implicitly by the hold state.
could be clarified as:
The <exclusive> element is a boolean, which when true, indicates
that the UA is willing to accept an INVITE with a Join or Replaces
header targeted to the dialog described by the <dialog> element
that is the parent of the <exclusive> element. For example, some
shared appearance systems only allow call pickup when the call is
on hold. In this case, the <exclusive> element should be set to
"true" when the call is held and "false" when the call is not held,
rather than having the "exclusive" value implied by the hold state.
BTW, is there a default value for "exclusive"? The schema doesn't
show one.
Expanding this sentence would help:
It is important to note that this element is a hint, and that the
UA must take additional steps to ensure that INVITE with Join or
Replaces is not applied to the dialog.
section 5.2.3:
Only the UA which is performing the actual media mixing
should include this element in publications to the Appearance Agent.
This is not exactly correct, as the UA may be doing 3pcc to a mixing
agent. What we want is:
Only the UA which is the common endpoint of the mixed dialogs (and
thus controlling the mixing operation) should include this element
in publications to the Appearance Agent.
section 5.3:
Should probably add:
User Agents which implement call pickup, joining and bridging MUST
support sending >>and receiving<<< an INVITE with Replaces
[RFC3891] or Join [RFC3911].
and omit the last sentence of the paragraph. Or else, the
requirements are more complex than I understand them to be.
These two sections probably ought to be combined to clarify the
operations that are intended:
A UA MUST send dialog package PUBLISH requests in the following
situations:
[...]
In all these cases, the INVITE SHOULD NOT be sent until the 200 OK
response to the PUBLISH has been received, except for an emergency
call, when a UA MUST never wait for a confirmed seizure before
sending an INVITE. Instead, the emergency call MUST proceed
regardless of the status of PUBLISH transaction.
viz.:
In the following cases, before sending the INVITE, a UA MUST send a
dialog package PUBLISH request to the Appearance Agent containing
the forthcoming dialog state changes and receive the 2xx response:
[...]
An exception is an emergency call, when a UA MUST never wait for a
confirmed seizure before sending an INVITE. Instead, the emergency
call MUST proceed without waiting for the PUBLISH transaction.
section 5.3, item 1:
I think "i.e." here should be "e.g.".
section 5.3:
It's not clear why this sentence using receipt of the 100 as a
criterion, as the receipt of the 100 does not provide any additional
dialog information:
If no dialog identification information is present in
the initial PUBLISH, the UA MUST PUBLISH again after receiving the
100 Trying response.
I believe that what is wanted is "[...] the UA MUST publish again
promptly after the Call-Id and from-tag are established."
This publication state is refreshed as described in [RFC3903] during
the early dialog state or the Appearance Agent may reassign the
I think you want "This publication [published?] state MUST be
refreshed as described in [RFC3903] or the Appearance Agent may
reassign [...]"
It's not clear why PUBLISH refreshes are not required after transition
to the confirmed state, as RFC 3903 states that published data are
soft-state with specified expiration time. If this I-D intends to
handle expiration differently from RFC 3903, this needs to be
specified clearly.
Shouldn't the following SHOULD be a MUST?
A user may select an appearance number but then abandon placing a
call (go back on hook). In this case, the UA SHOULD free up the
appearance number by removing the event state with a PUBLISH as
described in [RFC3903].
section 5.3.1:
The first sentence would be clearer as:
There are cases where two separate dialogs at a UA are not mixed
but share the same 'context'.
The last sentence of the paragraph would be clearer as:
These cases are best handled by not assigning an appearance number
to a newly-created dialog when it shares a context with a
pre-existing dialog. (But if the pre-existing dialog is
terminated, its appearance number should be reassigned to the
newly-created dialog.)
This sentence could be clarified:
If
the Appearance Agent policy does not allow calls without an assigned
appearance number, a 400 response with the reason phrase "Appearance
Number Conflict" will be received, and the UA will republish either
selecting/seizing an appearance number or send the INVITE without
publishing, in which case the Appearance Agent will assign one.
as:
If the Appearance Agent policy does not allow calls without an
assigned appearance number, a the UA will receive a 400 response
with the reason phrase "Appearance Number Conflict", and the UA
must either republish selecting/seizing an appearance number or
send the INVITE without publishing, in which case the Appearance
Agent will assign an appearance number.
See also comments below about using 400 as a response code.
section 5.3.2:
This explanation probably needs to be fleshed out. I can't visualize
what is expected to be published:
When an INVITE is generated to attempt to bridge or take a call (i.e.
contains Join or Replaces with a dialog identifier of another dialog
in the shared appearance group), the appearance number of the joined
or replaced call SHOULD be published. The publication MUST contain
the appearance number of the dialog to be joined or replaced and the
dialog identifier in the 'joined-dialog' or 'replaced-dialog'
elements.
section 5.3.3:
This paragraph contains a vicious passive construction, which
describes what is to be done but does not describe what is to do it:
If Alice is the transferee, the triggered INVITE from the REFER
should be treated as a consultation call, and should not use a new
appearance number. When the transfer completes, the appearance
number associated with the dialog with Carol is moved to the dialog
associated with David.
The last sentence should be "When the transfer completes, Alice's UA
publishes new state associating the appearance number of the former
dialog with Carol with the new dialog with David."
This paragraph isn't clear whether the incoming INVITE-with-Replaces
has no appearance number associated, or whether the AA should tag it
with the same appearance number. It seems from the rest of the I-D,
that the new dialog should have no appearance number until the dialog
that is replaced is terminated, and then Alice's UA should assign the
old appearance number to the new dialog. But that is not stated
clearly.
If Alice is the target, the incoming INVITE should not have a new
appearance number assigned. Instead, it should reuse the appearance
number associated with the dialog being replaced. If the Appearance
Agent does assign a different appearance number, when the transfer
completes, Alice should release that appearance number and use the
original appearance number associated with the dialog with Carol.
section 5.4:
The specification requires the use of a particular reason phrase,
"Appearance Number Conflict". Making the reason phrase significant is
contrary to all previous SIP usage. Wouldn't it be better to allocate
a specific 4xx response code?
section 6:
The schema gives the extension namespace as
"urn:ietf:params:xml:ns:sa-dialog-info-info" instead of
"urn:ietf:params:xml:ns:sa-dialog-info."
The indenting of the XML schema is irregular.
section 7:
appearance-param = "appearance" EQUAL *DIGIT
is probably intended to require at least one digit, which would be:
appearance-param = "appearance" EQUAL 1*DIGIT
section 8:
The design of the UI is strongly affected by the expected appearance
numbers. My belief is that the intended design is that the appearance
nubmers will be small non-negative integers. (See the item regarding
describing appearance numbers per se at the beginning of section 5.)
But there needs to be some stated policy regarding appearance numbers
that cannot be rendered by the UA. Is the UA allowed to reject them?
Section 8.1.1 appears to allow rejection, but this fact is a
significant protocol action that should not be buried in an apparently
non-normative section about user-interface design.
section 8.2:
"sip+rendering=no" should be "+sip.rendering=no" in two places.
section 9:
Two uses of "interop", which should be "interoperation".
section 12 (Security Considerations) should reference or include this text
from 5.3, as it is a life-safety consideration:
[For an emergency call, a] UA MUST never wait for a confirmed
seizure before sending an INVITE. Instead, the emergency call MUST
proceed regardless of the status of PUBLISH transaction.
section 10:
I see three different descriptions of how to determine if SA is
available for a particuar AOR:
section 4.2, REQ-1
[A UA] attempts a dialog state subscription to the AOR. If the
subscription fails, loops back to itself, or returns an error,
it knows there is no State Agent, and hence no Appearance Agent
and this feature is not implemented.
section 5.3
Upon initialization, the UA MUST subscribe to the dialog event
package of the AOR and refresh the subscription per the SIP Events
Framework. If the SUBSCRIBE request fails, then no Appearance Agent
may be present and this feature is not active for this AOR.
section 10
UAs can automatically discover if this feature is active for an AOR
by looking for the 'shared' Event header parameter in a response to a
dialog package SUBSCRIBE to the AOR, so no provisioning for this is
needed.
It would also be useful in practice if some hints were given for
interoperation with UAs that implement previous versions of this
work. This probably can be limited to methods to detect which version
a particular UA implements.
section 11.8:
The description says that a call from one UA in a group to another UA
in the group would only use one appearance number. This is not
uniform with the rest of the SA architecture and is not the behavior
of traditional key phone systems. Are you sure you want to present it
this way?
section 11.13:
Another passive:
Whenever Bob's dialog state changes, a NOTIFY is sent to the
Appearance Agent who then notifies the other other UAs in the
group.
should be:
Whenever Bob's dialog state changes, Bob sends a NOTIFY to the
Appearance Agent who then notifies the other other UAs in the
group.
You probably want to change "who" to "which".
----------------------------------------------------------------------
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
