# LS on IMS Network Behaviour for New Contact Header Parameters

## Document Information
- **Source:** SA4
- **Target:** SA2
- **Release:** Rel-19/Rel-20
- **Work Items:** AvCall-MED, FS_Avatar_Ph2_MED
- **Meeting:** SA4 Meeting #135, Goa, India, February 9-13, 2026

## Overall Description

### Context and Background
SA4 has introduced new media configuration requirements in TS 26.264 for Augmented Reality (AR) and avatar-based MTSI clients. These developments have architectural implications for IMS network behavior that require SA2's attention and clarification.

### AR-MTSI Client Requirements (Clause 7 of TS 26.264)

**New Contact Header Parameter: `+sip.3gpp-ar-support`**

- Indicates the level of AR capability during SIP registration
- Signals that the terminal requires network-based rendering support for AR call participation
- AR-MTSI terminals must register with appropriate parameter values depending on whether terminal-based or network-based rendering is used

### Avatar Support Requirements (Clause 7.3 of TS 26.264)

**New Contact Header Parameter: `+sip.3gpp-avatar-support`**

- **Values:**
  - `"avatar-capable"`: Terminal can animate and render avatars locally
  - `"avatar-assisted"`: Network support required for avatar animation and rendering

**Network-Based Avatar Rendering (Clause 7.3.2):**
- When network-based avatar animation/rendering is requested, an AR Application Server shall:
  - Allocate a Media Function (MF) capable of real-time avatar rendering
  - Configure the MF based on receiving UE's video capabilities
  - Modify SDP to insert the MF into the media path

## Identified Architectural Gap

SA4 has identified that **IMS architecture specifications do not currently define the behavior of IMS network elements** when MTSI clients include these new Contact header field parameters (`+sip.3gpp-ar-support` and/or `+sip.3gpp-avatar-support`) in SIP REGISTER messages.

## Question to SA2

**Is there any architectural guidance on:**
- Whether or how IMS entities should interpret these parameters?
- How suitable Media Functions providing AR rendering and/or avatar rendering support should be selected and invoked?

## Request to SA2

If guidance is not currently available, SA4 requests SA2 to consider studying, in the IMS architecture specifications, the expected behavior of IMS network elements when an AR-MTSI client registers its capabilities via Contact header field parameters.

**This includes (but is not limited to):**
- Mechanisms for recognizing terminal capabilities during registration
- Enabling the provisioning or insertion of appropriate Media Functions to support:
  - AR rendering
  - Avatar rendering
  - Future similar services within an IMS session

## Rationale

SA4 believes such clarification would:
- Ensure architectural consistency
- Facilitate interoperable deployment of AR and avatar-based services in IMS

## Action Requested

SA4 kindly asks SA2 to review the above information and provide guidance on the way forward.