|
|
|
| |
|
|
|
|
|
|
| | | | RFC4028
04/2005
(28 p.)
pdf(v)
pdf(p) | S. Donovan
J. Rosenberg | SIP |
| Session Timers in SIP | This document defines an extension to SIP. This extension allows for a periodic refresh of SIP sessions through a re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine whether the SIP session is still active. The extension defines two new header fields: "Session-Expires ", which conveys the lifetime of the session, and "Min-SE ", which conveys the minimum allowed value for the session timer.
This document defines the 'timer ' SIP option tag and the 422 Session Interval Too Small response code. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4032
03/2005
(10 p.)
pdf(p) | G. Camarillo
P. Kyzivat | SIP |
| Update to SIP Preconditions Framework | | This document updates RFC 3312 , which defines the framework for preconditions in SIP. It provides guidelines for authors of new precondition types and describes how to use SIP preconditions in situations that involve session mobility. |
|
|
|
|
|
|
|
| | | | RFC4079
07/2005
(7 p.)
pdf(p) | J. Peterson | GEOPRIV |
| A Presence Architecture for the Distribution of GEOPRIV Location Objects | | GEOPRIV defines the concept of a 'using protocol' -- a protocol that carries GEOPRIV location objects. GEOPRIV also defines various scenarios for the distribution of location objects that require the concepts of subscriptions and asynchronous notifications. This document examines some existing IETF work on the concept of presence, shows how presence architectures map onto GEOPRIV architectures, and moreover demonstrates that tools already developed for presence could be reused to simplify the standardization and implementation of GEOPRIV. |
|
|
|
|
|
|
|
| | | | RFC4083
05/2005
(36 p.)
pdf(p) | M. Garcia-Martin | SIPPING |
| Input 3GPP Release 5 Requirements on SIP | | The 3rd-Generation Partnership Project (3GPP) has selected SIP as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IMS). IMS is part of Release 5 of the 3GPP specifications. Although SIP is a protocol that fulfills most of the requirements for establishing a session in an IP network, SIP has never been evaluated against the specific 3GPP requirements for operation in a cellular network. In this document, we express the requirements identified by 3GPP to support SIP for Release 5 of the 3GPP IMS in cellular networks. |
|
|
|
|
|
|
|
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4092
06/2005
(6 p.)
pdf(p) | G. Camarillo
J. Rosenberg | SIP |
| Usage of SDP Alternative Network Address Types (ANAT) Semantics in SIP | | This document describes how to use the Alternative Network Address Types (ANAT) semantics of SDP grouping framework in SIP. In particular, we define the 'sdp-anat ' SIP option tag. This SIP option-tag ensures that SDP session descriptions that use ANAT are only handled by SIP entities with ANAT support. To justify the need for such a SIP option-tag, we describe what could possibly happen if an ANAT-unaware SIP entity tried to handle media lines grouped with ANAT. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | | RFC4119
12/2005
(24 p.)
pdf(p) | J. Peterson | GEOPRIV |
| A Presence-based GEOPRIV Location Object Format | | This document describes an object format for carrying geographical information on the Internet. This location object extends the Presence Information Data Format (PIDF), which was designed for communicating privacy-sensitive presence information and which has similar properties. |
|
|
| | | Up | Status: | Proposed Standard -- Updated by: RFC 5139 | |
|
|
|
|
| | | | RFC4122
07/2005
(32 p.)
pdf(p) | P. Leach
M. Mealling
R. Salz | - |
| A Universally Unique IDentifier (UUID) URN Namespace | This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation's (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.
This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4123
07/2005
(16 p.)
pdf(p) | H. Schulzrinne
C. Agboh | SIP |
| SIP-H.323 Interworking Requirements | | This document describes the requirements for the logical entity known as the Session Initiation Protocol (SIP)-H.323 Interworking Function (SIP-H.323 IWF) that will allow the interworking between SIP and H.323. |
|
|
|
|
|
|
|
| | | | RFC4145
09/2005
(15 p.)
pdf(p) | D. Yon
G. Camarillo | MMUSIC |
| TCP-Based Media Transport in SDP | | This document describes how to express media transport over TCP using SDP. It defines the SDP 'TCP' protocol identifier, the SDP 'setup' attribute, which describes the connection setup procedure, and the SDP 'connection' attribute, which handles connection reestablishment. |
|
|
| | | Up | Status: | Proposed Standard -- updated by RFC4572 | |
|
|
|
|
| | | | RFC4168
10/2005
(10 p.)
pdf(p) | J. Rosenberg
H. Schulzrinne
G. Camarillo | SIP |
| The Stream Control Transmission Protocol (SCTP) as a Transport for SIP | This document specifies a mechanism for usage of SCTP (the Stream Control Transmission Protocol) as the transport mechanism between SIP (Session Initiation Protocol) entities. SCTP is a new protocol that provides several features that may prove beneficial for transport between SIP entities that exchange a large amount of messages, including gateways and proxies. As SIP is transport-independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP.
This RFC adds the SIPS+D2S NAPTR service field value to the registry defined in RFC 3263 . |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4169
11/2005
(13 p.)
pdf(p) | V. Torvinen
J. Arkko
M. Naslund | HTTP |
| HTTP Digest Authentication using Authentication and Key Agreement (AKA) Version-2 | | HTTP Digest, as specified in RFC 2617 , is known to be vulnerable to man-in-the-middle attacks if the client fails to authenticate the server in TLS, or if the same passwords are used for authentication in some other context without TLS. This is a general problem that exists not just with HTTP Digest, but also with other IETF protocols that use tunneled authentication. This document specifies version 2 of the HTTP Digest AKA algorithm (RFC 3310 ). This algorithm can be implemented in a way that it is resistant to the man-in-the-middle attack. |
|
|
|
|
|
|
|
| | | | RFC4189
10/2005
(12 p.)
pdf(p) | K. Ono
S. Tachimoto | SIPPING |
| Requirements for End-to-Middle Security for SIP | | A Session Initiation Protocol (SIP) User Agent (UA) does not always trust all intermediaries in its request path to inspect its message bodies and/or headers contained in its message. The UA might want to protect the message bodies and/or headers from intermediaries, except those that provide services based on its content. This situation requires a mechanism called "end-to-middle security" to secure the information passed between the UA and intermediaries, which does not interfere with end-to-end security. This document defines a set of requirements for a mechanism to achieve end-to-middle security. |
|
|
|
|
|
|
|
| | | | RFC4190
11/2005
(28 p.)
pdf(p) | K. Carlberg
I. Brown
C. Beard | IEPREP |
| Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony | | This document presents a framework for supporting authorized, emergency-related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These models, coupled with an example of an existing service in the Public Switched Telephone Network (PSTN), contribute to a constrained solution space. |
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
| | | | RFC4215
10/2005
(24 p.)
pdf(p) | J. Wiljakka | V6OPS |
| Analysis on IPv6 Transition in 3GPP Networks | This document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) packet networks. These networks are based on General Packet Radio Service (GPRS) technology, and the radio network architecture is based on Global System for Mobile Communications (GSM) or Universal Mobile Telecommunications System (UMTS)/Wideband Code Division Multiple Access (WCDMA) technology.
The focus is on analyzing different transition scenarios and applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g., in the Internet, and IPv6/IPv4 transition mechanisms are needed. |
|
|
|
|
|
|
|
| | | | RFC4235
11/2005
(39 p.)
pdf(p) | J. Rosenberg
H. Schulzrinne
R. Mahy | SIPPING |
| An INVITE-Initiated Dialog Event Package for SIP | This document defines the 'dialog ' event package for the SIP Events architecture, along with a data format used in notifications for this package. The dialog package allows users to subscribe to another user and to receive notification of the changes in state of INVITE-initiated dialog usages in which the subscribed-to user is involved.
This RFC registers a new MIME type, application/ dialog-info+xml .
It also registers two new Media feature tags, sip.byeless (19) and sip.rendering (20) , placed into the SIP Media Feature Tag Registration Tree, which is defined in RFC 3840 . |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4240
12/2005
(24 p.)
pdf(p)
pdf(v) | E. Burger
J. Van Dyke
A. Spitzer | SIPPING |
| Basic Network Media Services with SIP | In SIP-based networks, there is a need to provide basic network media services. Such services include network announcements, user interaction, and conferencing services. These services are basic building blocks, from which one can construct interesting applications. In order to have interoperability between servers offering these building blocks (also known as Media Servers) and application developers, one needs to be able to locate and invoke such services in a well defined manner.
This document describes a mechanism for providing an interoperable interface between Application Servers, which provide application services to SIP-based networks, and Media Servers, which provide the basic media processing building blocks.
This specification adds new values to the IANA registration in the "SIP/SIPS URI Parameters " registry as defined in RFC 3969 : "play ", "content-type ", "delay ", "duration ", "repeat ", "locale ", "param[n] ", and "voicexml ". |
|
|
|
|
|
|
|
| | | | RFC4244
11/2005
(44 p.)
pdf(p)
pdf(v) | M. Barnes | SIP |
| An Extension to SIP for Request History Information | This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines a new optional SIP header, "History-Info ", for capturing the history information in requests.
This specification defines the 'histinfo ' SIP option tag. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4245
11/2005
(12 p.)
pdf(p) | O. Levin
R. Even | SIPPING |
| High-Level Requirements for Tightly Coupled SIP Conferencing | | This document examines a wide range of conferencing requirements for tightly coupled SIP conferences. Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed. Together, these documents will provide a guide for building interoperable SIP conferencing applications. |
|
|
|
|
|
|
|
| | | | RFC4282
12/2005
(16 p.)
pdf(p) | B. Aboba
M. Beadles
J. Arkko
P. Eronen | RADEXT |
| Network Access Identifier | | In order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network authentication. "Roaming" may be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of where roaming capabilities might be required include ISP "confederations" and ISP-provided corporate network access support. |
|
|
| | | Up | Status: | Standards Track | |
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | | RFC4317
12/2005
(24 p.)
pdf(p) | A. Johnston
R. Sparks | MMUSIC |
| SDP Offer/Answer Examples | | This document gives examples of Session Description Protocol (SDP) offer/answer exchanges. Examples include codec negotiation and selection, hold and resume, and addition and deletion of media streams. The examples show multiple media types, bidirectional, unidirectional, inactive streams, and dynamic payload types. Common Third Party Call Control (3pcc) examples are also given. |
|
|
|
|
|
|
|
| | | | RFC4320
01/2006
(7 p.)
pdf(p) | R. Sparks | SIP |
| Actions Addressing Identified Issues with the SIP Non-INVITE Transaction | | This document describes modifications to the Session Initiation Protocol (SIP) to address problems that have been identified with the SIP non-INVITE transaction. These modifications reduce the probability of messages losing the race condition inherent in the non-INVITE transaction and reduce useless network traffic. They also improve the robustness of SIP networks when elements stop responding. These changes update behavior defined in RFC 3261. |
|
|
| | | Up | Status: | Proposed Standard -- updates: RFC3261 | |
|
|
|
|
|
|
|
|
|
|
|
| | | | RFC4353
02/2006
(29 p.)
pdf(p) | J. Rosenberg | SIPPING |
| A Framework for Conferencing with SIP | | The Session Initiation Protocol (SIP) supports the initiation, modification, and termination of media sessions between user agents. These sessions are managed by SIP dialogs, which represent a SIP relationship between a pair of user agents. Because dialogs are between pairs of user agents, SIP's usage for two-party communications (such as a phone call), is obvious. Communications sessions with multiple participants, generally known as conferencing, are more complicated. This document defines a framework for how such conferencing can occur. This framework describes the overall architecture, terminology, and protocol components needed for multi-party conferencing. |
|
|
|
|
|
|
|
| | | | RFC4354
01/2006
(21 p.)
pdf(p) | M. Garcia-Martin | SIPPING |
| A SIP Event Package and Data Format for Various Settings in Support for the Push-to-Talk over Cellular (PoC) Service | The Open Mobile Alliance (OMA) is defining the Push-to-talk over Cellular (PoC) service where SIP is the protocol used to establish half-duplex media sessions across different participants, to send instant messages, etc. This document defines the 'poc-settings ' SIP event package to support publication, subscription, and notification of additional capabilities required by the PoC service. This SIP event package is applicable to the PoC service and may not be applicable to the general Internet.
This document registers a new MIME type, application/ poc-settings+xml . |
|
|
|
|
|
|
|
| | | | RFC4376
02/2006
(14 p.)
pdf(p) | P. Koskelainen
J. Ott
H. Schulzrinne
X. Wu | XCON |
| Requirements for Floor Control Protocols | | Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document defines the requirements for a floor control protocol for multiparty conferences in the context of an existing framework. |
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
| | | | RFC4411
02/2006
(22 p.)
pdf(p) | J. Polk | SIPPING |
| Extending SIP Reason Header for Preemption Events | This document proposes an IANA Registration extension to the SIP Reason Header (RFC 3326 ) to be included in a BYE Method Request as a result of a session preemption event, either at a user agent (UA), or somewhere in the network involving a reservation-based protocol such as the Resource ReSerVation Protocol (RSVP) or Next Steps in Signaling (NSIS). This document does not attempt to address routers failing in the packet path; instead, it addresses a deliberate tear down of a flow between UAs, and informs the terminated UA(s) with an indication of what occurred. This RFC defines a new protocol value: Preemption to the "Reason Protocols " sub-registry. It also defines the
http://www.iana.org/assignments/preemption-namespace registry, with 4 defined cause codes. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4453
04/2006
(8 p.)
pdf(p) | J. Rosenberg
G. Camarillo
D. Willis | SIPPING |
| Requirements for Consent-Based Communications in SIP | | The Session Initiation Protocol (SIP) supports communications across many media types, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including spam and denial-of-service attacks. This document identifies a set of requirements for extensions to SIP that add consent-based communications. |
|
|
|
|
|
|
|
| | | | RFC4457
04/2006
(8 p.)
pdf(p) | G. Camarillo
G. Blanco | SIPPING |
| The SIP P-User-Database Private-Header (P-Header) | | This document specifies the SIP "P-User-Database " Private-Header (P-header). This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) to provide SIP registrars and SIP proxy servers with the address of the database that contains the user profile of the user that generated a particular request. |
|
|
|
|
|
|
|
| | | | RFC4458
04/2006
(21 p.)
pdf(p) | C. Jennings
F. Audet
J. Elwell | SIP |
| SIP URIs for Applications such as Voicemail and Interactive Voice Response (IVR) | The Session Initiation Protocol (SIP) is often used to initiate connections to applications such as voicemail or interactive voice recognition systems. This specification describes a convention for forming SIP service URIs that request particular services based on redirecting targets from such applications.
This specification adds two new values ("target " and "cause ") to the IANA registration in the "SIP/SIPS URI Parameters " registry as defined in RFC 3969 . |
|
|
|
|
|
|
|
| | | | RFC4463
04/2006
(86 p.)
pdf(p) | S. Shanmugham
P. Monaco
B. Eberman | - |
| A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks | The Session Initiation Protocol (SIP) is often used to initiate This document describes a Media Resource Control Protocol (MRCP) that was developed jointly by Cisco Systems, Inc., Nuance Communications, and Speechworks, Inc. It is published as an RFC as input for further IETF development in this area.
MRCP controls media service resources like speech synthesizers, recognizers, signal generators, signal detectors, fax servers, etc., over a network. This protocol is designed to work with streaming protocols like RTSP (Real Time Streaming Protocol) or SIP (Session Initiation Protocol), which help establish control connections to external media streaming devices, and media delivery mechanisms like RTP (Real Time Protocol). |
|
|
|
|
|
|
|
| | | | RFC4474
08/2006
(41 p.)
pdf(p) | J. Peterson
C. Jennings | SIP |
| Enhancements for Authenticated Identity Management in SIP | The existing security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP messages. It does so by defining two new SIP header fields, "Identity ", for conveying a signature used for validating the identity, and "Identity-Info ", for conveying a reference to the certificate of the signer.
This RFC defines the following Response Codes: 428 Use Identity Header , 436 Bad Identity-Info , 437 Unsupported Certificate and 438 Invalid Identity Header . This RFC also defines two new sub-registries labeled "Identity-Info Parameters " and "Identity-Info Algorithm Parameter Values " under http://www.iana.org/assignments/sip-parameters . |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4475
05/2006
(53 p.)
pdf(p) | R. Sparks
A. Hawrylyshen
A. Johnston
J. Rosenberg
H. Schulzrinne | SIPPING |
| SIP Torture Test Messages | | This informational document gives examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" a SIP implementation. |
|
|
|
|
|
|
|
| | | | RFC4479
07/2006
(35 p.)
pdf(p) | J. Rosenberg | SIMPLE |
| A Data Model for Presence | | This document defines the underlying presence data model used by Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) presence agents. The data model provides guidance on how to map various communications systems into presence documents in a consistent fashion. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4480
07/2006
(37 p.)
pdf(p) | H. Schulzrinne
V. Gurbani
P. Kyzivat
J. Rosenberg | SIMPLE |
| RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) | The Presence Information Data Format (PIDF) defines a basic format for representing presence information for a presentity. This format defines a textual note, an indication of availability (open or closed) and a Uniform Resource Identifier (URI) for communication. The Rich Presence Information Data format (RPID) described here is an extension that adds optional elements to the Presence Information Data Format (PIDF). These extensions provide additional information about the presentity and its contacts. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity.
This extension includes information about what the person is doing, a grouping identifier for a tuple, when a service or device was last used, the type of place a person is in, what media communications might remain private, the relationship of a service tuple to another presentity, the person's mood, the time zone it is located in, the type of service it offers, an icon reflecting the presentity's status, and the overall role of the presentity.
These extensions include presence information for persons, services (tuples), and devices. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4482
07/2006
(11 p.)
pdf(p) | H. Schulzrinne | SIMPLE |
| CIPID: Contact Information for the Presence Information Data Format | | The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. The Contact Information for the Presence Information Data format (CIPID) is an extension that adds elements to PIDF that provide additional contact information about a presentity and its contacts, including references to address book entries and icons. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4483
05/2006
(17 p.)
pdf(p) | E. Burger | SIP |
| A Mechanism for Content Indirection in SIP Messages | | This document defines an extension to the URL MIME External-Body Access-Type to satisfy the content indirection requirements for the Session Initiation Protocol (SIP). These extensions are aimed at allowing any MIME part in a SIP message to be referred to indirectly via a URI. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4484
08/2006
(15 p.)
pdf(p) | J. Peterson
J. Polk
D. Sicker
H. Tschofenig | SIPPING |
| Trait-Based Authorization Requirements for SIP | | This document lays out a set of requirements related to trait-based authorization for the Session Initiation Protocol (SIP). While some authentication mechanisms are described in the base SIP specification, trait-based authorization provides information used to make policy decisions based on the attributes of a participant in a session. This approach provides a richer framework for authorization, as well as allows greater privacy for users of an identity system. |
|
|
|
|
|
|
|
| | | | RFC4485
05/2006
(23 p.)
pdf(p) | J. Rosenberg
H. Schulzrinne | SIP |
| Guidelines for Authors of Extensions to SIP | | The Session Initiation Protocol (SIP) is a flexible yet simple tool for establishing interactive communications sessions across the Internet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions. |
|
|
|
|
|
|
|
| | | | RFC4488
05/2006
(8 p.)
pdf(p) | O. Levin | SIP |
| Suppression of SIP REFER Method Implicit Subscription | The Session Initiation Protocol (SIP) REFER extension as defined in RFC 3515 automatically establishes a typically short-lived event subscription used to notify the party sending a REFER request about the receiver's status in executing the transaction requested by the REFER. These notifications are not needed in all cases. This specification provides a way to prevent the automatic establishment of an event subscription and subsequent notifications using a new SIP extension "Refer-Sub ", header field that may be included in a REFER request.
This document also registers a new SIP option tag: 'norefersub '. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4497
05/2006
(65 p.)
pdf(p) | J. Elwell
F. Derks
P. Mourot
O. Rousseau | SIPPING |
| Interworking between SIP and QSIG | | This document specifies interworking between the Session Initiation Protocol (SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks). SIP is an Internet application-layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls. QSIG is a signalling protocol for creating, modifying, and terminating circuit-switched calls (in particular, telephone calls) within Private Integrated Services Networks (PISNs). QSIG is specified in a number of Ecma Standards and published also as ISO/IEC standards. |
|
|
| | | Up | Status: | Best Current Practice (BCP: 117) |
|
296
非常没帮助
没帮助
一般
有帮助
非常有帮助
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
