[Technical] The LS proposes new SIP Contact header parameters (+sip.3gpp-ar-support, +sip.3gpp-avatar-support) without identifying any normative SIP/3GPP registration for these feature tags (e.g., in TS 24.229/24.229 annexes or an IANA/3GPP registry), so SA2 cannot assess interoperability or standard compliance as written.

[Technical] The statement that these parameters “signal that the terminal requires network-based rendering support” conflates capability indication with service request; in IMS, REGISTER Contact parameters are typically used for capability discovery/routing, not to mandate network media processing, so the intended semantics and enforcement point are unclear.

[Technical] The LS assigns network behavior to “an AR Application Server” (allocate MF, modify SDP, insert MF) but does not map this to existing IMS architectural roles (AS, MRFC/MRFP, SCC AS, IMS-ALG, B2BUA behavior) nor specify whether this is within IMS centralized services, SIP AS acting as B2BUA, or via MRF control—this is a major architectural ambiguity.

[Technical] “Modify SDP to insert the MF into the media path” is not generally achievable by a pure SIP proxy and implies B2BUA/SDP offer-answer manipulation; the LS should clarify the required SIP role and the impact on end-to-end integrity (e.g., SIP/SDP transparency, security, and interop).

[Technical] The LS focuses on REGISTER handling, but the described MF insertion is a session-time behavior (INVITE/UPDATE/PRACK/SDP negotiation); it is unclear why registration-time parameters alone are sufficient, and what happens if the UE’s needs vary per session or per media stream.

[Technical] No interaction is described with existing IMS capability mechanisms (e.g., SIP feature tags, Accept-Contact/Require/Supported, service profiles/IFCs, or 3GPP-defined media feature tags), risking duplication or inconsistent behavior across networks.

[Technical] The proposed values for +sip.3gpp-avatar-support (“avatar-capable”, “avatar-assisted”) are underspecified: there is no indication of whether multiple values are allowed, how they are encoded (token vs quoted-string), and how they relate to actual media/codec requirements in SDP (which ultimately drive rendering feasibility).

[Technical] The LS implies the network selects/configures MF “based on receiving UE’s video capabilities,” but does not define how the network learns those capabilities (REGISTER vs SDP in INVITE), nor how it handles mismatches between registered capabilities and actual session SDP.

[Technical] There is no consideration of roaming/interconnect: if these Contact parameters traverse visited/home networks or inter-IMS boundaries, behavior is undefined (stripping, privacy, policy), which is critical for IMS feature tags and service invocation.

[Technical] The term “Media Function (MF)” is not aligned with common IMS terminology (MRF/MRFP, IMS media resource function, or specific media processing functions); without anchoring to existing functional entities, SA2 cannot determine which specs need updates.

[Editorial] The LS cites “Clause 7” and “Clause 7.3/7.3.2 of TS 26.264” but provides no exact text excerpts or version/date of TS 26.264, making it hard for SA2 to verify the requirements and whether the parameters are already normatively defined.

[Editorial] The document mixes Rel-19/Rel-20 scope without stating which release introduces the parameters and expected IMS behavior, which may affect whether SA2 should treat this as a new WI, a CR to existing IMS specs, or a study item.