Цей вебсайт матиме обмежену функціональність, доки ми проводимо його обслуговування для поліпшення роботи. Якщо прочитана стаття не розв'язала вашу проблему і ви хочете поставити питання, наша спільнота підтримки з радістю допоможе вам на @FirefoxSupport у Twitter та /r/firefox на Reddit.

Шукати в статтях підтримки

Остерігайтеся нападів зловмисників. Mozilla ніколи не просить вас зателефонувати, надіслати номер телефону у повідомленні або поділитися з кимось особистими даними. Будь ласка, повідомте про підозрілі дії за допомогою меню “Повідомити про зловживання”

Докладніше

Ця тема перенесена в архів. Якщо вам потрібна допомога, запитайте.

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!