Sorry for the delayed response! Missed this question and just had it brought to my attention!
For the most part it is not needed unless:
1) You have legacy Outlook Addins (V9) in the environment. Those wlil still leverage the OWA proxy enabler to redirect recall requests to a server with the Exchange Mailbox Archiver agent installed (yes MB archiver NOT MB!)
2) Double click OWA recalls. Only valid for Exchange 2010 or 2003 though. Exchange 2013 does not support double click recalls for OWA. Instead either implement the office app that is available or make sure stubbing is done with a recall link.
As far as communication is concerned, depends on the type of recalls. Since you asked about OWA Proxy Enabler here lets start with 'legacy' recalls:
Recall request starts at the OWA Proxy enabler (most likely a CAS server for Exchange 2010, directly to the MB role server on Exchange 2007 -- this is determined by where the OL profile is pointed **NOTE if you are running Exchange 2013 since the Exchange server is listed as a GUID a registry key needs to be implemented to point recalls directly to the OWA proxy enabler or the mailbox archiver agent).
The OWA proxy enabler , by default, will take communication from the client over port 8402 (evmgrc). The request is then redirected to the server specified on that server under advanced 'exchange proxy'. That communication is also over port 8402 (evmgrc). From there the recall should be at the Mailbox archiver agent which will facilitate the rest of the recall which basically entails connecting to Exchnage via an Outlook profile and restoring the mail item directly there. The communication chain is than passed back to the requesting client over the same channels (8402-evmgrc) to notify the client that the recall is done and a refresh has to occur to view the item.
The process in V10 is completely different. All recall requests go through the web console regardless of its a recall link (quick look) that was embedded into the message, OWA double click, or Outlook addin. The web console receives that request and passes it along to the web server which facilitates the restore of the item. The Web server communicates to the commserve/media agent to determine the proper media to restore from and restore it! The item does NOT have to go back to Exchange! Instead it is rendered or passed back to the requestor via the web console as an HTML or as a MSG file. All communication from the Web Console to the requestor is via HTTP/HTTPS. All communication from the Web Console to the Web Server is also via HTTP.
Please let me know if this answers your question.