SIP UPDATE Support
Available Languages
Table Of Contents
Cisco BTS 10200 Softswitch SIP UPDATE Feature Module, Release 6.0.3
Reverse Processing of SIP UPDATE
Cisco BTS 10200 Softswitch SIP UPDATE Feature Module, Release 6.0.3
Last Updated: August 10, 2011The Cisco BTS 10200 Softswitch Session Initiation Protocol (SIP) UPDATE feature allows a User Agent Client (UAC) to modify the characteristics of a session (such as, putting the early media on hold) before or after a call is answered. The UPDATE is sent by the user agent (UA) to modify a session, within an early dialog without impacting the dialog state.
An early dialog refers to a state in the dialog, when a UAC (caller) sends an INVITE, but the destination UAC (callee) does not generate a 2xx response. Similarly, a confirmed dialog refers to a state of a dialog when a 200 OK response has been generated for the INVITE message sent by a caller. A 2xx response transitions the dialog to a confirmed state.
For more information on UA, UAC, User Agent Server (UAS), see the SIP Overview chapter in the Cisco BTS 10200 Softswitch SIP Guide.
NoteThe feature is based on:
RFC 3261, SIP: Session Initiation Protocol
RFC 3311, The Session Initiation Protocol (SIP) UPDATE Method
Note
RFC 3261, SIP: Session Initiation Protocol.
RFC 3960, Early Media and Ringing Tone Generation.
RFC 3311, The Session Initiation Protocol (SIP) UPDATE Method.
RFC 3264, An Offer/Answer Model Session Description Protocol.Contents
–
Feature Overview
An UPDATE is a mid-dialog request that a call originator or receiver sends after a session has been initiated using an INVITE message; but that has not been accepted by the receiver or the originator.
A SIP UPDATE enables a client to modify the parameters of a session (such as the media streams and codecs) in early dialogs. An UPDATE is similar to a RE-INVITE request, but unlike a RE-INVITE, it can be sent before the initial INVITE is answered. A RE-INVITE affects the session (the media stream) and the dialog. In contrast, an UPDATE does not impact the dialog state, and helps in scenarios where the media in early dialog needs to be put on hold.
For more information on a RE-INVITE request, see the RFC 3261: SIP: Session Initiation Protocol.
Reverse Processing of SIP UPDATE
Currently, the BTS 10200 supports forward processing of the SIP UPDATE. This means that the originator of a call (caller) would be able to send an UPDATE to modify the session characteristics, whereas the destination end (callee) would be unable to modify the session characteristics.
In Release 6.0.3, the BTS 10200 supports reverse processing of the UPDATE by processing UPDATE requests received from a callee.
Figure 1 displays the forward and reverse processing of a SIP UPDATE.
Figure 1 Reverse Processing of SIP UPDATE
Remote Target Refresh
The RFC 3261 defines a target refresh request sent within a dialog as a request that modifies the remote target of a dialog. An UPDATE is also a target refresh request. An UPDATE response can also be used for changing a contact address, and to receive further requests on a different contact address.
As per RFC 3311, if a UA uses an UPDATE request or an UPDATE response to modify the remote target while an INVITE transaction is in progress, and it is a UAS for that INVITE transaction, then it must place the same value into the Contact header field of the 2xx response to the INVITE that it placed into the UPDATE request or response.
Figure 2 shows a UPDATE response used to refresh a remote target.
Figure 2 UPDATE Response for Remote Target Refresh
Note
the originating segment (when the BTS 10200 receives an INVITE as a UAS) and the terminating segment (when the BTS 10200 sends the INVITE as a UAC). On both segments the contacts are maintained separately and updated on a remote target refresh request or response.Support in Early Dialogs
During an early dialog (where a session is established before the SIP INVITE is accepted), a caller can send an UPDATE containing an SDP offer to modify the characteristics of the session. As a result, the callee sends a 2xx response, which contains the answer to the SDP offer.
For more information on SDP answer and offer model, see RFC 3264, An Offer/Answer Model Session Description Protocol.
The Allow header field in the response of the callee indicates the support for an UPDATE.
NoteThe BTS 10200 handles updates in the following three scenarios:
•
•
•
Sending an UPDATE
The BTS 10200 creates an UPDATE request as any other request during the middle of a dialog. It may be sent for early dialogs, by either a caller or a callee. In confirmed dialogs, the BTS 10200 sends only RE-INVITE requests instead of an UPDATE.
The UPDATE is also used as a remote target refresh request. When an UPDATE request is sent by a client with a new contact SIP URI, then all subsequent SIP requests are received at the new address of the client.
Figure 3 shows the callflow for remote target refresh using UPDATE request.
Figure 3 UPDATE Request for Remote Target Refresh Call Flow
A client can also refresh a remote target by sending a new SIP URI in an UPDATE response. If it is processed successfully, all subsequent requests are sent at the new SIP URI of the client.
Receiving an UPDATE
If the BTS 10200 receives an UPDATE that contains an offer, and if the BTS 10200 received an offer earlier (in an UPDATE, PRACK, or INVITE) to which it has not yet generated an answer, it rejects the UPDATE with a 500 response. Additionally, it includes a Retry-After header field in the 500 response. (This behavior is applicable in both confirmed and early dialogs).
Figure 4 displays the call flow for rejection of an UPDATE with a 500 response.
Figure 4 Rejection of UPDATE with 500 Response Call Flow
Figure 5 shows the call flow for a rejection of UPDATE method with a 491 response.
Figure 5 Rejection of UPDATE with 491 Response Call Flow
If the BTS 10200 receives an UPDATE that contains an offer, and BTS 10200 has generated an offer (in an earlier UPDATE, PRACK or INVITE) to which it has not yet received an answer, it rejects the UPDATE with a 491 response. (This is applicable in both confirmed and early dialogs).
When a UAC of BTS 10200 (acting as a B2BUA) receives a 491 response for the UPDATE request, then the BTS 10200 notifies SIP Phone 1 with a 500 error response with a retry time of a second.
Processing an UPDATE
The BTS10200 processes all SIP UPDATE requests and responses. It generates the 200 OK message when the UPDATE is successfully processed. Otherwise, it generates error messages such as 4xx or 5xx. It also, refreshes the remote target based on an UPDATE request or response.
Additional References
Related Documents
Summary of features and usage guidelines for this release
Reference listing of all CLI tables and tokens
SIP Features
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2011 Cisco Systems, Inc. All rights reserved.
Feedback