In contrast to H.323, SIP was developed by the IETF (Internet Engineering Taskforce) with the Internet in mind and is therefore oriented towards the architecture of common Internet applications.
From the beginning, attention was paid to easy implementability, scalability, expandability and flexibility. SIP can be used to manage any number of sessions with one or several participants. However, it is not limited to Voice over IP as sessions can be any number of multimedia streams or conferences.
The security standard SIPS not only prevents eavesdropping and message manipulation, but also ensures the proxy server about the identity of the snom client phone and protects against identity spoofing.
Through the use of AES (Advanced Encryption Standard) in the counter mode for secure RTP one single key stream emerges for each RTP packet, which makes it practically impossible to retrieve an original RTP stream and abuse it.
To make an Internet phone call, you need more than just SIP, because it only serves to agree or negotiate the communication modalities - the actual data for the communication must be exchanged via other, suitable protocols. The Session Description Protocol (SDP, RFC 4566, the translation from the English "Session Description Protocol" is not commonly used) is often embedded in SIP to negotiate the details of the video and/or audio transmission. The devices tell each other which methods of video and audio transmission they master (the so-called codecs), with which protocol they want to do this and at which network address they want to send and receive.
This media negotiation is therefore not a direct component of SIP, but is achieved by embedding another protocol in SIP. This separation of session and media negotiation is one of the advantages of SIP, as it allows great flexibility in the supported payload: For example, if a manufacturer wants to use SIP for a specialized application, they can design their own media negotiation if no protocol exists yet.
Internet telephony uses the Real-Time Transport Protocol (RTP, RFC 3550) for media transmission. SIP negotiates the session, the embedded SDP negotiates the media details, and RTP is the protocol that finally transmits the video and audio streams.
Subscriber addresses are written in URI format, which is also used in e-mails and WWW addresses. Such a subscriber address usually follows one of the following three schemes:
By separating session and media, both data streams can also be encrypted independently of each other. SIP can be encrypted using the TLS protocol , also called SIPS , and the media stream (voice data) can also be encrypted using the SRTP protocol. Any combination of these is possible, but does not make sense in terms of secure encryption.
For secure encryption, both data streams (session and media) must be encrypted simultaneously. The symmetric keys of the media stream are exchanged via SDP (i.e. SIP) and could therefore be attacked via an unencrypted SIP. The symmetric keys of TLS are exchanged at the beginning of the session, but the mechanisms of SSL certificates, in which the symmetric keys are encrypted by the asymmetric keys of the SSL certificates, also take effect here.
Since transmission via a connectionless network protocol makes more sense with SIP, a UDP-based counterpart to TLS , which is based on TCP, was designed with DTLS. However, it is currently only implemented by a SIP stack (ReSIProcate).
SIP UA registration on SIP registrar with login authentication
Call flow through redirect server and proxy
Establish a connection with the B2BUA
→ main article: SIP status codes
The clients and servers involved in a SIP session send requests and answer them using response codes.
Preliminary status information that the server is performing further actions and therefore cannot yet send a final response.
The request was successful.
These messages inform about a new contact address of the called party or about other services that enable the connection to be established successfully.
The previous message could not be processed.
A server involved in the transmission could not process a message.
The server was contacted successfully, but the transaction does not take place.