Draft: Review of draft-ietf-sipping-offeranswer-03 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.