Well, it depends on some facts. Here are my thoughts.
I think you will call only people, not organizations. Perhaps you need a CallHistory table for customer employees and supplier employees only.
Where is the relation between entity table(s) and CallHistory table stored? There is no foreign key in your CallHistory table? You need a foreign key for the entity. Note that every field in the entity tables must have the same data type as the foreign key field.
If the foreign key is not important you need only one CallHistory table. But I doubt that it is unimportant to know, with whom you made a phonecall.
It's also a question of performance. How many records will be stored in the CallHistory table? And how often do you select/insert/update the data? To increase the performance it might be a good solution to create a CallHistory table for each entity.[/list=1]
You haven't said how (or where) you are storing phone numbers. And that will impact how you will design your phone call log.
Do you have a single table for all phone numbers or are they seperately stored for organizations, customers, etc.? Or do you intend for the data entry people to just enter phone numbers each time they make a call (not a good approach).
It appears you may be running against the normalization grain with seperate tables for each type of entity. Whether this will cost you down the road depends on where you go with the application and what will be done with the data.
As for the number of records - it shouldn't be a concern. Old phone log records are usually not used on a daily basis and hence easily and agreeably archived, so when your table begins accumulating more than a few hundred thousand records, you can consider some options.