Hi all,
I have just written a rough draft about nested UPDATEs.
As it cannot be uploaded at this moment, I send a copy by the list of sipping.
This is just a first version draft and may have mistakes even spelling one, thanks for pointing them out.
The only aim of this draft is to make SIP simple but more operational, and it is just a suggestion, not intended to forbid anything：）
And, any comments/criticism/sarcasm/flames are welcomed.
Have a nice day. :)
-------------------------------------------------------- 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 Wang.libo
Internet-Draft ZTE
Intended status: Informational March 12,2009
Expires: September 12, 2009
Nested UPDATEs in the Session Initiation Protocol (SIP)
draft-wang.libo-sipping-nested-updates-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.
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 sixmonths
and may be updated, replaced, or obsoleted by other documents atany
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 12, 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 yourrights
and restrictions with respect to this document.
Abstract
In this document, we clarify the handling of nested UPDATEs in
SIP. We classify UPDATEs method, and discuss about why UPDATEs are
nested in re-INVITE.
Wang.libo Expires September 12, 2009 [Page 1]
Internet-Draft Nested- UPDATEs March 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . .
2. Classification of UPDATEs . . . . . . . . . . . . . . . .
3. Analyse of UDPATEs. . . . . . . . . . . . . . . . . . . .
3.1 UPDATEs for preconditions . . . . . . . . . . . . . . . .
3.2 UPDATEs with new SDP . . . . . . . . . . . . . . . . . . .
3.2.1 nested UPDATEs in re-INVITE . . . . . . . . . . . . . . .
3.2.1.1 conflict with precondition UDPATEs . . . . . . . . . . . .
3.2.1.2 conflict with 2xx/4xx-6xx of re-INVITE . . . . . . . . . .
3.2.1.3 confusion state . . . . . . . . . . . . . . . . . . . . .
3.2.1.4 user approval . . . . . . . . . . . . . . . . . . . . . .
3.2.2 UPDATEs outside re-INVITE . . . . . . . . . . . . . . . .
3.3 UPDATEs for modifying codecs . . . . . . . . . . . . . . .
4. Conclusions. . . . . . . . . . . . . . . . . . . . . . . .
5. Security Considerations . . . . . . . . . . . . . . . . .
6. IANA Considerations . . . . . . . . . . . . . . . . . .
7. Normative References . . . . . . . . . . . . . . . . . .
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .
Wang.libo Expires September 12, 2009 [Page 2]
Internet-Draft Nested- UPDATEs March 2009
1. Introduction
Re-INVITE mothod is defined in Section 14 of RFC 3261 [RFC3261] and
UPDATE method is defined in Section 5 of RFC 3311 [RFC3311]. An
INVITE request sent within an existing dialog is known as a
re-INVITE, while UPDATE can be sent in both early and confirmed
dialogs.Although text in Section 5 of RFC 3311 [RFC3311] says, UPDATE
can be used on confirmed dialogs, it is RECOMMENDED that a re-INVITE
be used instead,but UPDATEs in confirmed dialogs are not limited now
if they obey OFFER/ANSWER model. As unlimited UPDATEs in confirmed
dialogs surely cause some intractable problems, expecially nested
ones.This document analysises the relationship between UPDATEs and
re-INVITEs, and raises a way in order to predigest intractable
problems.
UPDATEs talked in this document are in existing dialogs.
2. Classification of UPDATEs
According to usages, there are three classification of UPDATEs.
o UPDATEs for preconditions
o UPDATEs with new SDP to modify session parameters, dialog
parameters, or refresh target
o UPDATEs for modifying codecs
As there are arguments on UPDATEs for modifying codecs, I list as an
independent kind.
3. Analyse of UDPATEs
3.1 UPDATEs for preconditions
If new modification is implemented by a re-INVITE, precondition
notification UPDATEs coexist well with re-INVITEs, as the UAS should
wait for both preconditions are OK then decide whether to alert user
for approval. Figure.1 shows the case.
Wang.libo Expires September 12, 2009 [Page 3]
Internet-Draft Nested- UPDATEs March 2009
UAC UAS
| session established |
|<============================>|
| |
| F1 re-INVITE (SDP not met) |
|----------------------------->|
| F2 1xx-rel (SDP conf) |
|<-----------------------------|
| F3 UPDATE(met) |
|----------------------------->|
| F4 2xx (UPDATE) |
|<-----------------------------|
| |
| F5 180 ringing |
|<-----------------------------|
| |
| F6 2xx/4xx/5xx/6xx INV |
|<-----------------------------|
| F7 ACK |
|----------------------------->|
| |
Figure.1
3.2 UPDATEs with new SDP
3.2.1 Nested UPDATEs in re-INVITE
UPDATEs nested in re-INVITE with new SDP cause many problems.
3.2.1.1 Conflict with precondition UDPATEs
UPDATEs for new SDP will conflict with UPDATEs for precondition,as
UAs can change its codec at any moment, shown by figure.2.
UAC UAS
| session established |
|<===============================>|
| |
| F1 re-INVITE (SDP not met) |
|-------------------------------->|
| F2 1xx-rel (SDP conf) |
|<--------------------------------|
| F3 UPDATE(met) F4 UPDATE(codec) |
|-----------> <---------------|
| CONFLICT |
| |
Figure.2
Wang.libo Expires September 12, 2009 [Page 4]
Internet-Draft Nested- UPDATEs March 2009
3.2.1.2 Conflict with 2xx/4xx-6xx of re-INVITE
As UAS will send final response when preconditions are finished or
UAS decides to reject,unproposed UPDATEs for codec will raise
conflict, shown in figure 3 UAS accept re-INVITE and in figure 4 UAS
reject re-INVITE.
UAC UAS
| session established |
|<============================>|
| |
| F1 re-INVITE (SDP not met) |
|----------------------------->|
| F2 1xx-rel (SDP conf) |
|<-----------------------------|
| F3 UPDATE(met) |
|----------------------------->|
| F4 2xx (UPDATE) |
|<-----------------------------|
| |
| F5 180 ringing |
|<-----------------------------|
| |
| F6 UPDATE(codec) F7 2xx INV |
|-------------> <------------|
| CONFLICT |
Figure.3
UAC UAS
| session established |
|<==================================>|
| |
| F1 re-INVITE (SDP not met) |
|----------------------------------->|
| F2 1xx-rel (SDP conf) |
|<-----------------------------------|
| F3 UPDATE(met) |
|----------------------------------> |
| F4 2xx (UPDATE) |
|<-----------------------------------|
| |
| F5 180 ringing |
|<-----------------------------------|
| |
| F6 UPDATE(codec) F7 4xx/5xx/6xx INV|
|-------------> <---------------|
| / |
|F7 4xx/5xx/6xx INV/ |
|<---------------- |
| |
Figure.4
Wang.libo Expires September 12, 2009 [Page 5]
Internet-Draft Nested- UPDATEs March 2009
3.2.1.3 Confusion state
As there may be precondition UPDATEs,codec UPDATEs and new SDP
UDPATEs all nested in a re-INVITE, first of all, UAs have to
distinguish them from each other, and treat them different and it¡¯s
not wise and proper to treat them in a same way.
Also,when re-INVITE fails, UAs should determine which SDP to use, to
rollback to the state before re-INVITE,or to the state after
UPDATE/200.
3.2.1.4 User approval consideration
In Section 5 of RFC 3311 [RFC3311], it says, 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 is usual
needed, which can be processed with a re-INVITE.
Wang.libo Expires September 12, 2009 [Page 6]
Internet-Draft Nested- UPDATEs March 2009
To nested UPDATE for new SDP,UAS may have to reject the UPDATE with a
504 response if this new modification need user approval.For example,
first UAC send a re-INVITE with audio, when receives the answer,it
doesn¡¯t send precondition notification UPDATEs, instead, send an
UPDATE with both audio and vedio. As UAS cannot accept this new
UPDATE without asking for user approval,UAS should reject it with a
504 response ,and UAC should send a new re-INVITE with SDP again.This
case is shown in Figure 5.
UAC UAS
| session established |
|<==================================>|
| |
| F1 re-INVITE (audio) |
|----------------------------------->|
| F2 1xx-rel (SDP conf) |
|<-----------------------------------|
| F3 UPDATE (audio met) |
|----------------------------------> |
| F4 200 (UPDATE) |
|<-----------------------------------|
| F5 UPDATE(audio+vedio) |
|----------------------------------> |
| F6 504 (UPDATE) |
|<-----------------------------------|
| |
| F7 180 ringing |
|<-----------------------------------|
| |
| F8 200 INV |
|<-----------------------------------|
| |
| F9 ACK |
|----------------------------------> |
| |
| F10 re-INVITE(audio+vedio) |
|----------------------------------> |
| |
Figure.5
Wang.libo Expires September 12, 2009 [Page 7]
Internet-Draft Nested- UPDATEs March 2009
Although the new SDP UPDATE can be raised again after the re-INVITE,
waiting for the first re-INVITE finished and raising a new re-INVITE
just at the beginning seems better, shown in Figure 6.
UAC UAS
| session established |
|<==================================>|
| |
| F1 re-INVITE (audio) |
|----------------------------------->|
| F2 1xx-rel (SDP conf) |
|<-----------------------------------|
| F3 UPDATE (audio met) |
|----------------------------------> |
| F4 200 (UPDATE) |
|<-----------------------------------|
| F5 180 ringing |
|<-----------------------------------|
| |
| F6 200 INV |
|<-----------------------------------|
| |
| F7 ACK |
|----------------------------------> |
| |
| F8 re-INVITE(audio+vedio) |
|----------------------------------> |
Figure.6
3.2.2 UPDATEs outside re-INVITE
As RFC3311 says, although UPDATE can be used on confirmed dialogs, it
is RECOMMENDED that a re-INVITE be used instead, but I don¡¯t talk
more on UPDATEs outside re-INVITE as they can be processed without
confusion.
3.3 UPDATEs for modifying codecs
I list UDPATEs for modifying codecs as one classification as there
are diffierent opinions on whether this kind UPDATEs are new SDPs or
belong to the re-INVITEs.
NO MATTER it¡¯s a new SDP or not, this kind of UPDATEs surely cause
conflict as the cases list in section 3.2 UPDATEs with new SDP.
Wang.libo Expires September 12, 2009 [Page 8]
Internet-Draft Nested- UPDATEs March 2009
4. Conclusions
It¡¯s suggested£¬Precodition UPDATEs for re-INVITEs are allowed in
re-INVITEs,others,for NEW SDP and for NEW CODECs£¬are sent with new
re-INVITE.
If an UPDATE for NEW SDP and for NEW CODECs are happened just inside
a re-INVITE,UAC buffers and sends this SDP until the re-INVITE is
finished.
5. Security Considerations
This document does not introduce any new security issue. Security
issues related to re-INVITEs and UPDATE requests are discussed in RFC
3261 [RFC3261] and RFC 3311 [RFC3311].
6. IANA Considerations
There are no IANA actions associated with this document.
7. Normative References
[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.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, June 2002.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002.
[RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session
Initiation Protocol (SIP) Preconditions Framework",
RFC 4032, March 2005.
Author's Address
Wang libo
ZTE
Nanjing,CHINA
Email: wang.libo@xxxxxxxxxx
Wang.libo Expires September 12, 2009 [Page 9]
Internet-Draft Nested- UPDATEs March 2009
_______________________________________________ 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
