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.