08-30-2022 08:10 PM - edited 08-30-2022 08:13 PM
All was good until a major power failure. No one was onsite and battery backups went down due to power outage length. When system came back up outbound from IP Phones worked theough SIP Trunk. However inbound calls all fail.
Flow is through ASA5506 (IP:Port to 2821) - 2821 - Voice Dial Peer - UCM10.5 - CTI RT PT - CUC10.5 - System Call Handler
When I call the Call Handler from an internal IP PHONE I hear the CUC recorded System Call Handler message
Checking 2821 DialPeer I see incoming dialpeer match however UCM is never contacted and therfore CUC System Call Handler does not start
Here is a piece of debug voip dialpeer inout when the number is called. This log goes on until the call fails and the Calling - Called Number eventually become blank
010694: Aug 31 02:58:56.424: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
Calling Number=, Called Number=, Voice-Interface=0x0,
Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE,
Peer Info Type=DIALPEER_INFO_SPEECH
010695: Aug 31 02:58:56.424: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
Result=NO_MATCH(-1) After All Match Rules Attempt
010696: Aug 31 02:58:56.424: //-1/xxxxxxxxxxxx/DPM/dpMatchSafModulePlugin:
dialstring=NULL, saf_enabled=0, saf_dndb_lookup=0, dp_result=-1
010697: Aug 31 02:58:56.424: //-1/B035244E897A/DPM/dpAssociateIncomingPeerCore:
Calling Number=, Called Number=, Voice-Interface=0x0,
Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE,
Peer Info Type=DIALPEER_INFO_SPEECH
010698: Aug 31 02:58:56.424: //-1/B035244E897A/DPM/dpAssociateIncomingPeerCore:
Result=NO_MATCH(-1) After All Match Rules Attempt
010699: Aug 31 02:58:56.424: //-1/B035244E897A/DPM/dpMatchSafModulePlugin:
dialstring=NULL, saf_enabled=0, saf_dndb_lookup=0, dp_result=-1
010700: Aug 31 02:58:58.160: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
Calling Number=5856725663, Called Number=5856725663, Peer Info Type=DIALPEER_INFO_SPEECH
010701: Aug 31 02:58:58.160: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
Match Rule=DP_MATCH_DEST; Called Number=5856725663
010702: Aug 31 02:58:58.160: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
Result=Success(0) after DP_MATCH_DEST
010703: Aug 31 02:58:58.160: //-1/xxxxxxxxxxxx/DPM/dpMatchSafModulePlugin:
dialstring=5856725663, saf_enabled=1, saf_dndb_lookup=1, dp_result=0
010704: Aug 31 02:58:58.160: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersMoreArg:
Result=SUCCESS(0)
List of Matched Outgoing Dial-peer(s):
1: Dial-peer Tag=92
2: Dial-peer Tag=10
Here are the dialpeers
dial-peer voice 92 voip
SIP-UA info
sip-ua
no remote-party-id
retry invite 2
retry register 2
retry options 1
timers connect 100
registrar dns:sip34.vitelity.net expires 3600
sip-server dns:sip34.vitelity.net
host-registrar
Voice and SIP info
voice service voip
ip address trusted list
ipv4 66.241.99.181 255.255.255.255
ipv4 64.2.142.189 255.255.255.255
clid network-provided
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
no supplementary-service sip refer
no supplementary-service sip handle-replaces
redirect ip2ip
fax protocol pass-through g711ulaw
no fax-relay sg3-to-g3
h323
h450 h450-2 timeout T1 1000
h450 h450-3 timeout T1 1000
h225 timeout ntf 500
h225 display-ie ccm-compatible
h225 connect-passthru
h245 passthru all
modem passthrough nse codec g711ulaw
sip
registrar server expires max 600 min 60
early-offer forced
midcall-signaling passthru
no call service stop
Any thoughts on how to proceed are welcomed.
Solved! Go to Solution.
08-31-2022 10:26 PM
Carl,
Could you please try replacing dial peers 110 and 211 with the ones below?
These two dial peers ensure g711 is used on both legs of the call. This codec is required for rtp-nte DTMF singnaling to work.
Also, you do not need SIP early offer, or sip profile 1 on dial peer 211, or session target on dial peer 110 so I removed those here.
dial-peer voice 110 voip
description ### From SIP Provider Vitelity ###
session protocol sipv2
incoming called-number 5856725663
codec g711ulaw
voice-class sip dtmf-relay force rtp-nte
dtmf-relay rtp-nte
no vad
dial-peer voice 211 voip
description ### To CUCM ###
destination-pattern 5856725663
session protocol sipv2
session target ipv4:10.8.32.20:5060
codec g711ulaw
voice-class sip dtmf-relay force rtp-nt
dtmf-relay rtp-nte
no vad
If the issue still persists after adding these new dial peers, please do another debug using commands below.
debug voice ccapi inout
debug ccsip messages
08-31-2022 10:40 PM - edited 08-31-2022 10:40 PM
@TechLvr Why should G711 be necessary for RTP-NTE?
It is just a "number" in the RTP packet, it is not a "media" packet in that why like the voice is.
This may be correct if in-band audio DTMF would be used.
@Carl Fitzsimmons which DTMF methods are active in CUC? Under the port group --> advanced settings
09-01-2022 07:44 AM - edited 09-01-2022 08:25 AM
09-01-2022 09:27 AM
Apart from what you already shared can you please take screenshots of the entire SIP trunk configuration for both the Cube and the CUC, if you use SIP for that integration, from CM? I have a suspicion that you might be using a specific DTMF relay on either of these instead of the recommended No Preference.
09-02-2022 02:30 AM - edited 09-02-2022 02:47 AM
I know that you already have solved your issues, but I took the time anyway to go through your configuration and clean-up the parts that are related to the voice service. There are more things that I'd likely clean-up if it was my configuration to maintain, but as I don't know any details on your system landscape I left that out.
This is what I would suggest you to do to get a cleaner looking configuration.
voice service voip
ip address trusted list
no ipv4 10.8.32.30 255.255.255.255 ! not needed as this is your CUC server, only CM needs to be added to list of trusted
no allow-connections h323 to h323 ! not needed for SIP to SIP calls
no allow-connections h323 to sip ! not needed for SIP to SIP calls
no allow-connections sip to h323 ! not needed for SIP to SIP calls
mode border-element licence capacity XX ! the number of sessions that you have licensed for Cube, if you use never HW and SW combo the command is just mode border-element
h323 ! As you do not use H323 this is redundant
no h450 h450-2 timeout T1 1000
no h450 h450-3 timeout T1 1000
no h225 timeout ntf 500
no h225 display-ie ccm-compatible
no h225 connect-passthru
no h245 passthru all
no h323
no voice class h323 1 ! As you do not use H323 this is redundant
no voice class sip-profiles 1 ! As you do not use this profile this is redundant
! As you do not use any of these it is redundant
voice register pool 11
no translation-profile outgoing PSTN_CallForwarding
no voice translation-rule 1 ! not user anywhere, so redundant
!
no voice translation-rule 2 ! not user anywhere, so redundant
!
!
no voice translation-profile PSTN_CallForwarding ! the referenced translation rules in this profile does not exist, so it is redundant
!
no voice translation-profile PSTN_Outgoing ! not user anywhere, so redundant
!
no voice translation-profile To_CUCM ! not user anywhere, so redundant
!
no voice translation-profile add-prefix-9-to-CID ! not user anywhere, so redundant
interface GigabitEthernet0/1.36
no h323-gateway voip bind srcaddr 10.8.36.2 ! As you do not use H323 this is redundant
no dspfarm profile 3 conference ! As you do not use this profile this is redundant
dspfarm profile 1 conference ! this is to remove any codec with a "b" in the name as you do not use VAD
shut
y
no max sess
no codec g729br8
no codec g729abr8
maximum sessions 4
no shut
!
voice translation-rule 40 ! added to remove prefix for outbound calls
rule 1 /^9\(.*\)/ /\1/
!
voice translation-profile PSTN-OUT ! added to remove prefix for outbound calls
translate called 40
!
dial-peer voice 100 voip
destination-pattern 9T !to stop the loop, make sure that you send the called number for outbound calls with the prefix (9) that I think that you might use for external calls
no session target sip-server ! not needed on this dial peer
translation-profile outgoing PSTN-OUT ! added to remove prefix for outbound calls
!
dial-peer voice 110 voip
no session target sip-server ! not needed on this dial peer
!
dial-peer voice 111 voip
no session target sip-server ! not needed on this dial peer
!
dial-peer voice 200 voip
no session target sip-server ! not needed on this dial peer
!
! As you do not use MGCP this is redundant/unneeded
no ccm-manager fallback-mgcp
no ccm-manager mgcp
no ccm-manager config server 10.8.32.20
no ccm-manager config
no mgcp call-agent 10.8.32.20 service-type mgcp version 0.1
no mgcp
sccp ccm group 1
associate profile 33 register <name of the MTP that you have created in CM under Media Resoures MTP> ! this is for the MTP resource that you have in the gateway to register to CM
If you have any question or wonder about parts please reach out to me.
09-02-2022 05:30 AM
I just implemented the changes you suggested. Those changes read as the migration of the system from POTS to PSTN to SIP. Thank you very much for all your guidance and suggestions throughout. I left call control back in CCM 3.5 days and dove into database and custom programming to move - reuse data. While some of the call control is the same there are some important differences that would have taken me a while to understand and setup correctly.
I now wonder what improvements may be needed in the UCM side of Route/Hunt and Class Control. I would be open to connecting and discussing off line.
Again thank you very much for all your guidance and assistance
09-01-2022 08:24 AM
09-01-2022 09:53 AM - edited 09-01-2022 09:56 AM
Your config seems to be correct.
Per your debug output, the issue is that your SIP provider does not send an ACK message in reponse to the CUBE's 200 OK message.
This is why DTMF does not work, and also call drops. You need to raise a ticket with the SIP provider to resolve the issue.
Here is a summary of your call log analysis.
The incoming call arrives from the provider on dial peer 110 (with early offer)
CUBE sends trying message back to the provider
CUBE sends invite to the CUCM on dial peer 211 (with early offer)
CUCM sends trying message to the CUBE
CUCM sends a 200 OK message to the CUBE (choosing g711 for audio, and 101 for DTMF)
CUBE sends a ACK message back to the CUCM
CUBE sends a 200 OK messages to the provide (choosing g711 for audio, and 101 for DTMF)
The audio connects but the provider does not send back an ACK message
CUBE tries to send a few more 200 OK messages but the provider does not respond
CUBE then drops the call by sending a BYE message to the provider and the CUCM
CUCM and Provider both respond the BYE message with 200 OK
As you can see, both legs of the call use g711 for audio, and PT 101 for DTMF which is good but since the provider does not acknowledge
things don't work properly and the CUBE gives up.
09-01-2022 02:15 PM
I missed this. I sent that information to the ITSP and they responded with the following.
You are sending us you Private IP (10.8.36.2), instead of your Public IP (24.213.128.10), in both your Contact Header and SDP Profile on these calls. We cannot contact you at your Private IP. You will want to send us your Public IP (24.213.128.10) instead.
[23, 12:04:12:606934, 200 OK (SDP profile), 982 bytes, 24.213.128.10, 66.241.99.181, 53904, 5060]
Summary:
Response Code: 200
Response Reason: OK
From: "SEAMLESS COMMUN" sip:5857469235@66.241.99.181>;tag=as50ed416a
To: sip:5856725663@24.213.128.10>;tag=5F2F28C-15C
Call-ID: 659bf1781f9a89c723bf0b3409424574@10.44.109.67:5060
CSeq: 102 INVITE
Contact: sip:5856725663@10.8.36.2:5060>
SDP IP: 10.8.36.2
SDP Port: 17356
SDP IP: 10.8.36.2
o=CiscoSystemsSIP-GW-UserAgent 8900 5733 IN IP4 10.8.36.2
c=IN IP4 10.8.36.2
Please update your Contact Header and SDP Profile to the appropriate Public IP and retest.
What I am trying to understand is changing the IP for the response to ITSP from our Private IP (10.8.36.2) to our Public IP (24.213.128.10). If that is accurate then I am lost as I have never messed with headers. Been looking for a solution but have not found it and in the process outbound stopped working. I have outbound restored with same inbound call drop occurring. Any suggesting on a link that I can use to be able to update the contact header and sdp profile?
09-01-2022 02:27 PM
That makes perfect sense. I am currently away from my PC, but later tonight, I can create/send you a sip profile that you can apply to the CUBE to resolve the issue.
09-01-2022 04:20 PM - edited 09-01-2022 04:21 PM
Can you add the following SIP profile to the CUBE and test again?
configure terminal
voice service voip
sip
sip-profiles inbound
voice class sip-profiles 100
response ANY sip-header Contact modify "10.8.36.2" "24.213.128.10"
request ANY sip-header Contact modify "10.8.36.2" "24.213.128.10"
response ANY sdp-header Audio-Connection-Info modify "10.8.36.2" "24.213.128.10"
request ANY sdp-header Audio-Connection-Info modify "10.8.36.2" "24.213.128.10"
response ANY sdp-header Connection-Info modify "10.8.36.2" "24.213.128.10"
request ANY sdp-header Connection-Info modify "10.8.36.2" "24.213.128.10"
response ANY sdp-header Session-Owner modify "10.8.36.2" "24.213.128.10"
request ANY sdp-header Session-Owner modify "10.8.36.2" "24.213.128.10"
dial-peer voice 110 voip
voice-class sip profiles 100 inbound
09-01-2022 07:09 PM
Freakin awesome - that enabled DTMF.
I will go through this in the morning and mark helpful and solution. You provided DTMF solution and others pointed me to changes in Dial Peer that were needed as well.
Thank you - thank you - thank you.
I really enjoy BAT - db for new site and upgrade conversions on medium to large scale efforts. I have created solutions that reduce time and errors. Simply put I know this piece. Call control is something I left behind back in CCM 3.5 days as I dove into VG programming using CGI when it did not exist in BAT except in GUI.
Again - thank you
09-02-2022 06:26 AM
You're very welcome Carl. I'm glad that it worked.
09-02-2022 05:34 AM
I would also like to thank you for your assistance in helping me through this piece. Without some of what you have suggested I would still be in the weeds. Thank you very much.
08-31-2022 08:18 AM - edited 08-31-2022 09:07 AM
By the look of your debug you use dial peer 92 as the inbound and 10 as the outbound. Based on your shared configuration that is not likely what you want or expect. I would advice you to follow @Vladimir Adutskevich advice and rework your dial peers so that you have these.
The recommend best practice these days are to use information in the VIA header to match the inbound dial peer and then for the outbound you should make sure that you do not have any overlap in the match. With your current configuration you have that on dial peer 10 as it matches .T. This is a very bad way of setting up your dial peer as it would match anything and that creates loops in your call plan.
I would recommend you to read up on the topic and this outstanding document is a good place to start In Depth Explanation of Cisco IOS and IOS-XE Call Routing
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide