About: Session Description Protocol is a research topic. Over the lifetime, 541 publications have been published within this topic receiving 22009 citations. The topic is also known as: SDP.
TL;DR: RTP provides end-to-end network transport functions suitable for applications transmitting real-time data over multicast or unicast network services and is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks.
Abstract: This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers.
TL;DR: This document defines the Session Description Protocol, SDP, intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.
Abstract: This document defines the Session Description Protocol, SDP. SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.
TL;DR: This document describes version 2 of the multicast session directory announcement protocol, Session Announcement Protocol (SAP), and the related issues affecting security and scalability that should be taken into account by implementors.
Abstract: This document describes version 2 of the multicast session directory announcement protocol, Session Announcement Protocol (SAP), and the related issues affecting security and scalability that should be taken into account by implementors.
TL;DR: This experiment was not only the first sizeabl e audio muldcast over apacket network, but also significan t for the size of the IP multicast network topology itself.
Abstract: At the March, 1992 meeting of the Internet Engineerin g Task Force (IETF) in San Diego, live audio from severa l sessions of the meeting was "audiocast" using multicas t packet transmission from the IETF site over the Internet t o participants at 20 sites on three continents spanning 1 6 time zones . This experiment was not only the first sizeabl e audio muldcast over apacket network . but also significan t for the size of the IP multicast network topology itself .
TL;DR: In this paper, an IP Multimedia Subsystem (IMS) proxy adjunct is implemented to make extensions to messages according to any protocol providing a session description protocol (SDP) component, such as SIP or RTSP, so as to ensure the selected QoS.
Abstract: A user equipment (UE) device (11) including a mobile terminal (MT) (11b 11b') coupled to a terminal equipment (TE) device (11a) including an IP Multimedia Subsystem (IMS) proxy adjunct (P+) for use by the TE (11a) in making multimedia service requests for IP communications with a desired end-to-end QoS, the end-to-end including the local connection and a network supporting QoS, e.g. an UMTS network (12) having as an extension of its packet-switched core network (12b) an IMS (12c) providing multimedia services with selected QoS. The IMS proxy adjunct (P+) is implemented to make extensions to messages according to any protocol providing a session description protocol (SDP) component, such as SIP or RTSP, so as to ensure the selected QoS. In addition, a mechanism is provided by which the MT (11b') informs the IMS (12c) when it has IMS proxy capabilities.