Page 353 - From GMS to LTE

VoLTE, VoWifi and Mission Critical Communication 339

After the device has received the Invite message it responds with a 100 Trying message
and prepares to receive the call. Once ready it sends a 180 Ringing message and thus
signals the caller that the user is alerted about the call. If the user accepts the call, a 200
OK message is sent over the two proxy servers to the calling party and both devices
activate the speech path and enable the loudspeaker and microphone. Which codec is
used depends on the codecs supported by each device. Codec negotiation is initiated by
the calling party by including a codec list in the Invite message. The other side then
selects a compatible codec from the list and informs the calling device during the call
establishment which codec it has selected.
While signaling messages always traverse the SIP proxies, the speech channel can be
established directly between the two devices. In practice, however, it is often the case
that both devices are behind a Network Address Translation (NAT) router and thus use
local IP addresses and UDP ports that are translated in the NAT routers into public IP
addresses and different UDP ports. A direct exchange of speech packets is thus only
possible if a device detects the address translation and is able to inform the other device
of the public IP address and UDP port to which the speech packets have to be sent. As
the public addresses are not visible to the User Agent it sends a number of probe mes-
sages to a STUN (Session Traversal Utilities for NAT) server on the Internet. The STUN
server receives the packet with the public IP address and UDP port that were generated
by the NAT router and returns those values to the User Agent. The UA then tries to find
a rule for how the private UDP port is mapped to its public counterpart and then uses
that knowledge to determine the likely UDP port number used during a call establish-
ment. Unfortunately there are quite a number of different NAT implementations to be
found in practice and it is thus not always possible to find a rule. This is why SIP provid-
ers often use media gateways. Instead of direct interaction between the two devices,
each device sends its media stream to the media gateway and receives the correspond-
ing stream from the other direction also from there. As communication to the media
gateway is initiated from the device there is no need to detect the mapping between
internal and external UDP port numbers.
Independent of whether there is a direct connection between devices or whether the
connection uses a media gateway the Real‐time Transport Protocol (RTP) is used for
transporting the voice data. It is specified in RFC 3550 [4]. In fixed‐line SIP implemen-
tations the G.711 codec is mostly used; it is also used in circuit‐switched networks. If
supported by both devices the G.722 wideband codec is preferred as it offers much
better voice quality. Both codecs transmit at a rate of 64 kbit/s and packets are split into
chunks of 20 ms that are then transmitted over UDP. With the protocol overhead this
results in a datarate of around 100 kbit/s in each direction. It should be noted at this
point that the G.722 wideband codec is not compatible with the G.722.2 wideband
codec used in cellular networks as the datarate of this codec is only 12.2 kbit/s. Wideband
calls between fixed and wireless networks can thus only be made by transcoding from
one wideband codec to the other on a gateway in the network. Figure 5.4 shows how the
list of speech codecs is sent to the other subscriber in a SIP Invite message. The list is
part of the Session Description Protocol section specified in RFC 4566 [5].
In addition to looking up the IP address of a destination subscriber and forwarding
messages to them or to other proxies, proxies are also allowed to modify messages. If,
for example, a user is already busy in another call and thus rejects another Invite request,
the SIP proxy can replace the incoming Busy message and generate another Invite