Snipping the conversation down... gao.yang2@xxxxxxxxxx wrote: > >For example. > > > >The UAC sends an SDP offer in a re-INVITE, and receives an SDP > >answer in a reliable 18x. But, then what happens when the > >re-INVITE fails? > > To complicate it even futher, there may be some UPDATE transacations > with sdp between the two endpoints in session, before there is a final > response to re-Invite. > Since the transaction is complete in media plane, I think it should stay > even if actual signaling transacation finally fails. And that's not what > RFC 3261 says. > > [Gao] Yes. > > IMO: > > Modification triggered by Re-INVITE MUST rollback as the failure of > Re-INVITE. --That is the original concept of RFC3261 > > Any committed new modification during Re-INVITE with other SIP > transaction, would have nothing to do with the Re-INVITE's failure or > success. --That is the original concept of RFC3311. > > Do you think so? No. I think that makes no sense at all. Each offer that is sent is dependent on the ones that went before. If you accept a later one and then fail an earlier one the state is not well defined. For instance, suppose a reINVITE proposes addition of a codec to an existing audio stream and also addition of a second media stream (video). Then there is a subsequent UPDATE to modify the original audio stream (e.g. to make it inactive). That UPDATE *must* contain two m-lines, reflecting its understanding of the current state of both. Hence it is dependent on the reINVITE. If there is a 200 response to it, how can that be handled independently of the subsequent success or failure of the reINVITE? The response to the UPDATE must address what was in the offer in the UPDATE, about both streams. Thanks, Paul _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
