Hi Paul, Thanks for the info. I will read the draft which you have pointed. I agree with your comments. Reliable provisional responses are covered in different RFC.
I think the information in 13.3.1.4 need a correction. It should be inline with the description in 13.2.1. Regards Krishna On Tue, Sep 16, 2008 at 10:04 PM, Paul Kyzivat <[EMAIL PROTECTED]> wrote: > First, look at > http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-08.txt > > More comments inline. > > Thanks, > Paul > > krishna kalluri wrote: > >> Hi, >> >> The following para in "13.3.1.4 The INVITE is Accepted" in RFC 3261 is >> confusing with the description in 13.2.1 (At the end after the bullets) >> I just split the para in 13.1.4 in to two different statements. >> >> From 13.3.1.4: If the INVITE request contained an offer, and the UAS had >>> not >>> >> yet sent an answer, the 2xx MUST contain an answer. >> >> [Krishna] I interpret this as if UAS answers in 1xx then it need not >> answer >> in 2xx. >> > > Depending on how you want to think about it, answers in unreliable > provisional responses either don't count or just aren't answers at all. > (Because they are sent unreliably, the sender can't know if they got > there.) Hence, if an sdp response to an incoming offer was sent in an > unreliable provisional, then it must also be sent in the first subsequent > reliable response. In the context of 3261 that will be the 200. > > Conversely, if the sdp response to an incoming offer is sent in a > *reliable* provisional response (RFC 3262) then it *is* an answer. In that > case it *need not* be sent in the 200 response. (But it MAY be sent in the > 200. However that is not recommended.) > > Is that correct interpretation? >> But from section 13.2.1 "If the initial offer is in an INVITE, the answer >> MUST be in a reliable non-failure message from UAS back to UAC which is >> correlated to that INVITE". >> >> In RFC 3261 the reliable non-failure message from UAS to UAC is 2xx. So >> irrespective of answer is present in 1xx or not the answer must be include >> in 2xx. >> > > The wording is funny because the specification of reliable provisional > responses was split off into RFC 3262. 3261 didn't want to depend on it, but > also wanted to be written in such a way that reliable provisional responses > could be an extension. > > From 13.3.1.4: If the INVITE did not contain an offer, the 2xx MUST >>> contain >>> >> an offer if the UAS had not yet sent an offer. >> >> [Krishna] It is the same argument as above. >> >> I think the description in 13.3.1.4 is not consistent with 13.2.1 or I >> might >> have misinterpreted. >> > > Its the same game here. The room is being left for 3262 to fill in the > details. Also 3311, which defines UPDATE, and which also may be used to > exchange offers and answers after the INVITE begins but before it is > completed. > > Paul > > Regards >> Krishna >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> >> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
