Hi, > 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. there are situations where you need to do both at the same time (e.g., you get a new IP address). > 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. the draft explains what to do already... > 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 suggest you re-read that section to understand what it says. > 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. Same as above. 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
