MGCP and application mgcpapp

[ciscoforum]

I just want to what exactly mcgcpapp does.

I thought if I didn't apply application mgcpapp on the dialpeer, call will not succeed in and out in SRST mode. But I tested it still works even remove then application mgcpapp.1760 :c1700-ipvoice-mz.123-8.T.bin

Here is my partial config

ccm-manager fallback-mgcp

ccm-manager redundant-host 10.253.21.33

ccm-manager mgcp

ccm-manager music-on-hold

!

interface Serial0/0:23

no ip address

no logging event link-status

isdn switch-type primary-ni

isdn incoming-voice voice

isdn outgoing display-ie

no cdp enable

call application alternate DEFAULT

mgcp

mgcp call-agent 10.253.21.34 service-type mgcp version 0.1

mgcp dtmf-relay voip codec all mode cisco

dial-peer voice 1 pots

destination-pattern 9T

incoming called-number .

direct-inward-dial

port 0/0:23

!

!

call-manager-fallback

max-conferences 4

ip source-address 10.253.22.49 port 2000

max-ephones 4

max-dn 16

dialplan-pattern 1 6464235... extension-length 4

I shutdown the wan link, now

R1760#sh ccm

MGCP Domain Name: R1760

Priority Status Host

============================================================

Primary Down 10.253.21.34

First Backup Down 10.253.21.33

Second Backup None

R1760#sh ephone

ephone-1 Mac:000D.BCE9.73DD TCP socket:[2] activeLine:0 REGISTERED

mediaActive:0 offhook:0 ringing:0 reset:0 reset_sent:0 paging 0 debug:0

IP:10.253.22.51 50357 Telecaster 7940 keepalive 19 max_line 2 dual-line

button 1: dn 2 number 5001 CM Fallback CH1 IDLE

I still can make inbound and outbound call.

It's weird. Any idea?

Thanks

[allan.thomas]

All dial plan related configuration elements that are controlled by Cisco CallManager should not be configured in the MGCP gateway for MGCP-managed endpoints.

For your information the MGCPAPP statement binds the MGCP application to particular voice ports, these will typically be your FXS and FXO endpoints. When you configure these endpoints through CCM, the MGCPAPP command will be created when the config is downloaded from CallManager.

Hope this helps

Allan.

[ciscoforum]

Thanks for your answer. So MGCPAPP is not needed for PRI. But I have done a lot of projects using auto download, it also auto generates the following commands for PRI.This really confuses me.

dial-peer voice 9991000 pot/app mgcpapp/voice-port 2/0:23

And I recall before if no mgcpapp under the dial-peer when in srst mode, the call won't work. Thanks

[Aaron Harrison]

When you are in SRST mode your router is effectively working as a H323 gateway - so the mgcpapp command isn't effective at that point.

In order to make calls through your PRI in SRST mode you will need normal H323 dial-peers configured to route calls as you wish, so:

dial-peer voice x pots

destination-pattern 9T

port 2/0:23

Would send all calls prefixed 9 out your PRI.

[ciscoforum]

Actually guys, just for your information. I found out that if I removed the coming called-number . , the incoming call will not work.You'll get a 2nd dialtone when call go in the GW(more like you don't have direct inward digit command). So now the conclustion is: there are two ways to make MGCP srst work,

1. use application mgcpapp and call application alternate default

or

2. Just use incoming called-number . without app mgcpapp and call application alternate default.

Though I never seen Cisco uses 2nd way for SRST mode in MGCP.

[allan.thomas]

As previously mentioned, and to avoid confusion, when the MGCP PRI Backhaul (signalling) fails to establish with the CallManager, the gateway falls-back to SRST H323 mode.

For your information, I have come across various versions of IOS where incoming called number . fails, and hence direct-inward-dial is used.

Below is an example of MGCP Config with SRST:

ccm-manager fallback-mgcp

ccm-manager redundant-host 192.168.2.1

ccm-manager mgcp

ccm-manager music-on-hold

ccm-manager config server 192.168.2.1

ccm-manager config

mta receive maximum-recipients 0

!

!

controller E1 1/0

pri-group timeslots 1-31 service mgcp

!

interface FastEthernet0/0

ip address 192.168.1.1 255.255.255.0

speed 100

full-duplex

!

interface Serial1/0:15

no ip address

no logging event link-status

isdn switch-type primary-net5

isdn incoming-voice voice

isdn bind-l3 ccm-manager

no cdp enable

!

call application alternate DEFAULT

!

voice-port 1/0:15

!

mgcp

mgcp call-agent 192.168.2.1 2427 service-type mgcp version 0.1

mgcp dtmf-relay voip codec all mode out-of-band

mgcp rtp unreachable timeout 1000 action notify

mgcp package-capability rtp-package

mgcp package-capability sst-package

no mgcp timer receive-rtcp

mgcp sdp simple

mgcp fax t38 inhibit

mgcp rtp payload-type g726r16 static

!

mgcp profile default

!

!

!

dial-peer cor custom

!

dial-peer voice 9999 voip

incoming called-number .

dtmf-relay h245-alphanumeric

no vad

!

dial-peer voice 1000 pots

incoming called-number .

destination-pattern 9T

direct-inward-dial

port 1/0:15

!

call-manager-fallback

ip source-address 192.168.1.1 port 2000

max-ephones 144

max-dn 144

[maharris]

This is made even more confusing because there appears to be different default behaviours for DID on different platforms and T1 connections - Note: On Cisco 2600/3600 platforms, DID is enabled by default on CAS (immediate, wink, delay) interfaces. Therefore, do not configure the direct-inward-dial command for incoming calls. On Cisco AS5300 platforms, DID is not supported on interfaces configured for E & M immediate signaling.

http://www.cisco.com/en/US/tech/tk652/tk653/technologies_tech_note09186a00801142f8.shtml

So, on CAS it is on by default, and on PRI you have to configure it. Once you have it on, you have to make sure the right dial peer is matched to invoke it, and that is where the incoming called number . comes in, to force the match on the inbound peer. If you have application mgcpapp on your regular peers, those will be used as long as the link to the CM is up - but once the router notices that is gone, the application mgcpapp is no longer active, and so those peers are dead, so he will look for another way to handle the calls, which will be the call application alternate DEFAULT (which means H323).

Mary Beth

[jaywydra]

FYI on the MGCPAPP command. I had a case with TAC a couple of months back. We had a problem where MGCP got hung up every now and then. We had to do a "no mgcp" and then re-enter the MGCP commands to get funtionality to work again. Also, rebooting the router worked too. Turns out that Cisco told me that I should NOT have the MGCPAPP command on my pots dial peers. They showed me some documention supporting this. I've also seen other documents on TAC that tell you to configure the POTS peers with MGCPAPP. So, conflicting documents are on CCO. They told me they were going to remove the docs that said to configure MGCPAPP on the pots peers. Anyway, when I removed the MGCPAPP commands we no longer had issues with MGCP hanging up.

Jason

[JOSE TORRES]

Just want to throw in a final two cents, the PRI control being done by callmanager and mgcp is majorly influenced when doing SRST by two commands.

Under the serial interface,:

isdn bindl3 ccm-manager

this tells the router that this PRI layer 3 is being controlled by ccm-manager

under ccm-manager you have:

ccm-manager mgcp

this tells it to use mgcp for gateway protocol control.

There is also another command that you have there ccm-manager fallback-mgcp

This commnands tells the router that when it loses communications to any callmanager reconfigure to be an h.323 gateway.

It does this by quite literally removing the isdn bind-l3 ccm-manager command on the fly.

Therefore making the interface h.323 and then your dial peers take effect.

With FXO and FXS you need the application mgcpapp command so that the interfaces show up as mgcp endpoints.

[eloy.chio]

My 2 Cents,

Below is a config that I have used and has worked great. A practice I always follow is disable downloading the config from Call Manager when using MGCP. I manually create the MGCP dial-peers manually with a Low Tag #. You would normally need the following for Dial-Peers when the Router is being controlled by Call Manager via MGCP.

Example...

dial-peer voice 1 pots

application mgcpapp

direct-inward-dial

port 1/0:23

When being in SRST, since the router is no longer being controlled by CCM, you need to define H323 Dial-Peers. Below I have provided some examples.

dial-peer voice 2 pots

destination-pattern 911

port 1/0:23

prefix 911

!

dial-peer voice 3 pots

destination-pattern 9911

port 1/0:23

prefix 911

!

dial-peer voice 4 pots

destination-pattern 9[2-9]......

port 1/0:23

!

dial-peer voice 5 pots

destination-pattern 91[2-9]..[2-9]......

port 1/0:23

prefix 1

!

dial-peer voice 6 pots

incoming called-number .

direct-inward-dial

port 1/0:23

Complete Config Ex...

isdn switch-type primary-ni

voice rtp send-recv

no voice hpi capture buffer

no voice hpi capture destination

ccm-manager fallback-mgcp

ccm-manager redundant-host X.X.X.X

ccm-manager mgcp

ccm-manager music-on-hold

controller T1 1/0

framing esf

linecode b8zs

pri-group timeslots 1-12,24 service mgcp

interface Serial1/0:23

no ip address

no logging event link-status

isdn switch-type primary-ni

isdn incoming-voice voice

isdn bind-l3 ccm-manager

no isdn incoming alerting add-PI

no cdp enable

call application alternate DEFAULT

voice-port 1/0:23

echo-cancel coverage 32

mgcp

mgcp call-agent X.X.X.X 2427 service-type mgcp version 0.1

mgcp dtmf-relay voip codec all mode out-of-band

mgcp rtp unreachable timeout 1000 action notify

mgcp package-capability rtp-package

no mgcp package-capability res-package

mgcp package-capability sst-package

no mgcp package-capability fxr-package

no mgcp timer receive-rtcp

mgcp sdp simple

mgcp fax t38 inhibit

mgcp rtp payload-type g726r16 static

mgcp bind control source-interface FastEthernet0/0

mgcp bind media source-interface FastEthernet0/0

mgcp profile default

dial-peer voice 1 pots

application mgcpapp

direct-inward-dial

port 1/0:23

dial-peer voice 2 pots

destination-pattern 911

port 1/0:23

prefix 911

dial-peer voice 3 pots

destination-pattern 9911

port 1/0:23

prefix 911

!

dial-peer voice 4 pots

destination-pattern 9[2-9]......

port 1/0:23

dial-peer voice 5 pots

destination-pattern 91[2-9]..[2-9]......

port 1/0:23

prefix 1

dial-peer voice 6 pots

incoming called-number .

direct-inward-dial

port 1/0:23

call-manager-fallback

timeouts interdigit 4

ip source-address X.X.X.X port 2000 strict-match

max-ephones 48

max-dn 48

dialplan-pattern 1 444.... extension-length 4

transfer-pattern 9444....

default-destination 1200

voicemail XXXXXXXX

date-format dd-mm-yy

[maharris]

I have two more cents to add : ) I remembered a site where we had PRI problems where we had to do the no mgcp/mgcp to bring it back - and then I noticed that when we reloaded and/or synched the config with cm (we had turned config sync off for srst issues) that the dial peer for the ISDN D channel did not come back - all the other (analog port) pots peers get built by the CM config download, and CM adds the application mgcpapp to those, and I am(pretty) sure the PRI used to get one too - when we first noticed that it was missing, we were adding it back in, but then we noticed that it worked without it, and quit doing that - and have not had to do the no mgcp/mgcp on that gateway since. So, it seems like the d channel backhaul definitely takes care of the CM control.

Mary Beth

[ciscoforum]

OK. let me this question simply:

application mgcpapp is used when in mgcp mode or in srst mode? inbound or outbound?

I tested in both mgcp and srst mode, t1 PRI can work both way(make or receive call) without this mgcpapp command. This confuses me , then why need mgcpapp. This is what I want to know.

Thanks guys

[maharris]

I think Jose above is correct - the mgcpapp is needed in pots peers for analog ports, and T1 CAS, and that makes the MGCP application be in control of things (both in and out) while MGCP link is up to the callmanager. When the MGCP link goes down, then if you have configured the fallback and the application alternate, the h323 peers will take over (if you have any), or else there is some other behaviour you can define under the fallback section, that does not always behave as you think it will. If you have a PRI, and it is an MGCP gateway and you have backhauled the d channel, then there is no need for the dial peer with mgcpapp, since the backhaul takes care of the conversation with the call manager. When that link goes down, the backhaul disappears, and h323 peer will take over.

Mary Beth

[ciscoforum]

This looks good. I'll test CAS and FXO to verify the difference between them and PRI.Thanks.