Configure Mediant MGCP
IMPORTANT: All Mediant gateways support a single active MGCP Call Agent at a time (although it may have backups). It is not possible to have multiple controllers each for part of the circuits. Therefore for flexibility it is desirable to have several smaller gateways rather than a big one.
Contents |
Mediant configuration
It is possible to configure a Mediant gateway either from the Web interface or by editing the BOARD.ini configuration file (accessible from the Management menu).
The settings layout here apply to Mediant firmware version 5.80, other versions may differ. Version 4.x had a radically different layout.
Please make sure you select Full view mode (not Basic) or you will not find all settings described here.
TDM Trunk configuration
First settings that you are going to make are the boards. This setting is common for everything using the trunk, voice or signaling.
From the Configuration menu select PSTN Settings => Trunk Settings. For each trunk you configure for SS7/MGCP select Protocol Type => E1 transparent 31.
You may need to reboot the Mediant to activate changes to the board configuration so be sure to select the correct line parameters.
Protocol configuration
From the Configuration menu select Protocol Configuration.
- Protocol Selection => MGCP (x)
- Basic Configuration
- Call Agent IP => a.b.c.d (IP of the Yate server)
- Call Agent Port => 2727
- Gateway MGCP Port => 2427
- General Parameters
- Version => MGCP 1.0
- Send RSIP on Network Disconnection => Yes
- Advanced Configuration
- Enable Keep Alive => Enable
- Keep Alive Interval [sec] => 60
- Activate all Channels on Board Initialization => No
One setting that is not available from Web must be accomplished by editing the config file. You have to set the gateway name and add the MGCP port at end of it.
[ControlProtocols Params] GatewayName = 'mediant:2427'
You can set another name but remember to change it in the host=... lines of mgcpca.conf
Yate configuration
In Yate you will need one or more sections in mgcpca.conf plus some global engine settings:
[engine] request_ack=no send_provisional=no ;port=2727 ;address=0.0.0.0 [endpoint] ; defaults are OK [gw TRUNK_1] host=mediant user=ACgw1 version=MGCP 1.0 ;address=w.x.y.z ;port=2427 voicechans=2-31 offset=1 forward_rtp=yes ;forward_sdp=yes [gw TRUNK_2] host=mediant user=ACgw31 version=MGCP 1.0 ;address=w.x.y.z ;port=2427 voicechans=1-31 offset=1 forward_rtp=yes ;forward_sdp=yes
In the engine section it is possible to change the MGCP Call Agent port from the default of 2727. In case you need to bind to a specific local address (on the Yate machine) it can be specified there too. It is not possible to bind to more than one address and one port.
For each trunk the section name must start with gw, a space and the trunk name as referred from the call controller voice= setting in ysigchan.conf:
[SOME NAME] type=ss7-isup voice=TRUNK_1,TRUNK_2
The user part of the Endpoint Identifier must be set according to Mediant. This has two forms, depending on settings:
- Analog naming (default) - sequentially numbered circuits, ACgw0 - ACgwNNN
- Trunk naming (similar to Cisco) - trunk number is part of the name
The voicechans setting must match the voice timeslots. For each entry in range a voice circuit is created.
Note that in Analog naming the E1 synchronization timeslots are skipped so it's possible to define a large trunk encompassing all circuits in multiple E1 or T1 ports. For flexibility it is desirable to keep each trunk separate so they can be activated or deactivated.
For each trunk you should specify the IP address of Mediant (the w.x.y.z) so Yate doesn't have to wait a RSIP message. You may also specify the port if it's not the default 2427.
The forward_rtp setting allows a setup where RTP media is sent directly between the Media Gateway and the other endpoints, be them other gateways or SIP devices. This is very desirable for traffic but pay attention that Mediant gateways' RTP does not deal with NAT.
The forward_sdp setting enables the entire SDP of the MGCP connection to be passed unchanged. This allows using non-standard features but prevents any manipulation of the RTP session like limiting the codecs.
