Comments inline.
| Gonzalo Camarillo <Gonzalo.Camarillo@xxxxxxxxxxxx>
2009-03-04 15:04 |
|
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).
[Gao] I am talking about do not send target refresh and session modification which need user's
interaction together. Not about new IP.
> 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...
[Gao] I wanted to say that your way is not the only one. So, I think it is a heavy restriction.
> 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.
[Gao] I just wanted to say if UPDATE/200OK committed the target refresh, it should be free for 4xx of Re-INVITE.
You want to make "target refresh"'s state pending, then form a big nested transaction. I do not think so.
I think the later UPDATE/200OK has committed it!
Same as above.
Cheers,
Gonzalo
-------------------------------------------------------- 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
