Function dial_early 

pub async fn dial_early(
    endpoint: &Handle,
    target: Target,
    to: &Uri,
    options: &DialOptions,
) -> Result<Dialing>

Place a call and get the early dialog, rather than waiting for the call itself.

dial and dial_once wait for the final response and hand back a Call; this hands back a Dialing as soon as the far end has established a dialog, so the application can act while it rings — renegotiate the session with an UPDATE (RFC 3311 §5.1), answer one, or read the description a provisional carried. Dialing::answered then waits for the call exactly as dial would have.

It returns as soon as a dialog exists, which is not the same as an answered session: a far end that rings 180 with no body has established a dialog and described nothing. Dialing::has_early_session is what distinguishes them, and it is what Dialing::update requires.

Unlike dial there is no retry on a 422. The retry is a second INVITE, and the handle an application would be holding names the first; Error::IntervalTooBrief comes back from Dialing::answered instead, as it does from dial_once.

Errors

Fails if the INVITE cannot be built or sent, if the deadline passes before any dialog is established — in which case the invitation is withdrawn first, so the far end stops ringing — or if the transaction ends with no response at all.

It also fails if a reliable provisional answers our offer with a description that cannot be used: Error::Sdp for a body that does not parse or an a=crypto that fails RFC 4568 §5.1.3’s check, Error::NoCommonCodec for one that cannot be negotiated. The invitation is withdrawn with a CANCEL first (RFC 3261 §9.1), so no handle to a dead invitation comes back. A provisional carrying no description is not this case and is not an error.