My apologies for dealing with this earlier. I've been neglecting this
draft.
Fundamentally, I think the draft is in great shape. The only
significant change is that I think a summary of the "retain option"
procedures and considerations should be added so the reader can see
how it affects the procedures (and how gateways to the PSTN handle
"retain").
Only items 2 and 19 have technical content; the remainder are
editorial. Item 2 is a request to insert a short section summarizing
the "retain option" processing. The relevant information is scattered
throughout the draft and it could be difficult for an implementer to
find all the fragments that are relevent. Item 19 is probably an
editing error, but currently the ABNF doesn't match the text.
item 1) headers
Can you abbreviate my affiliation on the front page to "Ariadne"? I
you are using XML2RFC, you can use the 'abrev' attribute of the
<organization> element:
<organization abbrev='ISI'>
USC/Information Sciences Institute
</organization>
item 2) overall
The procedures regarding the retain option are scattered throughout
the document in a way that makes it difficult to see how it is
handled. It seems to me that it would be helpful to add a summary of
retain option processing as a section, perhaps at the end of section
4. This allows deleting the last paragraph of section 4.2, which is
vague when it stands alone.
4.5 Summary of retain option procedures
When the call completion call fails there are two possible options:
the CC feature has to be activated again by caller's agent
subscribing to callee's monitor, or CC remains activated and the
original CC request remains in the queue.
If the callee's monitor operates in the latter way, it is said to
support the retain option. Callee's monitors SHOULD support the
retain option. If a monitor supports the retain option, it SHOULD
provide the cc-service-retention header in its call-completion
events. The caller's agent can use this header to know that this
monitor supports the retain option.
If a callee's monitor does not support the retain option (e.g., if
it is a gateway to a network device whose CC functionality does not
support the retain option), it SHOULD NOT provide the
cc-service-retention header. In addition, after a failed CC call
that causes the CC request to be deleted from the queue, the
monitor MUST terminate the corresponding agent's subscription to
inform the agent that its CC request is no longer in the queue.
After a failed CC call, the caller's agent MAY terminate its
subscription, to inform the monitor that it is terminating its CC
request. After a failed CC call, the caller's agent MAY receive a
termination of its subscription from the callee's monitor, if the
monitor has terminated the agent's CC request. In either case, the
agent MAY create a new subscription (as described in section 6.2)
to create a new CC request for the same original call. The agent
SHOULD avoid terminating one subscription and creating a new one if
the caller's monitor has indicated support of the retain option.
I have used SHOULD to describe procedures which are desirable but are
not required for correct functioning. In particular, the
cc-service-retention value does not have to be correct for a
properly-implemented agent and monitor to interact correctly. This
gives us some freedom in situations where a gateway cannot discern
accurately whether the callee supports the retain option or not.
Pure SIP agents and monitors can implement all the SHOULD behaviors,
so in the pure-SIP case, CC is done with the retain option.
item 3) section 4.1
The callee's monitor maintains information about the set of INVITEs
received by the callee's UA(s) considered unsuccessful by the caller.
Strictly speaking, the monitor can't know if an INVITE is considered
unsuccessful by the caller. This wording might fix that:
The callee's monitor maintains information about the set of INVITEs
received by the callee's UA(s) that the caller might consider
unsuccessful.
item 4) section 4.2
The callee's monitor
keeps a list or queue of the caller's agent's subscriptions,
representing the requests from the caller's agent to the callee's
---------------------------------------------------^
should be "agents"
monitors for call-completion services.
----------^
should be "monitor"
item 5) section 4.2
When the callee's monitor determines the callee and/or callee's UA
insert "are" here
available for a CC call, it selects a caller to execute the CC call
and sends a call-completion event update (''cc-state: ready'') via a
---------------------------------------------^^
this should probably use " rather than ''
NOTIFY request to the selected caller's agent's subscription, telling
it to begin the CC call to the callee's UA.
item 6) section 4.2
When the call completion call fails there are two possible options:
the CC feature has to be activated again by caller's agent
subscribing to callee's monitor, or CC remains activated and the
original CC request retains its position in the queue if retain
option is supported.
This is kinda vague. See item 2.
item 7) section 4.3
There is no interaction between call completion and automatic redial,
-----------------------------------^
There is a risk of confusion. I think this could be clarified as
There is no interaction between automatic redial and call
completion (as defined in this document), as they use different
event packages and specify different behaviors regarding the
events.
item 8) section 5
Each CCE has an availability state, determined through caller's
presence status at the callee's monitor. A presence status of
''open'' represents CCE's availability state of 'available' and a
---^^
this should probably use " rather than ''
presence status of "closed" represents CCE's availability state of
'unavailable'.
item 9) section 5
A CCE is identified by the
request-URI (if it was taken from a call-completion event
--------------^^^^^^^
I think this would be clearer as
request-URI of the PUBLISH request (if that URI was taken from a
call-completion event
item 10) section 5
notification which identifies the CCE) or the From URI of the request
(matching the From URI recorded in the CCE).
state of the CCE to 'not-available' (suspend).
------------------------^^^^
Other locations in the text use the value 'unavailable'.
item 11) section 7.1
The callee's monitor SHOULD insert a URI in the Call-Info header
Since the first sentence of the previous paragraph specifies "MUST"
regarding inserting Call-Info, this "SHOULD" would be better specified
as "MUST".
item 12) section 7.1
The 'm' parameter defines the "mode" of call completion. The "m=NR"
parameter indicates that it failed due to lack of response, the
----------------------------^^
this "it" should be "the original call"
"m=BS" parameter indicates that it failed due to busy subscriber, and
-----------------------------------^^
the latter two "it"s are probably unambiguous
the "m=NL" parameter indicates that it failed due to non registered
---------------------------------------^^
subscriber (no devices are registered for the AoR contacted). The
item 13) section 7.4
The callee's UA(s) and the callee's monitor may give the CC call
precedence over non-CC calls by evaluating the presence of the 'm'
URI parameter and the From header of the INVITE request.
-----------------^^^
I don't think this "and" is correct. One possibility is:
The callee's UA(s) and the callee's monitor may give the CC call
precedence over non-CC calls by evaluating the presence of the 'm'
URI parameter in the From header of the INVITE request.
item 14) section 7.5
the retain option and terminate the subscription along with the queue
if it doesn't support the retain option. Similarly, if the CC call
I think "queue" is supposed to be "CCE".
item 15) section 7.5
completion" events, or any URI it returns as the "URI" line of the
---------------------------------------------^^
I think this is supposed to be "in".
item 16) section 7.5
The receipt of the PUBLISH request initiates a presence event state
for the caller's identity at the presence server functionality of the
callee's monitor as specified in [RFC3903] , together with a logical
presence server if this has not been done before for another call.
Note: The presence server may initiate a presence event state for the
caller's identity at the receipt of SUBSCRIBE request as well,
dependent on the implementation.
These paragraphs do not match the following paragraph from 4.2:
Upon receiving a SUBSCRIBE request from the caller's agent, the
callee's monitor instantiates a presence state for the caller's UA
which can be modified by the caller's UA to indicate its availability
for CC call. The status at the presence upon instantiation is
"open".
Also, this section doesn't explicitly specify what is happening: The
first sentences need to say that suspend requests are PUBLISH with
status 'closed'. Somewhere in this section it needs to be mentioned
that the CCE is set to 'unavailable'.
item 17) section 7.6
Similarly to 7.5, the first sentences need to say that suspend
requests are PUBLISH with status 'closed'. Somewhere in this section
it needs to be mentioned that the CCE is set to 'unavailable'.
The final sentence seems to be incorrect in some cases:
If the callee
is not busy and there is no entry in the CC queue which is currently
being processed, the callee's monitor MUST process the queue as
described in section 7.3 above.
because the callee's policy may not allow any CCE to be recalled at
this time. (For example, if a recall for that CCE has recently
failed.)
Assembling these changes, I think something like this would be better:
A CC request is resumed by a PUBLISH request from caller's agent as
described in section 6.6, that is, containing a 'state' of 'open'.
The presence event state for the caller's identity at the presence
server functionality of the CC monitor MUST be updated as described
in [RFC3903], and the corresponding CCE's availablity state must be
set to 'available'. This may cause the CCE to be selected for
recall under the monitor's policy.
item 18) section 8
In the second example, I see two uses of "Content-Type: 'app/pidf'".
I think this should be spelled out as "Content-Type: application/pidf".
For the bodies, I think it would be safer to spell out the PIDF a bit
more:
| Body: ...<status><basic>open</basic></status>...
item 19) section 10.3
The cc-URI line provides a URI (possibly in the form of a name-addr)
but it also says
cc-URI = "cc-URI" HCOLON addr-spec
There are three choices for the syntax of the value of cc-URI:
addr-spec
this eliminates the possibility of generic-params ("header parameters")
name-addr
this allows generic-params but requires that we rephrase the
first sentences of the section, as a name-addr isn't a URI, strictly
speaking.
addr-spec / name-addr
this alternative is used a lot in headers, but we would have
to mention that the rule in RFC 3261 section 20.10 applies:
Even if the "display-name" is empty, the "name-addr" form MUST be
used if the "addr-spec" contains a comma, semicolon, or question
mark. There may or may not be LWS between the display-name and the
"<".
Looking at the old drafts, we changed the value from "(name-addr /
addr-spec)" to "addr-spec" in -15. So the ABNF is probably correct.
So we should reduce the text of this section to just the first three
sentences:
The cc-URI line provides a URI (possibly in the form of a name-addr)
which the agent SHOULD use as the request-URI of the CC recall INVITE
and the suspend/resume PUBLISH. It SHOULD be provided in all
NOTIFYs. The URI SHOULD be globally routable and SHOULD uniquely
identify the CCE in question.
item 20) section 12.2
Intended usage: LIMITED USE
We could expand this to:
Intended usage: Within the procedures of RFC XXXX.
item 21) section 12.4
Reference: [RFC3261].[RFC5367][[RFC XXXX]]
-----------------------^
I think this is intended to be a comma.
Dale