SIP Working Group S. Kanumuri Internet-Draft S. Sarkar Intended status: Standards Track Wipro Technologies Expires: April 16, 2007 October 15, 2006 The SIP SPECIFY Method draft-sreeram-specify-method-00 Status of this Memo By submitting this Internet-Draft, each author represents that 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 becomes aware will be disclosed, in accordance with Section 6 of 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 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 April 16, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document proposes an extension to the Session Initiation Protocol (SIP). This extension adds the SPECIFY method to the SIP protocol. The intent of the SPECIFY method is to allow conveying SIP entity's (Proxy, User Agent, Redirect Server) intention of asynchronous service change (i.e. to be taken out of service or has just return to service) with and with out a backup SIP entity within the same administrative domain. Kanumuri & Sarkar Expires April 16, 2007 [Page 1] Internet-Draft draft-sreeram-sip-specify-method-00.txt October 2006 Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Sample Use Cases . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. When Proxy's fail in the middle of a transaction . . . . . 4 2.2. In the PSTN-SIP inter working using SIP-T/SIP . . . . . . 5 2.3. SIPT used between PSTN-PSTN (PSTN-SIPT-PSTN) . . . . . . . 6 2.4. Essential proxy . . . . . . . . . . . . . . . . . . . . . 6 3. SPECIFY Method . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Motivation of a new method . . . . . . . . . . . . . . . . 7 3.2. Condition Header . . . . . . . . . . . . . . . . . . . . . 7 3.3. Contact Header . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Timer Header . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. Message Body Inclusion . . . . . . . . . . . . . . . . . . 10 4. SPECIFY Handling . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Sending a SPECIFY . . . . . . . . . . . . . . . . . . . . 10 4.2. Receiving a SPECIFY . . . . . . . . . . . . . . . . . . . 11 5. Augmented BNF Definitions . . . . . . . . . . . . . . . . . . 12 6. Example Call Flow . . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7.1. IANA Registration of SPECIFY method . . . . . . . . . . . 13 7.2. IANA Registration of SPECIFY method . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Normative References . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Kanumuri & Sarkar Expires April 16, 2007 [Page 2] Internet-Draft draft-sreeram-sip-specify-method-00.txt October 2006 1. Introduction A SIP proxy server handles multiple subscribers. It is important that a backup server is available so that an active server can be temporarily taken out of service for maintenance. There are multiple ways backup proxy servers can be used to minimize the service disruption. A relatively simple way to support proxy redundancy (i.e. backup proxy) is to configure a static list of SIP proxy servers in the configuration profile where the list is arranged in some order of priority. The subscriber will attempt to contact the proxy server in the order of priority. But the dynamic nature of SIP message routing makes the use of a static list of proxy servers inadequate in certain scenarios. For instance, if SIP user agents are served by different domains, it would not be feasible to configure one static list of proxy servers per covered domain by the subscriber. One solution to get around this problem is through the use DNS SRV records. The subscriber can be instructed to contact a SIP proxy server in a domain named in SIP messages. The subscriber shall consult the DNS server to get a list of hosts in the given domain that provides SIP services. If an entry exists, the DNS server will return a SRV record which contains a list of SIP proxy servers for the domain, with their host names, priority, listening ports, etc. The SIP entity shall try to contact the list of hosts in the order of their stated priority. But this is not always the case because all proxies may not have a backup proxy. Also in some cases based on the load and other factors, the network operator(s) may change the proxy dynamically which may not reflect in the DNS SRV records. The problem when the proxy with out backup fails is more realistic in SIP than it is in other transactional protocols. The reason for this is some SIP responses can take a long time to be generated, because a human intervention in order to generate a acceptable response. So, it is common for tens of seconds to elapse between a call request and its acceptance. This document highlights the problems and solution for the cases where a SIP entity goes for an asynchronous service change (e.g. restart, disconnect, overload) with and with out a backup SIP entity. On restart/disconnect of a SIP entity with backup, there should be a Kanumuri & Sarkar Expires April 16, 2007 [Page 3] Internet-Draft draft-sreeram-sip-specify-method-00.txt October 2006 graceful way of taking down the transient calls. Generally in softswitches/traditional switches (typically acting as a multi-line SIP User Agent), the back up of the active call data will be taken only when the call is established (i.e. talking state) and not when the call is in transient state. On restart/disconnect the active calls will recover, whereas the calls in transient state will remain, until some protocol timer gets expired which eventually clean-up the call related resources. Similarly, on restart/disconnect of a SIP entity without backup, the same problem exists and there is no way by which SIP entity that is restarting/disconnecting can inform about the alternative IP address (if available) to other SIP entities to which it can communicate so that graceful handling of existing sessions (or calls) or future sessions can be performed using alternate IP address. Unlike other network protocols (SS7, H.323), SIP has not defined procedures for handling device failure. If a SIP entity fails, the other SIP entity detects this through timer expiration leading to long delays in call establishment. Also, there is no standardized mechanism by which a SIP entity can inform other SIP entities to which it can communicate, about intention of service change (i.e. to be taken out of service or has just return to service) asynchronously. This document proposes an extension to the Session Initiation Protocol to provide a mechanism for asynchronous service change notification within the same administrative domain. If the method described in the draft used along with existing mechanism of service discovery provides a better method for controlling the services. 2. Sample Use Cases 2.1. When Proxy's fail in the middle of a transaction It is possible for elements to fail in the middle of a transaction. Kanumuri & Sarkar Expires April 16, 2007 [Page 4] Internet-Draft draft-sreeram-sip-specify-method-00.txt October 2006 For example, after Proxy 2 forwards the request to UA 2, Proxy 1 fails. UA 2 sends its response to Proxy 2, which tries to forward it to Proxy 1, which is no longer available. UA 2 tries to resend the response until the timer expires as Proxy 2 is not aware that Proxy 1 is no longer available. ............. ............. . . . . . +-------+ . . +-------+ . . | | . SIP . | | . . | Proxy |--------------| Proxy | . . | 1 | . . | 2 | . . | | . . | | . . +-------+ . . +-------+ . . | . . | . . | . . | . . | . . | . . +-----+ . . +-----+ . . | UA1 | . . | UA2 | . . +-----+ . . +-----+ . . . . . . Domain x . . Domain y . ............. ............. 2.2. In the PSTN-SIP inter working using SIP-T/SIP When the originating office SIP-T MGC (acting a multi-line SIP UA) has originating a call which is in alerting state, a restart of the MGC tears down the originating side of the call but not the terminating side. The reverse is true when the terminator is restarted. The terminating side of the call is torn down but not the originating side. The call will terminate only after the protocol time out. (This problem is applicable only for the transient calls) Kanumuri & Sarkar Expires April 16, 2007 [Page 5] Internet-Draft draft-sreeram-sip-specify-method-00.txt October 2006 ............. ............. . . . . . +-------+ . . +-------+ . . | | . SIP/SIP-T. | | . . | MGC |--------------| MGC | . . | 1 | . . | 2 | . . | | . . | | . . +-------+ . . +-------+ . . | . . | . . | . . | . . | . . | . . +-----+ . . +-----+ . . | MG1 | . . | MG2 | . . +-----+ . . +-----+ . . . . . . Domain x . . Domain y . ............. ............. 2.3. SIPT used between PSTN-PSTN (PSTN-SIPT-PSTN) There will be a limit to the number of simultaneous calls that can be made using SIP-T (or) on proxy. There should be some way to inform the other side that the maximum numbers of calls it can handle has reached to prevent call failures because of overloading. 2.4. Essential proxy Essential proxy is a proxy which need to be inserted for all the outgoing and incoming requests to a particular domain. In the below call flow UA1--SIP GW--P1--P2--P3--UA2 SIP GW is a sip gateway for the UA1. P2 is the Essential proxy which need to be inserted for all the outgoing and incoming Requests coming from UA1 All the calls coming out of P1 will have the P2 inserted in the route. If there is no backup for Proxy P2, on Disconnecting P1 should be informed that another Proxy P4 is available in the network which does the opertions of P2. There is no exsisting mechanism which can do this. Kanumuri & Sarkar Expires April 16, 2007 [Page 6] Internet-Draft draft-sreeram-sip-specify-method-00.txt October 2006 3. SPECIFY Method 3.1. Motivation of a new method The INVITE method of SIP protocol helps in establishing voice calls between SIP user agents. Also the SIP INFO helps in carrying application level information along the SIP signaling path during a SIP Session and SIP MESSAGE method sends an instant message to remote UA. NOTIFY mechanism is used for asynchronous (but solicited) notification of events requested (SUBSCRIBED) by the other SIP entity only. Since none of the existing methods provide the intended functionality, we are proposing a NEW method which provides that functionality. Using SUBSCRIBE/NOTIFY mechanism for this problem is very expensive because it needs to have N x N subscriptions. Both the entities should maintain the subscription states for this new event. It should be the originator's responsibility to intimate others about the change of state and not be on request as with SUBSCRIBE/NOTIFY. This is an unsolicited request. None of these existing methods fulfill the requirement of conveying SIP Entity' intention of service change. Hence "SPECIFY" has been introduced. "SPECIFY" is a SIP method as defined by RFC 3261. "SPECIFY" will be hop to hop. The SPECIFY method indicates that the initiator of SPECIFY is changing (or has changed) its state. SPECIFY method follows the semantics of OPTIONS mechanism. SPECIFY can be used either between a proxy to proxy and proxy to UA or UA to UA. "SPECIFY" can be used before taken out of service or after return to service. A SPECIFY request does not establish a dialog.The Record-Route header field has no meaning in SPECIFY requests or responses, and MUST be ignored if present. In particular, the SIP entity MUST NOT create a new route set based on the presence or absence of a Record-Route header field in any response to a SPECIFY request. 3.2. Condition Header There is no SIP header, through which the service change reason of the SIP entity can be informed. So the "condition" header is introduced. Condition header can have the following possible values: a. Graceful - indicates that the entity that has sent "SPECIFY" will be taken out of service after the specified time; established Kanumuri & Sarkar Expires April 16, 2007 [Page 7] Internet-Draft draft-sreeram-sip-specify-method-00.txt October 2006 connections are not yet affected, but the notifier should refrain from establishing new connections and should attempt to gracefully tear down existing connections on the initiator affected by the "SPECIFY" Request. (This is a case of disconnect.) b. Forced - indicates that the entity was taken abruptly out of service and any established connection associated with them may be lost. The notifier is responsible for cleaning up the connections (if any) with which the initiator of the "SPECIFY" is associated. In this case "SPECIFY" MAY be used after the entity is back to service. (This is a "Restart" case) Trigger to sent out a SPECIFY after a disconnect or restart case is implementation dependent and is outside the scope of this document. c. Failover - indicate the primary SIP entity is out of service and a secondary SIP entity is taking over. In the case, where there is no secondary SIP entity, the primary SIP entity will behave as that of a "graceful" condition. d. Overload - indicates the entity's overloaded condition; established connections are not affected, but the notifier should refrain from establishing new connections A condition header parameter "cleared" is introduced for overload condition to indicate that the overload condition is cleared. This table expands on tables 2 and 3 in SIP RFC 3261 [RFC3261], as amended by the changes described in section 7.1. Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT SPY --------------------------------------------------------------------- Condition R - - - - - - - - - m 3.3. Contact Header There is no SIP header which can inform the "optional IP address" that is used for subsequent messages when the active SIP entity is out of service. Alternatively, we suggest using the existing "Contact" Header. In the SPECIFY method, if the Contact header is present it gives the address of the alternative (backup) SIP entity that will be used in subsequent messages. There can be multiple contact addresses in the SPECIFY request. If more than one Contact is sent in a SPECIFY request, the list can be prioritized with the "q" parameter in the Kanumuri & Sarkar Expires April 16, 2007 [Page 8] Internet-Draft draft-sreeram-sip-specify-method-00.txt October 2006 Contact header field. The "q" parameter indicates a relative preference for the particular Contact header field value compared to other. The entity receiving the SPECIFY method, not having the Contact header means all the calls that are related to the entity that initiated SPECIFY should be taken down (Assuming that when there is no Contact header, there is no back up for that entity). Similarly, the entity on receiving the SPECIFY method having the Contact header(s) MAY take down the transient calls. The only exception is in case of overload condition, where the entity receiving the SPECIFY method, not having the Contact header indicates no new connections should be made to the entity that initiated SPECIFY unless the overload condition is cleared and having the Contact header(s) indicates new connections will be routed to the alternate IP address. This table expands on tables 2 and 3 in SIP RFC 3261 [RFC3261], as amended by the changes described in section 7.1. Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT SPY --------------------------------------------------------------------- Contact R o - - m o o - m m o Bringing down the transient calls when SPECIFY is having Contact header is implementation dependent. For instance, having the proxy with backup of transient calls, using CONTACT header all the calls can be routed to that new IP address. 3.4. Timer Header This header indicates the time in seconds after which the entity that have sent the SPECIFY method will change its state. The SPECIFY method MUST have the Date header, when the Timer header is present. When the entity receives a SPECIFY, it computes the Time at which the entity that has sent the SPECIFY will change its state using the Timer and Date headers. The value of Timer field is an integral number of seconds (in decimal) between 0 and (2**32)-1. This table expands on tables 2 and 3 in SIP RFC 3261 [RFC3261], as Kanumuri & Sarkar Expires April 16, 2007 [Page 9] Internet-Draft draft-sreeram-sip-specify-method-00.txt October 2006 amended by the changes described in section 7.1. Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT SPY --------------------------------------------------------------------- Date R o o o o o o o o o c Timer R - - - - - - - - - o Note: The Expires header defined in RFC 3261 [RFC3261] can also be used BUT with overloading its existing meaning. This is still open. The Default value of Timer is 3600 seconds 3.5. Message Body Inclusion The SPECIFY request MAY contain a message body. The definition of the message bodies is outside the scope of this document. 4. SPECIFY Handling 4.1. Sending a SPECIFY Unless stated otherwise, the protocol rules for the SPECIFY request governing the usage of tags, retransmission and reliability, CSeq incrementing and message formatting follow those in RFC 3261 [RFC3261] as defined for the OPTIONS request. When the SIP entity is going for a Graceful disconnect and have no back-up server, it sends a SPECIFY with - Condition: Graceful - Timer and Date headers at what time it goes for Graceful disconnect, and - No Contact header When the SIP entity is going for a Graceful disconnect and want to route all the calls to some other (i.e. backup or alternate route) proxy(s), it sends SPECIFY with - Condition: Graceful - Contact header(s) with backup or alternate route proxy(s) information When the SIP entity is going for a Failover (Changing from active to inactive pair), it sends SPECIFY with - Condition: Failover Kanumuri & Sarkar Expires April 16, 2007 [Page 10] Internet-Draft draft-sreeram-sip-specify-method-00.txt October 2006 When the SIP entity recovers from a service disruption (i.e. proxy is back to service after a restart), it sends SPECIFY with - Condition: Forced When the SIP entity is going for an overload condition, it sends a SPECIFY with - Condition: Overload - Contact header(s) with alternate route information When the SIP entity is clearing an overload condition, it sends a SPECIFY with - Condition: Overload;cleared The list of sip entities that need to be send the SPECIFY request on a service change is beyond the scope of this document. It is up the implementation to decide to whom this Request is to be sent. 4.2. Receiving a SPECIFY The response to a SPECIFY is constructed using the standard rules for a SIP response as described in Section 8.2.6 in RFC 3261 [RFC3261] The SIP entity on receiving the SPECIFY (with Condition: Graceful and no contact header) will bring down all the transient calls and active calls at the mentioned time. The SIP entity on receiving the SPECIFY (with Condition: Graceful and contact header with alternate routes) will bring down all the transient calls and active calls and updates its SERV records in DNS with the new address as indicated in the contact header. The SIP entity on receiving the SPECIFY (with Condition: Failover) will bring down all the transient calls immediately. In general in soft switches, the transient call details will not be backed up. The SIP entity on receiving the SPECIFY (with Condition: Forced) will update the DNS record with proxy's IP address. The SIP entity on receiving the SPECIFY (with Condition: Overload and no contact header) should restrict itself form initiating any new connections to overloaded SIP entity. The SIP entity on receiving the SPECIFY (with Condition: Overload and contact header) should restrict itself for initiating any new Kanumuri & Sarkar Expires April 16, 2007 [Page 11] Internet-Draft draft-sreeram-sip-specify-method-00.txt October 2006 connections to overloaded SIP entity and updates its SERV records in DNS with the new address as indicate in the alternate incase of the current proxy. If a proxy receives a SPECIFY request it MUST send a final response following non-INVITE transaction state machine rules. A 200 OK response MUST be sent by a proxy for a SPECIFY request if the SPECIFY request was successfully handled. Other request failure (4xx) responses MAY be sent for the SPECIFY Request. 5. Augmented BNF Definitions The Augmented BNF definitions for the various new and modified syntax elements follow. The notation is as used in SIP RFC 3261 [RFC3261], and any elements not defined in this section are as defined in SIP and the documents to which it refers. SPECIFYm = %x53.50.45.43.49.46.59; SPECIFY in caps extension-method = SPECIFYm / token Condition = "Condition" HCOLON condition-type *( SEMI condition-param ) condition-type = "graceful" / "forced" / "failover" / "overload" / condition-type-extension condition-type-extension = token condition-param = generic-param / overload-condition-parm overload-condition-parm = "cleared" Timer = "Timer" HCOLON delta-seconds delta-seconds = 1*DIGIT Kanumuri & Sarkar Expires April 16, 2007 [Page 12] Internet-Draft draft-sreeram-sip-specify-method-00.txt October 2006 6. Example Call Flow UA 1 Server 1 Server 2 UA 2 | | | | | | SPECIFY | | | |-------------->| | | | 200 OK | | | |<--------------| | | | | | SPECIFY sip:server2@blr.example.com SIP/2.0 Via: SIP/2.0/UDP server1.example.com;branch=z9hG4bKhjhs8ass877 Max-Forwards: 70 To: Server 2 From: Server 1 ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 63104 SPECIFY Contact: Condition: Graceful Date: Sat, 01 Jun 2006 23:29:00 GMT Timer: 80 Content-Length: 0 SIP/2.0 200 OK Via: SIP/2.0/UDP server1.example.com;branch=z9hG4bKhjhs8ass877 To: Server 2 ;tag=93810874 From: Server 1 ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 63104 SPECIFY Contact: Content-Length: 0 7. IANA Considerations This document registers a new method and two new headers, based on the IANA registration process of RFC 3261 [RFC3261]. 7.1. IANA Registration of SPECIFY method This specification registers a new method, SPECIFY. The required information for this registration, as specified in RFC 3261 [RFC3261], is: RFC xxxx: This specification serves as the RFC for registering the SPECIFY request method. Kanumuri & Sarkar Expires April 16, 2007 [Page 13] Internet-Draft draft-sreeram-sip-specify-method-00.txt October 2006 Method Name: SPECIFY Reason Phrase: Not applicable. 7.2. IANA Registration of SPECIFY method The following is the registration for the Condition header: RFC Number: RFCxxxx Header Name: Condition Compact Form: none The following is the registration for the Timer header: RFC Number: RFCxxxx Header Name: Timer Compact Form: none 8. Security Considerations To Include In. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. Kanumuri & Sarkar Expires April 16, 2007 [Page 14] Internet-Draft draft-sreeram-sip-specify-method-00.txt October 2006 Authors' Addresses Sreeram Kanumuri Wipro Technologies Plot No.72, Keonics Electronics City, Hosur Main Road, Bangalore 560 100 India Email: sreeram.kanumuri@wipro.com Subhodeep Sarkar Wipro Technologies Plot # 1,7 & 8, Block DM, Sector - V, Salt Lake, Kolkata 700 091 India Email: subhodeep.sarkar@wipro.com Kanumuri & Sarkar Expires April 16, 2007 [Page 15] Internet-Draft draft-sreeram-sip-specify-method-00.txt October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Kanumuri & Sarkar Expires April 16, 2007 [Page 16]