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

From: "Andrew Allen" <[email-masked]>
Date: Wed, 3 Aug 2005 09:53:41 -0400

Dale,

Thanks for reviewing the draft and taking time to propose some
solutions.

Apologies for the delayed response.

My comments are inline.

Andrew

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Dale Worley
> Sent: Thursday, July 28, 2005 5:42 PM
> To: Sipping (E-mail)
> Subject: [Sipping] Comments on the P-Answer-State header
> 
> 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.

The thinking here is that it is always possible that some other node
further downstream may also decide to do buffering and if so then it
would indicate an Unconfirmed in the 200 OK it returns. The Confirmed is
really included for completeness but enables you to be sure that the 200
Ok response is a confirmed response rather than an unconfirmed response
from a node that doesn't support the extension.
> 
> 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?)

The following text in the draft indicates that this is application
specific and out of scope but does give some suggestions:
"How a UAC confirms whether the media was or was not
   received by the final destination when it his received a 2XX
   "unconfirmed response" is application specific and outside of the
   scope of this document.  If the application is a conference then the
   mechanism specified in [2] could be used to determine that the
   invited user joined.  Alternatively a BYE request could be received
   or the media could be placed on hold if the final destination UAS
   does not accept the session."
> 
> 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?

Again as above.
> 
> 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.

OK will try and add some text on this. Currently OMA PoC only supports
audio but in the future multimedia will be supported and the concept
then is that the PTT Server is informed of the AnswerMode preferences
for each media type.
> 
> 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.
> 
The examples do show that the tags are different between each node and
the text discussed B2BUA behavior. Is there some specific additional
text that you think needs to be added?

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

The flow is based on the OMA PoC Pre-established Session Architecture.
In this case the Node receiving the REFER does not terminate the
existing dialog. Where in RFC 3515 does it specify that the REFER
recipient replaces the existing dialog? The usage in OMA is similar to
the use of REFER to request a focus to invite another user to a
conference.
> 
> 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".

OK I will fix that.
> 
> 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.

OK I will try and improve.
> 
> 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.

OK I can re-title this.
> 
> 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.

I need to review in detail your proposed text for inclusion in the draft
but I will take this on board.
> 
> 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.
> 
OK I can add a clear definition as you suggest.

> 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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

_______________________________________________
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