Brett,
If the question is about the rollback, or not, of the Contact address...
IMO there was never really any question of rolling back Contact. 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.
Its hard for me to imagine that it could work any other way.
Thanks,
Paul
Brett Tate wrote:
Just to support Christer: I was initially in favor of the
full rollback approach. But the discussion showed that it
had the race condition that Christer mentions. We
considered introducing additional machinery to resolve
that race, but that just complicated things further,
especially backward compatibility, for an obscure case.
So, I have come to understand that there is no ideal
answer, and so am satisfied with the one that was chosen.
As mentioned within an August thread, I'm not necessarily opposed to the adjustment.
http://www.ietf.org/mail-archive/web/sipping/current/msg16073.html
However as mentioned within an email I sent Friday, I'm currently still unsure of the specifics of the chosen approach. What is the meaning of "successfully" updated/changed as criteria to not rollback session parameters? What are the rules concerning non session parameters (such as Contact)?
http://www.ietf.org/mail-archive/web/sipping/current/msg16567.html
I realize that not everybody knows all the history of
this, so we explain it again, but we can't re-open the
decision at this point.
Since the decision has been made, hopefully somebody knows the answers to the above questions.
Thanks,
Brett
_______________________________________________
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