Ky sajt do të funksionojë me kufizime, teksa bëjmë mirëmbajtjen e tij për të përmirësuar punën tuaj. Nëse një artikull nuk e zgjidh problemin tuaj dhe dëshironi të bëni një pyetje, kemi bashkësinë tonë të asistencës, e gatshme për t’ju ndihmuar, te @FirefoxSupport në Twitter dhe/r/firefox në Reddit.

Kërkoni te Asistenca

Shmangni karremëzime gjoja asistence. S’do t’ju kërkojmë kurrë të bëni një thirrje apo të dërgoni tekst te një numër telefoni, apo të na jepni të dhëna personale. Ju lutemi, raportoni veprimtari të dyshimtë duke përdorur mundësinë “Raportoni Abuzim”.

Mësoni Më Tepër

firefox webrtc rtp payload type

  • 1 përgjigje
  • 1 e ka hasur këtë problem
  • 15 parje
  • Përgjigjja më e re nga 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).

Krejt Përgjigjet (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!