1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
|
[[mncc]]
== MNCC for external Call Control
The 3GPP GSM specifications define an interface point (service access
point) inside the MSC between the call-control part and the rest of the
system. This service access point is called the MNCC-SAP. It is
described in _3GPP TS 24.007_ <<3gpp-ts-24-007>> Chapter 7.1.
However, like for all internal interfaces, 3GPP does not give any
specific encoding for the primitives passed at this SAP.
The MNCC protocol of OsmoNITB has been created by the Osmocom community
and allows to control the call handling and audio processing by an
external application. The interface is currently exposed using Unix
Domain Sockets. The protocol is defined in the `mncc.h` header file.
OsmoNITB can run in two different modes:
. with internal MNCC handler
. with external MNCC handler
=== Internal MNCC handler
When the internal MNCC handler is enabled, OsmoNITB will switch voice
calls between GSM subscribers internally and automatically based on
the subscribers __extension__ number. No external software is required.
NOTE: Internal MNCC is the default behavior.
==== Internal MNCC Configuration
The internal MNCC handler offers some configuration parameters under the
`mncc-int` VTY configuration node.
===== `default-codec tch-f (fr|efr|amr)`
Using this command, you can configure the default voice codec to be used
by voice calls on TCH/F channels.
===== `default-codec tch-h (hr|amr)`
Using this command, you can configure the default voice codec to be used
by voice calls on TCH/H channels.
=== External MNCC handler
When the external MNCC handler is enabled, OsmoNITB will not perform any
internal call switching, but delegate all call-control handling towards
the external MNCC program connected via the MNCC socket.
If you intend to operate OsmoNITB with external MNCC handler, you have
to start it with the `-m` or `--mncc-sock` command line option.
At the time of this writing, the only external application implementing
the MNCC interface compatible with the OsmoNITB MNCC socket was `lcr`,
the Linux Call Router.
=== MNCC protocol description
The protocol follows the primitives specified in 3GPP TS 04.07 Chapter
7.1. The encoding of the primitives is provided in the `openbsc/mncc.h`
header file, which uses some common definitions from
`osmocom/gsm/mncc.h` (part of libosmocore.git).
However, OsmoNITB MNCC specifies a number of additional primitives
beyond those listed in the 3GPP specification.
The different calls in the network are distinguished by their callref
(call reference), which is a unique unsigned 32bit integer.
==== MNCC_HOLD_IND
Direction: NITB -> Handler
A 'CC HOLD' message was received from the MS.
==== MNCC_HOLD_CNF
Direction: Handler -> NITB
Acknowledge a previously-received 'CC HOLD' message, causes the
transmission of a 'CC HOLD ACK' message to the MS.
==== MNCC_HOLD_REJ
Direction: Handler -> NITB
Reject a previously-received 'CC HOLD' message, causes the
transmission of a 'CC HOLD REJ' message to the MS.
==== MNCC_RETRIEVE_IND
Direction: NITB -> Handler
A 'CC RETRIEVE' message was received from the MS.
==== MNCC_RETRIEVE_CNF
Direction: Handler -> NITB
Acknowledge a previously-received 'CC RETRIEVE' message, causes the
transmission of a 'CC RETRIEVE ACK' message to the MS.
==== MNCC_RETRIEVE_REJ
Direction: Handler -> NITB
Reject a previously-received 'CC RETRIEVE' message, causes the
transmission of a 'CC RETRIEVE REJ' message to the MS.
==== MNCC_USERINFO_REQ
Direction: NITB -> Handler
Causes a 'CC USER INFO' message to be sent to the MS.
==== MNCC_USERINFO_IND
Direction: NITB -> Handler
Indicates that a 'CC USER-USER' message has been received from the MS.
==== MNCC_BRIDGE
Direction: Handler -> NITB
Requests that the TCH (voice) channels of two calls shall be
inter-connected. This is the old-fashioned way of using MNCC,
primarily required for circuit-switched BTSs whose TRAU frames are
received via an E1 interface card on the NITB machine.
==== MNCC_FRAME_RECV
Direction: Handler -> NITB
Enable the forwarding of TCHF voice frames via the MNCC interface in
NITB->Handler direction for the specified call.
==== MNCC_FRAME_DROP
Direction: Handler -> NITB
Disable the forwarding of TCHF voice frames via the MNCC interface in
NITB->Handler direction for the specified call.
==== MNCC_LCHAN_MODIFY
Direction: Handler -> NITB
Modify the current dedicated radio channel from signalling to voice, or
if it is a signalling-only channel (SDCCH), assign a TCH to the MS.
==== MNCC_RTP_CREATE
Direction: Handler -> NITB
Create a RTP socket for this call at the BTS/TRAU that serves this BTS.
==== MNCC_RTP_CONNECT
Direction: Handler -> NITB
Connect the RTP socket of this call to the given remote IP address and
port.
==== MNCC_RTP_FREE
Direction: Handler -> NITB
Release a RTP connection for one given call.
==== GSM_TCHF_FRAME
Direction: both
Transfer the payload of a GSM Full-Rate (FR) voice frame between the
NITB and an external MNCC handler.
==== GSM_TCHF_FRAME_EFR
Direction: both
Transfer the payload of a GSM Enhanced Full-Rate (EFR) voice frame
between the NITB and an external MNCC handler.
==== GSM_TCHH_FRAME
Direction: both
Transfer the payload of a GSM Half-Rate (HR) voice frame between the
NITB and an external MNCC handler.
==== GSM_TCH_FRAE_AMR
Direction: both
Transfer the payload of a GSM Adaptive-Multi-Rate (AMR) voice frame
between the NITB and an external MNCC handler.
==== GSM_BAD_FRAME
Direction: NITB -> Handler
Indicate that no valid voice frame, but a 'bad frame' was received over
the radio link from the MS.
|
