Trang web này sẽ có chức năng hạn chế trong khi chúng tôi trải qua bảo trì để cải thiện trải nghiệm của bạn. Nếu một bài viết không giải quyết được vấn đề của bạn và bạn muốn đặt câu hỏi, chúng tôi có cộng đồng hỗ trợ của chúng tôi đang chờ để giúp bạn tại @FirefoxSupport trên Twitter và /r/firefox trên Reddit.

Tìm kiếm hỗ trợ

Tránh các lừa đảo về hỗ trợ. Chúng tôi sẽ không bao giờ yêu cầu bạn gọi hoặc nhắn tin đến số điện thoại hoặc chia sẻ thông tin cá nhân. Vui lòng báo cáo hoạt động đáng ngờ bằng cách sử dụng tùy chọn "Báo cáo lạm dụng".

Tìm hiểu thêm

firefox webrtc rtp payload type

  • 1 trả lời
  • 1 gặp vấn đề này
  • 4 lượt xem
  • Trả lời mới nhất được viết bởi 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).

Tất cả các câu trả lời (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!