| 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 [here ]. | |
|
|
|
|
|
| |
|
|
| 
|
|
|
|
| | | | RFC3261
06/2002
(269 p.)
pdf(v)
pdf(p) | J. Rosenberg
H. Schulzrinne
G. Camarillo
A. Johnston
J. Peterson
R. Sparks
M. Handley
E. Schooler | SIP |
| SIP: Session Initiation Protocol | 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
http://www.iana.org/assignments/sip-parameters : 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 Content-Disposition header "disposition-types": alert , icon , session and render . |
|
|
|
|
|
|
|
|
|
| | | | RFC3262
06/2002
(14 p.)
pdf(v)
pdf(p) | J. Rosenberg
H. Schulzrinne | SIP |
| Reliability of Provisional Responses in SIP | | This document specifies an extension to SIP providing reliable provisional response messages. This extension uses the '100rel ' SIP option tag and defines the Provisional Response ACKnowledgement ("PRACK ") method. Each provisional response is given a sequence number, carried in the "RSeq " header field. The PRACK messages contain an "RAck " header field, which indicates the sequence number of the provisional response that is being acknowledged. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3263
06/2002
(17 p.)
pdf(v)
pdf(p) | J. Rosenberg
H. Schulzrinne | SIP |
| Locating SIP Servers | 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 " Registry for the SIP SRV Resource Record Services Field " and places the following NAPTR service field values: SIP+D2T , SIPS+D2T , SIP+D2U , SIP+D2S . |
|
|
|
|
|
|
|
| | | | RFC3264
06/2002
(25 p.)
pdf(v)
pdf(p) | J. Rosenberg
H. Schulzrinne | MMUSIC |
| An Offer/Answer Model with SDP | | 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. |
|
|
|
|
|
|
|
| | | | RFC3265
06/2002
(38 p.)
pdf(v)
pdf(p) | A. B. Roach | SIP |
| SIP - Specific Event Notification | 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 "SUBSCRIBE " and "NOTIFY " 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 "Event ", "Allow-Events ", and "Subscription-State " header fields. |
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
| | | | RFC3303
08/2002
(34 p.)
pdf(p) | P. Srisuresh
J. Kuthan
J. Rosenberg
A. Molitor
A. Rayhan | MIDCOM |
| Middlebox communication architecture and framework | 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. |
|
|
|
|
|
|
|
| | | | RFC3310
09/2002
(18 p.)
pdf(v)
pdf(p) | A. Niemi
J. Arkko
V. Torvinen | SIP |
| HTTP Digest Authentication using AKA | 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 " AKA-Version Namespace " IANA Registry and places the AKAv1 value. |
|
|
|
|
|
|
|
| | | | RFC3311
09/2002
(13 p.)
pdf(v)
pdf(p) | J. Rosenberg | SIP |
| SIP UPDATE Method | | This specification defines the new "UPDATE " 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. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3312
10/2002
(30 p.)
pdf(p) | G. Camarillo
W. Marshall
J. Rosenberg | SIP |
| Integration of Resource Management and SIP | 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 'precondition ' SIP option tag. |
|
|
|
|
|
|
|
| | | | RFC3313
01/2003
(16 p.)
pdf(p) | W. Marshall | SIP |
| Private SIP Extensions for Media Authorization | 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 "P-Media-Authorization " header field. |
|
|
|
|
|
|
|
| | | | RFC3314
09/2002
(23 p.)
pdf(p) | M. Wasserman | IPV6 |
| Recommendations for IPv6 in 3GPP Standards | 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. |
|
|
|
|
|
|
|
| | | | RFC3319
07/2003
(7 p.)
pdf(p) | H. Schulzrinne
B. Volz | SIP |
| Dynamic Host Configuration Protocol (DHCPv6) Options for SIP Servers | | 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. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3320
01/2003
(62 p.)
pdf(p) | R. Price
C. Bormann
J. Christoffersson
H. Hannu
Z. Liu
J. Rosenberg | ROHC |
| Signaling Compression (SigComp) | 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 (RFC 1951 ). |
|
|
| | | Up | Status: | Proposed Standard -- updated by: RFC 4896 | |
|
|
|
|
| | | | RFC3321
01/2003
(19 p.)
pdf(p) | H. Hannu
J. Christoffersson
S. Forsgren
K.-C. Leung
Z. Liu
R. Price | ROHC |
| Signaling Compression (SigComp) - Extended Operations | This document describes how to implement certain mechanisms in Signaling Compression (SigComp), RFC 3320 , 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 RFC 3320 . |
|
|
|
|
|
|
|
| | | | RFC3322
01/2003
(13 p.)
pdf(p) | H. Hannu | ROHC |
| Signaling Compression (SigComp) Requirements & Assumptions | | 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. |
|
|
|
|
|
|
|
| | | | RFC3323
11/2002
(22 p.)
pdf(v)
pdf(p) | J. Peterson | SIP |
| A Privacy Mechanism for SIP | 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 "Privacy " header field. It also defines the 'privacy ' SIP option tag. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3324
11/2002
(11 p.)
pdf(p) | M. Watson | SIPPING |
| Short Term Requirements for Network Asserted Identity | | 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. |
|
|
|
|
|
|
|
| | | | RFC3325
11/2002
(18 p.)
pdf(v)
pdf(p) | C. Jennings
J. Peterson
M. Watson | SIP |
| Private Extensions to SIP for Asserted Identity within Trusted Networks | 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 "P-Asserted-Identity " and "P-Preferred-Identity " header fields. |
|
|
|
|
|
|
|
| | | | RFC3326
12/2002
(8 p.)
pdf(p) | H. Schulzrinne
D. Oran
G. Camarillo | SIP |
| The Reason Header Field for SIP | For creating services, it is often useful to know why a SIP request was issued. This document defines the "Reason " 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 http://www.iana.org/ assignments/sip-parameters , 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. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3327
12/2002
(17 p.)
pdf(v)
pdf(p) | D. Willis
B. Hoeneisen | SIP |
| SIP Extension Header Field for Registering Non-Adjacent Contacts | 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: <sip:alice@pc33.atlanta.com> 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, "Path " which provides such a mechanism. The associated SIP option tag is 'path '. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3351
08/2002
(17 p.)
pdf(p) | N. Charlton
M. Gasson
G. Gybels
M. Spanner
A. van Wijk | SIPPING |
| User Requirements for SIP in Support of Deaf, Hard of Hearing and Speech-impaired Individuals | | 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. |
|
|
|
|
|
|
|
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3372
09/2002
(23 p.)
pdf(p) | A. Vemuri
J. Peterson | SIPPING |
| SIP for Telephones (SIP-T): Context and Architectures | | 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). |
|
|
| | | Up | Status: | Best Current Practice (BCP: 63) | |
|
|
|
|
| | | | RFC3388
12/2002
(21 p.)
pdf(p) | G. Camarillo
G. Eriksson
J. Holler
H. Schulzrinne | MMUSIC |
| Grouping of Media Lines in SDP | | 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. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3398
12/2002
(68 p.)
pdf(v)
pdf(p) | G. Camarillo
A. B. Roach
J. Peterson
L. Ong | SIPPING |
| ISUP to SIP Mapping | | 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). |
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3420
11/2002
(8 p.)
pdf(p) | R. Sparks | SIP |
| Internet Media Type message/sipfrag | | 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 REFER method to convey information about the status of a referenced request. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3427
12/2002
(12 p.)
pdf(p) | A. Mankin
S. Bradner
R. Mahy
D. Willis
J. Ott
B. Rosen | TSV area |
| Change Process for SIP | | 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. |
|
|
|
|
|
|
|
| | | | RFC3428
12/2002
(18 p.)
pdf(v)
pdf(p) | B. Campbell
J. Rosenberg
H. Schulzrinne
C. Huitema
D. Gurle | SIP |
| SIP Extension for Instant Messaging | 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 "MESSAGE " 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. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
|
|
|
|
|
|
|
| | | | RFC3485
02/2003
(30 p.)
pdf(p) | M. Garcia-Martin
C. Bormann
J. Ott
R. Price
A. B. Roach | SIPPING |
| SIP and SDP Static Dictionary for Signaling Compression (SigComp) | | 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. |
|
|
| | | Up | Status: | Proposed Standard -- updated by: RFC 4896 | |
|
|
|
|
| | | | RFC3486
02/2003
(12 p.)
pdf(p) | G. Camarillo | SIP |
| Compressing SIP | | 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. |
|
|
| | | Up | Status: | Proposed Standard -- updated by: RFC 5049 | |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
| | | | RFC3515
04/2003
(23 p.)
pdf(v)
pdf(p) | R. Sparks | SIP |
| The SIP Refer Method | | This document defines the "REFER " 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 'refer ' event package and the "Refer-To " request header. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3524
04/2003
(6 p.)
pdf(p) | G. Camarillo
A. Monrad | MMUSIC |
| Mapping of Media Streams to Resource Reservation Flows | | 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). |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3574
08/2003
(12 p.)
pdf(p) | J. Soininen | V6OPS |
| Transition Scenarios for 3GPP Networks | | 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. |
|
|
|
|
|
|
|
| | | | RFC3578
08/2003
(13 p.)
pdf(v)
pdf(p) | G. Camarillo
A. B. Roach
J. Peterson
L. Ong | SIPPING |
| Mapping of ISUP Overlap Signalling to SIP | | 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). |
|
|
|
|
|
|
|
| | | | RFC3581
08/2003
(13 p.)
pdf(p) | J. Rosenberg
H. Schulzrinne | SIP |
| An Extension to SIP for Symmetric Response Routing | | 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 Via 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 Via 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. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| | | | RFC3605
10/2003
(8 p.)
pdf(p) | C. Huitema | MMUSIC |
| Real Time Control Protocol (RTCP) attribute in SDP | | 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. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3665
12/2003
(94 p.)
pdf(p) | A. Johnston
S. Donovan
R. Sparks
C. Cunningham
K. Summers | SIPPING |
| SIP Basic Call Flow Examples | | 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. |
|
|
|
|
|
|
|
| | | | RFC3666
12/2003
(118 p.)
pdf(p) | A. Johnston
S. Donovan
R. Sparks
C. Cunningham
K. Summers | SIPPING |
| SIP Public Switched Telephone Network (PSTN) Call Flows | | 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. |
|
|
|
|
|
|
|
| | | | RFC3680
03/2004
(26 p.)
pdf(v)
pdf(p) | J. Rosenberg | SIPPING |
| A SIP Event Package for Registrations | This document defines the 'reg ' 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 . |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3693
02/2004
(30 p.)
pdf(p) | J. Cuellar
J. Morris
D. Mulligan
J. Peterson
J. Polk | GEOPRIV |
| Geopriv Requirements | 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. |
|
|
|
|
|
|
|
| | | | RFC3694
02/2004
(18 p.)
pdf(p) | M. Danley
D. Mulligan
J. Morris
J. Peterson | GEOPRIV |
| Threat Analysis of the Geopriv Protocol | | 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. |
|
|
|
|
218
非常没帮助
没帮助
一般
有帮助
非常有帮助
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
