Hello,
I had an odd issue today. I know the topic is strange but didn't know how else to title it. Maybe if I explain the issue and the workaround it'll make more sense.
We had a report of agents switching in CTIOS going from Reserved to Not Ready state and constantly toggling between the two. After finding no issues in CVP/ICM I looked at CUCM logs. This issue started after I later found out someone had added a trunk to a new gateway. The name of the gateway was AS5400 and was also the ingress gateway for inbound calls to agents. Call flow was such.
ITSP--sip--AS5400--sip--cusp---sip--cvp--cusp--sip--cucm.
After looking at CUCM traces I could see invites being received from cusp with the correct label and getting a 404 not found from CUCM. Which for example was passed with significant digits of 000333XXXX. On the CSS of the SIP trunk to CUSP, it had access of a translation which would strip the signifacant digits and XXXX would be the DN. But looking at the digit analysis I saw it found no matches and didn't have any CSS. And the name which was showing up was the name of the new trunk which had been added instead of the CUSP trunk.
88221913.004 |14:53:58.740 |AppInfo |SIPD(159) - updateOriginalCalledExtensionSupport: mTsp.deviceName[AS_5400] - supported header has timer,resource-priority,replaces,sdp-anat
The invite came from CUSP with the FQDN.
=====================================================
INVITE sip:00033324429@cucm.voice.local SIP/2.0
Via: SIP/2.0/TCP 172.21.30.XXX:5060;branch=z9hG4bKppKNPekcFN+hwjqAh4EvEg~~6638435
Via: SIP/2.0/TCP 172.21.21.XX:5060;branch=z9hG4bKjLI5bgMcStto79bWIq19NQ~~4406137
Max-Forwards: 67
To: <sip:00033324429@cusp.voice.local;transport=tcp>
From: 562204XXXX <sip:562204XXXX@172.21.21.XX:5060>;tag=dsdbf18d54
Contact: <sip:5622049060@172.21.21.XX:5060;transport=tcp>
Expires: 15
Remote-Party-ID: <sip:562XXXXXXX@10.6.142.X>;party=calling;screen=yes;privacy=off
Call-ID: 4C5AAD1F96AF11E4BF30002291581FEA-142075040581575158@172.21.21.XX
CSeq: 1 INVITE
Content-Length: 0
User-Agent: CVP 10.0 (1) ES-3 Build-15
Call-Info: <sip:10.6.142.1:5060>;purpose=x-cisco-origIP
Date: Thu, 08 Jan 2015 20:53:57 GMT
Min-SE: 1800
Cisco-Guid: 1281010975-2528055780-3207594018-2438471658
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: kpml, telephone-event
MIME-Version: 1.0
Cisco-Gucid: 4C5AAD1F96AF11E4BF30002291581FEA
Supported: timer
Supported: resource-priority
Supported: replaces
Supported: sdp-anat
App-Info: <172.21.XX.XX8000:8443>
===================================
The enterprise settings for organization top level domain was voice.local
Cluster FQDN was: *.voice.local.
So what would happen I assume is since it didn't match the top level domain exactly of cucm.voice.local. It then went out the newly added trunk. Since in the invite it saw that IP address on the trunks destination. After I added the partition of the translation pattern to the new trunks CSS. Calls begin working properly and no issues.
My question is. How was this matching before? Would the top level domain have to be cucm.voice.local? And why didn't it use the FQDN which had a wild card in front?
Thanks
