Funkcjonalność tej witryny będzie ograniczona w czasie konserwacji. Jeśli artykuł nie rozwiązuje twojego problemu i chcesz zadać pytanie, to nasza społeczność wsparcia jest dostępna na @FirefoxSupport na Twitterze i /r/firefox na Reddicie.

Przeszukaj pomoc

Unikaj oszustw związanych z pomocą.Nigdy nie będziemy prosić Cię o dzwonienie na numer telefonu, wysyłanie SMS-ów ani o udostępnianie danych osobowych. Zgłoś podejrzaną aktywność, korzystając z opcji „Zgłoś nadużycie”.

Więcej informacji

firefox webrtc rtp payload type

  • 1 odpowiedź
  • 1 osoba ma ten problem
  • 4 wyświetlenia
  • Ostatnia odpowiedź od 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).

Wszystkie odpowiedzi (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!