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