draft-ietf-sipping-sip-offeranswer-05.txt   draft-ietf-sipping-sip-offeranswer-06.txt 
SIPPING Working Group T. Sawada SIPPING Working Group T. Sawada
Internet Draft KDDI Corporation Internet Draft KDDI Corporation
Intended status: Informational P. Kyzivat Intended status: Informational P. Kyzivat
Expires: July 2008 Cisco Systems, Inc. Expires: August 2008 Cisco Systems, Inc.
January 13, 2008 February 25, 2008
SIP (Session Initiation Protocol) Usage of the Offer/Answer Model SIP (Session Initiation Protocol) Usage of the Offer/Answer Model
draft-ietf-sipping-sip-offeranswer-05.txt draft-ietf-sipping-sip-offeranswer-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 37 skipping to change at page 1, line 37
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on November 13, 2007. This Internet-Draft will expire on November 25, 2007.
Abstract Abstract
The Session Initiation Protocol (SIP) utilizes the offer/answer The Session Initiation Protocol (SIP) utilizes the offer/answer
model to establish and update multimedia sessions using the Session model to establish and update multimedia sessions using the Session
Description Protocol (SDP). The description of the offer/answer Description Protocol (SDP). The description of the offer/answer
model in SIP is dispersed across multiple RFCs. This document model in SIP is dispersed across multiple RFCs. This document
summarizes all the current usages of the offer/answer model in SIP summarizes all the current usages of the offer/answer model in SIP
communication. communication.
skipping to change at page 2, line 35 skipping to change at page 2, line 35
5.2.2. Responding with an Offer when the Initial INVITE has 5.2.2. Responding with an Offer when the Initial INVITE has
no Offer..................................................16 no Offer..................................................16
5.2.3. Answering an Initial INVITE with Offer.............17 5.2.3. Answering an Initial INVITE with Offer.............17
5.2.4. Answering when the Initial INVITE had no Offer.....18 5.2.4. Answering when the Initial INVITE had no Offer.....18
5.2.5. Subsequent Offers and Answers......................18 5.2.5. Subsequent Offers and Answers......................18
5.3. Hold and Resume of media................................19 5.3. Hold and Resume of media................................19
5.4. Behavior on receiving SDP with c=0.0.0.0................20 5.4. Behavior on receiving SDP with c=0.0.0.0................20
6. Remaining Issues or Best Practices on Offer/Answer...........20 6. Remaining Issues or Best Practices on Offer/Answer...........20
6.1. Rejecting PRACK Offer...................................21 6.1. Rejecting PRACK Offer...................................21
6.2. Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE 6.2. Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE
Transaction..................................................21 Transaction..................................................22
6.3. Offer in a Reliable Response............................23 6.3. Offer in a Reliable Response............................23
6.4. Requesting Hold while already on Hold...................23 6.4. Requesting Hold while already on Hold...................24
7. Add New Offer/Answer Usage in SIP............................24 7. Add New Offer/Answer Usage in SIP............................24
7.1. Explicit Usage..........................................24 7.1. Explicit Usage..........................................24
7.2. Rejection of an Offer...................................24 7.2. Rejection of an Offer...................................24
7.3. Backward Compatibility..................................24 7.3. Backward Compatibility..................................24
7.4. Exceptional Case Handling...............................24 7.4. Exceptional Case Handling...............................24
8. IANA Considerations..........................................24 8. IANA Considerations..........................................25
9. Security Considerations......................................24 9. Security Considerations......................................25
10. References..................................................25 10. References..................................................25
10.1. Normative References...................................25 10.1. Normative References...................................25
10.2. Informative References.................................25 10.2. Informative References.................................25
Author's Addresses..............................................25 Author's Addresses..............................................26
Full Copyright Statement........................................26 Full Copyright Statement........................................26
Intellectual Property Statement.................................26 Intellectual Property Statement.................................26
Acknowledgment..................................................27 Acknowledgment..................................................27
1. Introduction 1. Introduction
SIP utilizes the offer/answer model to establish and update the SIP utilizes the offer/answer model to establish and update the
session. The rules to govern the offer/answer behaviors in SIP are session. The rules to govern the offer/answer behaviors in SIP are
described in the several RFCs. described in the several RFCs.
skipping to change at page 6, line 7 skipping to change at page 6, line 7
When a UA receives an UPDATE request with an offer which it can not When a UA receives an UPDATE request with an offer which it can not
accept, it should respond with a 488 response preferably with accept, it should respond with a 488 response preferably with
Warning header field indicating the reason of the rejection, unless Warning header field indicating the reason of the rejection, unless
another response code is more appropriate to reject it. (Pattern 6) another response code is more appropriate to reject it. (Pattern 6)
When a UA receives a PRACK request with an offer which it can not When a UA receives a PRACK request with an offer which it can not
accept, it may respond with a 200 response with a syntactically accept, it may respond with a 200 response with a syntactically
correct session description. This may optionally be followed by an correct session description. This may optionally be followed by an
UPDATE request to rearrange the session parameters if both ends UPDATE request to rearrange the session parameters if both ends
support the UPDATE method. Alternatively the UA may terminate the support the UPDATE method. Alternatively the UA may terminate the
dialog and send an error response to the INVITE request. (Pattern dialog and send an error response to the INVITE request. The
5) validity and consequences of a 488 response to PRACK is an open
issue which is discussed within a sequent section. (Pattern 5)
When a UA receives a response with an offer which it can not accept, When a UA receives a response with an offer which it can not accept,
the UA does not have a way to reject it explicitly. Therefore, a UA the UA does not have a way to reject it explicitly. Therefore, a UA
should respond to the offer with the correct session description should respond to the offer with the correct session description
and rearrange the session parameters by initiating a new and rearrange the session parameters by initiating a new
offer/answer exchange, or alternatively terminate the session. offer/answer exchange, or alternatively terminate the session.
(Pattern 2 and Pattern 4.) When initiating a new offer/answer, a UA (Pattern 2 and Pattern 4) When initiating a new offer/answer, a UA
should take care not to cause an infinite offer/answer loop. should take care not to cause an infinite offer/answer loop.
Offer Rejection Offer Rejection
----------------------------------------------------- -----------------------------------------------------
1. INVITE Req. 488 INVITE Response 1. INVITE Req. 488 INVITE Response
2. 2xx INVITE Resp. Answer in ACK Req. followed by new offer 2. 2xx INVITE Resp. Answer in ACK Req. followed by new offer
OR termination of dialog OR termination of dialog
3. INVITE Req. 488 INVITE Response (same as Pattern 1.) 3. INVITE Req. 488 INVITE Response (same as Pattern 1.)
4. 1xx-rel INVITE Resp. Answer in PRACK Req. followed by new offer 4. 1xx-rel INVITE Resp. Answer in PRACK Req. followed by new offer
5. PRACK Req. (*) 200 PRACK Resp. followed by new offer 5. PRACK Req. (*) 200 PRACK Resp. followed by new offer
skipping to change at page 10, line 24 skipping to change at page 10, line 24
A UA can send an UPDATE request with a new offer if both ends A UA can send an UPDATE request with a new offer if both ends
support the UPDATE method. Note that if the UAS needs to prompt the support the UPDATE method. Note that if the UAS needs to prompt the
user to accept or reject the offer, the delay can result in user to accept or reject the offer, the delay can result in
retransmission of the UPDATE request. retransmission of the UPDATE request.
A UA can send a PRACK request with a new offer only when A UA can send a PRACK request with a new offer only when
acknowledging the reliable provisional response carrying the answer acknowledging the reliable provisional response carrying the answer
to an offer in the INVITE request. Compared to using the UPDATE to an offer in the INVITE request. Compared to using the UPDATE
method, using PRACK can reduce the number of messages exchanged method, using PRACK can reduce the number of messages exchanged
between the UAs. However, as a PRACK request should not be rejected, between the UAs. However, to avoid problems or delays caused by
the UA is recommended to send a PRACK request only when it has PRACK offer rejection, the UA is recommended to send a PRACK
strong reasons to expect the receiver will accept it. For example, request only when it has strong reasons to expect the receiver will
the procedure used in precondition extension [5] is a case where a accept it. For example, the procedure used in precondition
PRACK request should be used for updating the session status in an extension [5] is a case where a PRACK request should be used for
early dialog. Note also that if a UAS needs to prompt the user to updating the session status in an early dialog. Note also that if a
accept or reject the offer, the delay can result in retransmission UAS needs to prompt the user to accept or reject the offer, the
of the PRACK request. delay can result in retransmission of the PRACK request.
From a UA receiving an INVITE request: From a UA receiving an INVITE request:
A UA can send an UPDATE request with a new offer if both ends A UA can send an UPDATE request with a new offer if both ends
support the UPDATE method. A UAS can not send a new offer in the support the UPDATE method. A UAS can not send a new offer in the
reliable provisional response, so the UPDATE method is the only reliable provisional response, so the UPDATE method is the only
method for a UAS to update an early session. method for a UAS to update an early session.
3.3. Offer/Answer Exchange in an Established Dialog 3.3. Offer/Answer Exchange in an Established Dialog
skipping to change at page 12, line 10 skipping to change at page 12, line 10
Figure 3 Message Crossing Case Figure 3 Message Crossing Case
When offer2 is in an UPDATE request or a re-INVITE request, a When offer2 is in an UPDATE request or a re-INVITE request, a
session description cannot be the expected answer. Then UA A must session description cannot be the expected answer. Then UA A must
reject the message including offer2 with a 491 response with Retry- reject the message including offer2 with a 491 response with Retry-
After header field. After header field.
When offer2 is in a PRACK request(as shown in Figure 4), that is, When offer2 is in a PRACK request(as shown in Figure 4), that is,
when the PRACK request is acknowledging a reliable provisional when the PRACK request is acknowledging a reliable provisional
response with an answer to an offer in an INVITE request containing response with an answer to an offer in an INVITE request containing
a session description, UA A knows it is an offer. As a PRACK a session description, UA A knows it is an offer. To avoid
request should not be rejected, UA A is recommended to wait for rejecting the PRACK or PRACK offer, UA A is recommended to wait for
answer1 before sending a PRACK response with the answer to the answer1 before sending a PRACK response with the answer to the
offer2. Note that if UA A does not send a new offer until the offer2. Note that if UA A does not send a new offer until the
reliable provisional response with an answer to the offer in the reliable provisional response with an answer to the offer in the
INVITE request is acknowledged with a PRACK request, this case INVITE request is acknowledged with a PRACK request, this case
never happens. Therefore, to simplify implementations, a UA acting never happens. Therefore, to simplify implementations, a UA acting
as a UAS for an INVITE transaction is recommended not to defer as a UAS for an INVITE transaction is recommended not to defer
sending an UPDATE request with an offer until after the reliable sending an UPDATE request with an offer until after the reliable
response with an answer to the offer in the INVITE request is response with an answer to the offer in the INVITE request is
acknowledged with a PRACK request. acknowledged with a PRACK request.
skipping to change at page 21, line 17 skipping to change at page 21, line 17
RFCs. Those remaining issues are described in this section mainly RFCs. Those remaining issues are described in this section mainly
for further study. for further study.
6.1. Rejecting PRACK Offer 6.1. Rejecting PRACK Offer
As stated in section 2.2. and 3.2. , it is recommended that an As stated in section 2.2. and 3.2. , it is recommended that an
offer not be sent in a PRACK request unless UAC has strong reasons offer not be sent in a PRACK request unless UAC has strong reasons
to assume the receiver will accept it. Even so, there may be cases to assume the receiver will accept it. Even so, there may be cases
when the UAS has to reject the offer for some reason. The current when the UAS has to reject the offer for some reason. The current
RFCs do not provide a way to reject the offer and at the same time RFCs do not provide a way to reject the offer and at the same time
to acknowledge the reliable response. to indicate that the PRACK adequately acknowledged the reliable
response. It is unclear whether a non-200 response can still
indicate an acknowledgement of the reliable response.
Several ideas were presented to resolve this issue, such as sending Several ideas were presented to resolve this issue, such as sending
2xx PRACK response without SDP to reject the offer, or sending SDP 2xx PRACK response without SDP to reject the offer, or sending SDP
with a decreased version value in the o-line. Some of the with a decreased version value in the o-line. Some of the
candidates may also be adapted as a way to reject an unacceptable candidates may also be adapted as a way to reject an unacceptable
offer in a response. Anyway, those proposals violate the current offer in a response. Anyway, those proposals violate the current
rules and lose backward compatibility to some extent (e.g. section rules and lose backward compatibility to some extent (e.g. section
5 of RFC 3262). It is beyond the scope of this document and remains 5 of RFC 3262). It is beyond the scope of this document and remains
for further study. for further study.
The 488 response is another proposed solution; however the validity
and consequences of a 488 response to PRACK is an open issue.
Because the 488 response may be sent by a proxy, the UAC cannot
assume the reliable transaction has been adequately acknowledged.
If a 488 response is received, the UAC should ensure acknowledgment
of the reliable response by sending a new PRACK with the offer
removed or modified based upon the received 488 response. If the
488 response is sent by UAS (open issue), it cannot assume that the
UAC thinks that the reliable transaction has been adequately
acknowledged even though the UAS may treat otherwise (open issue).
If a 488 response is sent by UAS, the UAC should accommodate
receiving the altered PRACK with higher CSeq without expecting it
to trigger a 481 response (open issue).
NOTE: Deprecation of the usage of offer in PRACK may be NOTE: Deprecation of the usage of offer in PRACK may be
another solution. As the precondition mechanism specification another solution. As the precondition mechanism specification
[2] explicitly shows a usage of sending offer in PRACK, its [2] explicitly shows a usage of sending offer in PRACK, its
deprecation could cause backward compatibility issues. deprecation could cause backward compatibility issues.
6.2. Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE 6.2. Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE
Transaction Transaction
When a re-INVITE transaction fails, the dialog remains with the When a re-INVITE transaction fails, the dialog remains with the
session bound to it. The issue here is: what is the session status session bound to it. The issue here is: what is the session status
 End of changes. 13 change blocks. 
23 lines changed or deleted 40 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/