Subject: [Sipping] Comments on the P-Answer-State header

From: "Dale Worley" <[email-masked]>
Date: Thu, 28 Jul 2005 17:41:54 -0400

Comments on "The P-Answer-State Header",
draft-allen-sipping-poc-p-answer-state-header-00.

This I-D isn't as mature as the BLA draft, so I won't try to be a
copy-editor.  But there are some technical issues that I think need
some consideration, and some overall presentation issues that could be
addressed at this point.

Technical

1. Given that a 200 response always permits the buffered media to be
played out, it isn't clear what additional function "P-Answer-State:
Confirmed" in a 200 performs.  Perhaps this is to make the operation
of P-Answer-State parallel an existing PoC facility?  That would be a
legitimate reason for something that would otherwise be redundant, but
that needs to be explained.

2. It would help if the overview and the examples explicated some
further cases:

A. When the caller's UA (unexpectedly) returns a failure response.
(Given that the caller's UA has already received a 200 response, how
is the failure reflected to the caller's UA?)

B. Similarly, if the caller's UA remains ringing for a long time, or
generates no response, how is it reflected to the caller's UA?

3. In order to use "P-Answer-State: Unconfirmed", one of the
intermediate SIP agents has to guess at the media that will be
acceptable to the called UA.  This is probably not difficult in the
PoC environment, but it should be explicitly mentioned somewhere as a
prerequisite for using P-Answer-State.

4. The provisional response bearing "P-Answer-State: Unconfirmed" must
provide a to-tag, but the SIP agent producing it cannot predict the
to-tag that will be generated by the caller's UA.  Officially, this
makes the provisional response be in a different dialog than the
confirmed dialog to the caller's UA.  This is probably not a problem
in any practical situation, but implementors should probably be warned
of it.

5. I'm not sure I understand the call flow in section 6.2.  In it, a
REFER is sent within the dialog established by INVITE F1.  But the
semantics of such an action are well-defined:  The recipient is
commanded to terminate the current dialog and replace it (from the
recipient's user's point of view) with a new dialog to the Refer-To
URI.  This is not the effect that is desired, nor the one that is
illustrated in section 6.2.  But it is the one that would result if I
took an ordinary SIP phone and pressed the "BLIND TRANSFER" key and
entered a URI to send a REFER.

Or perhaps not -- I can now count three different expectations of what
user experience should result from an in-dialog REFER.  Perhaps an
additional parameter is needed for REFER, to state what should happen
to the media streams / user-level connections?

Presentation

6. In the Table of Contents, there is no consistency in the
capitalization style of items.  E.g., section 5 is titled "Formal
Syntax", but section 9 is titled "Changes since previous version".

7. I think that more attention needs to be paid toward ease of
reading.  E.g., the second sentence of the last paragraph of section 3
contains 11 verbs (by my count).  This is OK if the user is already
familiar with the subject matter, but as this is an introductory
section, it might be a barrier to understanding.

8. Section 3 is titled "Overview", but it reads as if it should be
titled "Background", since it doesn't give an overall view of how the
extension operates.

9. Here is a possible overview for the extension:

    The purpose of this extension is to support a trick that makes it
    possible for the network to provide a faster push-to-talk experience,
    viz., an intermediate SIP agent provides a 200 response before the
    called UA does, and then the agent buffers the media generated by the
    calling UA for replay to the called UA when it answers.  But the
    intermediate agent only wants to do this if there is a high
    probability that the called UA is in Automatic Answer mode.  It is
    likely that intermediate SIP agents near the called UA have up-to-date
    knowledge of the answering mode of the called UA, and due to the
    nature of the cellular network, they can pass upstream an indication
    of the called UA's answering mode faster than the called UA can
    deliver an automatically generated 200 response.

    Thus, when a SIP agent forwards an INVITE and knows that the called UA
    is likely to be in Automatic Answer mode, it also generates a 183
    response containing a "P-Answer-State: Unconfirmed" header to signal
    to upstream SIP agents that they may buffer the caller's media.

    A SIP agent that wishes to buffer the caller's media, upon seeing the
    provisional response containing "P-Answer-State: Unconfirmed" absorbs
    it and generates a 200 response for the caller's UA with appropriate
    SDP.

    When the called UA generates a 200 response, the SIP agent that
    generated the provisional response containing "P-Answer-State:
    Unconfirmed" adds to the 200 response a header "P-Answer-State:
    Confirmed".  The 200 response is absorbed by the SIP agent that is
    buffering the caller's media, as it has already generated a 200
    response.  The buffering SIP agent now starts un-buffering the media.

10. The use of the phrases "unconfirmed indication" and "confirmed
indication" seem like they would be confusing to an IETF audience.
The terms "confirmed" and "unconfirmed" are used only in regard to
dialogs, not the information contained in messages.  "Confirmed
indication" is particularly confusing, as the only "confirmed
indication" is a message containing the header "P-Answer-State:
Confirmed", which must be contained in a 200 response, which makes it
unclear why there is a new name invented for it.

One possibility would be to eliminate these terms entirely.  But I
suspect from their heavy use (and lack of a really integrated
definition) that the term has a rich meaning in the PSTN world.  If
so, early in the I-D there should be a definition of the term that
fleshes out the denotations and connotations of these terms.

Dale

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