mmusic Y. Gao
Internet-Draft ZTE
Intended status: Standards Track February 9, 2009
Expires: August 13, 2009
Session State Analysis
draft-gaoyang-sipping-session-state-analysis-00.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 August 13, 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Gao Expires August 13, 2009 [Page 1]
Internet-Draft Session State Analysis February 2009
Abstract
Session state on unsuccessful re-INVITE is an open issue[1]. Many
people interested in this topics and there has been a lot of
discussion in the mail list publicly or among participants privately.
This text tried to analyse incorrectness or drawback of some of the
methods to reveal the imortance of precise definition of session
state.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Rollback to session state before Re-INVITE . . . . . . . . . . 4
3. Commit any session parameters that have been sucessfully
changed . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Intuitionistic drawback . . . . . . . . . . . . . . . . . 5
3.2. Confirmed state but not enough for usage . . . . . . . . . 5
3.3. Iseless pending state . . . . . . . . . . . . . . . . . . 5
3.4. Inconsistent state . . . . . . . . . . . . . . . . . . . . 6
4. Manual rollback using a new Re-INVITE . . . . . . . . . . . . 7
4.1. Problems for ordinary SDP . . . . . . . . . . . . . . . . 7
4.2. Problems for non-integrative SDP . . . . . . . . . . . . . 7
4.2.1. Theoretical analysis . . . . . . . . . . . . . . . . . 7
4.2.2. Unable to construct the new complete SDP . . . . . . . 7
5. Giving out a precise definition of session state . . . . . . . 8
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Gao Expires August 13, 2009 [Page 2]
Internet-Draft Session State Analysis February 2009
1. Introduction
There are more than one method to solve the problem mentioned above.
I collected four types of such way from discussion and other open
way, such as drafts.
o rollback to session state before Re-INVITE; o commit any session
parameters that have been sucessfully changed; o "manual rollback"
using a new Re-INVITE; o giving out a precise definition of session
state;
I will analyse incorrectness and drawback of the first three ways to
reveal the importance of precise definition of session state. This
text is not intend to introduce any solution in the fourth way, and
one of such way can be found in [2].
Gao Expires August 13, 2009 [Page 3]
Internet-Draft Session State Analysis February 2009
2. Rollback to session state before Re-INVITE
If the Offer/Answer pairs belonging to or during(such as UPDATE) the
Re-INVITE is just parts of the original modification triggered by Re-
INVITE, such as precondition notification, should rollback with the
failure of Re-INVITE.
There will be one and only one Offer/Answer pair belonging to Re-
INVITE, others is just during the Re-INVITE. The succedent Offer/
Answer pairs during the Re-INVITE, can be parts of the original
modification or a new modification of the same session. If it is a
new modification, and having been processed successfully, it must not
rollback with the failure of Re-INVITE. The reason is that we have
no reason to say that the the new successful modification should be
commited by the signal(2XX of Re-INVITE) associate to the original
modification request. And in signal level, Re-INVITE and UPDATE is
independent transaction(SIP). The new modification commitment and
its state have nothing to do whit the success/failure of Re-INVITE.
So, we can find that ignoring the relationship among Offer/Answer
pairs, and just "rollback to session state before Re-INVITE" is
arbitrary. This method is not acceptable.
Gao Expires August 13, 2009 [Page 4]
Internet-Draft Session State Analysis February 2009
3. Commit any session parameters that have been sucessfully changed
3.1. Intuitionistic drawback
As mentioned in RFC3311: Although UPDATE can be used on confirmed
dialogs, it is RECOMMENDED that a re-INVITE be used instead. This is
because an UPDATE needs to be answered immediately, ruling out the
possibility of user approval. Such approval will frequently be
needed, and is possible with a re-INVITE.
It reveal the main difference of Re-INVITE and UPDATE. If we can not
clarify the session state on unsuccessful re-INVITE, we just give up
the advantages of Re-INVITE.
"Commit any session parameters that have been sucessfully changed"
just make Re-INVITE as UPDATE. And we may ask: Why we need Re-INVITE
further while modification of session using Re-INVITE is just as the
one using UPDATE?
3.2. Confirmed state but not enough for usage
Considering situation: One side using Re-INVITE to reduce the number
of media types, such as audio and vedio session to audio session, or
to use codec needing less resources. There are Offer/Answer pairs
before the final response of Re-INVITE. At last, the other side
reject the modification.
If we obey the rule "session parameters that have been sucessfully
changed during the duration of the re-INVITE transaction MUST remain
unchanged", the media types or resources are not enough for the user.
EEven if user sends a new Re-INVITE to reopen the media types, but
there is not enough media types or resources during this new Re-
INVITE and it violates the continuity of session usage. For advanced
media type, such as virtual reality pursuing immersion for users, it
will be terrible.
3.3. Iseless pending state
Reasons, such as precondition, can make the session state in pending
state. And if the preconidtion is not met, the two sides may not use
the resources.
Perhaps, the only way to resuming the session is to send a new Re-
INVITE. So the violation of continuity of session usage is also
exist here. It is ironic that if the session state has been
rollbacked to the one before the previous Re-INVITE, the session
state will be clear, and it can assure the continuity of session
Gao Expires August 13, 2009 [Page 5]
Internet-Draft Session State Analysis February 2009
usage by the rules in section 8 of RFC3264.
3.4. Inconsistent state
Considering precondition(in fact any modification overlaps more than
one Offer/Answer may be same), the two sides just has a shared view
of the status of a media stream, not the precondition. So the
precondition in each side can be different
The suspending and resuming of modification is operated by each user
agent itself[6]. Then the modification here might not be consistent.
For example, if precondition of one side is met and the other side is
not met, the two sides will have inconsistent states. As 3.3, the
only way to resuming the session is to send a new Re-INVITE.
The situations mentioned above show that this method has problems.
This method is not acceptable.
There are cases in this section need help of "manual rollback" using
a new Re-INVITE. Incorrectness or drawback of "manual rollback"
using a new Re-INVITE is in section 4.
Gao Expires August 13, 2009 [Page 6]
Internet-Draft Session State Analysis February 2009
4. Manual rollback using a new Re-INVITE
4.1. Problems for ordinary SDP
Sections mentioned above introduced "manual rollback" using a new Re-
INVITE as the way to resume the session under ambiguous situations.
But if the two sides have no consistent view of session state, no
matter which side sends the new Re-INVITE, the other side will treat
it as violation of session continuity because of different view of
session state.
So, from the points of session continuity, a precise definition of
session state, as the fourth way, is needed for all situations
mentioned above.
4.2. Problems for non-integrative SDP
4.2.1. Theoretical analysis
Because the SDP just describe part of the session, not all aspects of
the session. It must be combined with the previous one(or ones) to
show the effects, as the formula:
"current session state" = "previous session state" + "modification
session description".
Even if using a new Re-INVITE with "modification session
description", we can not rebulid the "current session state" without
the definition of the "previous session state". So, the "previous
session state" is important here, and we still need to give out a
precise definition of session state to get the "previous session
state" here.
4.2.2. Unable to construct the new complete SDP
Some persons may ask that can we construct the new complete SDP.
First, complete SDP might not be constructed for syntax of non-
integrative SDP, such as the usage in [7].
RFC4566 pointed out that attribute interpretation depends on the
media tool being invoked. And if the interpretation refer to some
kind of complex function expression. The rollback of modification
can only be processed in the media tool side. The other
side(controlling side) have no way to onstruct the new complete SDP,
so it can not do such rollback by a new Re-INVITE.
Situations unable to rollback using "manual rollback", can be treated
as proof of the importance of precise definition of session state.
Gao Expires August 13, 2009 [Page 7]
Internet-Draft Session State Analysis February 2009
5. Giving out a precise definition of session state
A precise definition of session state is the way giving out the rules
which can be practical in all situations. This text is not intend to
introduce any solution in this way, and one of such way can be found
in [2].
Gao Expires August 13, 2009 [Page 8]
Internet-Draft Session State Analysis February 2009
6. Conclusion
Considering incorrectness or drawback of the first three ways, we can
admit that a precise definition of session state is important for
current SIP/SDP usage and for the evolvement in the future.
Gao Expires August 13, 2009 [Page 9]
Internet-Draft Session State Analysis February 2009
7. Acknowledgements
Thanks for Christer Holmberg and Paul Kyzivat for discussion on this
topic in SIPPING mail list. And thanks for my colleagues Wang Libo,
Shi hao for discussion on this topic in daily work.
Gao Expires August 13, 2009 [Page 10]
Internet-Draft Session State Analysis February 2009
8. References
[RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the
Session Description Protocol (SDP) for ATM Bearer
Connections", RFC 3108, May 2001.
[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.
Gao Expires August 13, 2009 [Page 11]
Internet-Draft Session State Analysis February 2009
Author's Address
Gao yang
ZTE
CHINA
Email: gao.yang2@zte.com.cn
Gao Expires August 13, 2009 [Page 12]