|
|
|
| |
|
| Note: These RFCs -- Prior to RFC 3261 -- are listed in reverse order |
|
|
|
|
|
|
| | | | RFC3219
01/2002
(79 p.)
pdf(p) | J. Rosenberg
H. Salama
M. Squire | IPTEL |
| Telephony Routing over IP (TRIP) | 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. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3204
12/2001
(10 p.)
pdf(p) | E. Zimmerer
J. Peterson
A. Vemuri
L. Ong
F. Audet
M. Watson
M. Zonoun | SIP |
| MIME media types for ISUP and QSIG Objects | | 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. |
|
|
| | | Up | Status: | Proposed Standard -- updated by RFC3459 | |
|
|
|
|
| | | | RFC3087
04/2001
(39 p.)
pdf(p) | B. Campbell
R. Sparks | SIP |
| Control of Service Context using SIP Request-URI | 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. |
|
|
|
|
|
|
|
| | | | RFC3050
01/2001
(35 p.)
pdf(p) | J. Lennox
H. Schulzrinne
J. Rosenberg | SIP |
| Common Gateway Interface for SIP | | 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. |
|
|
|
|
|
|
|
| | | | RFC2976
10/2000
(9 p.)
pdf(v)
pdf(p) | S. Donovan | SIP |
| The SIP INFO Method | | This document proposes an extension to SIP. This extension adds the "INFO " 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. |
|
|
|
|
|
|
|
| | | | RFC2871
06/2000
(25 p.)
pdf(p) | J. Rosenberg
H. Schulzrinne | IPTEL |
| A Framework for Telephony Routing over IP | | 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. |
|
|
|
|
|
|
|
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC2824
05/2000
(25 p.)
pdf(p) | J. Lennox
H. Schulzrinne | IPTEL |
| Call Processing Language Framework and Requirements | | 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. |
|
|
|
|
|
|
|
|
|
| | | Up | Status: | Standards Track | |
|
|
|
|
| | | | RFC2779
02/2000
(26 p.)
pdf(p) | M. Day
S. Aggarwal
G. Mohr
J. Vincent | IMPP |
| Instant Messaging / Presence Protocol Requirements | 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. |
|
|
|
|
|
|
|
| | | | RFC2778
02/2000
(17 p.)
pdf(p) | M. Day
J. Rosenberg
H. Sugano | IMPP |
| A Model for Presence and Instant Messaging | | 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. |
|
|
|
|
|
|
|
| | | | RFC2617
06/1999
(34 p.)
pdf(v)
pdf(p) | J. Franks
P. Hallam-Baker
J. Hostetler
S. Lawrence
P. Leach
A. Luotonen
L. Stewart | HTTP |
| HTTP Authentication: Basic and Digest Access Authentication | "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. |
|
|
|
|
|
|
|
| | | | RFC2616
06/1999
(176 p.)
pdf(v)
pdf(p) | R. Fielding
J. Gettys
J. Mogul
H. Frystyk
L. Masinter
P. Leach
T. Berners-Lee | HTTP |
| Hypertext Transfer Protocol -- HTTP/1.1 | | 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. |
|
|
|
|
4656
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
