Login Form
RECENT IETF DRAFTS
SIP internet drafts statistics
- 115 SIP related internet drafts (IETF).
- 13 new and updated drafts posted in the last 14 days.
| Title | Author | Date |
| Transporting User to User Call Control Information in SIP for ISDN Interworking | Alan Johnston, Joanne McMillen | 2009-07-02 |
| Several approaches to transporting the ITU-T Q.931 User to User Information Element (UU IE) data in SIP have been proposed. As networks move to SIP it is important that applications requiring this data can continue to function in SIP networks as well as the ability to interwork with this ISDN service for end-to- end transparency. This document discusses three mechanisms to meet the requirements defined in the Requirements for SIP Call Control UUI document. A new SIP header field which bests meets these requirements is proposed. | ||
| Requirements for Transporting User to User Call Control Information in SIP for ISDN Interworking | Alan Johnston, Joanne McMillen | 2009-07-02 |
| Several approaches to transporting the ITU-T Q.931 User to User Information Element (UU IE) data in SIP have been proposed. As networks move to SIP it is important that applications requiring this data can continue to function in SIP networks as well as the ability to interwork with this ISDN service for end-to-end transparency. This document discusses requirements and approaches. This extension will also be used for native SIP endpoints implementing similar services and interworking with ISDN services. Example use cases include an exchange between two user agents, retargeting by a proxy, and redirection. An example application is an Automatic Call Distributor (ACD) in a contact center. | ||
| P2PSIP Event Notification Extension | Jun Wang, Zhifeng Chen, Yu Meng, Jiong Shen | 2009-07-01 |
| The p2p technology is data centric. Data objects are distributed in the p2p overlay according to routing algorithm.Applications access the data objects via peer/client protocol or gateways, some of which need data replicas to be synchronized in real time. This can be achieved by introducing a Subscribe/Notify mechanism to p2psip. This document describes the Subscribe/Notify mechanism extension for p2psip, and also defines several new methods as needed. | ||
| P2PSIP Overlay Diagnostics | Song Yongchao, XingFeng Jiang, Roni Even, David Bryan | 2009-06-30 |
| This document describes mechanisms for P2PSIP diagnostics. It describes the usage scenarios and defines several simple methods for performing diagnostics in P2PSIP overlay networks. It also describes the diagnostic information which is useful for the connection and node status monitoring. The methods and message formats are specified as extensions to P2PSIP base protocol RELOAD. | ||
| VoIP SIP Peering Use Cases | Adam Uzelac, Yiu Lee | 2009-06-30 |
| This document depicts many common Voice over IP (VoIP) use cases for Session Initiation Protocol (SIP) Peering. These use cases are categorized into static and on-demand, and then further sub- categorized into direct and indirect. These use cases are not an exhaustive set, but rather the most common use cases deployed today. | ||
| Simple SIP Usage Scenario for Applications in the Endpoints | Kundan Singh, Henry Sinnreich, Alan Johnston, Eunsoo Shim | 2009-06-29 |
| For Internet-centric usage, the number of SIP required standards for presence; IM and audio/video communications can be drastically smaller than what has been published, by using only the rendezvous and session initiation capabilities of SIP. The simplification is based on avoiding emulating telephony and its model of the intelligent network. \'Simple SIP\' by contrast relies on powerful computing endpoints. Simple SIP desktop applications can be combined with rich Internet applications (RIA). Significant telephony features may also be implemented in the endpoints. This approach for SIP reduces the number of SIP standards to comply with, currently from roughly 100 and still growing, to about 11. References for NAT traversal and for security are also provided. | ||
| Reusing Transport Layer Connections in Session Initiation Protocol (SIP) | Rajnish Jain, Vijay Gurbani, Hadriel Kaplan | 2009-06-28 |
| The current Session Initiation Protocol (SIP) specification dictates that a transport layer connection can carry SIP requests in only one direction i.e. from the client to the server. This presents scalability problems as twice the number of connections are needed for each pair of SIP entities that communicate with each other. The internet-draft [I-D.ietf-sip-connect-reuse] specifies a mechanism for reusing SIP over TLS connections. However, that document is predicated on secure TLS mutual authentication and specifically refrains connection reuse for transports such as SIP over TCP and SCTP. There are many situations, such as in Trust Domains [RFC3324], where TLS mutual authentication may not be required but where connection reuse is beneficial. This document specifies connection reuse for SIP over connection-oriented transports such as TCP and SCTP. It specifies the same mechanism for connection reuse as specified in [I-D.ietf-sip-connect-reuse], however, the solution is presented in the context of Trust Domains. | ||
| Requirements for secure caller identification in the Session Initiation Protocol (SIP) | John Elwell, Victor Pascual | 2009-06-28 |
| This document examines requirements for secure caller identification in SIP. Although existing mechanisms exist to achieve this, there are some known shortcomings or deployment difficulties. This work is being discussed on the dispatch@ietf.org mailing list. | ||
| A Session Initiation Protocol (SIP) Event Package for Communication Diversion Information in support of the Communication Diversion (CDIV) Notification (CDIVN) CDIV service | Ranjit Avasarala, Subir Saha, John-Luc Bakker | 2009-06-25 |
| 3GPP and ETSI TISPAN are defining PSTN/ISDN simulation services and in particular the Communication Diversion (CDIV) using IP Multimedia (IM) core Network (CN) subsystem supplementary service. As part of CDIV, a (SIP) Event Notification Framework-based mechanism is used for notifying Users about diversions (re-directions or forwarding) of their incoming communication sessions. A new event package is proposed for allowing users to subscribe for and receive such notifications. Users have further capability to define filters controlling the selection, rate and content of such notifications. This SIP event package is applicable to the IMS and may not be applicable to the general Internet. | ||
| Mapping and interworking of Diversion information Between Diversion and History-Info Headers in the Session Initiation Protocol (SIP) | Marianne Mohali | 2009-06-24 |
| The Diversion header is not standardized but widely used to convey diverting information in Session Initiation Protocol (SIP) signaling. This informational document proposes a way to interwork call diversion information contained in Diversion header with a History- Info header. In addition, an interworking policy is proposed to manage the headers coexistence. The History-Info header is described in [RFC4244] and the Diversion header is described in [draft-levy-sip-diversion-09]. Note to the RFC-Editor: The reference to this draft should be replaced by the Historic RFC reference (work in progress). Since the Diversion header is used in many existing networks implementations for transport of diversion information and its interworking with standardized solutions is not obvious, an interworking recommendation is needed. | ||
| A Session Initiation Protocol (SIP) Load Control Event Package | Charles Shen, Henning Schulzrinne, Arata Koike | 2009-06-23 |
| This document defines a load control event package for the Session Initiation Protocol (SIP). It allows SIP servers to distribute user load control information to SIP servers. The load control information can throttle outbound calls based on their destination domain, telephone number prefix or for a specific user. The mechanism helps to prevent signaling overload and complements feedback-based SIP overload control efforts. | ||
| Presence Interdomain Scaling Analysis for SIP/SIMPLE | Avshalom Houri, Edwin Aoki, Sriram Parameswar, Tim Rang, Vishal Singh, Henning Schulzrinne | 2009-06-23 |
| The document analyzes the traffic that is generated due to presence subscriptions between domains. It is shown that the amount of traffic can be extremely big. In addition to the very large traffic the document also analyzes the affects of a large presence system on the memory footprint and the CPU load. Current approved and in work optimizations to the SIP protocol are analyzed with the possible impact on the load. Separate documents contain the requirements for optimizations and suggestions for new optimizations. | ||
| SIPFIX: Use Cases and Problem Statement for VoIP Monitoring and Exporting | Felipe Huici, Saverio Niccolini, Sven Anderson | 2009-06-22 |
| The deployment of Voice-over-IP (VoIP) telephony is increasing fast. VoIP\'s paradigm and the features it offers differ significantly from that of regular telephony, and, as a result, its monitoring requirements do so as well. This draft employs use cases to derive these requirements and introduces SIPFIX, an extension to IPFIX (IP Flow Information eXchange), that meets them. | ||
| Considerations for Information Services and Operator Services Using SIP | John Haluska, Renee Berkowitz, Paul Roder, Wesley Downum, Richard Ahern, Paul Lung, Nicholas Costantino, Chris Blackwell | 2009-06-19 |
| Information Services are services whereby information is provided in response to user requests, and may include involvement of a human or automated agent. A popular existing Information Service is Directory Assistance (DA). Moving ahead, Information Services providers envision exciting multimedia services that support simultaneous voice and data interactions with full operator backup at any time during the call. Information Services providers are planning to migrate to SIP based platforms, which will enable such advanced services, while continuing to support traditional DA services. Operator Services are traditional PSTN services which often involve providing human or automated assistance to a caller, and often require the specialized capabilities traditionally provided by an operator services switch. Market and/or regulatory factors in some jurisdictions dictate that some subset of Operator Services continue to be provided going forward. This document aims to identify how Operator and Information Services can be implemented using existing or currently proposed SIP mechanisms, to identity existing protocol gaps, and to provide a set of Best Current Practices to facilitate interoperability. For Operator Services, the intention is to reproduce the current PSTN behaviour. | ||
| Signaling Compression dictionary for SIP | Lei Zhu | 2009-06-18 |
| The SigComp static dictionary for Session Initiation Protocol (SIP) signalling was done by first version RFC3485. SIP protocol related extensions were completed and published in a series IETF documents. Those SIP protocol extensions had been used in 3GPP IMS and IMS based applications. The new extensions to SIP protocol weaken the intention of static dictionary for SIP signalling compressing which is to reduce overload risks in radio access network and core network involving wireless network | ||
| PCAP-compatible Binary Syntax for SIP Common Log File Format | Hadriel Kaplan | 2009-06-16 |
| This document proposes a libpcap/PCAP-compatible binary syntax for the SIP common log format (CLF). It does not cover semantic issues, and is meant to be evaluated in the context of the other efforts discussing SIP CLF. | ||
| SIP/SDP Overlap with RTSP | Jan Lindquist, Jouni Maenpaa, Priya Rajagopal, Xavier Marjou | 2009-06-16 |
| The Session Initiation Protocol (SIP) is widely used for establishing multimedia sessions, whereas the Real Time Streaming Protocol (RTSP) is a protocol for use in streaming media systems. RTSP has a dual role: it establishes a media session for the delivery of streaming media as well as controls the streaming session once it has been set up. Since RTSP is also used for session establishment, there exists an overlap between the functionality provided by SIP and RTSP. In this document, we analyze a model in which SIP and the SDP offer/ answer model are used to set up a streaming session with an RTSP control channel and one or more media delivery streams. Such a model is beneficial since it allows the reuse of current architecture and functionality (e.g., authentication, charging, and QoS) established around SIP also for RTSP-based streaming. | ||
| The References Header for SIP | Dale Worley | 2009-06-12 |
| This document defines a SIP extension header, References, to be used within SIP messages to signify that the message (and the dialog containing it) is related to one or more other dialogs. It is expected to be used largely for diagnostic purposes. | ||
| An Extension to the Session Initiation Protocol (SIP) for Request History Information | Mary Barnes, Francois Audet | 2009-06-11 |
| 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. | ||
| Managing Client Initiated Connections in the Session Initiation Protocol (SIP) | Cullen Jennings | 2009-06-10 |
| The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections or to send asynchronous UDP datagrams to User Agents in order to deliver requests. However, in a large number of real deployments, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs) or the use of TLS with server-provided certificates, prevent servers from connecting to User Agents in this way. This specification defines behaviors for User Agents, registrars and proxy servers that allow requests to be delivered on existing connections established by the User Agent. It also defines keep alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections from the User Agent to its Registrar. | ||
| SIP endpoint security case study | Hendrik Scholz | 2009-06-09 |
| SIP endpoints are subject to unwanted communication often perceived as Spam over Internet Telephony (SPIT). This document describes caveats on various layers which can be abused to send unsolicited messages. As a result users receive a degraded experience. The issues found are based on case studies of various events seen in VoIP provider networks. | ||
| Implementing Call Park and Retrieve using the Session Initiation Protocol (SIP) | Michael Procter | 2009-06-08 |
| Call Park and Call Retrieve are useful telephony services that are familiar to many users. Existing implementations using the Session Initiation Protocol (SIP) show that a variety of approaches can be taken, with varying degrees of interoperability. This draft discusses a number of feature variations, and how they may be implemented using existing techniques. An additional URI parameter is also described, which enables further common use-cases to be implemented. | ||
| Requirements for a Condition-based URI Selection (CBUS) using the Session Initiation Protocol (SIP) | Christer Holmberg | 2009-05-27 |
| This specification defines CBUS requirements for the SIP interface between the CBUS Client and the CBUS server, based on the requirements in OMA. | ||
| SOS Uniform Resource Identifier (URI) Parameter for Marking of Session Initiation Protocol (SIP) Requests related to Emergency Services | Milan Patel | 2009-05-26 |
| This document defines a new Session Initiation Protocol (SIP) Uniform Resource Identifier (URI) parameter intended for marking SIP registration requests related to emergency services. The usage of this new URI parameter complements the usage of the Service Uniform Resource Name (URN) and is not intended to replace it. | ||
| A SIP server event package for SIP server farm | Tao Ma, LiChun Li, Chunhong Zhang, Xituchen Beijing, Yang Ji | 2009-05-26 |
| This document defines the Session Initiation Protocol (SIP) server even package for SIP server farm using the SIP event framework. The SIP server event package allows clients to subscribe to the servers for server information in the server farm, and serves to communicate information with each other. Based on this, an overall view of the SIP server farm is built and delivered to the entity (including SIP phone proxy or other SIP servers) which subscribes and receives the event packages. The view would help failover and load balancing in the server farm. The event notification mechanism of SIP event framework guarantees its adaption to the dynamic changes of server state. We instantiate the usage of SIP server event package in three scenarios: client based failover, DNS based failover, load balancer based load balancing. To be added, we introduce some specific usage in Peer-to-Peer SIP(P2PSIP) and service discovery to expand and explore the potential usage space. Compared with the failover and load balancing mechanisms in traditional SIP, the new SIP event package would apply its explicit and dynamic notification mechanism to improve the efficiency and service availability of SIP server farm. This mechanism using server event package can also be a complementary way for the DNS functionality defined in RFC 3263[RFC 3263] to locate SIP servers. | ||
| << Start < Prev 1 2 3 4 5 Next > End >> | ||
| Display # Results 1 - 25 of 115 | ||