Function in_contact 

pub fn in_contact(contact: &str, device: &Device) -> String

Put the push parameters into a contact’s URI (§4.1.2).

The parameters are URI parameters, and the difference is the whole of why this is not a format!. Inside the angle brackets a ; starts a uri-parameter; outside them it starts a header parameter, which RFC 3261 §20 makes a different field of a different grammar. A registrar reading Contact URIs would never see one pasted on the outside — and would answer 200 to the registration, so nothing would say it had gone wrong.

A contact arriving without angle brackets gains them, because that form has nowhere to put a URI parameter at all; any header parameters after it stay outside, where they were.

A contact that cannot carry the parameters is returned byte-for-byte unchanged, and warned about. There are two such contacts and they fail for different reasons:

• one whose URI does not parse — including a display name whose own quoted < or > defeats the split above, since a bracket sipx picked wrongly yields text that is not a URI;
• one whose URI parses under a scheme sipx does not model — tel:, http:, urn: — which has no uri-parameter list to put them in, so setting them is a no-op.

Returning the contact unchanged is failure-closed, and the warning is the point: the second case is otherwise indistinguishable from success. The registration would go out looking ordinary, the registrar would answer 200, and the device would be unreachable by exactly the mechanism it was configured for. This is the application’s own configuration rather than network input, so it is a fault an operator can fix once told about it.