Subject: [Sipping] Discussion of the Allen PoC P-headers draft

From: Dean Willis <[email-masked]>
Date: Wed, 22 Dec 2004 18:19:38 -0600

Sometime soon, OMA is going to ask us to perform expert review and  
publish (as informational) a draft based on:

http://www.ietf.org/internet-drafts/draft-allen-sipping-poc-p-headers 
-00.txt

This draft defines two P-headers (limited function headers with strong  
caveats) used by OMA in their push-to-talk specification, PoC  
(push-to-talk over cellular).

Please review this draft, and if you have guidance, get it to Andrew  
ASAP, as I believe he's working on a revision with more justification  
and other cleanups suggested by people who have responded privately.

A few comments on the draft here:

1) The P-Alerting-Mode header field is used in INVITE and seems to  
indicate a preference, on the part of the caller or his supporting  
applications, that the called party provide either automatic or manual  
answer modes as indicated by the header field's value.

Why is a "caller preferences" approach not usable here?

2) The P-Answer-State header field is used in 1xx or in a 200OK to  
indicate that a B2BUA generated the response on behalf of a UAS that it  
expects (but cannot be certain) will eventually answer, and that the  
media stream may be buffered "in network" pending a final answer. If  
the answer contains SDP, then the generating node is accepting the  
responsibility of buffering the transmitted media until the final  
answer is received, and will deal with the cleanup should the expected  
final answer not arrive.

I alternate between thinking this is clever, and thinking it is evil.

In the case where the response-generating node is also assuming  
responsibility for the buffering, I can't see from this draft how the  
user experience is affected by the presence of the P-Answer-State  
header. They call, get connected, and start talking. MAYBE (if the  
final leg fails) they get some kind of failure notification, after  
they've been talking awhile. Perhaps the response is used to give a  
different confirmation tone to the user, alerting them to a  
higher-than-usual probability of post-answer failure? This usage needs  
to be explained in the draft. I also don't understand the use case here  
with a non-SDP 200OK, although it makes sense with a 183.

In the case where the response-generating node is NOT buffering and we  
insert no SDP, we appear to be using this header field to indicate that  
an upstream node should take responsibility for the buffering, and  
should consequently insert SDP into the response and act as a B2BUA for  
the call. It seems if this occurred, that the response sent back  
upstream from the now-buffering node would need to be a 200 OK, and not  
an intermediate 18x type message. But there's a problem -- since nobody  
with knowledge of the terminating client's capabilities inserted SDP,  
we can't use the "answer" model to determine the client's actual  
capabilities, so we could end up with an unresolvable codec mismatch.

Here's the scenario: UA-A places a PoC call through S-1 and S-2 to UA-B.

UA-A and S-1 only understand AMR, and UA-B only understands the EVRC  
encoding.

S-2 knows that UA-B supports auto-answer, is registered, is not busy,  
and is expected to be able to receive the call (we don't go into HOW it  
knows this). So S-2 returns a 183 with a P-Answer-State=unconfirmed and  
no media, and S-1 decides to buffer the call, returning a 200OK with  
media indicating that it is prepared to receive AMR. UA-A starts  
talking, and S-1 starts buffering. Eventually, UA-B answers, and sends  
a 200 OK containing EVRC SDP back to S-2 and thence to S-1. Rather than  
playing the buffered media on toward UA-B, S-1 is now stuck -- it has  
buffered AMR media, UA-B only understands EVRC, and S-1 doesn't know  
how to convert. This is precisely the reason we have end-to-end  
offer-answer.

Perhaps I read the draft wrong, but if so it could use some clarity on  
this matter, and if not, the mechanism for preventing this error  
condition needs to be better explained. I think that if the usage of  
the header in provisional versus final responses were more clearly  
specified, that this error condition would be either precluded (or  
discovered to be unavoidable, indicating a clear flaw in the design).

3)  The draft has normative text in 4.2.2.1 saying:

"A UAC that receives a 1XX or 2XX response without a P-Answer-State  
Header or containing a P-Answer-State header field containing the  
parameter "Confirmed" SHALL treat it as a "confirmed response"."

I don't believe that it is reasonable for a P-draft to make normative  
statements about how the absence of a a P-header impacts a UAC in  
general. In the general case, a 200 OK is a confirmed response. Perhaps  
something along the lines of:

"A UAC conformant to this specification that receives a response not  
containing a P-Answer-State header field proceeds as if that response  
contained a P-Answer-State header field with the value "confirmed"."

4) Somebody who understands early media much better than I do needs to  
review this draft carefully. Note that we have new RFCs on the topic,  
RFC 3959 and 3960.

--
Dean Willis

_______________________________________________
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

---

From: "Andrew Allen" <[email-masked]>
Date: Thu, 23 Dec 2004 01:42:03 -0500

Just to summarise what changes are intended in the 01 version from 00:

1. Addition of a section on Requirements for this functionality.

2. Addition of a section discussing the alternate approaches to defining new headers that were considered.

3. Addition of support for a server in the Proxy Role to optionallly support the P-Alerting-Mode and P-Answer-State headers.

We hope to have the 01 version submitted in mid January after the OMA PoC working group has had a chance to review and comment on the proposed revision.

Merry Christmas
Andrew
--------------------------
Andrew Allen
Manager Standards
Research In Motion Ltd
BlackBerry Mobile  +1 847 809 8636
http://www.rim.com/

Sent from my BlackBerry Wireless Handheld

-----Original Message-----
From: Dean Willis <[email-masked]>
To: [email-masked] <[email-masked]>; Andrew Allen <[email-masked]>
CC: Rohan Mahy <[email-masked]>; Gonzalo Camarillo <[email-masked]>; Ileana Leuca <[email-masked]>
Sent: Wed Dec 22 19:19:38 2004
Subject: Discussion of the Allen PoC P-headers draft

--
Dean Willis

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