I feel your proposal is no bad for a summary.
[Gao] Yes, it is summary. That's why I think we can solve the open issue without any change to current RFCs.
BUT, The biggest drawback is which UPDATE is "part of the original
modification" or "new modification". it is very very ambiguous.
[Gao] It is clear. Because the distinction is according as modification itself(SDP).
And by current RFCs, only precondition notification can be treated as "part of the original modification". Others is just substitute of the orignal modification.
I think this concept itself is clear.
People may want to treat some type of SDP as "part of the original modification", without specific definition as precondition. The concept itself(as framework) is open for this.
One example is "refine codec".
If we want to make "refine codec" as "part of the original modification" normative. I have a suggestion: treat it as part of the original modification, but "protected" by precondition.
Why "protected" by precondition?
By RFCs it is new modification at all, and as to make it part of the original modification, we should have semantics of suspending/resuming modification.
How "protected" by precondition?
We can define that only use "refine codec" in suspending state of QoS precondition.
IMO, it is better to define a new precondition type for "refine codec".
It is no doubt that an UPDATE without SDP is "new modification".
UPDATE after ACk is "new modification" too.
but it has a racing condition.
new UAS behavior
reject all UPDATEs received between 4xx and ACK
can the above rule solve the problem ?
[Gao] It can solve it. Because which is "part of the original modification" is decided by the modification's property while sequence(or order) of the signal(message), so it can solve it. (or say that it is unrelated tosequence(or order) of the signal(message)) . I think it is a merit.
-------------------------------------------------------- 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
