In this blog article we continue to analyze RTP and RTCP and we will see why Jitter Buffer is important and how it affects call quality.
As we saw in the previous article — SDP is not able to transfer media–this task is delegated to protocols such as RTP or RTSP.
RTCP (or Real Time Control Protocol) provides different levels of feedback about the ongoing RTP Stream.
The goal of RTCP is to provide information to the remote endpoint about the quality of service of the ongoing communication.
This is done by providing regular statistics about the amount of packets received, jitter, and packets lost (either via network or discarded by the jitter buffer). Continue reading
Media is another vital component of a Unified Communication system. Once signaling is in place and working between two endpoints, information about media capabilities can be transferred, eventually allowing for streaming audio, making video calls, or exchanging other information.
In this blog article we will analyze what technologies are used to transfer information about available media between endpoints.
SDP (Session Description Protocol) is a format for describing streaming media initialization parameters standardized by IETF in 1998.
What follows is the Session Description fields usage and an example:
This time we will talk about transport protocols over the web, in particular, about BOSH and WebSocket.
Besides TCP (XMPP/SIP) and UDP (SIP only) transports, two other transports, BOSH and WebSocket, are available which are embedded inside existing TCP/HTTP stacks.
Bidirectional-streams Over Synchronous HTTP (BOSH) allows real-time communication between a browser and a web server. The browser connects to the server and will keep the connection open as long as it has no data to send. When data is available, the server sends it over the open HTTP connection and closes the connection itself. This reduces the number of requests, as the browser is not continuously polling the server. The server retains a cache of events that the client missed between reconnections.
This is a phrase that we’re all familiar in the US. It means to slow down, relax or calm down. It means to think about things before you let your enthusiasm lead you too quickly down a path that can cause more harm than good. As a VAR, MSP, System Integrator or an ISP, we know that in the world of software updates this can simply mean… don’t blindly upgrade all systems at once. No matter how many developers there are or how many tests a company performs, new software releases can have issues that need to be addressed after the release. Perhaps it’s better to roll the software out in a controlled, planned and well thought out fashion.
However, this can be easier said than done. We’ve all been faced with the pressure from customers that want a new feature now or demand a fix for something that, in the long run, is nothing more than an irritant. Continue reading
In this blog article we will discuss the basic standards used for real-time communications — SIP and XMPP — what is the difference, how each of them works, and, which one to choose.
SIP and XMPP
The IETF has two documented standards for real-time communications that are widely implemented: SIP and XMPP.
These standards transport text information and rely on other standards for the actual media transmission.
As both support real-time communications, many question which solution is most suited to their needs.
Let’s briefly explore the history and purpose of both.