Cisco CME 8.8 Destination Pattern Required for CID to work?

hismartalarms · ‎12-22-2022

Hi! I am running Cisco IOS 15.2, with CME 8.8. I have had this issue on 15.1, CME 8.6.

I am using a SIP trunk to my Asterisk Server for PSTN connections. I am using "dial-peer incoming called-number <REDACTED>..." but whenever I call into it, it gives me a SIP CC 400 (CC 100), which means an invalid header. Noticeably there is no Calling ID in SIP debug (thus the reason for the CC 400). The only way for my CID to pass (that I have found) is to add a "destination-pattern ......." This fixes my Caller ID issue, and inbound calls route fine. But now my outbound is broken, and forces everything to be 7 digits long.

What I don't understand is, why would I even have to add "destination-pattern" to begin with on an inbound dial-peer?

Dial-Peer Configuration:

dial-peer voice 101 voip
description SIP Incoming
translation-profile incoming SIPinbound
destination-pattern .......$
session protocol sipv2
session target dns:<REDACTED>
incoming called-number <REDACTED>...
codec g711ulaw
exit

dial-peer voice 100 voip
description SIP Outbound
translation-profile outgoing SIPstrip
destination-pattern 9.......
session protocol sipv2
session target dns:<REDACTED>
codec g711ulaw
exit

Also here is some SIP Debug Info:

Without "destination-pattern"

The Call Setup Information is:
Call Control Block (CCB) : 0x2C262198
State of The Call        : STATE_DEAD
TCP Sockets Used         : NO
Calling Number           :
Called Number            : <REDACTED>
Source IP Address (Sig   <REDACTED>
Destn SIP Req Addr:Port  : <REDACTED>
Destn SIP Resp Addr:Port : <REDACTED>
Destination Name         : <REDACTED>

Roger Kallberg · ‎12-22-2022

It is absolutely not required.
One observation, as you have a session target line configured on your so called inbound dial peer it can act as an outbound as well. Try cleaning up your configuration so that you have pure inbound and outbound dial peers. I also recommend you to add “no vad” to all your voip dial peers.

A general recommendation is that it’s better to use information in the VIA header as the match for your inbound dial peer instead of calling number.

This document explains the call routing in IOS in a very detailed manner. In Depth Explanation of Cisco IOS and IOS-XE Call Routing

If you want detailed analysis of what is going on please provide the output from debug ccsip message and debug voip ccapi inout, running in parallel, in an attached file.

hismartalarms · ‎12-23-2022

Alright, I have removed the session target and added "no vad", but still the same issue. Below is the debug outputs, and here is my current dial-peer config.

dial-peer voice 1 pots
 description NNIS / No-Man's Land Protector
 incoming called-number .
 port 0/1/0
!
dial-peer voice 101 voip
 description SIP Incoming
 translation-profile incoming SIPinbound
 session protocol sipv2
 incoming called-number 3238...
 codec g711ulaw
 no vad
!
dial-peer voice 100 voip
 description SIP Outbound (TandmX)
 translation-profile outgoing SIPstrip
 destination-pattern 9.......
 session protocol sipv2
 session target dns:<REDACT>
 codec g711ulaw
!

hsl-cme-1(config-dial-peer)#
Dec 23 20:23:29.911: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:<REDACT (CISCO DID NUMBER)>@<REDACT> SIP/2.0
Via: SIP/2.0/UDP <REDACT>;branch=z9hG4bK7cf70ea2;rport
Max-Forwards: 70
From: "Hi-Smart Labs" <sip:<REDACT (CALLERID)>@<REDACT>>;tag=as0c3992f8
To: <sip:<REDACT (CISCO DID NUMBER)>@<REDACT>>
Contact: <sip:<REDACT (CALLERID)>@<REDACT>>
Call-ID: 7f24a1a26b9b85624032f25030c9d279@<REDACT>
CSeq: 102 INVITE
User-Agent: Asterisk PBX 18.8.0
Date: Fri, 23 Dec 2022 20:27:13 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 243

v=0
o=root 1864659207 1864659207 IN IP4 <REDACT>
s=Asterisk PBX 18.8.0
c=IN IP4 <REDACT>
t=0 0
m=audio 10118 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=maxptime:150
a=sendrecv

Dec 23 20:23:29.915: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 400 Bad Request - 'Invalid Host'
Via: SIP/2.0/UDP <REDACT>;branch=z9hG4bK7cf70ea2;rport
From: "Hi-Smart Labs" <sip:<REDACT (CALLERID)>@<REDACT>>;tag=as0c3992f8
To: <sip:<REDACT (CISCO DID)>@<REDACT>>;tag=DEE4D4C-2111
Date: Fri, 23 Dec 2022 20:23:29 GMT
Call-ID: 7f24a1a26b9b85624032f25030c9d279@<REDACT>
CSeq: 102 INVITE
Allow-Events: telephone-event
Reason: Q.850;cause=100
Server: Cisco-SIPGateway/IOS-15.2(1)T,
Content-Length: 0


Dec 23 20:23:29.979: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:<REDACT (CISCO DID)>@7<REDACT> SIP/2.0
Via: SIP/2.0/UDP <REDACT>;branch=z9hG4bK7cf70ea2;rport
Max-Forwards: 70
From: "Hi-Smart Labs" <sip:<REDACT (CALLERID)>@<REDACT>>;tag=as0c3992f8
To: <sip:<REDACT (CISCO DID)>@<REDACT>>;tag=DEE4D4C-2111
Contact: <sip:<REDACT (CALLERID)>@<REDACT>>
Call-ID: 7f24a1a26b9b85624032f25030c9d279@<REDACT>
CSeq: 102 ACK
User-Agent: Asterisk PBX 18.8.0
Content-Length: 0


Dec 23 20:23:29.979: //-1/7F9BD8FD87C2/SIP/Call/sipSPICallInfo:
The Call Setup Information is:
Call Control Block (CCB) : 0x2C262198
State of The Call        : STATE_DEAD
TCP Sockets Used         : NO
Calling Number           :
Called Number            : 3238380
Source IP Address (Sig   <REDACT>
Destn SIP Req Addr:Port  : <REDACT>
Destn SIP Resp Addr:Port : <REDACT>
Destination Name         : <REDACT>

Dec 23 20:23:29.979: //-1/7F9BD8FD87C2/SIP/Call/sipSPICallInfo:
Disconnect Cause (CC)    : 100
Disconnect Cause (SIP)   : 400

Roger Kallberg · ‎12-23-2022

You’re getting

400 Bad Request - 'Invalid Host'

By the look of things this post could possibly be a match of what you’re seeing. https://community.cisco.com/t5/ip-telephony-and-phones/sip-2-0-400-bad-request-invalid-host/td-p/1561768

As you redacted much of the information in the output and shared configuration it is not that easy to see what’s going on. Do you really need to redact it that much? For example are all the IP information made up by public IPs? If not there should be no reason to redact that.

It would help if you could share your entire running configuration and a slightly less redacted output.

Roger Kallberg · ‎12-24-2022

If in fact the invite is sent with a public IP in the URI this post may be useful. https://community.cisco.com/t5/ip-telephony-and-phones/sip-2-0-400-bad-request-invalid-host/td-p/3022872