== AoIP message flow examples

The flow diagrams / ladder diagrams of this section are intended to
provide some examples on how AoIP procedures work.  We hope they will be
useful in understanding the interface better and aid in debugging any
related issues.

=== AoIP interface bring-up

This Figure shows the exchange of messages of a BSC when it is
establishing its AoIP interface from scratch, for example because it has
just been started up.  We assume the BSC/CN has already been fully
brought up, so no SCTP/M3U*A bring-up between MSC and STP is dieplayed.

The diagram shows only one possible scenario.

Depending on the MSC implementation, in between the BSC and the MSC
there may be either

* a dedicated STP (or multiple replicated STPs)
* no dedicated STP, as the functionality is implemented inside the MSC
* an entire SS7 network between BSC and MSC, with multiple STP, SGW,
  elements switching messages from the BSCs to the MSCs.

The configuration details that need to be known to the BSC at start-up
time are:

* at SCTP level
** remote IP addresses to which it should establish a SCTP association
** SCTP port number for M3UA at the STP
* at M3UA level
** routing key (0 for none)
** local BSC-side SS7 point code
** remote MSC-side SS7 point code

There possibly may be more configuration details, such as

* multiple local and/or remote IP addresses for SCTP multi-homing
* a fixed local (BSC side) IP address and/or SCTP port (default:
  dynamic/random)

.AoIP interface bring-up between BSC and MSC
[mscgen]
----
include::../message-sequences/a_interface_bringup.msc[]
----

For the purpose of clairty, SCTP-level acknowledgement chunks are not
shown.  Those are automatically generated by the receiver for every
DATA chunk received in order to confirm its reception and to allow the
transmitter to re-transmit in case of packet loss.

==== SCTP multi-homing

If SCTP multi-homing is used, the additional IP addresses are typically
exchanged via additional information elements in the INIT/INIT_ACK
chunks at connection establishment.  They may also change at a later
point.

==== MSC pooling

If there is MSC pooling configured, there is typically still only one
M3UA ASP / SCTP association.  The different MSCs are addressed on the
SCCP point-code level.  It's the STPs job to route the messages based
on point codes to the respective MSC.

The BSC will try to establish BSSAP to each of the MSCs in the pool,
using a separate BSSAP reset procedure to each of the pool members
point code.

See the Chapter _MSC Pooling_ in the OsmoBSC user manual for
configuration examples of this situation.


=== MO call establishment on AoIP with user plane

The following figure shows a simplified version of the messages between
MS, OsmoBTS, OsmoBSC, OsmoMGW@BSC, MSC[-Server] and MSC-MGW in during
the establishment and release of a MO voice call.  Particular focus
is given on messages related to the establishment of the RTP based
user plane.

The fact whether or not the RAN or the CN use media gateways, how they
control their respective media gateway, and whether there are multiple
media gateways for load distribution is a private implementation detail
of either RAN or CN.  Either side does not need to know the
internal structure of the other side, since the RTP endpoint parameters
are signaled for each call individually over the A interface.

The signaling between the BSC-colocated MGW and OsmoBSC is IETF MGCP
(Media Gateway Control Protocol).

The signaling between the MSC[-Server] and the MGW is internal to the
CN. It is typically based on MEGACO/H.248.

As only the BSC and the MSC exchange 3GPP specified signaling messages,
there is no direct interaction between the RAN and the CN side MGW.
They only exchange RTP and associated RTCP.

In many real deployments, OsmoMGW will have a different IP address on
the BTS/Abis facing interface than on the MSC/A facing interface.  As
a simplification, this has been omitted in the figure.

[mscgen]
----
include::../message-sequences/mo_call-bsc-msc-mgw-aoip.msc[]
----