为提升您的使用体验,本站正在维护,部分功能暂时无法使用。如果本站文章无法解决您的问题,您想要向社区提问的话,请到 Twitter 上的 @FirefoxSupport 或 Reddit 上的 /r/firefox 提问,我们的支持社区将会很快回复您的疑问。

搜索 | 用户支持

防范以用户支持为名的诈骗。我们绝对不会要求您拨打电话或发送短信,及提供任何个人信息。请使用“举报滥用”选项报告涉及违规的行为。

详细了解

firefox webrtc rtp payload type

  • 1 个回答
  • 1 人有此问题
  • 15 次查看
  • 最后回复者为 guigs

more options

I'm seeing an issue when placing a webrtc call with firefox when the answer SDP has different payload types than the offer. for example, i get an offer from firefox that has the opus codec with payload type 109. if the answer SDP comes in with the opus codec and payload type 110, audio will not be heard. looking in the WebRTC.log file you will see a whole bunch of "IncomingRTPPacket received invalid payloadtype".

i believe the correct behavior in this case is for firefox to transmit opus with RTP payload type 110 (ie the remote payload type) and expect to receive opus with payload type 109. it looks like firefox will send with 110 and expect to receive with 110.

the same scenario with chrome does not have a problem. if i change the SDP answer to match the payload type of the offer, audio can be heard in firefox.

the same issue can be seen with VP8 video or other codecs with dynamic payload types.

for reference, the relevant excerpt from rfc3264:

"In the case of RTP, if a particular codec was referenced with a

  specific payload type number in the offer, that same payload type
  number SHOULD be used for that codec in the answer. "

in this case the answer SDP is violating the SHOULD in the rfc, but this is sometimes unavoidable when interworking SDP between devices (ie some sort of back-to-back signaling agent).

I'm seeing an issue when placing a webrtc call with firefox when the answer SDP has different payload types than the offer. for example, i get an offer from firefox that has the opus codec with payload type 109. if the answer SDP comes in with the opus codec and payload type 110, audio will not be heard. looking in the WebRTC.log file you will see a whole bunch of "IncomingRTPPacket received invalid payloadtype". i believe the correct behavior in this case is for firefox to transmit opus with RTP payload type 110 (ie the remote payload type) and expect to receive opus with payload type 109. it looks like firefox will send with 110 and expect to receive with 110. the same scenario with chrome does not have a problem. if i change the SDP answer to match the payload type of the offer, audio can be heard in firefox. the same issue can be seen with VP8 video or other codecs with dynamic payload types. for reference, the relevant excerpt from rfc3264: "In the case of RTP, if a particular codec was referenced with a specific payload type number in the offer, that same payload type number SHOULD be used for that codec in the answer. " in this case the answer SDP is violating the SHOULD in the rfc, but this is sometimes unavoidable when interworking SDP between devices (ie some sort of back-to-back signaling agent).

所有回复 (1)

more options

That RFC is a proposed standard at the moment http://datatracker.ietf.org/doc/rfc3264/

However, this would be a great bug for tech evangelism, I would encourage you to file a bug with some technical examples. Way to keep the web open!