|
This page lists the RFCs related to SIP. For each RFC, the following information is provided: |
| |
| - |
RFCxxxx: the RFC number is a link to the IETF's tool HTML version, which includes a link to the errata, if any |
|
| - |
Date (month/year) |
|
| - |
Number of pages |
|
| - |
pdf(v): possibly a pdf version for viewing (unaltered content and unprintable) |
|
| - |
pdf(p): a two-page printable version |
|
| - |
Author List |
|
| - |
Originating WG |
|
| - |
Title: with a link to itself, for a display at the top of the screen |
|
| - |
RFC's Abstract, possibly modified for pointing out new METHODs, Header Fields, Option Tags, Event Packages |
|
| - |
Status |
|
| - |
See also (possibly) | |
|
| For a reminder of capitalized key words used in RFCs, click []. |
| | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
56xx |
57xx |
58xx |
59xx |
60xx |
61xx |
62xx |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
06/2002
(269 p.)
|
J. Rosenberg
H. Schulzrinne
G. Camarillo
A. Johnston
J. Peterson
R. Sparks
M. Handley
E. Schooler |
|
|
This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.
SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users. SIP also provides a registration function that allows users to upload their current locations for use by proxy servers. SIP runs on top of several different transport protocols.
This RFC instructs the IANA to create four new sub-registries under
: Option Tags, Warning Codes (warn-codes), Methods and Response Codes, added to the sub-registry of Header Fields that is already present there.
It registers the "message/sip" MIME media type. It also registers four new header "disposition-types": alert, icon, session and render. | | |
|
|
|
Status: |
Proposed Standard
-- updated by: , , , , |
| |
|
|
|
|
|
|
|
|
|
06/2002
(14 p.)
|
J. Rosenberg
H. Schulzrinne |
|
|
| This document specifies an extension to SIP providing reliable provisional response messages. This extension uses the '' SIP option tag and defines the Provisional Response ACKnowledgement ("") method. Each provisional response is given a sequence number, carried in the "" header field. The PRACK messages contain an "" header field, which indicates the sequence number of the provisional response that is being acknowledged. | | |
|
|
|
Status: |
Proposed Standard |
| |
|
|
|
|
|
|
|
06/2002
(17 p.)
|
J. Rosenberg
H. Schulzrinne |
|
|
SIP uses DNS procedures to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. It also uses DNS to allow a server to send a response to a backup client if the primary client has failed. This document describes those DNS procedures in detail.
This RFC defines the "" and places the following NAPTR service field values: SIP+D2T, SIPS+D2T, SIP+D2U, SIP+D2S. | | |
|
|
|
Status: |
Proposed Standard |
|
See also: |
, , , , |
| |
|
|
|
|
|
|
|
06/2002
(25 p.)
|
J. Rosenberg
H. Schulzrinne |
|
|
| This document defines a mechanism by which two entities can make use of SDP to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like SIP. | | |
|
|
|
Status: |
Proposed Standard |
|
See also: |
|
| |
|
|
|
|
|
|
|
06/2002
(38 p.)
|
A. B. Roach |
|
|
This document describes an extension to SIP. The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. The "" and "" methods described in this document provide a framework by which notification of these events can be ordered. This document does not describe an extension which may be used directly; it must be extended by other documents, referred to as "event packages".
This document defines the "", "", and "" header fields. | | |
|
|
|
Status: |
Proposed Standard |
|
See also: |
('refer' package)
('reg' package)
('message-summary' package)
('presence' package)
('winfo' template-package)
('spirits-INDPs' and 'spirits-user-prof' packages)
('dialog' package)
('poc-settings' package)
('conference' package)
('kpml' package)
('consent-pending-additions' package)
('PUBLISH' method) |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
56xx |
57xx |
58xx |
59xx |
60xx |
61xx |
62xx |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
08/2002
(34 p.)
|
P. Srisuresh
J. Kuthan
J. Rosenberg
A. Molitor
A. Rayhan |
MIDCOM |
|
A principal objective of this document is to describe the underlying framework of middlebox communications (MIDCOM) to enable complex applications through the middleboxes, seamlessly using a trusted third party.
There are a variety of intermediate devices in the Internet today that require application intelligence for their operation. Datagrams pertaining to real-time streaming applications, such as SIP and H.323, and peer-to-peer applications, such as Napster and NetMeeting, cannot be identified by merely examining packet headers. Middleboxes implementing Firewall and Network Address Translator services typically embed application intelligence within the device for their operation. The document specifies an architecture and framework in which trusted third parties can be delegated to assist the middleboxes to perform their operation, without resorting to embedding application intelligence. Doing this will allow a middlebox to continue to provide the services, while keeping the middlebox application agnostic. | | |
|
|
|
|
|
|
|
|
|
09/2002
(18 p.)
|
A. Niemi
J. Arkko
V. Torvinen |
|
|
This memo specifies an Authentication and Key Agreement (AKA) based one-time password generation mechanism for Hypertext Transfer Protocol (HTTP) Digest access authentication. The HTTP Authentication Framework includes two authentication schemes: Basic and Digest. Both schemes employ a shared secret based mechanism for access authentication. The AKA mechanism performs user authentication and session key distribution in Universal Mobile Telecommunications System (UMTS) networks. AKA is a challenge-response based mechanism that uses symmetric cryptography.
This RFC defines the "" IANA Registry and places the AKAv1 value. | | |
|
|
|
Status: |
Informational |
|
See also: |
, |
| |
|
|
|
|
|
|
|
09/2002
(13 p.)
|
J. Rosenberg |
|
|
| This specification defines the new "" method for SIP. UPDATE allows a client to update parameters of a session (such as the set of media streams and their codecs) but has no impact on the state of a dialog. In that sense, it is like a re-INVITE, but unlike re-INVITE, it can be sent before the initial INVITE has been completed. This makes it very useful for updating session parameters within early dialogs. | | |
|
|
|
Status: |
Proposed Standard |
| |
|
|
|
|
|
|
|
10/2002
(30 p.)
|
G. Camarillo
W. Marshall
J. Rosenberg |
|
|
This document defines a generic framework for preconditions, which are extensible through IANA registration. This document also discusses how network quality of service can be made a precondition for establishment of sessions initiated by SIP. These preconditions require that the participant reserve network resources before continuing with the session. We do not define new quality of service reservation mechanisms; these preconditions simply require a participant to use existing resource reservation mechanisms before beginning the session.
This document defines the '' SIP option tag. | | |
|
|
|
Status: |
Proposed Standard -- updated by: , |
| |
|
|
|
|
|
|
|
01/2003
(16 p.)
|
W. Marshall |
|
|
This document describes the need for Quality of Service (QoS) and media authorization and defines a SIP extension that can be used to integrate QoS admission control with call signaling and help guard against denial of service attacks. The use of this extension is only applicable in administrative domains, or among federations of administrative domains with previously agreed-upon policies, where both the SIP proxy authorizing the QoS, and the policy control of the underlying network providing the QoS, belong to that administrative domain or federation of domains.
This document defines the "" header field. | | |
|
|
|
|
|
|
|
|
|
09/2002
(23 p.)
|
M. Wasserman |
IPV6 |
|
This document contains recommendations from the Internet Engineering Task Force (IETF) IPv6 Working Group to the Third Generation Partnership Project (3GPP) community regarding the use of IPv6 in the 3GPP standards. Specifically, this document recommends that the 3GPP specify that multiple prefixes may be assigned to each primary PDP context, require that a given prefix must not be assigned to more than one primary PDP context, and allow 3GPP nodes to use multiple identifiers within those prefixes, including randomly generated identifiers.
The IPv6 Working Group supports the use of IPv6 within 3GPP and offers these recommendations in a spirit of open cooperation between the IPv6 Working Group and the 3GPP community. Since the original publication of this document as an Internet-Draft, the 3GPP has adopted the primary recommendations of this document. | | |
|
|
|
|
|
|
|
|
|
07/2003
(7 p.)
|
H. Schulzrinne
B. Volz |
|
|
| This document defines a Dynamic Host Configuration Protocol version 6 (DHCPv6) option that contains a list of domain names or IPv6 addresses that can be mapped to one or more SIP outbound proxy servers. This is one of the many methods that a SIP client can use to obtain the addresses of such a local SIP server. | | |
|
|
|
Status: |
Proposed Standard |
| |
|
|
|
|
|
|
|
01/2003
(62 p.)
|
R. Price
C. Bormann
J. Christoffersson
H. Hannu
Z. Liu
J. Rosenberg |
ROHC |
|
This document defines Signaling Compression (SigComp), a solution for compressing messages generated by application protocols such as SIP and the Real Time Streaming Protocol (RTSP). The architecture and prerequisites of SigComp are outlined, along with the format of the SigComp message.
Decompression functionality for SigComp is provided by a Universal Decompressor Virtual Machine (UDVM) optimized for the task of running decompression algorithms. The UDVM can be configured to understand the output of many well-known compressors such as DEFLATE (). | | |
|
|
|
Status: |
Proposed Standard -- updated by: |
| |
|
|
|
|
|
|
|
01/2003
(19 p.)
|
H. Hannu
J. Christoffersson
S. Forsgren
K.-C. Leung
Z. Liu
R. Price |
ROHC |
|
This document describes how to implement certain mechanisms in Signaling Compression (SigComp), , which can significantly improve the compression efficiency compared to using simple per-message compression.
SigComp uses a Universal Decompressor Virtual Machine (UDVM) for decompression, and the mechanisms described in this document are possible to implement using the UDVM instructions defined in . | | |
|
|
|
Status: |
Informational -- updated by: |
| |
|
|
|
|
|
|
|
01/2003
(13 p.)
|
H. Hannu |
ROHC |
|
| The purpose of this document is to outline requirements and motivations for the development of a scheme for compression and decompression of messages from signaling protocols. In wireless environments and especially in cellular systems, e.g., GSM (Global System for Mobile communications) and UMTS (Universal Mobile Telecommunications System), there is a need to maximize the transport efficiency for data over the radio interface. With the introduction of SIP/SDP to cellular devices, compression of the signaling messages should be considered in order to improve both service availability and quality, mainly by reducing the user idle time, e.g., at call setup. | | |
|
|
|
|
|
|
|
|
|
11/2002
(22 p.)
|
J. Peterson |
|
|
This document defines new mechanisms for SIP in support of privacy. Specifically, guidelines are provided for the creation of messages that do not divulge personal identity information. A new "privacy service" logical role for intermediaries is defined to answer some privacy requirements that user agents cannot satisfy themselves. Finally, means are presented by which a user can request particular functions from a privacy service.
This document defines the "" header field. It also defines the '' SIP option tag. | | |
|
|
|
Status: |
Proposed Standard |
| |
|
|
|
|
|
|
|
11/2002
(11 p.)
|
M. Watson |
|
|
| A Network Asserted Identity is an identity initially derived by a SIP network intermediary as a result of an authentication process. This document describes short term requirements for the exchange of Network Asserted Identities within networks of securely interconnected trusted nodes and to User Agents securely connected to such networks. There is no requirement for identities asserted by a UA in a SIP message to be anything other than the user's desired alias. | | |
|
|
|
|
|
|
|
|
|
11/2002
(18 p.)
|
C. Jennings
J. Peterson
M. Watson |
|
|
This document describes private extensions to SIP that enable a network of trusted SIP servers to assert the identity of authenticated users, and the application of existing privacy mechanisms to the identity problem. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport and usage of such information. This document does NOT offer a general privacy or identity model suitable for use between different trust domains, or use in the Internet at large.
This document defines the "" and "" header fields. | | |
|
|
|
|
|
|
|
|
|
12/2002
(8 p.)
|
H. Schulzrinne
D. Oran
G. Camarillo |
|
|
For creating services, it is often useful to know why a SIP request was issued. This document defines the "" header field that provides this information. The Reason header field is also intended to be used to encapsulate a final status code in a provisional response. This functionality is needed to resolve the "Heterogeneous Error Response Forking Problem", or HERFP.
This RFC defines a new sub-registry under , labeled "Reason Protocols", for registering the "SIP" and "Q.850" protocol values (and their associated protocol cause) to be used with the Reason header field. | | |
|
|
|
Status: |
Proposed Standard |
| |
|
|
|
|
|
|
|
12/2002
(17 p.)
|
D. Willis
B. Hoeneisen |
|
|
The REGISTER function is used in a SIP system primarily to associate a temporary contact address with an address-of-record.
This contact is generally in the form of a Uniform Resource Identifier (URI), such as Contact: and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA). The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies. The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use.
This document defines an extension header field, "" which provides such a mechanism. The associated SIP option tag is ''. | | |
|
|
|
Status: |
Proposed Standard |
| |
|
|
|
|
|
|
|
01/2003
(24 p.)
|
J. Arkko
V. Torvinen
G. Camarillo
A. Niemi
T. Haukka |
|
| Security Mechanism Agreement for SIP |
This document defines new functionality for negotiating the security mechanisms used between a SIP user agent and its next-hop SIP entity. This new functionality supplements the existing methods of choosing security mechanisms between SIP entities.
This document defines the "Security-Client", "Security-Server", and "Security-Verify" header fields. It also defines the '' SIP option tag. | | |
|
|
|
Status: |
Proposed Standard |
| |
|
|
|
|
|
|
|
08/2002
(17 p.)
|
N. Charlton
M. Gasson
G. Gybels
M. Spanner
A. van Wijk |
|
|
| This document presents a set of SIP user requirements that support communications for deaf, hard of hearing and speech-impaired individuals. These user requirements address the current difficulties of deaf, hard of hearing and speech-impaired individuals in using communications facilities, while acknowledging the multi-functional potential of SIP-based communications. A number of issues related to these user requirements are further raised in this document. Also included are some real world scenarios and some technical requirements to show the robustness of these requirements on a concept-level. | | |
|
|
|
|
|
|
|
|
|
08/2002
(7 p.)
|
H. Schulzrinne |
|
|
| This document defines a Dynamic Host Configuration Protocol (DHCP-for-IPv4) option that contains a list of domain names or IPv4 addresses that can be mapped to one or more SIP outbound proxy servers. This is one of the many methods that a SIP client can use to obtain the addresses of such a local SIP server. | | |
|
|
|
Status: |
Proposed Standard |
| |
|
|
|
|
|
|
|
09/2002
(23 p.)
|
A. Vemuri
J. Peterson |
|
|
| The popularity of gateways that interwork between the PSTN (Public Switched Telephone Network) and SIP networks has motivated the publication of a set of common practices that can assure consistent behavior across implementations. This document taxonomizes the uses of PSTN-SIP gateways, provides uses cases, and identifies mechanisms necessary for interworking. The mechanisms detail how SIP provides for both 'encapsulation' (bridging the PSTN signaling across a SIP network) and 'translation' (gatewaying). | | |
|
|
|
Status: |
Best Current Practice (BCP: 63) |
| |
|
|
|
|
|
|
|
12/2002
(21 p.)
|
G. Camarillo
G. Eriksson
J. Holler
H. Schulzrinne |
|
|
| This document defines two SDP attributes: "group" and "mid". They allow to group together several "m" lines for two different purposes: for lip synchronization and for receiving media from a single flow (several media streams) that are encoded in different formats during a particular session, on different ports and host interfaces. | | |
|
|
|
Status: |
Proposed Standard |
| |
|
|
|
|
|
|
|
12/2002
(68 p.)
|
G. Camarillo
A. B. Roach
J. Peterson
L. Ong |
|
|
| This document describes a way to perform the mapping between two signaling protocols: SIP and the Integrated Services Digital Network (ISDN) User Part (ISUP) of Signaling System No. 7 (SS7). This mechanism might be implemented when using SIP in an environment where part of the call involves interworking with the Public Switched Telephone Network (PSTN). | | |
|
|
|
Status: |
Proposed Standard |
|
See also: |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
56xx |
57xx |
58xx |
59xx |
60xx |
61xx |
62xx |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
10/2002
(6 p.)
|
M. Mealling |
- |
|
This document specifies the exact documents that make up the complete Dynamic Delegation Discovery System (DDDS). DDDS is an abstract algorithm for applying dynamically retrieved string transformation rules to an application-unique string.
This document along with , and obsolete and , as well as updates . | | |
|
|
|
|
|
|
|
|
|
10/2002
(17 p.)
|
M. Mealling |
- |
|
| This document describes the Dynamic Delegation Discovery System (DDDS) algorithm for applying dynamically retrieved string transformation rules to an application-unique string. Well-formed transformation rules will reflect the delegation of management of information associated with the string. | | |
|
|
|
Status: |
Proposed Standard |
| |
|
|
|
|
|
|
|
10/2002
(14 p.)
|
M. Mealling |
- |
|
| This document describes a Dynamic Delegation Discovery System (DDDS) Database using the Domain Name System (DNS) as a distributed database of Rules. The Keys are domain-names and the Rules are encoded using the Naming Authority Pointer (NAPTR) Resource Record (RR). Since this document obsoletes , it is the official specification for the NAPTR DNS Resource Record. | | |
|
|
|
Status: |
Proposed Standard |
| |
|
|
|
|
|
|
|
10/2002
(18 p.)
|
M. Mealling |
- |
|
| This document describes a specification for taking Uniform Resource Identifiers (URI) and locating an authoritative server for information about that URI. The method used to locate that authoritative server is the Dynamic Delegation Discovery System. | | |
|
|
|
Status: |
Proposed Standard |
| |
|
|
|
|
|
|
|
11/2002
(8 p.)
|
R. Sparks |
|
|
| This document registers the message/sipfrag Multipurpose Internet Mail Extensions (MIME) media type. This type is similar to message/sip, but allows certain subsets of well formed SIP messages to be represented instead of requiring a complete SIP message. In addition to end-to-end security uses, message/sipfrag is used with the method to convey information about the status of a referenced request. | | |
|
|
|
Status: |
Proposed Standard |
| |
|
|
|
|
|
|
|
12/2002
(12 p.)
|
A. Mankin
S. Bradner
R. Mahy
D. Willis
J. Ott
B. Rosen |
TSV area |
|
| This memo documents a process intended to apply architectural discipline to the future development of SIP. There have been concerns with regards to new SIP proposals. Specifically, that the addition of new SIP features can be damaging towards security and/or greatly increase the complexity of the protocol. The Transport Area directors, along with the SIP and Session Initiation Proposal Investigation (SIPPING) working group chairs, have provided suggestions for SIP modifications and extensions. | | |
|
|
|
Status: |
Best Current Practice (BCP: 67) -- updated by: , |
| |
|
|
|
|
|
|
|
12/2002
(18 p.)
|
B. Campbell
J. Rosenberg
H. Schulzrinne
C. Huitema
D. Gurle |
|
|
Instant Messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation.
This document proposes the "" method, an extension to SIP that allows the transfer of Instant Messages. Since the MESSAGE request is an extension to SIP, it inherits all the request routing and security features of that protocol. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. | | |
|
|
|
Status: |
Proposed Standard |
| |
|
|
|
|
|
|
|
01/2003
(34 p.)
|
M. Garcia-Martin
E. Henrikson
D. Mills |
|
|
This document describes a set of private SIP headers (P-headers) used by the 3rd-Generation Partnership Project (3GPP), along with their applicability, which is limited to particular environments. The P-headers are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses.
This document defines the "", "", "", "", "", and "" header fields. | | |
|
|
|
|
|
|
|
|
|
02/2003
(30 p.)
|
M. Garcia-Martin
C. Bormann
J. Ott
R. Price
A. B. Roach |
|
|
| SIP is a text-based protocol for initiating and managing communication sessions. The protocol can be compressed by using Signaling Compression (SigComp). Similarly, SDP is a text-based protocol intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This memo defines the SIP/SDP-specific static dictionary that SigComp may use in order to achieve higher efficiency. The dictionary is compression algorithm independent. | | |
|
|
|
Status: |
Proposed Standard -- updated by: |
| |
|
|
|
|
|
|
|
02/2003
(12 p.)
|
G. Camarillo |
|
|
| This document describes a mechanism to signal that compression is desired for one or more SIP messages. It also states when it is appropriate to send compressed SIP messages to a SIP entity. | | |
|
|
|
Status: |
Proposed Standard -- updated by: |
| |
|
|
|
|
|
|
|
02/2003
(17 p.)
|
H. Schulzrinne |
IEPREP |
|
| This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using SIP. | | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
56xx |
57xx |
58xx |
59xx |
60xx |
61xx |
62xx |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
04/2003
(23 p.)
|
R. Sparks |
|
|
| This document defines the "" method. This SIP extension requests that the recipient REFER to a resource provided in the request. It provides a mechanism allowing the party sending the REFER to be notified of the outcome of the referenced request. This can be used to enable many applications, including call transfer. In addition to the REFER method, this document defines the '' event package and the "" request header. | | |
|
|
|
Status: |
Proposed Standard |
| |
|
|
|
|
|
|
|
04/2003
(6 p.)
|
G. Camarillo
A. Monrad |
|
|
| This document defines an extension to SDP grouping framework. It allows requesting a group of media streams to be mapped into a single resource reservation flow. The SDP syntax needed is defined, as well as a new "semantics" attribute called Single Reservation Flow (SRF). | | |
|
|
|
Status: |
Proposed Standard |
| |
|
|
|
|
|
|
|
08/2003
(12 p.)
|
J. Soininen |
V6OPS |
|
| This document describes different scenarios in Third Generation Partnership Project (3GPP) defined packet network, i.e., General Packet Radio Service (GPRS) that would need IP version 6 and IP version 4 transition. The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g., in the Internet. GPRS network internal transition scenarios, i.e., between different GPRS elements in the network, are out of scope. The purpose of the document is to list the scenarios for further discussion and study. | | |
|
|
|
|
|
|
|
|
|
08/2003
(13 p.)
|
G. Camarillo
A. B. Roach
J. Peterson
L. Ong |
|
|
| This document describes a way to map Integrated Services Digital Network User Part (ISUP) overlap signalling to SIP. This mechanism might be implemented when using SIP in an environment where part of the call involves interworking with the Public Switched Telephone Network (PSTN). | | |
|
|
|
Status: |
Proposed Standard |
|
See also: |
|
| |
|
|
|
|
|
|
|
08/2003
(13 p.)
|
J. Rosenberg
H. Schulzrinne |
|
|
| SIP operates over UDP and TCP, among others. When used with UDP, responses to requests are returned to the source address the request came from, and to the port written into the topmost header field value of the request. This behavior is not desirable in many cases, most notably, when the client is behind a Network Address Translator (NAT). This extension defines a new parameter for the header field, called "rport", that allows a client to request that the server send the response back to the source IP address and port from which the request originated. | | |
|
|
|
Status: |
Proposed Standard |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
56xx |
57xx |
58xx |
59xx |
60xx |
61xx |
62xx |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
10/2003
(8 p.)
|
C. Huitema |
|
|
| SDP is used to describe the parameters of media streams used in multimedia sessions. When a session requires multiple ports, SDP assumes that these ports have consecutive numbers. However, when the session crosses a network address translation device that also uses port mapping, the ordering of ports can be destroyed by the translation. To handle this, we propose an extension attribute to SDP. | | |
|
|
|
Status: |
Proposed Standard |
| |
|
|
|
|
|
|
|
10/2003
(17 p.)
|
D. Willis
B. Hoeneisen |
|
|
| This document defines a SIP extension header field ("") used in conjunction with responses to REGISTER requests to provide a mechanism by which a registrar may inform a registering user agent (UA) of a service route that the UA may use to request outbound services from the registrar's domain. | | |
|
|
|
Status: |
Proposed Standard |
| |
|
|
|
|
|
|
|
12/2003
(94 p.)
|
A. Johnston
S. Donovan
R. Sparks
C. Cunningham
K. Summers |
|
|
| This document gives examples of Session Initiation Protocol (SIP) call flows. Elements in these call flows include SIP User Agents and Clients, SIP Proxy and Redirect Servers. Scenarios include SIP Registration and SIP session establishment. Call flow diagrams and message details are shown. | | |
|
|
|
Status: |
Best Current Practice (BCP: 75) |
|
See also: |
|
| |
|
|
|
|
|
|
|
12/2003
(118 p.)
|
A. Johnston
S. Donovan
R. Sparks
C. Cunningham
K. Summers |
|
|
| This document contains best current practice examples of SIP call flows showing interworking with the Public Switched Telephone Network (PSTN). Elements in these call flows include SIP User Agents, SIP Proxy Servers, and PSTN Gateways. Scenarios include SIP to PSTN, PSTN to SIP, and PSTN to PSTN via SIP. PSTN telephony protocols are illustrated using ISDN (Integrated Services Digital Network), ISUP (ISDN User Part), and FGB (Feature Group B) circuit associated signaling. PSTN calls are illustrated using global telephone numbers from the PSTN and private extensions served on by a PBX (Private Branch Exchange). Call flow diagrams and message details are shown. | | |
|
|
|
Status: |
Best Current Practice (BCP: 76) |
|
See also: |
|
| |
|
|
|
|
|
|
|
03/2004
(26 p.)
|
J. Rosenberg |
|
|
This document defines the '' SIP event package for registrations. Through its REGISTER method, SIP allows a user agent to create, modify, and delete registrations. Registrations can also be altered by administrators in order to enforce policy. As a result, these registrations represent a piece of state in the network that can change dynamically. There are many cases where a user agent would like to be notified of changes in this state. This event package defines a mechanism by which those user agents can request and obtain such notifications.
This document registers a new MIME type, application/reginfo+xml. | | |
|
|
|
Status: |
Proposed Standard |
| |
|
|
|
|
|
|
|
02/2004
(30 p.)
|
J. Cuellar
J. Morris
D. Mulligan
J. Peterson
J. Polk |
|
|
Location-based services, navigation applications, emergency services, management of equipment in the field, and other location-dependent services need geographic location information about a Target (such as a user, resource or other entity). There is a need to securely gather and transfer location information for location services, while at the same time protect the privacy of the individuals involved.
This document focuses on the authorization, security and privacy requirements for such location-dependent services. Specifically, it describes the requirements for the Geopriv Location Object (LO) and for the protocols that use this Location Object. This LO is envisioned to be the primary data structure used in all Geopriv protocol exchanges to securely transfer location data. | | |
|
|
|
|
|
|
|
|
|
02/2004
(18 p.)
|
M. Danley
D. Mulligan
J. Morris
J. Peterson |
|
|
| This document provides some analysis of threats against the Geopriv protocol architecture. It focuses on protocol threats, threats that result from the storage of data by entities in the architecture, and threats posed by the abuse of information yielded by Geopriv. Some security properties that meet these threats are enumerated as a reference for Geopriv requirements. | | |
|
|
