Subject: [Sipping] Comments on draft - draft-ietf-sipping-sip-offeranswer-04.txt

From: <[email-masked]>
Date: Wed, 21 Nov 2007 10:48:21 +0530

All,

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.

Regards,
Nataraju A B
+91-98455-95744

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Nov 2007 11:18:45 -0500

Nataraju,

Thank you for taking the trouble to comment. Please understand that this 
document has already completed working group last call, so only limited 
sorts of changes are appropriate.

It is possible that certain things can be done as part of the author's 
48 hour update period. But this needs to be checked with the WG chairs. 
Also I would want approval from the other (and primary) author Takuya. 
So take my comments inline below as tentative.

	Thanks,
	Paul

> Solution: Let us remove this initial confusing statement

Can you be more specific about the contradiction you are seeing? I don't 
see one.

> Sec 3.1.2. INVITE request without SDP

Figure 2 is clearly an example of pattern 4. I see nothing in the 
example that contradicts the section of 2.1 that you cite. Please 
explain the contradiction you see.

> content more meaningful and readable also.

Yes, that would probably be helpful.

> content more meaningful and readable also.

Again, that might be helpful.

> is an open issue. Can this be added to Sec 6 - Open issues.

Why is this an open issue? The need is to wait until answer1 is 
received. In both cases that answer is expected in the 2xx response to 
an UPDATE. The time to wait is until it is received or the UPDATE 
transaction times out.

> Regards,
> Nataraju A B
> +91-98455-95744
> 
> 
> 
> The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. 
> 
> WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
>  
> www.wipro.com
>

---

From: <[email-masked]>
Date: Tue, 27 Nov 2007 13:28:53 +0530

Comments inline...

Regards,
Nataraju A B

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Monday, November 26, 2007 9:49 PM
> To: Nataraju Alilughatta basavaraju (WT01 - TES-Mobility & 
> Carrier Infrastructure)
> Cc: [email-masked]; Takuya Sawada
> Subject: Re: Comments on draft - 
> Thank you for taking the trouble to comment. Please 
> understand that this document has already completed working 
> group last call, so only limited sorts of changes are appropriate.
> 
> Can you be more specific about the contradiction you are 
> seeing? I don't see one.
> 
[ABN] its my mistake, getting confused with different inputs... Ignore
this comment.

> Figure 2 is clearly an example of pattern 4. I see nothing in 
> the example that contradicts the section of 2.1 that you 
> cite. Please explain the contradiction you see.
> 
[ABN] Pattern 2 and pattern 4 can occur only when the INVITE request
does not include an offer

In sec 2.1 its been mentioned as o/a sequence 2 AND 4 possible,
effectively it mean that ixx/prack and 2xx/ACK can carry SDPs in the
same transaction. 
I think that is not what you wanted to mention right ?

In the Figure-2, its been clearly mentioned that O/A is not allowed in
2xx/ACK if its completed in 1xx/PRACK.

Am I still missing something or confusing you all... ?

> > 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.
> 
> Why is this an open issue? The need is to wait until answer1 
> is received. In both cases that answer is expected in the 2xx 
> response to an UPDATE. The time to wait is until it is 
> received or the UPDATE transaction times out.
> 
[ABN] I personally feel, this has a loop hole, not many implementaters
would interpret the same way and end up with different implementations.
Also I am not sure what more information we can provide so that we can
make it clear enough to enable uniform implementations..:(
 
If we make it explicit, upon transaction expiration or completion there
should be a trigger to process the subsequent offers (if there exists a
pending offer to process).

> > Regards,
> > Nataraju A B
> > +91-98455-95744
> > 
> > 
> > 
> > The information contained in this electronic message and 
> any attachments to this message are intended for the 
> exclusive use of the addressee(s) and may contain 
> proprietary, confidential or privileged information. If you 
> are not the intended recipient, you should not disseminate, 
> distribute or copy this e-mail. Please notify the sender 
> immediately and destroy all copies of this message and any 
> attachments. 
> > 
> > WARNING: Computer viruses can be transmitted via email. The 
> recipient should check this email and any attachments for the 
> presence of viruses. The company accepts no liability for any 
> damage caused by any virus transmitted by this email.
> >  
> > www.wipro.com
> > 
>

---

From: Takuya Sawada <[email-masked]>
Date: Tue, 27 Nov 2007 23:24:12 +0900

Nataraju,

Sorry for not responding for long time.
Thank you for the comments. We can consider some of your 
comments during Auth48.

Comments inline.
Ommitted lines on Issue-1.

> Am I still missing something or confusing you all... ?
Well, I don't mean "o/a sequence 2 AND 4 possible (at the same time)".
I am not sure that the subject of the sentence 'Pattern 2 and pattern 4'
may easily be misinterpreted or not. 
But in this context I think the meaning is clear.

> > Again, that might be helpful.
We will consider these comments. Thanks.

> pending offer to process).
I think transaction expiration is an error case.
UA might consider the connection to the peer was lost.
It really depend on each implementation how to act in such a situation.
IMO I don't think it needs to be described in this document.

Regards,
Takuya

> The information contained in this electronic message and any attachments to this 
message are intended for the exclusive use of the addressee(s) and may contain
 
proprietary, confidential or privileged information. If you are not the 
intended 
recipient, you should not disseminate, distribute or copy this e-mail. Please 
notify
 the sender immediately and destroy all copies of this message and any 
attachments. 
> 
> WARNING: Computer viruses can be transmitted via email. The recipient should check
 this email and any attachments for the presence of viruses. The company 
accepts no 
liability for any damage caused by any virus transmitted by this email.
> www.wipro.com

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

---

From: <[email-masked]>
Date: Wed, 28 Nov 2007 18:05:52 +0530

Few comments inline...

Regards,
Nataraju A B
 
> From: Takuya Sawada [mailto:[email-masked]] 
> Sent: Tuesday, November 27, 2007 7:54 PM
> Carrier Infrastructure); [email-masked]
> Cc: [email-masked]; [email-masked]
[ABN] if you go by other scenarios and how its been described, "its the
same time" meaning right ???

For instance, "exactly one of the patterns 1, 2, 3, 4." 
It mean exactly one of 1-4 at the same time right ?

> > > >    offer in the INVITE request contains a session 
> description, UA 
> > > > A
> > > > 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.
> > > 
> > > received. In both cases that answer is expected in the 
> 2xx response 
> > > to an UPDATE. The time to wait is until it is received or 
> the UPDATE 
> > > transaction times out.
> > > 
> > If we make it explicit, upon transaction expiration or completion 
> > there should be a trigger to process the subsequent offers 
> (if there 
> > exists a pending offer to process).
> > 
[ABN] if we add some normative text here would help avoid the
mis-interpretation, and hence there would not be any open ended
description.

> exclusive use 
> > > of the addressee(s) and may contain proprietary, confidential or 
> > > privileged information. If you are not the intended 
> recipient, you 
> > > should not disseminate, distribute or copy this e-mail. Please 
> > > notify the sender immediately and destroy all copies of 
> this message 
> > > and any attachments.
> > > > 
> > > presence of viruses. The company accepts no liability for 
> any damage 
> > > caused by any virus transmitted by this email.
> > > >  
> > > > www.wipro.com
> > > > 
> > > 
> > 
> > 
> recipient 
> > should check
>  this email and any attachments for the presence of viruses. 
> The company accepts no liability for any damage caused by any 
> virus transmitted by this email.
> >  
> > www.wipro.com
> 
> --------
> Takuya Sawada
> KDDI Corporation (KDDI)

---

From: Takuya Sawada <[email-masked]>
Date: Fri, 30 Nov 2007 23:37:33 +0900

Comments inline
> It mean exactly one of 1-4 at the same time right ?
If 'at the same time' means 'in the exchange initiated by an INVITE
request', then right.

Well, I may not catch your question. What I want to describe here
can be expressed well in the sentences below:

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

> mis-interpretation, and hence there would not be any open ended
As Paul pointed out, I think timer duration is not an open issue.
UA should obey the rules defined in RFC 3264.
There can not be normative behaviour upon transaction timer
expiration. UA can give up the call or process the pending offer,
in such an error case.
Am I missing something?

Regards,
Takuya

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

---

From: <[email-masked]>
Date: Fri, 30 Nov 2007 20:38:24 +0530

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

> There can not be normative behavior upon transaction timer 
> expiration. UA can give up the call or process the pending 
> offer, in such an error case.
> Am I missing something?
> 

I got your point, Probably rejecting the offer2 with 491 should have
been better option instead buffering offer2 till reception of answer1.

Regards,
Nataraju A B

> Sent: Friday, November 30, 2007 8:08 PM
> Carrier Infrastructure); [email-masked]; [email-masked]
> Cc: [email-masked]
> > > To: Nataraju Alilughatta basavaraju (WT01 - TES-Mobility 
> & Carrier 
> > > Infrastructure); [email-masked]
> > > Thank you for the comments. We can consider some of your comments 
> > > during Auth48.
> > > 
> > > Comments inline.
> > > > > > Issue-2: contradicting statements Sec 2.1. Offer/Answer 
> > > > > > Exchange Pairs in SIP Messages
> > > > > the example that contradicts the section of 2.1 that 
> you cite. 
> > > > > Please explain the contradiction you see.
> > > > > 
> > [ABN] if you go by other scenarios and how its been described, "its 
> > the same time" meaning right ???
> > 
> If 'at the same time' means 'in the exchange initiated by an 
> INVITE request', then right.
> 
> Well, I may not catch your question. What I want to describe 
> here can be expressed well in the sentences below:
> 
> "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."
> 
> 
> expiration. UA can give up the call or process the pending 
> offer, in such an error case.
> Am I missing something?
> 
> Regards,
> Takuya
> 
> > > Regards,
> > > Takuya
> > > 
> > > > > > Regards,
> > > > > > Nataraju A B
> > > > > > +91-98455-95744
> > > > > > 
> > > > > > 
> > > > > > 
> > > proprietary, confidential or privileged information. If 
> you are not 
> > > the intended recipient, you should not disseminate, distribute or 
> > > copy this e-mail. Please notify  the sender immediately 
> and destroy 
> > > all copies of this message and any attachments.
> > > > 
> > > The company accepts no liability for any damage caused by 
> any virus 
> > > transmitted by this email.
> > > >  
> > > > www.wipro.com
> > > 
> > > --------
> > > 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]
> > > 
> > > 
> > 
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Nov 2007 10:25:18 -0500

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

	Paul