Call Establishment Using MEGACO

Based on the foregoing
high-level descriptions, we are in a position to describe how a basic call can
be established using MEGACO. Figure 8-13 shows a scenario where a call
is to be established between two terminations, T1 and T4, which reside on
two different MGs. In this example, the two MGs are controlled by the same
MGC.
The MGC has determined, through call control signaling (not shown),
that a call needs to be established between termination T1 on MG-A and
termination T4 on MG-B. It first requests MG-A to add T1 to a new context.
The fact that it is a new context is indicated by the $ wildcard. It also
requests that the MG create a new ephemeral termination (indicated by the
wildcard associated with the second Add command) and add that termination
to the same context. The MGC specifies that the new termination
should be able to receive media from the far end, but not send media to the
far end. This is reasonable, because the MG has not yet received any information
as to where the media should be sent.
The MGC also makes a suggestion as to the media coding that the new
termination should use. This can be seen in the local descriptor, which contains
an SDP description. In this example, the suggestion is that the new
termination use audio coded according to AMR and use the dynamic RTP
payload type value of 98. Note that the MGC has not specified any IP
address or port number, as these are associated with a termination that
MG-A has yet to create. Note also that the session description provided by
the MGC is merely a suggestion. The MGC is not required to suggest any
format. If it does suggest a format, then the MG should comply with that
suggestion if possible, but it does not have to.
MG-A responds to the MGC using the same transaction ID. It indicates
that it has created a new context with ContextID
1001. It has added termination T1 to the context as requested. It has also created termination
T2 and added it to the same context. Associated with termination T2 is an
SDP session description. Unlike the suggested session description received
from the MGC, this session description (included in the local descriptor)
includes an IP address (311.311.1.1) and port number (1199) at which termination
T2 expects to receive the RTP stream.
The MGC now requests MG-B to set up a new context and to add two terminations
to that context—termination T4 and a new termination that
MG-B must create. For the new termination, the MGC makes a suggestion
as to the content of the local descriptor. It also specifies the exact content of
the remote descriptor. Although the information for the local descriptor is
simply a suggestion, the information in the remote descriptor is what the
new termination must use. The content of the remote descriptor is, after all,
the content of the local descriptor for termination T2 on MG-A. In other
words, the local descriptor specifies which media format the new termination
should send and where it should send it.
Note the use of the local control descriptor. In this case, the MGC specifies
that the mode should be send-receive. This is because the far end is
ready to receive RTP packets and will soon know where to send them, even
though it does not know that quite yet.
MG-B creates the new context (Context ID
2002) and adds termination
T4 to that context. It also creates termination T3 and adds it to the context.
For the new termination, it specifies a local descriptor, which includes
the media format it wants to receive, and the address and port number to
which the packets should be sent.
The MGC takes the local descriptor information related to termination
T3 and, using the Modify command, sends it to MG-A as a remote descriptor
for termination T2. It also specifies the mode for termination T2 to be
send-receive. Termination T2 now knows where to send RTP packets and
has permission to send them.
The chain is now complete.Terminations T1 and T2 are in the same context,
so a path exists between them across MG-A. Equally, terminations T3
and T4 are in the same context, so a path is created between them across
MG-B. Finally, T2 and T3 have established a bidirectional RTP stream
between them. Thus, a path is available from T1 to T4, as originally
intended.