Draft:  draft-ietf-sipping-sip-offeranswer-04.txt
Reviewer: B, Nataraju [bnataraju@sonusnet.com]
Review Date: 11/20/2007, 12/2/2007 (follow-up)
Review Deadline: 11/20/2007
Status: Post-WGLC 


Follow-up (12/2/2007):
========================

The modifications looks fine with me.

Regards,
Nataraju A B
 
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Friday, November 30, 2007 8:55 PM
> To: Nataraju Alilughatta basavaraju (WT01 - TES-Mobility & Carrier 
> Infrastructure)
> Cc: tu-sawada@kddi.com; sipping@ietf.org
> Subject: Re: Comments on draft -
> draft-ietf-sipping-sip-offeranswer-04.txt
> 
> 
> 
> nataraju.basavaraju@wipro.com wrote:
> >> "Note that an offer/answer exchange initiated by an INVITE
> request
> >> must follow exactly one of the patterns 1, 2, 3, 4.
> >>  <snip>
> >>  Pattern 2 and pattern 4 can occur only when the INVITE
> request does
> >> not include an offer. 'The first reliable non-failure
> message' must
> >> have an offer if there is no offer in the INVITE request. 
> This means
> >> that UA which receives the INVITE request without an offer must 
> >> include an offer in the first reliable response with 100rel 
> >> extension. If no reliable provisional response has been
> sent, the UAS
> >> must include an offer when sending 2xx response."
> >>
> > 
> > The complete paragraph makes sense, but I still think 1st sentence 
> > does confuse. Particularly the word ***AND*** confuses even though 
> > subsequent sentences makes the complete logic clear.
> > I was thinking changing the phrase from "Pattern 2 AND
> pattern 4" to
> > "Pattern 2 OR pattern 4" makes it clear enough.
> > 
> > If I am still confusing you, you can ignore this comment since the 
> > complete paragraph makes it clear about delayed O/A.
> 
> I get your point but the paragraph seems a little awkward to me that 
> way. What about:
> 
>     Note that an offer/answer exchange initiated by an INVITE request
>     must follow exactly one of the patterns 1, 2, 3, 4. When an 
> initial
>     INVITE causes multiple dialogs due to forking, an offer/answer
>     exchange is carried out independently in each distinct dialog.
>     When an INVITE request contains no offer, only pattern 2 or
>     pattern 4 apply. 'The first reliable non-failure message' must
>     have an offer if there is no offer in the INVITE request. 
> This means
>     that UA which receives the INVITE request without an offer must
>     include an offer in the first reliable response with 100rel
>     extension. If no reliable provisional response has been sent, the 
> UAS
>     must include an offer when sending 2xx response.
> 
> This only changes the ordering of the words, but it makes it more 
> consistent with the earlier part of the paragraph and seems slightly 
> clearer to me.
> 
[ABN] This looks fine with me... At least no confusion...:)

> 	Paul
> 


Comments (11/20/2007):
=========================

Here are few comments on the draft
draft-ietf-sipping-sip-offeranswer-04.txt

Issue-1: contradicting statements
Sec 2.1
   Note that an offer/answer exchange initiated by an INVITE request 
   must follow exactly one of the patterns 1, 2, 3, 4..............

Comment: The 1st sentence seems to convey that exactly one of 1,2,3,4 patterns which is not really true and also contradicts with what is mentioned in sec 3.1.1. 
Solution: Let us remove this initial confusing statement

Issue-2: contradicting statements
Sec 2.1. Offer/Answer Exchange Pairs in SIP Messages
   Pattern 2 and pattern 4 can occur only when the INVITE request does 
   not include an offer. 'The first reliable non-failure message' must 

Sec 3.1.2. INVITE request without SDP

   UAC                   UAS  
     | F1  INVITE (no SDP) |  
     |-------------------->|  
     | F2     1xx          |  
     |<--------------------|     
     |                     |     
     | F3 1xx-rel (SDP)    | <- The first 1xx-rel must contain an SDP  
     |<--------------------|    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 (no SDP) | <- The subsequent 1xx-rel should not   
     |<--------------------| |  contain an SDP.  
     | F7   PRACK          | |  
     |-------------------->| | UAC can send a new offer in an UPDATE  
     | F8 2xx PRA          | | request after F4.  
     |<--------------------| v   
     |                     |   
     | F9 2xx INV (no SDP) | <- The final response should not  
     |<--------------------|    contain an SDP.  
     | F10    ACK          |  
     |-------------------->|  
    
        Figure 2 Example of Offer/Answer with 100rel Extension (2) 

Comment: Sec 2.1 and F9/F10 contradicts each other.
Solution:
Remove the following statements completely from sec 2.1

   Note that an offer/answer exchange initiated by an INVITE request 
   must follow exactly one of the patterns 1, 2, 3, 4. When an initial 
   INVITE causes multiple dialogs due to forking, an offer/answer 
   exchange is carried out independently in each distinct dialog. 
   Pattern 2 and pattern 4 can occur only when the INVITE request does 
   not include an offer.

Issue-3:
Sec 4.1 Message Crossing Case Handling 

   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
Comment: if we provide the cross reference for Figure-4 would make the content more meaningful and readable also.

   When offer2 is in a reliable provisional response or a successful 
   final response, UA A knows it is not the answer to the offer1. For a 
   reliable response to an initial INVITE request, this case never
Comment: if we provide the cross reference for Figure-5 would make the content more meaningful and readable also.

Issue-3: 
In sec 4.1 and figures 4 and 5, its mentioned that UA-A has to wait for some time before act upon with offer-2. the details about timer duration is an open issue. Can this be added to Sec 6 - Open issues.