RFCs related to SIP (page 4 of 4)
|
|
|
|
|
|
|
|
|
|
|
|
Note: These RFCs -- Prior to RFC 3261 -- are listed in reverse order
|
|
|
|
|
| | | |
RFC3219
01/2002
(79 p.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
B. Campbell
R. Sparks |
SIP |
| Control of Service Context
using SIP Request-URI |
This memo provides information for the Internet community. It
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.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
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 |
|
|
|
|
|
|
|
|
| | | |
RFC2871
06/2000
(25 p.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
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.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC2822
05/2000
(51 p.)
[html]
[pdf(2)] |
P. Resnick |
DRUMS |
| Internet Message Format |
|
This standard specifies a syntax for text messages that are sent
between computer users, within the framework of "electronic mail"
messages.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC2779
02/2000
(26 p.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
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.)
[html]
[pdf(2)] |
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 |
|
|
|
|
|
|
|
|
|
|
