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
