Brief Tutorial of the SIP Signaling and SDP Media Protocols
| Note | The features and/or parameters listed in this article may not be available from your telephone service provider. |
|
|
|
|
|
Introduction
The VoIP Switch administrators, operators and supporters find here information about the Session Initiation Protocol SIP and Session Description Protocol SDP.
Basic knowhow about connection signalization with Session Initiation Protocol SIP:
Basic knowhow about media (speech) transmission with Session Description Protocol SDP:
Contents
Knowhow Connection Signaling with "Session Initiation Protocol SIP"
The Session Initiation Protocol SIP is a communications protocol for signaling and controlling multimedia communication sessions. One of the most common applications of SIP is in Internet telephony for voice and video calls.
For an extended overview of the SIP protocol visit:
Basics: Session Session Protocol SIP
Example of a "SIP dialog" with the minimal needed messages for a connection setup or connection renegotiation:
Example of a "SIP dialog" with the minimal needed messages for a connection release:
Examples: SIP Signaling Flows
Example of a regular outgoing call into the PSTN:
Example of a regular incoming call from the PSTN:
Example of an outgoing call into the PSTN with three exceptional signaling situations:
- The PSTN Gateway 1 doesn't respond so the VoIP Switch has to re-route to the PSTN Gateway 2
- The telephone on side A offers an invalid "Session Time" value which is refused by the PSTN Gateway 2. The telephone on side A has to do a reINVITE with an acceptable "Session Time" value.
- End point B is busy.
Example of a connection where the VoIP Switch checks the presence of the end points with OPTION messages. The VoIP Switch would release the connection if one end point doesn't respond with "200 OK":
SIP Response Codes
A list of SIP response codes and their meaning can be found here:
Most Important 1xx—Provisional Responses
100 Trying
Extended search being performed may take a significant time so a forking proxy must send a 100 Trying response.
180 Ringing
Destination user agent received INVITE, and is alerting user of call.
183 Session in Progress
This response may be used to send extra information for a call which is still being set up.
Most Important 2xx—Successful Responses
200 OK
Indicates the request was successful.
Most Important 3xx—Redirection Responses
302 Moved Temporarily
The client should try at the address in the Contact field. If an Expires field is present, the client may cache the result for that period of time.
Most Important 4xx—Client Failure Responses
400 Bad Request
The request could not be understood due to malformed syntax.
401 Unauthorized
The request requires user authentication. This response is issued by UASs and registrars.
403 Forbidden
The server understood the request, but is refusing to fulfil it.
404 Not Found
The server has definitive information that the user does not exist at the domain specified in the Request-URI. This status is also returned if the domain in the Request-URI does not match any of the domains handled by the recipient of the request.
406 Not Acceptable
The resource identified by the request is only capable of generating response entities that have content characteristics but not acceptable according to the Accept header field sent in the request.
408 Request Timeout
Couldn't find the user in time. The server could not produce a response within a suitable amount of time, for example, if it could not determine the location of the user in time. The client MAY repeat the request without modifications at any later time.
410 Gone
The user existed once, but is not available here any more.
480 Temporarily Unavailable
Callee currently unavailable.
486 Busy Here
Callee is busy.
487 Request Terminated
Request has terminated by bye or cancel.
488 Not Acceptable Here
Some aspect of the session description or the Request-URI is not acceptable.
Most Important 5xx—Server Failure Responses
503 Service Unavailable
The server is undergoing maintenance or is temporarily overloaded and so cannot process the request. A "Retry-After" header field may specify when the client may reattempt its request.
Most Important 6xx—Global Failure Responses
603 Decline
The destination does not wish to participate in the call, or cannot do so, and additionally the destination knows there are no alternative destinations (such as a voicemail server) willing to accept the call.
Knowhow Media Stream Signaling with "Session Description Protocol SDP"
The Session Description Protocol SDP describes how during a connection setup the end points negotiate the parameters of this exchange as session announcement, session invitation, and parameter. SDP does not deliver media itself but is used between end points for negotiation of media type, format, and all associated properties for voice, Fax, DTMF, bit transparent data etc..
For an extended overview of the SDP protocol visit Wikipedia.
| Note |
The VoIP Switch doesn't interfere in the SDP negotiation of the end points! There may be exceptions for certain Customer Premises Equipment CPE devices where interoperation problems are known. Check with the VoIP switch administrator which CPE devices are known with SDP manipulations by the VoIP switch. |
Basics: Session Description Protocol SDP
The SDP is embedded in the SIP messages during connection setup or connection renegotiation:
The following SDP properties and parameters are important for supporting customer problems:
Example of a SDP offer from the calling side A:
Example of a SDP answer from the called side B:
Example of a SDP offer for a Fax transfer with T.38 from the calling side A:
Interpretation of the "Media Attributes":
| Index | Type | Attribute | Remark |
| 0 | PCMU | ISDN G.711µlaw | Very good quality VoIP codec |
| 1 | PCMA | ISDN G.711alaw | Very good quality VoIP codec |
| 2 | G.726-32 | Good quality VoIP codec | |
| 18 | G.729 | Low quality VoIP codec | |
| 125 | x-clear-channel | data service bit transparent | Echo canceling will be switched off and the data bit by bit transferred |
| 101 | telephone-event | DTMF, RFC 2833 | DTMF will not be transferred inband but as RTP event according RFC 2833 |
| 18 | annexb=0 | Special information for codec with index 18 | Special directive for codec G.729 |
| 101 | 0-16 | Special information for for telephone-event with index 101 | 0-15 : DTMF character 0-9, *,#, A,B,C,D 0-16 : DTMF character 0-9, *,#, A,B,C,D, Flash |
Basics: RTP/RTCP
The Real Time Protocol RTP is used to transfer media data, e.g. speech in VoIP based telephony.
The Real Time Control Protocol RTPC transfers periodically statistical media data between the peers of a connection.
If RTP packets are lost, delayed or jitter then we speak of a Quality of Service QoS problem. For the support it is of interest to know if the number of transferred packets between the peers of a connection and if the numbers in the receive and send paths are reasonable equal, if packets were lost on call leg etc. With these statistical media information it can be possible to identify a path or transfer direction were QoS problems occure.
| Note |
The media stream must be proxied via the MediaServer of the VoIP Switch in order to compute statistical numbers of a connection. |
The Aarenet VoIP Switch supports RTP/RTCP statistic data collection of a connection. How they can be obtained is described in article "Manual of the Aarenet VoIP Switch Support Tools", chapter "The ConfigCenter Call Data"
Overview of "RTP/RTCP" information collection:
Details of "RTP/RTCP" information collection:
© Aarenet Inc 2018
Version: 3.0
Author: Aarenet
Date: May 2017
