SIP RFC 关系图汇总--超全---part7

	Next
		56xx	57xx	58xx	59xx	60xx	61xx	62xx

Note: These RFCs -- Prior to RFC 3261 -- are listed in reverse order

#
#
#
#
#
#
#
#
#
#
#
#
#

01/2002 (79 p.)	J. Rosenberg H. Salama M. Squire		This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations. TRIP's operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol. The Border Gateway Protocol (BGP-4) is used to distribute routing information between administrative domains. TRIP is used to distribute telephony routing information between telephony administrative domains. The similarity between the two protocols is obvious, and hence TRIP is modeled after BGP-4.

	Status:	Proposed Standard

12/2001 (10 p.)	E. Zimmerer J. Peterson A. Vemuri L. Ong F. Audet M. Watson M. Zonoun		This document describes MIME types for application/ISUP and application/QSIG objects for use in SIP applications, according to the rules defined in RFC2048. These types can be used to identify ISUP and QSIG objects within a SIP message such as INVITE or INFO, as might be implemented when using SIP in an environment where part of the call involves interworking to the PSTN.

	Status:	Proposed Standard -- updated by

04/2001 (39 p.)	B. Campbell R. Sparks		This memo describes a useful way to conceptualize the use of the standard SIP Request-URI (Uniform Resource Identifier) that the authors and many members of the SIP community think is suitable as a convention. It does not define any new protocol with respect to RFC2543. In a conventional telephony environment, extended service applications often use call state information, such as calling party, called party, reason for forward, etc, to infer application context. In a SIP/2.0 call, much of this information may be either non-existent or unreliable. This document proposes a mechanism to communicate context information to an application. Under this proposal, a client or proxy can communicate context through the use of a distinctive Request-URI. This document continues with examples of how this mechanism could be used in a voice mail application.

	Status:	Informational

01/2001 (35 p.)	J. Lennox H. Schulzrinne J. Rosenberg		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 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.

	Status:	Informational

10/2000 (9 p.)	S. Donovan		This document proposes an extension to SIP. This extension adds the "" method to the SIP protocol. The intent of the INFO method is to allow for the carrying of session related control information that is generated during a session. One example of such session control information is ISUP and ISDN signaling messages used to control telephony call services.

	Status:	Proposed Standard
	See also:

06/2000 (25 p.)	J. Rosenberg H. Schulzrinne		This document serves as a framework for Telephony Routing over IP (TRIP), which supports the discovery and exchange of IP telephony gateway routing tables between providers. The document defines the problem of telephony routing exchange, and motivates the need for the protocol. It presents an architectural framework for TRIP, defines terminology, specifies the various protocol elements and their functions, overviews the services provided by the protocol, and discusses how it fits into the broader context of Internet telephony.

	Status:	Informational

06/2000 (73 p.)	S. Petrack L. Conroy	PINT	This document contains the specification of the PINT Service Protocol 1.0, which defines a protocol for invoking certain telephone services from an IP network. These services include placing basic calls, sending and receiving faxes, and receiving content over the telephone. The protocol is specified as a set of enhancements and additions to the SIP 2.0 and SDP protocols.

	Status:	Proposed Standard

05/2000 (25 p.)	J. Lennox H. Schulzrinne		A large number of the services we wish to make possible for Internet telephony require fairly elaborate combinations of signalling operations, often in network devices, to complete. We want a simple and standardized way to create such services to make them easier to implement and deploy. This document describes an architectural framework for such a mechanism, which we call a call processing language. It also outlines requirements for such a language.

	Status:	Informational

02/2000 (12 p.)	A. Gulbrandsen P. Vixie L. Esibov	-	This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain.

	Status:	Standards Track

02/2000 (26 p.)	M. Day S. Aggarwal G. Mohr J. Vincent	IMPP	Presence and Instant Messaging have recently emerged as a new medium of communications over the Internet. Presence is a means for finding, retrieving, and subscribing to changes in the presence information (e.g. "online" or "offline") of other users. Instant messaging is a means for sending small, simple messages that are delivered immediately to online users. Applications of presence and instant messaging currently use independent, non-standard and non-interoperable protocols developed by various vendors. The goal of the Instant Messaging and Presence Protocol (IMPP) Working Group is to define a standard protocol so that independently developed applications of instant messaging and/or presence can interoperate across the Internet. This document defines a minimal set of requirements that IMPP must meet.

	Status:	Informational

02/2000 (17 p.)	M. Day J. Rosenberg H. Sugano	IMPP	This document defines an abstract model for a presence and instant messaging system. It defines the various entities involved, defines terminology, and outlines the services provided by the system. The goal is to provide a common vocabulary for further work on requirements for protocols and markup for presence and instant messaging.

	Status:	Informational

06/1999 (34 p.)	J. Franks P. Hallam-Baker J. Hostetler S. Lawrence P. Leach A. Luotonen L. Stewart	HTTP	"HTTP/1.1" includes the specification for a Basic Access Authentication scheme. This scheme is not considered to be a secure method of user authentication (unless used in conjunction with some external secure system such as SSL), as the user name and password are passed over the network as cleartext. This document also provides the specification for HTTP's authentication framework, the original Basic authentication scheme and a scheme based on cryptographic hashes, referred to as "Digest Access Authentication". Like Basic, Digest access authentication verifies that both parties to a communication know a shared secret (a password); unlike Basic, this verification can be done without sending the password in the clear, which is Basic's biggest weakness. As with most other authentication protocols, the greatest sources of risks are usually found not in the core protocol itself but in policies and procedures surrounding its use.

	Status:	Draft Standard

06/1999 (176 p.)	R. Fielding J. Gettys J. Mogul H. Frystyk L. Masinter P. Leach T. Berners-Lee	HTTP	The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.

	Status:	Draft Standard -- Updated by:
	See also:

Refer from: