ACK method confirms that an entity has received a final response to an INVITE request. In its turn, BYE method signals termination of a dialog and ends a call.
Here is the example:
SIP INVITE method
Calls are started by means of the methods INVITE together with SDP (Session Description Protocol) which carry the information necessary to allow the endpoints of the calls to exchange audio in form of RTP (Real Time Protocol) packets.
Let’s see a typical call dialog: Continue reading “SIP INVITE method”
Understanding REGISTER method
SIP is a peer-to-peer protocol where the roles client – server and exchangeable depending on who starts a session. In reality most deployments foresee a process called registration (method: REGISTER) which allows a central server (registrar) to store the location of a SIP User-Agent.
A SIP Phone is a client to the central Unified Communication Platform (registrar) – and the UC platform is a client to the SIP Server of the operator (registrar).
Once the SIP Server gets to know the location of an SIP Client, it can deliver calls and other messages to it from other Clients connected to the same Server.
Analyzing SIP and SIP calls
This blog article will be dedicated to SIP and SIP calls. It is meant to provide an introduction for UC Engineers to the main headers and guide through the debugging of the most popular call scenarios that will be described in the next articles.
As we have seen in SIP and XMPP standards in Unified Communications and Media transfer in Unified Communications – SDP protocol, SIP (Session Initiation Protocol) and SDP-RTP have become the de facto replacement mode for traditional analog and digital lines provided by operators all over the world.
SIP is also the most popular signaling mode to handle VoIP calls.
Being able to understand SIP sessions has become for a Unified Communication Engineer as important as in the past for Telephony Experts to read signaling traces in Q.931 / Q.921 / DS1 / QSIG generated by T1 / E1 PRI – BRI ISDN lines.
Before Starting the Analysis
RTP, RTCP and Jitter Buffer
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 “RTP, RTCP and Jitter Buffer”