It is important to understand now the difference between a transaction and a dialog. A transaction occurs between a user agent client and a user agent server and comprises all messages from the first request to the final response. The responses can be provisional starting with 1 followed by two digits (e.g. 180 Ringing) or final starting with 2 followed by two digits (e.g. 200 OK). The scope of a transaction is defined by the stack of VIA headers of the SIP messages. So, the user agents, after the initial invite, don't need to rely on DNS or location tables to route the messages.
A dialog usually starts with an INVITE transaction and ends with a BYE transaction. A dialog is identified by the CALL-ID header field. A combination of the TO tag, the FROM tag, and the Call-ID completely defines the dialog.
According to RFC 3665 there are 11 basic session establishment flows. The list is not meant to be complete, but covers the best practices. The first two were already covered in this chapter, "Successful Session Establishment" and 'Session Establishment Through Two Proxies". Some of them will be seen in the chapter dedicated to call forwarding such as "Unsuccessfull with no Answer" and "Unsuccessful Busy".
The Real Time Protocol (RTP) is responsible for the real-time transport of data such as audio and video. It was standardized in RFC3550. It uses UDP as the transport protocol. To be transported, the audio or video has to be packetized by a codec. Basically, the protocol allows the specification of timing and content requirements of the media transmission for the incoming and outgoing packets using:
Sequence number
Timestamps
Packet forward without retransmission
Source identification
Content identification
Synchronism
The RTP has a companion protocol called RTCP (Real Time Control Protocol) used to monitor the RTP packets. It can measure the delay and jitter.
The content described in the RTP protocol is usually encoded by a codec. Each codec has a specific use. Some have compression while others don't. The G.711 codec, which does not use compression, is very common. With 64Kbps of bandwidth for a single channel it needs a high speed network, commonly found in Local Area Networks (LANs). However, in Wide Area Networks (WAN) 64Kbps can be too expensive to buy for a single voice channel. Codecs such as G.729 and GSM can compress the voice packets to as low as 8Kbps saving a lot of bandwidth. Some codecs such as the iLBC from Global IP sound can conceal packet loss. The iLBC can sustain a good voice quality even with 7% packet loss. So you have to choose the codecs you will support in your VoIP provider wisely.
In some cases the RTP protocol is used to carry signaling information such as DTMF. RFC2833 describes a method to transmit DTMF as named events in the RTP protocol. It is very important that you use the same method between user agent servers and user agent clients.
The SDP protocol is described in RFC4566. It is used to negotiate session parameters between the user agents. Media details, transport addresses, and other media-related information are exchanged between the user agents using the SDP protocol. Normally the INVITE message contains the SDP offer message, while the "200 OK" contains the answer message. Below these messages are shown. You can observe that the GSM codec is offered, but the other phone does not support it. Then it answers with the supported codecs, in this case G.711 ulaw (PCMU) and G.729. The session rtpmap:101 is the DTMF-relay described in the RFC2833.
INVITE (SDP Offer).
200 OK (SDP Answer).
