|
| | | Top
| p. 1
| 3261-32xx
| 33xx
| 34xx
| 35xx
| 36xx
| 37xx
| 38xx
| 39xx
| | Prev
| Next | 40xx
| 41xx
| 42xx
| 43xx
| 44xx
| 45xx
| 46xx
| 47xx
| | | | 48xx
| 49xx
| 50xx
| 51xx
| 52xx
| 53xx
| 54xx
| 55xx
| | | | 56xx | 57xx | 58xx | 59xx | 60xx | 61xx | 62xx | Before 3261
| |
| | |
|
Before RFC 3261
|
|
Note: These RFCs -- Prior to RFC 3261 -- are listed in reverse order
|
| | # RFC 3219
| Telephony Routing over IP (TRIP)
| # RFC 3204
| MIME media types for ISUP and QSIG Objects
| # RFC 3087
| Control of Service Context using SIP Request-URI
| # RFC 3050
| Common Gateway Interface for SIP
| # RFC 2976
| SIP INFO Method
| # RFC 2871
| Framework for Telephony Routing over IP
| # RFC 2848
| PINT Service Protocol
| # RFC 2824
| Call Processing Language Framework and Requirements
| # RFC 2782
| DNS RR for specifying the location of services (DNS SRV)
| # RFC 2779
| Instant Messaging / Presence Protocol Requirements
| # RFC 2778
| Model for Presence and Instant Messaging
| # RFC 2617
| HTTP Authentication: Basic and Digest Access Authentication
| # RFC 2616
| Hypertext Transfer Protocol -- HTTP/1.1
| |
|
|
|
|
|
| | | | 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. |
|
|
| | Up
| Status: | Proposed Standard | | See also: | draft-ietf-sip-info-events
| |
|
|
|
|
| | | | 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. |
|
|
|
|
|
|
| | | | RFC2848
06/2000
(73 p.)
pdf(p)
| S. Petrack
L. Conroy | PINT | The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services
| 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. |
|
|
| | 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.
|
|
|
|
|
|
|
| | | | RFC2782
02/2000
(12 p.)
pdf(v)
pdf(p)
| A. Gulbrandsen
P. Vixie
L. Esibov | - | A DNS RR for specifying the location of services (DNS SRV)
| | This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. |
|
|
|
|
|
|
| | | | 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. |
|
|
| | Up
| Status: | Draft Standard -- Updated by: RFC2817
| | See also: | HTTPBIS
|
|
