I found the diagram we looked at in Montreal describing the problem with dialog state - here's a copy.
Christer's proposal 2 for the offer/answer situation is to stay with whatever offer/answer exchange completed successfully last (perhaps in the INVITE/183 below). Would it also be acceptable to stay with whatever remote Target was successfully set last? In the diagram below that means the NOTIFY in question would use A'.
At the moment, I can't think of why drawing the line in the sand at that place would be any worse than rolling back to the beginning of the INVITE transaction. Further, in the case of multiple usages, it's arguably better - if I have a successful reSUBSCRIBE in a usage sharing a dialog with a pending INVITE transaction, it feels wrong that the whatever target that reSUBSCRIBE might have set be rolled back by the INVITEs failure.
So, unless someone comes up with an obvious problem with this, then I'm ok going with Christer's proposal 2 for offer/answer and propose we do a correction for 3261 clarifying the treatment of remoteTarget on failed target refresh transactions addressing having overlapping transactions that succeed.
RjS
Attachment:
sipping66-sparks-dialogusage.ppt.pdf
Description: Adobe PDF document
_______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors at cs.columbia.edu for questions on current sip Use sip at ietf.org for new developments of core SIP