Struct Registration 

pub struct Registration {
    pub registrar: Uri,
    pub aor: String,
    pub contact: String,
    pub expires: Duration,
    pub call_id: String,
    pub cseq: u32,
    pub instance: Option<InstanceId>,
    pub reg_id: Option<RegId>,
    pub gruu: Option<Kind>,
    pub push: Option<Device>,
    pub headers: Vec<Header>,
}

What to register.

Fields

registrar: Uri

The registrar’s URI, which is the Request-URI of the REGISTER.

aor: String

The address of record being registered.

contact: String

Where to reach this user agent.

expires: Duration

How long a lease to ask for.

call_id: String

The Call-ID, constant across refreshes.

cseq: u32

The CSeq, increasing across refreshes.

instance: Option<InstanceId>

The device identity this registration presents (RFC 5626 §4.1, RFC 5627 §4.1).

One field, and that is the point. Outbound and GRUU both identify the instance with the same +sip.instance media feature tag, and they must present the same value: a registrar that correlates them sees one device asking to be two. Two fields would eventually hold two values, and the resulting fault appears at the registrar rather than here — which is the worst place to discover it.

When set, the Contact carries +sip.instance.

reg_id: Option<RegId>

Which Outbound flow this registration is (RFC 5626 §4.2), when Outbound is in use.

Together with Registration::instance it makes the Contact an Outbound one and has the REGISTER offer the outbound option tag. A reg-id without an instance is not an Outbound registration — §4.2 needs both — and is ignored rather than half-offered.

gruu: Option<Kind>

Which GRUU this UA will use once the registrar issues them (RFC 5627 §4.4).

Some asks for one: §4.1 has the REGISTER offer the gruu option tag alongside the instance ID. None does not ask, and no registrar will volunteer.

push: Option<Device>

How a push notification service can wake this device (RFC 8599 §4.1.2).

Beside the instance identity rather than in a story of its own, because it is the same claim: this is the device, and this is how to reach it when there is no flow. When set, the Contact URI carries pn-provider, pn-param and pn-prid — inside the angle brackets, which is where a registrar’s URI parser looks.

None registers without push, which is every client that holds a connection of its own.

headers: Vec<Header>

Validated application-owned fields repeated on retries and refreshes.

Implementations

impl Registration

pub fn request(&self) -> Result<Request, BuildError>

Build the REGISTER request.

Note the two URIs that are easy to confuse: the Request-URI names the registrar, the To names the user. A REGISTER addressed to the user reaches nothing.

pub fn contact(&self) -> String

The Contact to register: the configured one, plus whatever the instance identity adds.

+sip.instance appears exactly once, however many mechanisms want it — RFC 5626 §4.1 and RFC 5627 §4.1 name the same tag, and it is emitted from the one field that holds it.

The push parameters go on first and go inside: RFC 8599 §8.7 registers them as URI parameters, so they belong in the URI’s own grammar, while +sip.instance and reg-id are contact-params and belong after the angle brackets. Two lists, two meanings, and putting either in the other’s place produces a Contact that parses and says the wrong thing.

pub fn advance(&mut self)

Advance the sequence number for the next attempt.

The Call-ID deliberately does not change: a new one makes this a new registration rather than a refresh, which leaves the old contact at the registrar until it expires.

Trait Implementations

impl Clone for Registration

fn clone(&self) -> Registration

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for Registration

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.