📄 rfc3050.txt
字号:
Network Working Group J. LennoxRequest for Comments: 3050 H. SchulzrinneCategory: Informational Columbia U. J. Rosenberg dynamicsoft January 2001 Common Gateway Interface for SIPStatus of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved.Abstract In Internet telephony, there must be a means by which new services are created and deployed rapidly. In the World Wide Web, the Common Gateway Interface (CGI) has served as popular means towards programming web services. Due to the similarities between the Session Initiation Protocol (SIP) and the Hyper Text Transfer Protocol (HTTP), CGI is a good candidate for service creation in a SIP environment. This document defines a SIP CGI interface for providing SIP services on a SIP server.IESG Note The IESG notes that the mechanism specified here depends on the Common Gateway Interface. Should this interface change or be enhanced changes in this specification may also be necessary or appropriate. According to the W3C, the CGI is presently maintained by the NCSA Software Development Group. See http://www.w3c.org/cgi for additional information on the current state of the CGI interface.Lennox, et al. Informational [Page 1] RFC 3050 CGI for SIP January 2001Table of Contents 1 Introduction ....................................... 3 2 Motivations ........................................ 4 3 Differences from HTTP CGI .......................... 5 3.1 Basic Model ........................................ 6 3.2 Persistence Model .................................. 8 3.3 SIP CGI Triggers ................................... 9 3.4 Naming ............................................. 9 3.5 Environment Variables .............................. 9 3.6 Timers ............................................. 10 4 Overview of SIP CGI ................................ 10 5 SIP CGI Specification .............................. 12 5.1 Introduction ....................................... 12 5.1.1 Relationship with HTTP CGI ......................... 12 5.1.2 Conventions of This Document ....................... 12 5.1.3 Specifications ..................................... 12 5.1.4 Terminology ........................................ 13 5.2 Notational Conventions and Generic Grammar ......... 13 5.3 Invoking the Script ................................ 14 5.4 The SIP CGI Script Command Line .................... 14 5.5 Data Input to the SIP CGI Script ................... 14 5.5.1 Message Metadata (Metavariables) ................... 14 5.5.1.1 AUTH_TYPE .......................................... 16 5.5.1.2 CONTENT_LENGTH ..................................... 16 5.5.1.3 CONTENT_TYPE ....................................... 17 5.5.1.4 GATEWAY_INTERFACE .................................. 17 5.5.1.5 Protocol-Specific Metavariables .................... 18 5.5.1.6 REGISTRATIONS ...................................... 18 5.5.1.7 REMOTE_ADDR ........................................ 19 5.5.1.8 REMOTE_HOST ........................................ 19 5.5.1.9 REMOTE_IDENT ....................................... 19 5.5.1.10 REMOTE_USER ........................................ 20 5.5.1.11 REQUEST_METHOD ..................................... 20 5.5.1.12 REQUEST_TOKEN ...................................... 21 5.5.1.13 REQUEST_URI ........................................ 21 5.5.1.14 RESPONSE_STATUS .................................... 21 5.5.1.15 RESPONSE_REASON .................................... 21 5.5.1.16 RESPONSE_TOKEN ..................................... 21 5.5.1.17 SCRIPT_COOKIE ...................................... 22 5.5.1.18 SERVER_NAME ........................................ 22 5.5.1.19 SERVER_PORT ........................................ 22 5.5.1.20 SERVER_PROTOCOL .................................... 22 5.5.1.21 SERVER_SOFTWARE .................................... 23 5.5.2 Message Bodies ..................................... 23 5.6 Data Output from the SIP CGI Script ................ 23 5.6.1 CGI Action Lines ................................... 25 5.6.1.1 Status ............................................. 25Lennox, et al. Informational [Page 2] RFC 3050 CGI for SIP January 2001 5.6.1.2 Proxy Request ...................................... 25 5.6.1.3 Forward Response ................................... 26 5.6.1.4 Script Cookie ...................................... 26 5.6.1.5 CGI Again .......................................... 27 5.6.1.6 Default Action ..................................... 27 5.6.2 CGI Header Fields .................................. 28 5.6.2.1 Request-Token ...................................... 28 5.6.2.2 Remove ............................................. 28 5.7 Local Expiration Handling .......................... 28 5.8 Locally-Generated Responses ........................ 29 5.9 SIP CGI and REGISTER ............................... 29 5.10 SIP CGI and CANCEL ................................. 29 5.11 SIP CGI and ACK .................................... 30 5.11.1 Receiving ACK's .................................... 30 5.11.2 Sending ACK's ...................................... 30 6 System Specifications .............................. 30 6.1 Unix ............................................... 30 6.2 Microsoft Windows .................................. 31 7 Security Considerations ............................ 31 7.1 Request Initiation ................................. 31 7.2 Authenticated and Encrypted Messages ............... 31 7.3 SIP Header Fields Containing Sensitive Information.. 32 7.4 Script Interference with the Server ................ 32 7.5 Data Length and Buffering Considerations ........... 32 8 Acknowledgements ................................... 33 9 Authors' Addresses ................................. 33 10 Bibliography ....................................... 34 11 Full Copyright Statement ........................... 351 Introduction In Internet telephony, there must be a means by which new services are created and deployed rapidly. In traditional telephony networks, this was accomplished through IN service creation environments, which provided an interface for creating new services, often using GUI- based tools. The WWW has evolved with its own set of tools for service creation. Originally, web servers simply translated URLs into filenames stored on a local system, and returned the file content. Over time, servers evolved to provide dynamic content, and forms provided a means for soliciting user input. In essence, what evolved was a means for service creation in a web environment. There are now many means for creation of dynamic web content, including server side JavaScript, servlets, and the common gateway interface (CGI) [1].Lennox, et al. Informational [Page 3] RFC 3050 CGI for SIP January 2001 Multimedia communications, including Internet telephony, will also require a mechanism for creating services. This mechanism is strongly tied to the features provided by the signaling protocols. The Session Initiation Protocol (SIP) [2] has been developed for initiation and termination of multimedia sessions. SIP borrows heavily from HTTP, inheriting its client-server interaction and much of its syntax and semantics. For this reason, the web service creation environments, and CGI in particular, seem attractive as starting points for developing SIP based service creation environments.2 Motivations CGI has a number of strengths which make it attractive as an environment for creating SIP services: Language independence: CGI works with perl, C, VisualBasic, tcl, and many other languages, as long as they support access to environment variables. Exposes all headers: CGI exposes the content of all the headers in an HTTP request to the CGI application. An application can make use of these as it sees fit, and ignore those it doesn't care about. This allows all aspects of an HTTP request to be considered for creation of content. In a SIP environment, headers have greater importance than in HTTP. They carry critical information about the transaction, including caller and callee, subject, contact addresses, organizations, extension names, registration parameters and expirations, call status, and call routes, to name a few. It is therefore critical for SIP services to have as much access to these headers as possible. For this reason, CGI is very attractive. Creation of responses: CGI is advantageous in that it can create all parts of a response, including headers, status codes and reason phrases, in addition to message bodies. This is not the case for other mechanisms, such as Java servlets, which are focused primarily on the body. In a SIP environment, it is critical to be able to generate all aspects of a response (and, all aspects of new or proxied requests), since the body is usually not of central importance in SIP service creation.Lennox, et al. Informational [Page 4] RFC 3050 CGI for SIP January 2001 Component reuse: Many of the CGI utilities allow for easy reading of environment variables, parsing of form data, and often parsing and generation of header fields. Since SIP reuses the basic RFC822 [3] syntax of HTTP, many of these tools are applicable to SIP CGI. Familiar environment: Many web programmers are familiar with CGI. Ease of extensibility: Since CGI is an interface and not a language, it becomes easy to extend and reapply to other protocols, such as SIP. The generality, extensibility, and detailed control and access to information provided by CGI, coupled with the range of tools that exist for it, which can be immediately applied to SIP, make it a good mechanism for SIP service creation.3 Differences from HTTP CGI While SIP and HTTP share a basic syntax and a request-response model, there are important differences. Proxies play a critical role in services for SIP, while they are less important for HTTP. SIP servers can fork requests (proxying multiple requests when a single request is received), an important capability absent from HTTP. SIP supports additional features, such as registrations, which are absent from HTTP. These differences are reflected in the differences between SIP CGI and HTTP CGI. SIP CGI runs primarily on proxy, redirect, and registrar servers, rather than user agent servers (which are the equivalent of origin servers in HTTP). SIP CGI allows the script to perform specific messaging functions not supported in HTTP CGI (such as proxying requests), and SIP CGI introduces a persistence model that allow a script to maintain control through multiple message exchanges. HTTP CGI has no persistence for scripts.Lennox, et al. Informational [Page 5] RFC 3050 CGI for SIP January 20013.1 Basic Model The basic model for HTTP CGI is depicted in figure 1. ----- ------------ ~~~~~~~~ |req | | -------- | | |----------| | http | | | client | |resp | | | server | | | |----------| | | |w ~~~~~~~~ | | | -------- |e ----- | s| /\s |b net | t| |t | |e d| C |d |s |n i| G |o |e |v n| I |u |r | | |t |v | \/ | |e | ------- |r | | | | | | CGI | | | | prog. | | | | | | | ------- | ------------ Figure 1: HTTP CGI Model A client issues an HTTP request, which is passed either directly to the origin server (as shown), or is forwarded through a proxy server. The origin server executes a CGI script, and the CGI script returns a response, which is passed back to the client. The main job of the script is to generate the body for the response. Only origin servers execute CGI scripts, not proxy servers.⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -