Brett,
Sorry, I'm busy and didn't think much before replying.
You are right that it isn't clear. If you receive a reINVITE with a
changed Contact, and respond with something other than 2xx, then what do
you do about the Contact?
There are some cases in which you shouldn't accept it. E.g. if you are
responding with 401 or 481, or maybe if you respond with 100 while you
think about it. But if you decide it is good enough to begin to process,
(which would be evidenced eventually by a 1xx or 2xx response, but you
may decide before sending that) then I think you accept the Contact, and
then never roll it back.
Is it necessary that the UA sending the changed Contact to know that it
has been accepted? I think only if it has the ability to continue to
support both and needs to know when it can stop supporting the old one.
The best evidence for doing that is receiving a message at the new
address, but that might not happen for a long time in some cases.
Thanks,
Paul
Brett Tate wrote:
Hi Paul,
Thanks for the response. Reply inline.
If the question is about the rollback, or not, of
the Contact address...
That was one of the questions.
IMO there was never really any question of rolling
back Contact.
Draft-holmberg-sipping-reinvite-rollback-00 section 1 indicates:
"Different solutions were discussed, and it was agreed that session parameters that have been sucessfully updated are not rolled back in the case of a re-INVITE failure. The same applies to any other parameter, e.g. that remote target, that have been sucessfully changed."
Draft-holmberg-sipping-reinvite-rollback-00 does contain normative text associated with the last sentence of the above quote. It also does not define "sucessfully updated" concerning session parameters and other parameters; thus I'm not sure what it means.
1) received re-INVITE, 2) sent 18x, 3) reliable 18x's PRACK successful prior to sending failure response, 4) sent INVITE 2xx 5) UPDATE transaction was successful during the re-INVITE transaction which failed and/or 6) something else.
If the request contains a new contact,
and if the request itself succeeds, then the Contact
is updated, and isn't ever rolled back after that.
What is meant by "request itself succeeds": 1) received re-INVITE, 2) sent 18x, 3) reliable 18x succeeds PRACK successful prior to sending failure response, 4) sent INVITE 2xx 5) UPDATE transaction was successful during the re-INVITE transaction which failed and/or 6) something else.
_______________________________________________
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
_______________________________________________
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
