Absolutely YES.
Let's analyse atomicity's semantics.
Atomicity's semantics is “all or nothing”. All of what?
All of the modifications in Re-INVITE, not during Re-INVITE. So, I use the words "modification triggered by Re-INVITE" to distinguish from the later modification during Re-INVITE.
If people want to form everything during Re-INVITE as a big nested transaction, there are problems as:
1. Violation of the RFC3311: If the session description has changed, the UAS MUST adjust the session parameters accordingly and generate an answer in the 2xx response.
2. Racing condition again(during or not during).
3. And nested transaction must have specific definition at first.
If we treated it as “all or nothing” of modifications in Re-INVITE, not during Re-INVITE. We can find that there is no violation.
If a new modification is acceptted, the older pending one discard(that is the "nothing").
| OKUMURA Shinji <shin@xxxxxxxxxxxxxxx>
2009-03-05 17:33 |
|
Gao,
I see, but
RFC3261
8.2 UAS Behavior
Note that request processing is atomic. If a request is accepted,
all state changes associated with it MUST be performed. If it is
rejected, all state changes MUST NOT be performed.
I think we neet to consider the above sentence carefully.
Regards,
Shinji
gao.yang2@xxxxxxxxxx
>Dear Shinji
>
>The session state by my proposal is right.
>The dialog state by my proposal is always c4.
>
>And I'd like to replace the words "a part of the original modification"
>with "only refresh the precondtion state table",
>replace "new modification" with "The others".
>Beacuse currently RFCs, just "only refresh the precondtion state table"
>can be treated as "a part of the original modification".
>And it is words from the RFC.
>
>And thanks for your works.
>
>Gao
>
>OKUMURA Shinji <shin@xxxxxxxxxxxxxxx>
>发件人: sipping-bounces@xxxxxxxx
>2009-03-05 16:24
>
>收件人
>sipping@xxxxxxxx
>抄送
>
>主题
>[Sipping] Summary of the rollback issue
>
>Hi, all
>
>This thread is too big and complicated.
>I would summarize the discussion.
>
>For that purpose I make a simpler proposal.
>It is the straw-man proposal, but it will work without a
>problem, I think.
>
>signaling | O/A state | remote target
>---------------------+-----------+--------------
>init-INVITE/200/ACK | state1 | c1
>re-INVITE/183-rel | state2 | c2
>PRACK/200OK | [noSDP] | -
>UPDATE/200OK | [noSDP] | c3
>UPDATE/200OK | state3 | c4
>4xx/ACK | state1 | c3 <- this record is my proposal.
>
>1. Main concept is full-rollback according to RFC3261.
>2. UPDATE without SDP change remote target immediately.
> it doesn't rollback.
>3. The rollback is NOT depend on preconditions.
> there is no need to check SDP attribute.
>4. UAS should reject UPDATE received between 4xx and ACK.
> UAC should NOT send UPDATE between 4xx and ACK.
>5. UAC should ignore 200 response to UPDATE(with SDP) that send
> before 4xx received.
>
>Now we have discussed three additional proposal.
>
>A. commit-latest-exchange(Liaison Statement ?)
> 4xx/ACK | state3 | c4
>
>B. late-commit ( by Gao)
> if UPDATE is "a part of the original modification"
> 4xx/ACK | state1 | c3
> else (UPDATE is "new modification")
> 4xx/ACK | state3 | c4
>
> the decision depend on preconditions.
>
>C. Gonzaro's draft
> 4xx/ACK | state1 | c1
> and he says
> C1. UAS should NOT send 4xx.
> C1. UAC should send UPDATE after sending
>ACK for 4xx.
>
>Is my summary up to this right ?
>
>Regards,
>
>Shinji
-------------------------------------------------------- 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
