Content-Type Clause Samples
Content-Type. The Content-Type header will contain the value application/registration+xml (from RFC 3680). The body of the NOTIFY request will contain a registration element for each non-barred public user identity (identified in the aor attribute of each <registration> element). The <uri> sub-element inside each <contact> sub-element of the <registration> element will contain the contact address provided by the respective UE. If the public user identity has been de-registered ⮚ The state attribute within the <registered> and <contact> elements is set to ‘terminated’. ⮚ The event attribute within each <contact> element to one of ‘deactivated’,’expired’,’unregistered’,’rejected; or ‘probation’ according to RFC3680. If the deregistration of the public user identity has already been indicated in an earlier NOTIFY and no new registration has occurred then the <registration> element for the deregistered public user identity is not included. If the public user identity has been registered ⮚ The state attribute within the <registered> and <contact> elements is set to ‘active’. ⮚ The event attribute within the <contact> element is set to ‘registered’ If the public user identity has been automatically registered ⮚ The state attribute within the <registration> and <contact> elements is set to ‘active’. ⮚ The event attribute within the <contact> element is set to ‘created’.
Content-Type. Support for the Content-Type header is mandatory for both UACs and UASs.
Content-Type. If Service Information is associated with the Application Server iFC for the REGISTER method then this SHOULD be included as an XML element in the message body of the REGISTER request. In this case then Content-Type header will include the MIME type application/3gpp-ims+xml as defined in section 7.6 in 3GPP TS 24.229 V7.2.0.