Subject: [Sipping] Summary of the rollback issue

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 05 Mar 2009 17:24:49 +0900

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

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 05 Mar 2009 18:33:13 +0900

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

[email-masked]
>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 <[email-masked]> 
>发件人:  [email-masked]
>2009-03-05 16:24
>
>收件人
>[email-masked]
>抄送
>
>主题
>[Sipping] Summary of the rollback issue
>
>Hi, all
>

---

From: [email-masked]
Date: Thu, 5 Mar 2009 17:07:48 +0800

Dear  Shinji

Gao

收件人
[email-masked]
抄送

主题

Hi, all

B. late-commit ( by Gao)

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.

Regards,

Shinji
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] 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.

--------------------------------------------------------
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.

---

From: [email-masked]
Date: Thu, 5 Mar 2009 18:02:27 +0800

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"). 

2009-03-05 17:33

收件人
[email-masked]
抄送
[email-masked]
主题
Re: [Sipping] Summary of the rollback issue

Gao,

I see, but

RFC3261
8.2 UAS Behavior

Regards,

Shinji

[email-masked]

---

From: [email-masked]
Date: Thu, 5 Mar 2009 18:52:05 +0800

Using your chart:

1. If there is target refresh and session modification during Re-INVITE

Re-INVITE failed, nothing in it is committed. 
The committed target refresh and session modification is by UPDATE/200OK.
signaling            | O/A state | remote target
---------------------+-----------+--------------
init-INVITE/200/ACK  | state1    | c1
re-INVITE/183-rel    | state2    | c2
PRACK/200OK          | [noSDP]   | -
UPDATE/200OK         | state3    | c4
4xx/ACK              | state3    | c4 

2. If there is only target refresh during Re-INVITE

Re-INVITE failed, nothing in it is committed. 
The committed target refresh is by UPDATE/200OK.
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
4xx/ACK              | state1    | c3 

3. If the UPDATE/200OK has target refresh and "only refresh the 
precondtion state table"

Re-INVITE failed, nothing in it is committed. 
The committed target refresh is by UPDATE/200OK.

The committed "refresh the precondtion state table" is by UPDATE/200OK.
But the session state is given up by 4xx of Re-INVITE.

4xx/ACK              | state1    | c4 

收件人
[email-masked]
抄送
[email-masked]
主题

Gao,

I see, but

RFC3261
8.2 UAS Behavior

Regards,

Shinji

[email-masked]