Does RTCRtpSender's dtmf attribute return the same object every time?

[foolip]

https://w3c.github.io/webrtc-pc/#rtcrtpsender-interface-extensions

If it does, then using [SameObject] would be good.

[annevk]

You cannot use it for nullable attributes: https://heycam.github.io/webidl/#SameObject. (Is there already an issue for this being unclear when it actually returns null?)

[foolip]

Oh, it's nullable, that's weird. It says "or null if unset" but it can't actually be set.

In what @alvestrand implemented in https://chromium-review.googlesource.com/c/chromium/src/+/926181 the getter could throw an exception, but never return null.

@jan-ivar, what does Gecko do?

[alvestrand]

Since the DTMF sender has state that is preserved between calls (the ToneBuffer), it would be very silly to have a new object be created. [SameObject] is good documentation.

[alvestrand]

It's supposed to be null when the track is not an audio track.

[foolip]

OK, so it should be nullable, and means we can't use [SameObject], as @annevk pointed out.

Maybe to make this clearer, create a slot for it and initialize it in https://w3c.github.io/webrtc-pc/#dfn-create-an-rtcrtpsender?