Gonzalo,
Very concise documents!
In terms of best practice I think they are good.
In terms of what to do if one finds oneself in a position where these
procedures aren't used, I think it is still not entirely clear. Even so,
I think we might be able to structure guidance around that. I think we
also must still decide if we need to make a *normative* change here or not.
A key part of the doc is the guideline: don't send an error response to
the reinvite unless no changes have been made since the reinvite was
sent. As long as that guidance is followed I think most things are good.
Having the UAS send another o/a when the above wasn't followed seems
like a good idea. Of course there is a window in there until that o/a is
completed, and the state during that time (and offered in that offer)
should still be defined if possible.
Thanks,
Paul
Gonzalo Camarillo wrote:
Hi,
I have put together the following draft. It contains a proposal for the
rollback issue that has been discussed on the list:
http://www.ietf.org/internet-drafts/draft-camarillo-sipping-reinvite-00.txt
I have also written another short draft on an issue related to
preconditions that was also discussed on the list in one of the
rollback-related threads:
http://www.ietf.org/internet-drafts/draft-camarillo-sipping-precons-00.txt
Comments are welcome.
Cheers,
Gonzalo
_______________________________________________
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
