Module transfer 

Transfer: REFER (RFC 3515) and the implicit subscription it creates.

The shape of a blind transfer, and the part that is easy to get wrong:

1. The transferor sends REFER inside the existing dialog, naming where to go in Refer-To.
2. The transferee answers 202 Accepted — which means “I will try”, and nothing more.
3. The transferee places the new call and reports back with NOTIFY.

Step 2 is where implementations go wrong. A 202 is not success: treating it as success reports a completed transfer to a user whose call may have been refused, gone to voicemail or rung out. RFC 3515 §2.4.4 exists precisely so the transferor can tell those apart, and that is why this module models the outcome as something that arrives later.

The subscription is implicit — REFER creates one without a SUBSCRIBE — and it must end. A transferee that reports the outcome and then says nothing leaves the transferor holding a subscription that never terminates, which is a leak on both sides and, on a real network, a dialog a proxy keeps state for.

Structs

Referral

What a REFER asked of us.

Replaces

The dialog an INVITE asks to take the place of (RFC 3891).

Transfer

A transfer this side asked for, and what has become of it.

Enums

TransferState

How far a transfer has got, as the transferor learns it from NOTIFY.

Functions

is_terminated

Whether a Subscription-State says the subscription is over (RFC 6665 §4.1.3).

parse_sipfrag

The status line out of a message/sipfrag body.

sipfrag

The body of a NOTIFY about a transfer: a status line and nothing else.

subscription_suppressed

Whether a transferor asked for no implicit subscription (RFC 4488 §3).