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