Subject: Re:[Sipping] RE: Comments on draft-ietf-sipping-sip-offeranswer-03.txt

From: Takuya Sawada <[email-masked]>
Date: Tue, 4 Sep 2007 22:32:10 +0900

Hi, Nataraju,

Thanks.
Response inline.

> ----------------
> From: "B, Nataraju" <[email-masked]>
> Date: Tue, 4 Sep 2007 14:49:59 +0530
> To: <[email-masked]>, <[email-masked]>
> Cc: [email-masked]
> Subject: [Sipping] RE: Comments on draft-ietf-sipping-sip-offeranswer-03.txt
> 
> Few more minor comments
> 
> 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.
> 
Yes, we can add this.

> 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'

This is not intended to be a standards track document.
Then I do not think RFC 2119 key words should be applied (Am I right?).
If so, I will change 'may not' to 'must not'.
Or 'MUST NOT' with referencing RFC 3264.

> Sec 4.3. Hold and Resume of media
>     
>       If UA2 has been "placed on hold" by UA1 via receipt of "a=inactive", 
>       and subsFrom [email-masked] Tue Sep 04 09:34:12 2007
To: [email-masked]
Subject: Re:[Sipping] RE: Comments on draft-ietf-sipping-sip-offeranswer-03.txt
From: Takuya Sawada <[email-masked]>
Date: Tue, 4 Sep 2007 22:32:10 +0900
Cc: [email-masked], [email-masked]

Hi, Nataraju,

Thanks.
Response inline.

> ----------------
> From: "B, Nataraju" <[email-masked]>
> Date: Tue, 4 Sep 2007 14:49:59 +0530
> To: <[email-masked]>, <[email-masked]>
> Cc: [email-masked]
> Subject: [Sipping] RE: Comments on draft-ietf-sipping-sip-offeranswer-03.txt
> 
> Few more minor comments
> 
> 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.
> 
Yes, we can add this.

> 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'

This is not intended to be a standards track document.
Then I do not think RFC 2119 key words should be applied (Am I right?).
If so, I will change 'may not' to 'must not'.
Or 'MUST NOT' with referencing RFC 3264.

> 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".

now be either "inactive" or "sendonly" 

 or

now be "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.
> 
Do you mean roll back to one before the re-INVITE transaction was initiated?
Or really mean one negotiated during initial INVITE transaction?

If the latter, I do not agree. 

If the former, it is controversial. Then we decided to make it beyond the scope
of this document and put it in '5. Remaining Issues ...'
At least so far, we reach the consensus that we can not decide which one is the
right behaviour base on the exidting RFCs, unfortunately.

> 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.
> 
In my personal feeling, I feel option-1 iwould be better in this case.
I do not know which is easy for implementation.

Probably we need to equently 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".

now be either "inactive" or "sendonly" 

 or

now be "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.
> 
Do you mean roll back to one before the re-INVITE transaction was initiated?
Or really mean one negotiated during initial INVITE transaction?

If the latter, I do not agree. 

If the former, it is controversial. Then we decided to make it beyond the scope
of this document and put it in '5. Remaining Issues ...'
At least so far, we reach the consensus that we can not decide which one is the
right behaviour base on the exidting RFCs, unfortunately.

> 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.
> 
In my personal feeling, I feel option-1 iwould be better in this case.
I do not know which is easy for implementation.

Probably we need to have more opinions from the implementation point
of view. That is one of the reasons why we take a long last call
period for this document.
> 
> 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.
> 
I will add this in Sec.1.1.

Regards,
Takuya

> Thanks, 
> Nataraju A B 
> 
> _____________________________________________
> From: B, Nataraju 
> Sent: Monday, September 03, 2007 2:43 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Comments on draft-ietf-sipping-sip-offeranswer-03.txt
> 
> All, 
> 
> Here are few comments about the draft draft-ietf-sipping-sip-offeranswer-03.txt.
> 
> 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 窶・汚x 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.
> 
> Thanks,
> Nataraju A B
> Sonus Networks India Pvt Ltd.,
> 
> 
> 
> _______________________________________________
> 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
> 
> 
> 

--------
Takuya Sawada
KDDI Corporation (KDDI)
Garden Air Tower, 3-10-10, Iidabashi, 
Chiyoda-ku, Tokyo 102-8460, Japan
Tel: +81-3-6678-2997
Fax: +81-3-6678-0286
[email-masked]

_______________________________________________
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 [email-masked] Tue Sep 04 0have more opinions from the implementation point
of view. That is one of the reasons why we take a long last call
period for this document.
> 
> 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.
> 
I will add this in Sec.1.1.

Regards,
Takuya

> Thanks, 
> Nataraju A B 
> 
> _____________________________________________
> From: B, Nataraju 
> Sent: Monday, September 03, 2007 2:43 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Comments on draft-ietf-sipping-sip-offeranswer-03.txt
> 
> All, 
> 
> Here are few comments about the draft draft-ietf-sipping-sip-offeranswer-03.txt.
> 
> 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 窶・汚x 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.
> 
> Thanks,
> Nataraju A B
> Sonus Networks India Pvt Ltd.,
> 
> 
> 
> _______________________________________________
> 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
> 
> 
> 

--------
Takuya Sawada
KDDI Corporation (KDDI)
Garden Air Tower, 3-10-10, Iidabashi, 
Chiyoda-ku, Tokyo 102-8460, Japan
Tel: +81-3-6678-2997
Fax: +81-3-6678-0286
[email-masked]

_______________________________________________
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: Takuya Sawada <[email-masked]>
Date: Tue, 4 Sep 2007 22:36:26 +0900

Hi,

Sorry, I missed one thing and left imcomplete...

> now be either "inactive" or "sendonly" 

I can not remember which one is originally intended.

Probably Paul can answer.

Regards,
Takuya

--------
Takuya Sawada
KDDI Corporation (KDDI)