Subject: [Sipping] Review of draft-ietf-sipping-offeranswer-02

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 01 Oct 2007 11:28:29 -0400

Draft:  Review of draft-ietf-sipping-offeranswer-02
Reviewer: Jonathan Rosenberg
Review Date: 1 Oct 2007
Status: WGLC

Summary:

This draft is basically ready for publication, but has nits that should 
be fixed before publication.

Major comments:

* the document needs an introduction which explains the purpose of the 
specification. It kind of jumps right in.

> An unreliable provisional 
>        response may include a session description in the body if the UAS has 
>        not sent a reliable response, but its session description is neither 
>        an offer nor an answer. 

This is confusing, since later on the text says that this is a preview 
answer.

The implication of the text here is that it is valid to send previews in 
unreliable responses and then the answer in a reliable provisional 
response. That is a different use case from previews in unreliable 
provisionals and then the answer in the final response. To be frank, 
this first case was not contemplated when rfc3264 was written, and I'm 
not sure we want to make it allowed. It raises some more questions like, 
once the reliable provisional is sent with the answer, and a PRACK comes 
with an offer, can you send more unreliable provisionals with previews 
of the next answer, and then the answer in the 200 to PRACK (NO!).

> When a UAC includes an SDP body in the INVITE request as an offer, it 
>        expects the answer to be received with one of the reliable responses. 
>        Other than that, no offer/answer exchanges can occur in the INVITE 3-
>        way handshake process. 

This text is confusing; since there can be O/A exchanges in PRACK and 
UPDATE that occur "in" the 3-way handshake, in that these other 
exchanges are bounded by the 3-way handshake.

> For example, in Figure 2, only the SDP in F3 is the offer. The SDP in 
>        the non-reliable response (F2) is the preview of the offer and must 
>        be the same as the offer in F3, but is not officially the offer. 

Offer previews? Again this is not something envisioned in 3264. Where in 
there is justification for this?

> UA can send an UPDATE request with a new offer if both ends support 
>        the UPDATE method. Support for the UPDATE method must be declared in 
>        an Allow header in some prior messages in the dialog. 

Not any messages (i.e., error responses) but dialog forming requests and 
responses.

Somewhere in here, should probably mention that a big drawback of doing 
O/A in 1xx-rel/PRACK is that if the UAC needs to prompt the user to 
accept or reject the offer, this can result in retransmits of the 1xx 
until the PRACK can be sent, which is bad.

> When offer2 is in a PRACK request, that is, when a PRACK request to 
>        acknowledge the reliable provisional response with an answer to the 
>        offer in the INVITE request contains a session description, UA A 
>        knows it is an offer.

This sentence is very hard to follow. It might help if you use offer1 
and answer1 specifically. Indeed, when you do that, this doesn't seem to 
make sense. I think its saying that offer2=PRACK, and that there was a 
reliable provisonal response with an answer, but the figure shows no 
answers from A to B.... I think you need to show a message sequence 
diagram for the specific case you are trying to explain.

> When offer2 is in a reliable provisional response or a successful 
>        final response, UA A knows it is not the answer to the offer1. 

It seems the opposite is true. If offer1=INVITE, and then UA A gets a 
provisional response with an SDP (or a final response), the ONLy thing 
this can be is the answer to offer1.

> For a reliable response to a re-INVITE request, UA A can 
>        detect the offer2 is not the answer1. In this case, UA A can not 
>        reject offer2 in a reliable response, it is recommended to wait for 
>        answer1 before sending a PRACK request with the answer to offer2. 
>        Note that this case only occurs when UA A, while waiting for an 
>        answer, sends an INVITE request without session description.  

As above, this is really hard to follow. You need a sequence diagram for 
this case, and more explanation. It is also unclear why there is a 
difference here in the invite and re-invite cases.

> The receipt of an offer containing "a=sendonly" or "a=inactive" and 
>        the sending of a compatible answer should not change the desired 
>        state of the recipient. 

Right - but I still think this is not being clear enough here. I think 
the text needs to be realy clear in saying, "if UA A has placed UA B on 
hold by means of an a=sendonly or a=inactive, but UA B themselves had 
not placed the call on hold, when UA B sends an offer (perhaps in 
response to an offerless INVITE to A), UA B does NOT indicate a=inactive 
or a=recvonly, but rather, whatever it would normally send had UA A not 
placed the call on hold". It should also be stated somewhere that not 
following this guidance can cause calls to be permanently on hold.

Also the text should talk about codecs to send in a new offer. This is 
particularly troubling when the new offer is sent in response to an 
offerless INVITE. I think the text should explicitly state that all 
codecs supported by the UA are to be included, not just the ones that 
were negotiated by previous O/A exchanges. Same with media types - so if 
A initially offered audio and video to B, and they end up with only 
video, and B sends an offerless INVITE to A, A's resulting offer should 
re-attempt video, by reusing the zeroed m-line used previously.

> To resolve this issue may be beyond the scope of this document and 
>        require another normative document which is for further study. 

Not just may, "is beyond" the scope.

> For example, in Figure 1, only the SDP in F6 is the answer. The SDP 
>        in the non-reliable response (F2) is the preview of the answer and 
>        must be the same as the answer in F6, but is not officially the 
>        answer.

I think the text needs to be much more clear on what it means to be 
'official' and not official. Really, the ONLY thing is that the O/A 
transaction is not closed by the preview, thus making further exchanges 
in either direction illegal until the proper answer. Thats it.

Another thing that might be useful to point out in here - it is legal to 
have UPDATE/2xx exchanges without O/A exchanges.

Nits:

> SIP (Session Initiation Protocol) Usage of Offer/Answer Model 
>                      draft-ietf-sipping-sip-offeranswer-02.txt 

Title should include a "the" between "of" and "Offer/Answer". This error 
occurs throughout the document, in fact.

Table 1: suggest that, instead of "X" and "O", use "Y" and "N" which are 
less ambiguous. In particular, "Y" means that the model can be used in 
the given situation, "N" means it cannot.

> Note that an offer/answer exchange initiated by an INVITE request 
>        must follow exactly one of the patterns 1, 2, 3, 4. 

I think this is meaning to say, "All INVITE transactions result in an 
offer/answer exchange, and that exchange will be patterns 1,2,3 or 4.". 
I think its also worth noting here that there can be additional O/A 
exchanges in the provisional responses, which are very much part of the 
INVITE transaction, and so this can be confusing.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Oct 2007 20:53:58 -0400

Hi Jonathan,

I'm way behind in my reading. I already responded to Takuya's edits in 
response to this, before reading your comments here. I've trimmed this 
down to the things I have comments on.

	Paul

Jonathan Rosenberg wrote:

>> An unreliable provisional        response may include a session 
>> description in the body if the UAS has        not sent a reliable 
>> response, but its session description is neither        an offer nor 
>> an answer. 
> 
> not sure we want to make it allowed.

AFAIK 3264 is irrelevant to this. It discusses O/A in general, not at it 
maps to sip. And so it doesn't address exchanges of SDP that aren't 
offers or answers, or how one decides what is/isn't an offer or answer.

The normative statements of that are only in 3261, 3262, 3311.

I can find no text either way about this. I'll accept your memory that 
this was never contemplated. Much of the stuff in this document is about 
things that were never contemplated - there are way more cases than 
anybody realized at the time.

Since its not forbidden, and its not inconsistent with anything, I don't 
see how this non-normative document can forbid this. It can however 
*discourage* it, while still stating what it means and what the proper 
behavior is if you happen to be on the receiving end.

> It raises some more questions like, 

It was concluded in those long ago email discussions that only the 
patterns in this document were workable.

I have long wondered if those conclusions were actually derivative to 
the normative documents or if new normative text was required to 
legislate them. We have certainly been acting on the assumption that 
those conclusions were derivative and implied. I don't know that the one 
I commented on above falls into that same category. (But I realize that 
this is shaky ground.)

>>        the non-reliable response (F2) is the preview of the offer and 
>> must        be the same as the offer in F3, but is not officially the 
>> offer. 
> 

I believe the use of the term "preview" originated with me. AFAIK the 
term appears nowhere in normative documents. I found it an equivalent, 
but hopefully clearer, explanation of the situation where a session 
description appears in an unreliable response and then must still be 
delivered later in a reliable response.

>>        the sending of a compatible answer should not change the 
>> desired        state of the recipient. 
> 

This is already stated in the last paragraph of section 4.3. Is it still 
insufficient???

> re-attempt video, by reusing the zeroed m-line used previously.

Section 4.2.5 is intended to address this. Isn't it enough?