You won’t be able to do this with MGCP controlled port as it’s a client/server relation style of control. You’d need to have the control of the port transfer to IOS to make modifications to called number, or calling if this was your requirement, in the gateway. For this you’d need to use SIP or H.323, where the preferred these days would be SIP.
Using MGCP protocol for VG, digit strip will be from CUCM. As @Roger Kallberg mentioned you can try SIP or H323.
It is absolutely possible to use both protocols simultaneously. In CM you just configure a SIP trunk that points to the IP of the gateway and create a route pattern for the number you have on the FXO port.
In the gateway you remove the service mgcpapp from the dial peer and define a destination pattern for the directory number that you would send to the FXO. For a pots dial peer the default behaviour is to consume any digits that are specifically matched by the destination pattern, so the digit striping should by this be automatically solved for you. You would also need to define dial peers for the connection to/from your CM.
Went in and took the parts that where of interests from our gateway configuration template for you to use as a reference if you want.
voice service voip ip address trusted list ipv4 10.138.16.32 ;CPE Subscriber ipv4 10.138.16.33 ;CPE Subscriber ipv4 10.138.16.34 ;CPE Subscriber ;add as many line as there are CPE nodes in the CM cluster sip bind control source-interface GigabitEthernet0/0/0 bind media source-interface GigabitEthernet0/0/0 ! voice class codec 1 codec preference 1 g711ulaw codec preference 2 g711alaw codec preference 3 g729r8 codec preference 4 ilbc ! voice class e164-pattern-map 1 description E164 Pattern Map for called number to CUCM e164 +46555777T ! voice class server-group 1 ipv4 10.138.16.32 preference 1 ipv4 10.138.16.33 preference 2 ipv4 10.138.16.34 preference 3 description Inbound calls from PSTN to CUCM ! voice class sip-options-keepalive 1 description Used for Server Group SIP OPTIONS PING ! sip-ua g729-annexb override retry invite 2 timers trying 300 no remote-party-id ! controller E1 0/0/0 clock source line primary pri-group timeslots 1-31 description DID Range: +46 555 777 (XXXX) no shutdown ! interface Serial0/0/0:15 no ip address encapsulation hdlc isdn switch-type primary-net5 isdn incoming-voice voice isdn negotiate-bchan resend-setup no cdp enable no shutdown ! voice-port 0/0/0:15 bearer-cap Speech
cptone SE ! dial-peer voice 1000 voip description Outbound calls from UCM voice-class codec 1 session protocol sipv2 incoming called-number . dtmf-relay rtp-nte sip-kpml no vad ! dial-peer voice 1010 voip description Inbound calls to CUCM subscribers modem passthrough nse codec g711ulaw session protocol sipv2 session server-group 1 destination e164-pattern-map 1 voice-class codec 1 voice-class sip options-keepalive profile 1 dtmf-relay rtp-nte sip-kpml no vad ! dial-peer voice 100 pots tone ringback alert-no-PI description Inbound calls from PSTN incoming called-number . direct-inward-dial ! dial-peer voice 110 pots tone ringback alert-no-PI description Outbound calls to PSTN destination-pattern 0T progress_ind setup enable 3 progress_ind alert enable 8 progress_ind progress enable 8 progress_ind connect enable 8 progress_ind disconnect enable 8 no digit-strip port 0/0/0:15 no sip-register !
You’re welcome.
To answer your questions, yes a pots dial peer will consume any explicitly matched digits if you don’t have that command. As an example if you have a destination-pattern of 1234 it would consume (drop) all of these. So either you use that built in functionality or you can create a voice translation profile that you set in the outbound direction on your voice port or dial peer to drop the digits.
For the other question, no you should not need to add that as it pertains to the specific case where pots dial peers with SIP tries to register to SIP SRST on the router and even so I don’t think it would apply to the MGCP controlled pots dial peers.
Change dial peer 201 to not have the session target as this is for an outbound dial peer and add codec g711alaw, without it you’ll get g729, and add incoming called-number . (dot). Also add no vad to both voip dial peers.
You’d likely want to have some dtmf relay function defined on these, like I have in the example.
Do you only have one CM? If not I’d recommend you to use the server group from my configuration example or multiple dial peers towards CM for each CPE node. Otherwise the routers security features for voip will reject the call if it comes from any of the other CM nodes.
When a call hit dial peer 28010 to directory number 28010 it should route it out via port 2/20 with an empty called number.
Edit:
Added the configuration as I would have made it.
voice service voip
sip
bind control source-interface GigabitEthernet0/0/0
bind media source-interface GigabitEthernet0/0/0
!
voice class server-group 1
ipv4 10.20.2.27 preference 1
description Server group for CUCM
!
voice class codec 1
codec preference 1 g711ulaw
!
voice-port 2/20
ring frequency 50
cptone FR
description **telephone analogique**
station-id number 28010
!
dial-peer voice 28010 pots
description **telephone analogique**
destination-pattern 28010$
port 2/20
!
dial-peer voice 201 voip
description **Incoming Call from CUCM SIP Trunk**
voice-class codec 1
session protocol sipv2
incoming called-number .
dtmf-relay rtp-nte sip-kpml
no vad
!
dial-peer voice 200 voip
description **Outgoing Call to CUCM SIP Trunk**
session protocol sipv2
session server-group 1
destination-pattern 10...
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
no vad
!
sip-ua
g729-annexb override
retry invite 2
timers trying 300
no remote-party-idPrimary difference is how the calling endpoint is updated with any transformation done on the called number. Doing it on the RP level will update the calling device display of called number for changes done, whereas putting it on RG level can result in no update to the calling endpoint. What can influence this on the RG level is what control protocol that is used for the gateway. Especially this is so if H.323 is used.
As I wrote before the CM will in most instances not pass along the update of number manipulation when it’s done on the RG level. This behavior depends upon what control protocol that is used for the entities in the RG. You’ll get different behavior for example with a H323 gw if you haven’t configured it with a command that “tells” CM to not pass along the number transformation information. As you use MGCP you should not need to worry about this as it’s the default behavior for a MGCP controlled gateway.
Sorry for forgetting about this specific earlier, it’s been a quite long time since I did anything that didn’t involve SIP gateways and there you would naturally be doing this directly in the gateway.
