Please see below query and execution plan - Any advice on how to get rid of SORT operator cost (nothing coming on missing indexes recommendation)
Your plan is an image and this is bad.
Your tables are heaps and this is worse.
With knowing nothing about uniqueness in your tables and deducing it only from table names, I suggest you to add PK clustered to your DimCorp:
alter table DimCorp add constraint PK_DimCorp primary key clustered(DimCorpId)
And clustered (I don't think it is unique) on your FactCallDetail:
create clustered index ix_cl_DimCorpId on FactCallDetail(DimCorpId)
As sepupic's answer points out, the reason you're getting a sort operator (and poor performance) is because you're missing clustered indexes on your tables, and therefore their underlying data structure is a heap.
In order for SQL to be able to "efficiently" join them together with the nested loop operator, it first sorts one of the heaps, which in this case has millions of rows causing the sort to be extra heavy of an operation.
If you add clustered indexes on the DimCorpId field in the FactCallDetail and DimCorp tables, then the data will be saved to disk pre-sorted by DimCorpId in a B-Tree data structure. Not only will this eliminate the sort operator from that part of the execution plan, it'll tremendously increase performance of the join between both tables on DimCorpId.