A call transferred between feature servers arrives at the receiving server as a
fresh INVITE, so the session runs through trying, ringing, early-media and
answered again as it accepts the REFER. The application was already told all of
that by the server that first handled the call, so it sees a second round of
events for a call it believes is long since answered.
Skip only the application-facing status callback for those four statuses when
the session is a transferred call. callInfo, the redis call record and
record-all-calls still run exactly as before, so the call record stays accurate
and answering a transferred call still starts recording.
Fixes#1392
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>