More comments for http://www.ietf.org/internet-drafts/draft-camarillo-sipping-reinvite-00.txt
1. UA can send target refresh and session modification(limited for address\port) automatically. So, I think for BCP level, it is better to separate target refresh from session modification which need user's interaction. Because make something deniable together with something dis-deniable is not friendly.
2. As your proposal, UAS of Re-INVITE is in pending state of target refresh, then choices is that:
2.1 the UAS will never send any more UPDATE before the final response of Re-INVITE;
2.2 trying a new UPDATE. And after recv the peer's 200OK(with the target refresh as Re-INVITE), it commit the target refresh for this successful UPDATE/200OK.
And then UAS can treat the session modification separately.
3. In "3. Clarifications on the Target Refresh Procedure", your proposal means that Re-INVITE's "Target Refresh" can only be committed after the 200OK, even if there are UPDATE during it.
I think if UAC of Re-INVITE send another UPDATE(with the target refresh), and the UAS of Re-INVITE accept it with 200OK. The target refresh MUST be committed.
4. I think we talk too much about target refresh. Your proposal base on the combination of "target refresh" and "session modification". But I think the case is not usual(My point 1). And the unusual case has solution(My point 2 and 3).
| Gonzalo Camarillo <Gonzalo.Camarillo@xxxxxxxxxxxx>
发件人: sipping-bounces@xxxxxxxx 2009-03-03 21:32 |
|
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
-------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________ 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
