Network Working Group Pengsheng. Zhang Internet-Draft China Telecom Expires: March 15, 2006 Peili. Xu Huawei Technologies Hao. Shi ZTE Jonathan. Chen UtstarCom Zhiqiang. Liu Alcatel Shanghai Bell Yijun. Hu September 11, 2005 A method for overlap signalling in SIP draft-zhang-sipping-overlap-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 March 15, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Zhang, et al. Expires March 15, 2006 [Page 1] Internet-Draft A method for overlap signalling in SIP September 2005 Overlap signalling is a traditional feature in telecom network. RFC 3578 addresses how to implement it in a SIP network. It mainly introduce the method to carry subsequent dialed number in INVITE. But there are still some issues for it. This document gives a detailed discussion on another method based on INFO. It can be treated as a supplementary for RFC 3578. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Overlap signalling in a SIP network . . . . . . . . . . . . . 8 5. x-session-info . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Entity behavior for overlap signalling . . . . . . . . . . . . 12 6.1. Originating Server Behavior . . . . . . . . . . . . . . . 12 6.1.1. SIP-ISUP Interworking Function (IWF) Behavior . . . . 12 6.1.2. SIP based IAD or AG Behavior . . . . . . . . . . . . . 12 6.2. Intermediate Server Behavior . . . . . . . . . . . . . . . 13 6.3. Terminating Server Behavior . . . . . . . . . . . . . . . 13 6.3.1. SIP-ISUP IWF Behavior . . . . . . . . . . . . . . . . 13 6.3.2. B2BUA Behavior . . . . . . . . . . . . . . . . . . . . 14 7. Additional requirements for Originating Server . . . . . . . . 15 7.1. Convert subsequent overlap signalling into SIP en-bloc Signalling . . . . . . . . . . . . . . . . . . . . . . . . 15 7.2. Continue trying to sending overlap signalling to a SIP Network . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. Normative References . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Zhang, et al. Expires March 15, 2006 [Page 2] Internet-Draft A method for overlap signalling in SIP September 2005 1. Introduction There are two approaches of sending overlap signalling in a SIP network described in RFC 3578 [2]: sending the subsequent digits in a SIP request (e.g., INFO [3]) within an early dialog, or sending a new INVITE which contains all the digits received so far every time a new SAM is received. RFC 3578 mainly focuses on the INVITE method and doesn`t address the INFO method in detail. For the second approach, it can work well in the applicability scope of RFC 3578. However, in some scenarios, this solution might cause some problems. In this document, we will analyze the limitation of the second approach and have a detailed discussion about the INFO based solution which is based on RFC 3578. The limitations of sending a new INVITE to support the overlap signalling in real deployment are listed below. (1) One of the advantages of the INVITE is the re-route function. However, according to the section 3.1 of RFC 3578, it is required that all of INVITEs, which belong to a same call attempting, should be routed to the same gateway. To ensure all INVITEs of a call reaches one gateway, routing in SIP can be controlled by the administrator of network. But in some cases, because of the load balance and the dynamic routing in a network, it is difficult to fulfill this requirement. ------ |MGC2| /------\ / \ / \ / \ ------ ------ --------/ \------ |LEC1|------|MGC1|------|proxy1| |LEC1| ------ ------ --------\ ------ \ / \ / \ / \------ / |MGC3|/ ------ Figure 1: INVITEs are routed to different gateways For example, in the Figure 1, the MGC1 is aware of that the Zhang, et al. Expires March 15, 2006 [Page 3] Internet-Draft A method for overlap signalling in SIP September 2005 subsequent INVITEs belong to a same call attempting. So, the MGC1 can send these INVITEs to a same SIP proxy. In the proxy1, there might be some load balance rules. As the result, these INVITEs might be routed to MGC2 and MGC3 respectively. In this case, both gateways generate an IAM. Since only one of the gateways can receive the complete called party number, those PSTN resources consumed by another gateway become unwanted duplicate. And it needs additional effort to release those resources. (2) According to the section 3.5 of RFC 3578, to bind subsequent INVITEs to the previous one, the gateway need to check the value of Call-ID and from tag. -------- |proxy2| /--------\ / \ / \ / \ ------ ------ --------/ \------ |LEC1|------|MGC1|------|proxy1| |MGC2| ------ ------ --------\ ------ \ / \ / \ / \-------- / |B2BUA1| -------- Figure 2: A B2BUA based SIP server involved in the path However, the Call-ID and From tag might be changed by a B2BUA. For example, in the Figure 2, if the subsequent INVITEs are routed to the gateway through different paths, and in one of these paths, a B2BUA based SIP server is involved, then it is possible that the Call-ID and from tag of the subsequent INVITEs received in the gateway can not match to the previous one. As the result, a new IAM will be generated by the gateway. This will cause the same problem as we discussed above. One of the solutions to solve these limitations is to route the subsequent INVITEs following the same path as the initial INVITE was routed. To ensure it, all of the SIP intermediate servers should be aware of the overlap signalling, which will impact the proxy behavior greatly. For example, to bind the INVITEs, the proxy needs to Zhang, et al. Expires March 15, 2006 [Page 4] Internet-Draft A method for overlap signalling in SIP September 2005 analyze the Call-ID, From tag and Request-URI for every incoming INVITE request. Moreover, using reINVITE to support the overlap signalling brings the following disadvantages. (1) The INVITE transaction consumes more system resource than the other non-INVITE transactions. (2) There are some additional 4xx responses even for a successful call. It will impact the statistic of the network traffic. (3) The subsequent INVITEs might be confused with the INVITEs generated by a forking. (4) If the SIP based application is involved, it needs to suppress the multiple service trigger for the subsequent INVITEs. According to the descriptions above, based on the RFC 3578, we recommend a new solution which uses INFO method to send the overlap signalling in a SIP network. This solution has the following advantages. (1) By establishing the early dialog, all of the INFO requests automatically follow the same path as the initial INVITE was routed. (2) No more requirements to the network administrator and the intermediate SIP servers. Zhang, et al. Expires March 15, 2006 [Page 5] Internet-Draft A method for overlap signalling in SIP September 2005 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and indicate requirement levels for compliant implementations. Zhang, et al. Expires March 15, 2006 [Page 6] Internet-Draft A method for overlap signalling in SIP September 2005 3. Definitions Originating Server: An originating server is an entity that triggers initial overlap signalling behavior in a SIP network. Integrated Access Device , Access Gateway or SIP-ISUP interworking unit may act as an Originating Server. Intermediate Server: An intermediate server is an intermediary network entity in a SIP network. Proxy or B2BUA may act as an intermediate server. Terminating Server: A terminating server is a network entity that terminates the overlap signalling behavior in a SIP network. B2BUA or SIP-ISUP interworking unit may act as a Terminating Server. Zhang, et al. Expires March 15, 2006 [Page 7] Internet-Draft A method for overlap signalling in SIP September 2005 4. Overlap signalling in a SIP network This section describes the solution of overlap signalling in a SIP network. When there is overlap signalling behavior in the network, the Originating Server uses INFO request to carry the subsequent numbers, and sends it to next-hop network entity as a message within a dialog. 1. The Originating Server is configured to support overlap signalling. It waits for the minimum amount of digits to route a call. Once the minimum amount of digits has been received, the Originating Server will generate an INVITE request with the received called number and then will send it to next-hop server. 2. The Originating Server uses INFO request to carry the subsequent digits. The subsequent digits are carried in the message body of INFO request. * If the interface between the Originating Server and next-hop server is SIP-I [6], subsequent digits are carried by a SAM encapsulated in the INFO request. * If the interface between the Originating Server and next-hop server is SIP, subsequent digits are carried by x-session-info message body (See Section 5) in the INFO request. 3. If the Terminating Server supports overlap signalling solution described in this specification, it MUST send a reliable 183 response according to RFC3262 [4] when it received an INVITE request with incomplete called number. This 183 response creates an early dialog, which ensures that subsequent digits can be carried through INFO request(s) in the same dialog. 4. The Originating Server MUST NOT send any INFO request until it receives 183 response that creates an early dialog. 5. The Originating Server MUST NOT send a new INFO request until it receives final response for the previous INFO request. Zhang, et al. Expires March 15, 2006 [Page 8] Internet-Draft A method for overlap signalling in SIP September 2005 PSTN Originating Terminating PSTN | Server Server | | | | | |------IAM------>| | | | |------INVITE------->| | |------SAM1----->| |------IAM------>| | |<-------183---------| | |------SAM2----->|------PRACK-------->| | | |<---200(PRACK)------| | | | | | | |-------INFO-------->| | | | |------SAM1----->| | |<----200(INFO)------| | | | | | | |-------INFO-------->| | |------SAM3----->| |------SAM2----->| | |<----200(INFO)------| | | | | | | |-------INFO-------->| | | | |------SAM3----->| | |<----200(INFO)------| | | | | | | | | | Figure 3: one SAM mapped to one INFO request Zhang, et al. Expires March 15, 2006 [Page 9] Internet-Draft A method for overlap signalling in SIP September 2005 PSTN Originating Terminating PSTN | Server Server | | | | | |------IAM------>| | | | |-------INVITE------>| | |------SAM1----->| |------IAM------>| | |<-------183---------| | |------SAM2----->|-------PRACK------->| | | |<----200(PRACK)-----| | | | | | | |-------INFO-------->| | |------SAM3----->| |------SAM1'---->| | |<----200(INFO)------| | | | | | | |--------INFO------->| | | | |------SAM3----->| | |<----200(INFO)------| | | | | | Figure 4: multiple SAMs mapped to one INFO request 6. The Originating Server may receive more than one SAM before it sends a new INFO request. Multiple SAMs can be merged into one INFO request. Alternatively, the Originating Server can also send multiple INFO requests each with one SAM encapsulated. An implementation is free to take any approach to deal with the mapping of multiple SAMs. Zhang, et al. Expires March 15, 2006 [Page 10] Internet-Draft A method for overlap signalling in SIP September 2005 5. x-session-info When the interface between the Originating Server and next-hop server is SIP, subsequent number is carried by in the INFO request. For that purpose, this document defines a new message body, application/ x-session-info, which can be used to carry additional number/address information. x-session-info = CalledParty CalledParty = "CalledParty" HCOLON addr-spec The userinfo part of the addr-spec MUST contain all the digits received so far. In this case, INFO request MUST contain a message body with the type of "application/x-session-info", and this INFO request MUST NOT contain any ISUP encapsulation. Zhang, et al. Expires March 15, 2006 [Page 11] Internet-Draft A method for overlap signalling in SIP September 2005 6. Entity behavior for overlap signalling 6.1. Originating Server Behavior The Originating Server should support RFC 3262 [4], so that an early dialog can be established through a reliable 183 response. 6.1.1. SIP-ISUP Interworking Function (IWF) Behavior When an IAM is received, if the Originating Server can determine the route to next hop, it will send an INVITE with the current available called party number carried in To and Request-URI. If it can not determine the route to next hop and the number is incomplete (as indicated in IAM), it should wait until the number is sufficient or timeout. Note: by network management, Intermediate Servers can always determine the route to next hop based on the called party number in INVITE message. The Originating Server may receive subsequent SAMs after INVITE is sent out. It MUST NOT map them to INFO(s) until the early dialog is established. If multiple SAMs are received, the Originating Server can map them into one or more INFO messages. The mapping of INFO should follow the rules described below: 1) The generation of INFO message should follow the rule described in section 12.2.1.1 of RFC 3261. [1] 2) Subsequent digits should be carried in the INFO message body: * When SIP is used, an new message body x-session-info is introduced in this document. Please refer to section 5. * When SIP-I is used, the SAM can be encapsulated in INFO, x-session-info MUST NOT be used in this situation. Note: If 183 is only used to establish the early dialog, there is no need to map it to ACM. 6.1.2. SIP based IAD or AG Behavior For SIP based IAD or AG, overlap signalling may also be used. It can also use the new message body x-session-info to carry subsequent dialed digits if needed. Zhang, et al. Expires March 15, 2006 [Page 12] Internet-Draft A method for overlap signalling in SIP September 2005 6.2. Intermediate Server Behavior Intermediate Server may be Proxy or B2BUA. If required, network operator can guarantee the routing of Intermediate Server by network management. For example, specify the minimal length of number collected before INVITE can be sent at the Originating Server. 6.3. Terminating Server Behavior The Terminating Server will take the responsibility of terminating the overlap signalling in a SIP network. If it acts as a SIP-ISUP interworking unit, it may still use overlap signalling in the PSTN side, or it may terminate the overlap procedure and convert it to en-bloc signalling. It may also act as a B2BUA, in this case, it should be able to terminate the incomming SIP overlap procedure and process the outgoing SIP session in either overlap or en-bloc mode. 6.3.1. SIP-ISUP IWF Behavior This section describes the behavior of Terminating Server (acting as SIP-ISUP IWF). 6.3.1.1. Continue Overlap signalling in PSTN 1) If the information in INVITE is sufficient to route to the next- hop, IWF can immediately send IAM, otherwise it should wait for subsequent INFO, until sufficient called address info is received. 2) SIP-ISUP IWF should send a reliable 183 immediately after INVITE is received. The purpose of this 183 is to establish an early dialog as soon as possible, so that subsequent overlapped number can be delivered by INFO. It must be reliable, and contain To tag and Contact. It should also copy the Record-Route header from INVITE. No message body should be included in the 183 response. 3) When subsequent INFO message is received, the Terminating Server should judge if there is x-session-info or SAM contained. If exists, it should be mapped to SAM. Zhang, et al. Expires March 15, 2006 [Page 13] Internet-Draft A method for overlap signalling in SIP September 2005 6.3.1.2. Convert to en-bloc in PSTN Refer to section 6.3.2. 6.3.2. B2BUA Behavior For Terminating B2BUA, it should terminate the overlap signalling and convert it to en-bloc mode. It must be able to analyze the called party number. If the called party number is incomplete, Terminating Server should send 183 to establish early dialog [refer to section 6.3.1.1], and then wait for subsequent number. The Terminating Server should also start timer T35 (as defined in ITU-T Q.764 [5]) to wait for subsequent number. The length of T35 is implementation specific and is recommended to be 15~20 seconds. When the number is collected completely, it can then forward the INVITE with updated called party number info to the next hop. if there is still not sufficient number received after T35 timeout, the Terminating Server should send 484 or 404 to reject the session. Specifically, if the number is complete in the initial INVITE, the Terminating Server can forward the INVITE directly and may not need to send 183 response to establish early dialog. Zhang, et al. Expires March 15, 2006 [Page 14] Internet-Draft A method for overlap signalling in SIP September 2005 7. Additional requirements for Originating Server If one of the Intermediate Server can not determine the route to the next hop according to the initial INVITE, it will normally return 404 or 484 to reject the request. In this situation, the Originating Server can act in two way: Convert subsequent overlap signalling into SIP en-bloc Signalling or continue trying to sending overlap signalling to a SIP Network as section 6 in this document. The decision can be made by configuration. 7.1. Convert subsequent overlap signalling into SIP en-bloc Signalling Like the precedures described in section 2 RFC 3578, the Originating server may decide to convert the overlap procedure to en-bloc signalling by waiting for the termination indication of dialed number(such as, #) or T10 timeout, and then send a new INVITE with all the numbers received. This time, the INVITE starts a new session. 7.2. Continue trying to sending overlap signalling to a SIP Network Also like section 3 in RFC 3578, if the Originating Server would like to retry the overlap procudure when additional number(s) is received, it can send a new INVITE with all the numbers received so far. The subsequent procedure is the same as section 6.1. Zhang, et al. Expires March 15, 2006 [Page 15] Internet-Draft A method for overlap signalling in SIP September 2005 8. Security Considerations Since this method is based on exiting SIP mechanism like INFO, 183, PRACK. There are no other specific security issues here. Zhang, et al. Expires March 15, 2006 [Page 16] Internet-Draft A method for overlap signalling in SIP September 2005 9. IANA Considerations None. 10. Normative References [1] 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. [2] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)", RFC 3578, August 2003. [3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [4] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in the Session Initiation Protocol (SIP)", RFC 3262, June 2002. [5] "Signalling system No. 7 - ISDN user part signalling procedures", ITU-T Recommendation Q.764, December 1999. [6] "Interworking between Session Initiation Protocol (SIP) and Bearer Independent Call Control protocol or ISDN User Part", ITU-T Recommendation Q.1912.5, March 2004. Zhang, et al. Expires March 15, 2006 [Page 17] Internet-Draft A method for overlap signalling in SIP September 2005 Authors' Addresses Pengsheng Zhang China Telecom-Guangzhou R&D Center 109 Zhongshan Ave. Guangzhou, Tianhe 510630 China Phone: +86 20 38639313 Email: zhangps@gsta.com Peili Xu Huawei Technologies Bantian Shenzhen, Longgang 518129 China Phone: +86 755 28780808 Email: xupeili@huawei.com Hao Shi ZTE Zijinghua RD. Nanjing, 210009 China Phone: +86 025 2871361 Email: shi.hao2@zte.com.cn Jonathan Chen UtstarCom 3/F Legend Building, High-tech Industrial Park Shenzhen, Nanshan 518057 China Phone: +86 755 26952899-33519 Email: jonathan.chen@utstar.com Zhang, et al. Expires March 15, 2006 [Page 18] Internet-Draft A method for overlap signalling in SIP September 2005 Zhiqiang Liu Alcatel Shanghai Bell Co. China Phone: +86 21 26109534 Email: Zhiqiang.LIU@alcatel-sbell.com.cn Yijun Hu Jiu Xian Qiao Post Office Beijing, Chaoyang 100016 China Phone: +86 10 58671322 Email: yijun.hu@eyou.com URI: Zhang, et al. Expires March 15, 2006 [Page 19] Internet-Draft A method for overlap signalling in SIP September 2005 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Zhang, et al. Expires March 15, 2006 [Page 20]