I'd call the sp directly from the trigger, unless there's some logic or state info (that you need for your CLR code) that's available in the trigger but not in the SP.
If I may use a process threading anology (analogy because the SQL Server engine doesn't have the same process control as Windows) the trigger is essentially a synchronus event handler that expects to return immediately after the last statement is called...you can use it to start another execution thread (e.g. exec proc ) where an 'asynchronous' (i.e. protracted) transaction can happen.
Disclaimer: though I'm a Developer/Architect Evangelist at Microsoft, my opinions are my own.