I just called into the Comcast Enterprise Trunking support department to have them update the Targus / TNSI public CNAM databases for a couple of DIDs which we want to display another CNAM than the current CNAM. What I was just told was baffling because I believe I have a strong understanding of how CNAM systems and lookups occur. The receiving partie's TELCO only receives only a CID number and is responsible for performing CNAM lookups (cached/real-time) within their own customer database and or third-party database such as Targus or TNSI. The tech support representative told me that he couldn't currently set my custom CNAMs per DID because we had "Caller ID Pass-Through" enabled on our account. He told me that with this setting enabled that the PBX vendor is responsible for sending CNAM information to the recipient TELCO. I asked him to clarify again since this technically does not seem possible. I googled it and couldn't find anything other than what I already knew about CNAM lookups being performed at the recipients telco ( https://supportforums.cisco.com/discussion/11302061/set-outbound-caller-id-name ). I asked if he had any Comcast supplied technical documentation I could view and he reported that he didn't have any and that its been that way since he started working for Comcast Enterprise Trunking 2 years ago. I called back hoping to get another tech support agent, but I got the same person and he stuck with his story about our Cisco PBX being the one responsible for outbound CNAM data. I asked him if we removed the "Comcast PRI Caller ID Pass-Through" feature, would he be able to update the Targus CNAM information, and he said yes. I requested that he remove that feature which could take 5-7 days to complete at which point I would need to call in a make another ticket to set the CNAM records for all their DIDs (not exactly streamlined). Has anyone else heard of this feature? I would like to escalate this within the Comcast Enterprise Trunking support division, but I wanted to make sure I wasn't crazy before I push this topic up the chain. Thanks, Dave Frank ... View more