Draft: draft-ietf-sipping-sip-offeranswer-03.txt Reviewer: B, Nataraju [bnataraju@sonusnet.com] Review Date: 9/3/2007, 9/4/2007 Review Deadline: 9/10/2007 Status: WGLC Summary: This draft is on the right track but has open issues, described in the review. Comments: 1. In Table-2 option 3 seems to be redundant and is not conveying any useful information or the intended meaning is not been mentioned clearly in the this section about offer rejection. Offer Rejection ----------------------------------------------------- 1. INVITE Req. 488 INVITE Response 3. INVITE Req. 488 INVITE Response (same as Pattern 1.) Table 2. Rejection against an Offer 2. in sec 3.1. Message Crossing Case Handling, A B |offer1 | |----------------->| | answer1| |<------\ /-------| | \/ | | /\ offer2| |<------/ \-------| The paragraph is relatively difficult to understand. Can we divide this logic into few more sections so that it would be easy to describe the expected behavior, which include offer/answer in which request/response? For example offer1 – INVITE request answer1 – 1xx response offer2 – UPDATE request Or offer2 – PRACK request ………………… OR Following diagrammatic presentation would convey the information better. A B |offer1 (INV) | |----------------------------->| | answer1(100-rel)| |<--------------\ /-----------| | \/ | | /\ offer2(UPD)| |<--------------/ \-----------| We can mention the above set of information per scenario so that any one can easily understand the logic behind each of the scenarios. When offer2 is in an UPDATE request or a re-INVITE request Behavior-1 ………… When offer2 is in a PRACK request Behavior-2 ………… When offer2 is in a reliable provisional response or a successful final response Behavior-3 ………… Probably by drawing a separate diagrams for different scenarios would help explain the logic in simpler terms and easy for any one to understand. Similarly we can update the section 3.2 also. -----Following comments posted on 9/4/2007-------------------------------- Sec 4.2.4. Answering when Initial INVITE had no Offer        When a UAC has sent an initial INVITE without an offer, and then        receives a response with the first offer, it should answer in the        same way as a UAS receiving an initial INVITE with an offer. Comment: We can add one more sentence to mention, this offer (one sent in 1st reliable response) is also same as what would have been offered when this sip endpoint initiates an offer/answer negotiation. Sec 4.2.5. Subsequent Offers and Answers        o The number of m-lines may not be reduced in a subsequent offer.           Previously rejected media streams must remain, or be reused to           offer the same or a different stream. Comment: This requirement should have been mentioned as MUST requirement. Change “may not” to “MUST NOT” Sec 4.3. Hold and Resume of media           If UA2 has been "placed on hold" by UA1 via receipt of "a=inactive",        and subsequently wants to initiate its own hold, also using        "a=inactive", it need not send a new offer, since the only valid        response is "a=inactive" and that is already in effect. However, its        local desired state will now be either "inactive". This affects what        it will send in future offers and answers. Comment: Incomplete sentence “However, its local desired state will now be either "inactive".” Sec 5.2 Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE Transaction        UAC                   UAS          | session established |          |<===================>|          |                     |          | F1  re-INVITE (SDP) |          |-------------------->|          | F2 1xx-rel (SDP)    |          |<--------------------|          | F3   PRACK          | <- PRACK request may include new offer and          |-------------------->|    can complete the offer/answer with          | F4 2xx PRA          |    the answer in 2xx PRACK response.          |<--------------------|          |                     | <- UPDATE method can update the session          |                     |    status before receiving the final          | F5 4xx/5xx/6xx INV  |    response to re-INVITE request (F1).          |<--------------------|          | F6     ACK          |          |-------------------->|  Issue: What is the correct session status          |                     |         after re-INVITE transaction.      Comment: Here probably dropping all the offer/answer negotiations transacted during open re-INVITE, and roll back to one negotiated during initial INVITE transaction. Let the session status be committed only when the re-INVITE transaction is completed successfully. One more scenario to be addressed:        UAC                   UAS          | session established |          |<===================>|          |                     |          | F1  re-INVITE (SDP) |          |-------------------->|          | F2 1xx-rel (SDP)    |          |<--------------------|           | F3   PRACK          | <- PRACK request may include new offer and          |-------------------->|    can complete the offer/answer with          | F4 2xx PRA          |    the answer in 2xx PRACK response.          |<--------------------|           | F5  UPDATE (SDP)    |          |-------------------->|          | F6 200-UPD (SDP)    |          |<--------------------|           | F7  UPDATE (SDP)    |          |<--------------------|          | F8 488-UPD (SDP)    |  offer in UPDATE is not acceptable (o/a failed)          |-------------------?|           | F9 2xx INV          |    Success response to re-INVITE request (F1).          |<--------------------|          | F10   ACK           |          |-------------------->|  Issue: What is the correct session status          |                     |         after re-INVITE transaction. Here there are two alternatives for session status: Option-1: Commit the session status to one negotiated with UPD/200 F5/F6. Option-2: Commit the session status to one negotiated with UPD/200 F1/F2. I feel option-2 would be better, since that makes easy to implement and easy to roll back in case of subsequent o/a failure before the re-INVITE transaction completes. Generic comment: Also, it might be worth mentioning the sentence “There could be ONLY ONE offer/answer negotiation open at any point in time”. This is inherited from 3264, but it’s the very basic and necessary requirement for all these scenarios. Probably Sec 1.1 is a better place for this one to mention.