Module update 

The UPDATE method (RFC 3311).

A re-INVITE renegotiates a session that is already up. It cannot renegotiate one that is not: until the INVITE has a final response there is a transaction in progress, and a second INVITE inside it is not a thing SIP has. UPDATE is the request that fills that hole — an in-dialog renegotiation that runs alongside the INVITE transaction without disturbing it — and RFC 4028 §7.4 then reuses it as the cheaper way to refresh a session timer.

Everything here is pure. What is written down is the offer/answer bookkeeping a dialog has to keep in order to decide whether an UPDATE may be sent or accepted, and the three different refusals §5.2 requires when it may not. The sending, the clock and the randomness live a layer up; see docs/specs/sip-update.md.

Structs

Negotiation

One dialog’s offer/answer bookkeeping, as far as UPDATE is concerned (RFC 3264, RFC 3311 §5).

Enums

Reception

What to do with an UPDATE that has arrived.

Refusal

Why an UPDATE cannot be processed now (RFC 3311 §5.2).

Constants

ALLOW

The Allow value sipx advertises (RFC 3311 §4, RFC 3261 §20.5).

RETRY_AFTER_MAX_SECS

The largest Retry-After a §5.2 refusal may name.

Functions

peer_allows

Whether a peer’s Allow lists UPDATE (RFC 3311 §4).