[AVTCORE] Re: My pre-WGLC review of draft-ietf-avtcore-rtp-haptics

[Hyunsik Yang <[e-mail]>]

Sure, I will upload the updated version when it becomes available.

Thanks
Best regards,

-----Original Message-----
From: Jonathan Lennox <[e-mail]> 
Sent: Tuesday, March 4, 2025 3:06 PM
To: Hyunsik Yang <[e-mail]>
Cc: [e-mail]; [e-mail]; Xavier De Foy <[e-mail]>
Subject: Re: My pre-WGLC review of draft-ietf-avtcore-rtp-haptics



> On Feb 26, 2025, at 2:44 PM, Hyunsik Yang <[e-mail]> wrote:
> 
> Dear Jonathan,
> 
> First of all, thank you for your review.
> Based on your comments, I have revised the haptic draft, and we will update it soon. Below is my brief response to your question.
> 
> Regarding FIR, we agree with you. In the next version of the haptic document, we have described how FIR is applied to the haptic codec. Regarding SDP, we have reviewed all SDP parameters again and precisely defined the purpose, usage, and attributes of each parameter.
> 
> Here is the text that we plan to add to the draft to address your points:
> 
> section 5.4
> "In some multimedia conference scenarios using an RTP video mixer (e.g., when adding or selecting a new source), it is recommended to use Full Intra Request (FIR) feedback messages with Haptic {{RFC5104}}. The purpose of the FIR message is to force an encoder to send a decoder refresh point at the earliest opportunity. In the context of haptics, an appropriate decoder refresh point is an initialization MIHS unit. The initialization MIHS unit point enables a decoder to be reset to a known state and be able decode all MIHS units following it.  "

I would say “cause the encoder” rather than “force the encoder” (the encoder could always choose to do something else, e.g. leave the session, instead), but otherwise this sounds good.

> section 7.1
> 
> When used for a unidirectional stream, the SDP parameters represent the properties of the sender (on the sending side) and of the receiver (on the receiving side). When used for a sendrecv stream, the SDP parameters represent the properties of the receiver. The receiver properties expressed using the SDP parameters 'hmpg-ver', 'hmpg-profile'  and 'hmpg-lvl' have a mandatory character, since they represent implementation capabilities. The properties expressed using the other SDP parameters are provided as recommendations for efficient data transmission and is not binding, meaning that a sender is encouraged but not required to conform to the parameters specified by the receiver.
> Any receiver compliant with {{ISO.IEC.23090-31}} must accept any stream with a compatible version, profile and level. A receiver supporting a more general profile will accept a stream corresponding to a same or less general profile (e.g., "main" is more general than "simple-parametric"). A receiver supporting a given level will accept a stream corresponding to a same or lower level. A receiver supporting a given version will accept a stream corresponding to the same version and may accept other versions. A receiver may ignore any part of a received stream, e.g., that it does not have support for rendering.

This certainly seems better!

I apologize for not responding until after the draft deadline.  Can you submit a draft as soon as the repository re-opens, at the beginning of IETF week?




> If you have any questions, please feel free to contact me!
> 
> Thanks.
> Best regards,
> 
> -----Original Message-----
> From: Jonathan Lennox <[e-mail]>
> Sent: Tuesday, February 11, 2025 5:48 PM
> To: [e-mail]; [e-mail]
> Subject: My pre-WGLC review of draft-ietf-avtcore-rtp-haptics
> 
> In the interim meeting today, we discussed that the Haptics draft has been lingering for some time (my apologies!) and should be considered for WGLC.
> 
> In preparation for this, I reviewed the draft, and I had some comments.  I suspect these are issues that would come up in a WGLC, and so it would probably be better to get a consensus resolution before WGLC.
> 
> These are all comments as an individual, not as chair; all these decisions are subject to working group consensus, and if the WG feels I’m wrong about any of these points, that’s fine.
> 
> 
> The RTP payload proper seems well-defined.
> 
> 
> I observe that HMPG, like video codecs, supports both dependent and independent frames.  Thus, I would ask whether there should be a section in this document defining the use of RTCP feedback messages with this codec — specifically, I would suggest that the spec define that support for the Full Intra Request (FIR) feedback message MAY be negotiated, and when one is received, a sender MUST send an Independent unit at its earliest convenience.  This will make implementation of multi-party topologies much easier.
> 
> 
> The other point I would make is that I feel that the SDP offer/answer negotiation section is somewhat under-specified.  In particular, it is unclear what happens in a sendrecv media section; in that case, which payload parameters indicate receiver capabilities, and which ones indicate sender properties?
> 
> (In general for most RTP payloads, we’ve found it most useful for SDP 
> parameters to indicate receiver capabilities in this case, where each 
> side indicates its own capabilities; but this needs to be made clear.)
> 
> 
> Additionally, the document says that the payload parameters allow a receiver to “indicate a preference”.  Does this mean that these parameters are merely advisory, to indicate to the sender what information is useful, but a receiver MUST be prepared to receive any valid HMPG stream regardless of what it sent in SDP?  Or conversely, should these parameters be considered binding, such that a sender MUST conform to the parameters specified by the receiver?
> 
> Different payloads have made different choices here; generally, the philosophy that a receiver MUST be prepared to receive any valid stream makes for the easiest interop, but this can impose a lot of complexity on implementors of receivers.  In practice this decision should be based on what existing HMPG decoder libraries can do - can they consume any valid HMPG bitstream (even if they ignore parts of it that aren’t relevant to them), or do they have limitations on what they can support?
> 
> 
> Hopefully these are both relatively easy questions to answer.
> 
> Thanks!
> 
> Jonathan
> 
> [Banner]
> 
> [Banner]<https://www.interdigital.com/white_papers/spotlight-on-sustai
> nability-towards-a-greener-tv-and-video-value-chain?utm_source=email&u
> tm_medium=Email&utm_term=signature&utm_content=email&utm_campaign=sust
> ainability>
> 
> Spotlight on Sustainability: Towards a greener TV and video value 
> chain<https://www.interdigital.com/white_papers/spotlight-on-sustainab
> ility-towards-a-greener-tv-and-video-value-chain?utm_source=email&utm_
> medium=Email&utm_term=signature&utm_content=email&utm_campaign=sustain
> ability> This e-mail is intended only for the use of the individual or 
> entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.