Draft: draft-ietf-sipping-sip-offeranswer-03
Reviewer: Seth, Rajeev [rseth@sonusnet.com]/Ganesh Natarajan
Review Date: 1 Oct 2007
Review Deadline: 30 Sept 2007
Status: WGLC

Summary: Right track; minor issues.

1.	Section 2.1.2 (Invite without SDP)

Comment : If the Invite was without an offer, UAS sends the 1xx-rel with
offer1 and UAC respond with PRACK with answer1. Now if the UAS sends the same offer (offer1) in the next 1xx-rel [ As it is a "should" condition and UAC behavior is recommended "to ignore" on receiving the SDP ] UAC will ignore it, but it is no clear if the UAC need to repeat the SDP answer ( answer1) in the PRACK and may be a problem for the UAS, which may be expecting the answer SDP in the PRACK? 
Similarly
If the Invite was without offer, UAS sends the 1xx-rel with offer1 and UAC respond with PRACK with answer1. Now if the UAS sends the same offer
(offer1) in the 200 OK [ As it is a "should" condition and UAC behavior is recommended "to ignore" on receiving the SDP] UAC will ignore it, but it is not clear if the UAC need to repeat the SDP answer ( answer1) in the ACK? It is not clear.


	UAC                   	UAS  
         | F1  INVITE (no SDP) |  
         |-------------------->|  
         | F2     1xx (SDP)    | <- SDP may be included but it is notthe   
         |<--------------------|    offer. UAC may act as if it receives
         |                     |    the offer.  
         | F3 1xx-rel (SDP)    | <- The first 1xx-rel must contain anSDP  
         |<--------------------|    as the offer.  
         | F4   PRACK (SDP)    | <- A PRACK request to the first 1xx-rel
         |-------------------->|    must contain an SDP as the answer.  
         | F5 2xx PRA (no SDP) | -  
         |<--------------------| |  
         |                     | |  
         | F6 1xx-rel (SDP) | <-  If the subsequent 1xx-rel   
         |<--------------------| |  contains the same SDP as F3.  
         | F7   PRACK (SDP??)  | |  
         |-------------------->| | Does the UAC need to repeat the SDP sent 
         |                     | | in the last answer in F4
         | F8 2xx PRA          | | 
         |<--------------------| v   
         |                     |   
         | F9 2xx INV (SDP)    | <- If the  final response 
         |<--------------------|    contain the same SDP as F3.  
         | F10    ACK (SDP??)  |  Does the UAC need to repeat the SDP
         |                     |sent in the last answer F4
         |-------------------->|  
        

2.	Section 5.2 :
 "To make bad things worse, if a new offer from UAC and the final
response to re-INVITE are sent at nearly the same time, the UAS can not
know whether this new offer was sent before or after UAC received the
final failure response"

Comment :- Assuming that the new offer is in an UPDATE, which is anyway
separate offer answer exchange on a confirmed dialog, So the UAS should
have the same behavior whether the UPDATE is sent before the final
failure for the ReInvite is sent or not.  The point is fine for an
Initial INVITE but not relevant for the ReInvite as the UPDATE is always
sent on the confirmed dialog.

3.	Section 1.1 : 
   Comment :- We should define the behavior for a UAC which sends out an
INVITE without SDP and receives the first non-failure reliable response
without an Offer, due to the UAS not conforming to the draft. As this
being an open point can lead to multiple different implementations. Does
the UAC clear the call or send a PRACK and wait for the offer in
subsequent reliable responses.

4.	Section 4.3  :
   "If UA1 is first to go off hold it will then send an offer with
"a=sendrecv". The UA2 will respond with its desired state of
"a=sendonly" because that is a permitted response"
 Comment :- Here if the UAC also wants to initiate it's on unhold on
receiving the offer with sendrecv, it can send "a= sendrecv" in the
answer. It is not becoming clear from the text.

5.	There is another issue with respect to the 3264, which is not
clear. 
AS per 3264   
"RFC 2543 [10] specified that placing a user on hold was accomplished by
setting the connection address to 0.0.0.0. However, it can be useful in
an    
Initial offer when the offerer knows it wants to use a particular set of
media streams and formats, but doesn't know the addresses and ports at
the time of the offer"

Comment :- RFC 3264 does not specify that the answer should have
"a=sendrecv" media line. So if this SDP is used in an initial INVITE, UA
respond with "a= inactive", treating the initial SDP as a hold SDP,  the
call does not go through well. Can this draft address this issue.