Internet DRAFT - draft-gaoyang-sipping-session-state-criterion
draft-gaoyang-sipping-session-state-criterion
sipping Y. Gao
Internet-Draft ZTE
Intended status: Standards Track March 6, 2009
Expires: September 7, 2009
The Criterion of Session State
draft-gaoyang-sipping-session-state-criterion-03.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 7, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Gao Expires September 7, 2009 [Page 1]
Internet-Draft The Criterion of Session State March 2009
Abstract
There is debate on the topic of "Commit/Rollback of Offer/Answer on
Unsuccessful re-INVITE". The reason of the confusion is some
application/session usages of offer/answer imply the nest
transaction(mean transaction theory, not mean sip transaction)
concept, but whitout unambiguous definition. This paper reveal the
concept of nest transactions in current RFC and other well known
application/session usages. And then clarify that there is no
ambiguous state of session modification using current RFC definition.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Atomicity's semantics . . . . . . . . . . . . . . . . . . . . 4
2.1. Atomicity's semantics of UPDATE . . . . . . . . . . . . . 4
2.2. Atomicity's semantics of Re-INVITE . . . . . . . . . . . . 4
2.3. Combination of the two ones . . . . . . . . . . . . . . . 4
2.3.1. Is precondition use-case violation of RFC3311 . . . . 5
2.4. Dialog state and session state clarification . . . . . . . 5
2.4.1. There is target refresh and session modification
during Re-INVITE . . . . . . . . . . . . . . . . . . . 5
2.4.2. There is only target refresh during Re-INVITE . . . . 5
2.4.3. The UPDATE/200OK has target refresh and refreshing
the precondtion state table . . . . . . . . . . . . . 6
3. Why nested transaction . . . . . . . . . . . . . . . . . . . . 7
3.1. Nested transaction concept in current RFCs . . . . . . . . 7
3.1.1. Precondition . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. Late commitment of Re-INVITE 200OK . . . . . . . . . . 7
3.2. Opened for evolution and extension in the future . . . . . 7
4. The Criterion . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Rules for current nested-transaction usages . . . . . . . 9
4.2. Explanation for some concepts . . . . . . . . . . . . . . 9
4.3. This proposal has no racing condition . . . . . . . . . . 9
5. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Normative references . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Gao Expires September 7, 2009 [Page 2]
Internet-Draft The Criterion of Session State March 2009
1. Introduction
There has been some confusion among dialog state and session state
after unsuccessful Re-INVITE. In this document, we clarify that
there is no ambiguous dialog state and session state by current RFC
definition.
Gao Expires September 7, 2009 [Page 3]
Internet-Draft The Criterion of Session State March 2009
2. Atomicity's semantics
As we know, atomicity's semantics is "all or nothing". And if new
modification is acceptted, the older pending one would be
discarded(that is the semantics of "nothing").
2.1. Atomicity's semantics of UPDATE
In RFC3311, when the UPDATE is accepted by the other side(UPDATE/
200OK), the change of states is committed and effort at once. If the
other side can not accept it at once, it can reject it by 504. The
semantics is clear, and, the states including "dialog state" and
"session state".
2.2. Atomicity's semantics of Re-INVITE
If people want to form everything during Re-INVITE as a big nested
transaction, there are problems as:
o Casecade of the nested transaction must have specific definition at
first.
o Racing condition again(during or not during).
o 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.
So, the modifications associated with Re-INVITE is the ones 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. The states including "dialog state" and "session
state".
2.3. Combination of the two ones
Except for later Offer/Answer pairs which are used as "refreshing the
precondtion state table" during suspending state of session, any new
Offer/Answer MUST be treated as a new modification. If a new
modification is acceptted, the older pending one discard(that is the
"nothing").
The discarding of the older pending one(Re-INVITE) obeys RFC3261.
And commitment of the new one obeys RFC3311.
Gao Expires September 7, 2009 [Page 4]
Internet-Draft The Criterion of Session State March 2009
2.3.1. Is precondition use-case violation of RFC3311
In RFC3312, there can be UPDATE/200OK used as "refreshing the
precondtion state table" before failure of Re-INVITE. And the
anticipated session state is the one before Re-INVITE. Is this
violation of Re-INVITE?
First, we should make sure the effect of the later Offer/Answer pairs
which are used as "refreshing the precondtion state table" during
suspending state of session. By RFC3312, these Offer/Answer pairs
just refresh the precondtion state table, but it has no impact on the
commitment of the modification.
Then, as the UAs has adjusted the session parameters(refresh the
precondtion state table) accordingly, it obeys RFC3311.
And as current pending session modification is still the one
triggered by Re-INVITE, and it is discarded for the failure of Re-
INVITE. This obeys RFC3261.
2.4. Dialog state and session state clarification
Let's use some examples to show the concept mentioned above.
2.4.1. There is target refresh and session modification during Re-
INVITE
Re-INVITE failed, nothing in it is committed. This obeys RFC3261.
The committed target refresh and session modification is by UPDATE/
200OK. This obeys RFC3311.
signaling | O/A state | remote target
---------------------+-----------+--------------
init-INVITE/200/ACK | state1 | c1
re-INVITE/183-rel | state2 | c2
PRACK/200OK | [noSDP] | -
UPDATE/200OK | state3 | c3
4xx/ACK | state3 | c3
Figure 1
2.4.2. There is only target refresh during Re-INVITE
Re-INVITE failed, nothing in it is committed. This obeys RFC3261.
The committed target refresh is by UPDATE/200OK. This obeys RFC3311.
Gao Expires September 7, 2009 [Page 5]
Internet-Draft The Criterion of Session State March 2009
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
Figure 2
2.4.3. The UPDATE/200OK has target refresh and refreshing the
precondtion state table
Re-INVITE failed, nothing in it is committed. This obeys RFC3261.
The committed target refresh is by UPDATE/200OK. This obeys RFC3311.
The committed "refreshing 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 | state2.1 | c3
4xx/ACK | state1 | c3
Figure 3
Gao Expires September 7, 2009 [Page 6]
Internet-Draft The Criterion of Session State March 2009
3. Why nested transaction
Chapter 2 reveals the necessity of a new solution for session state.
And this chapter is about why the new solution is based on the
concept of nested-transaction.
3.1. Nested transaction concept in current RFCs
3.1.1. Precondition
As RFC3312(Quality-of-Service precondition)\4032(Precondition
Framework)\5027(Security Preconditions) defines, session
establishment and modification suspended until precondtion is
satisfied. And during the suspended state, there can be Offer/Answer
pairs used as precondition notification.
This is a typical nested transaction using Offer/Answer pairs as sub-
transaction.
3.1.2. Late commitment of Re-INVITE 200OK
As RFC3261 defines, for unsuccessful Re-INVITE, the session
parameters MUST remain unchanged, as if no re-INVITE had been issued.
This is about session modification triggered by Re-INVITE. And the
"Late commitment of Re-INVITE 200OK" just corresponds to the
modification triggered by the Re-INVITE. A new modification during
the Re-INVITE has nothing to do with the final response of Re-INVITE,
such as UPDATE with a new modification.
This is also a typical nested transaction using Offer/Answer pair as
sub-transaction. And it is intuitionistic requirement for rejecting
session modification.
What MUST be pointed out is that, by RFC3262, Offer/Answer of the
modification triggered by Re-INVITE can be exchanged before final
response. In signal level, the modification is in pending state and
waits for late commitment. But in media level, the new session
parameters can be used. And this obeys RFC3264 and RFC3262.
3.2. Opened for evolution and extension in the future
We should accept the idea that using offer/answer as sub-transaction
of modification should be open for the future extension. For
example, in the future we can define a complex application which need
negotiation of session parameter using more than one offer/answer
pairs for one modification, just like "Precondition".
As nested transaction is the natural property of session modification
Gao Expires September 7, 2009 [Page 7]
Internet-Draft The Criterion of Session State March 2009
and it is important for evolution and extension in the future, so the
new solution is based on the concept of nested-transaction.
Gao Expires September 7, 2009 [Page 8]
Internet-Draft The Criterion of Session State March 2009
4. The Criterion
4.1. Rules for current nested-transaction usages
"Late commitment of Re-INVITE 200OK" contains "Precondition". And
that is "Precondition" can be sub-transaction of "Late commitment of
Re-INVITE 200OK" to form a bigger nested-transaction. And this is
practical for session modification with precondition using Re-INVITE.
Rule 1: Late commitment of the modification triggered by Re-INVITE is
200OK. Before the 200OK, the modification is in pending state in the
point of view of signal level. If the Re-INVITE is unsuccessful, the
pending modification MUST rollback.
Rule 2: Precondition notification is part of the original
modification.
Rule 3: when a new modification succeeds during the pending state of
the previous modification, the new one MUST be committed and the
original one discarded.
Rule 4: when a new modification request is rejected during the
pending state of the previous modification, the original one can go
on.
4.2. Explanation for some concepts
Precondition notification is later Offer/Answer pair which is used as
"refreshing the precondtion state table" during suspending state of
session. Except for Precondition notification, any new Offer/Answer
MUST be treated as a new modification.
4.3. This proposal has no racing condition
As the new modification has been committed and its state have nothing
to do with F8, the problem of racing condition(4xx of Re-INVITE and
UPDATE) described in 6.2 of "draft-ietf-sipping-sip-offeranswer" does
not exist.
Gao Expires September 7, 2009 [Page 9]
Internet-Draft The Criterion of Session State March 2009
Racing condition of 4xx of Re-INVITE and UPDATE
UAC UAS
| session established |
|===================|
| |
| F1 re-INVITE (SDP) |
|--------------------|
| F2 1xx-rel (SDP) |
|--------------------|
| F3 PRACK |
|--------------------|
| F4 2xx PRA |
|--------------------|
| |
|F5 UPDATE F6 2xx INV |
|---------\ /--------|
| \/ |
| /\ |
|--------/ \-------| - UPDATE request inclue a new
| | modification
Figure 4
Currently, there are only two cases for the Offer in UPDATE:
o precondtion notification;
o a new modification request.
If it is precondtion notification, the session state is clear. That
is committed state of the modification triggered by F1.
If it is a new modification request, there are only two cases for the
UPDATE:
o accepted by 200OK;
o rejected by 4xx/5xx/6xx, such as 504.
If it is accepted by 200OK, the new modification is committed. And
the session state is committed state of the modification triggered by
F5.
If it is rejected, and the original modification failed, the session
state is one before F1.
Gao Expires September 7, 2009 [Page 10]
Internet-Draft The Criterion of Session State March 2009
So, the session state is clear for this situation. And the solution
is racing condition free.
Gao Expires September 7, 2009 [Page 11]
Internet-Draft The Criterion of Session State March 2009
5. Acknowledgment
Thanks Gonzalo Camarillo, OKUMURA Shinji, Ian Elz and Christer
Holmberg for discussion.
Gao Expires September 7, 2009 [Page 12]
Internet-Draft The Criterion of Session State March 2009
6. Normative references
[I-D.ietf-sipping-sip-offeranswer]
Sawada, T. and P. Kyzivat, "SIP (Session Initiation
Protocol) Usage of the Offer/Answer Model",
draft-ietf-sipping-sip-offeranswer-08 (work in progress),
April 2008.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002.
[RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session
Initiation Protocol (SIP) Preconditions Framework",
RFC 4032, March 2005.
Gao Expires September 7, 2009 [Page 13]
Internet-Draft The Criterion of Session State March 2009
Author's Address
Gao yang
ZTE
CHINA
Email: gao.yang2@zte.com.cn
Gao Expires September 7, 2009 [Page 14]
