Function answer_early 

pub async fn answer_early(
    endpoint: &Handle,
    incoming: &Incoming,
    ringing: &mut Ringing,
) -> Result<Call>

Answer an INVITE that was rung with crate::rel::ring_early.

The counterpart of answer_ringing for a dialog whose offer/answer already completed in the provisional. Three things follow from that and none is optional:

• The provisional must already be acknowledged. RFC 3262 §5 is a MUST: a UAS that put a session description in a reliable provisional delays the 2xx until that provisional is acknowledged. So this returns Error::UnacknowledgedProvisional rather than answering, and the caller keeps feeding messages to Ringing::on_prack until Ringing::is_acknowledged is true. It cannot wait on the caller’s behalf: the PRACK arrives on the application’s own inbox, and this holds the &mut that handling it would need.
• The 200 carries no session description. There is nothing left to say: the offer was answered in the 183, and anything an UPDATE renegotiated afterwards was answered in its own 2xx. Repeating the last answer here would be a second answer to the INVITE’s offer, and repeating the first one would silently undo the renegotiation. That is only safe because of the rule above — the PRACK is proof the caller holds the answer, and without it a lost 183 would leave the caller in a confirmed dialog with no description at all.
• The media port is the one the provisional named, not a fresh one, because that is the port the far end has already been told to send to.

The Ringing is borrowed mutably and emptied rather than consumed, because it owns the retransmission of the provisional and must go on owning it until it is dropped.