Testing against FF 33 beta. H264 SDP offered contains the following a=rtpmap options: m=video 62635 RTP/SAVPF 120 126 97 ... a=rtpmap:120 VP8/90000 a=rtpmap:126 H264/90000 a=fmtp:126 profile-level-id=42e01f;packetization-mode=1 a=rtpmap:97 H264/90000 a=fmtp:97 profile-level-id=42e01f a=sendrecv The answer returned by my far end also supports both: m=video 40078 RTP/SAVPF 97 126 120 ... a=rtpmap:97 H264/90000 a=fmtp:97 profile-level-id=42c014;max-br=1659;max-mbps=108000;max-fs=3600;max-smbps=108000;max-fps=3000 a=rtpmap:126 H264/90000 a=fmtp:126 profile-level-id=42c014;max-br=1659;max-mbps=108000;max-fs=3600;max-smbps=108000;max-fps=3000;packetization-mode=1 a=rtpmap:120 VP8/90000 a=fmtp:120 max-fs=3600;max-fr=30 a=sendrecv However, given this, we choose to send H264 packetization mode 0, on Payload Type 97. No video is displayed. If I remove the lines: a=rtpmap:126 H264/90000 a=fmtp:126 profile-level-id=42c014;max-br=1659;max-mbps=108000;max-fs=3600;max-smbps=108000;max-fps=3000;packetization-mode=1 And so the SDP answer looks like this: m=video 40084 RTP/SAVPF 97 120 ... a=rtpmap:97 H264/90000 a=fmtp:97 profile-level-id=42c014;max-br=1659;max-mbps=108000;max-fs=3600;max-smbps=108000;max-fps=3000 a=rtpmap:120 VP8/90000 a=fmtp:120 max-fs=3600;max-fr=30 Video is displayed just fine. There is no difference in what we are sending, it is still packetization mode 0 on PT 97. It appears to be that the presence of this packetization-mode=1 line in the SDP that is causing the problem, not the RTP that we are sending.

Per SDP rules, it *should* we ready to accept any of 97/126/120 at any time (and on a codec switch shut down the old codec and spin up the new one). There are no rules saying it must send the same codec it receives, but endpoints that support multiple active codecs typically do so. There is a "should" that if multiple codecs are in the answer, the first should be preferred (for sending) at both ends.

Looking at the code starting at gsm_sdp.c:3259 it appears that we are walking through our local list looking for a match on the remote side. This is giving priority to the ordering from the offer in this case. We could probably switch that to walk through the codecs in the answer to give its order priority, but I don't think we're going to be set up to accept more than one until after the SDP handling rewrite.

ehugg: note the block starting at ling 3276 - 3259 only applies if you're using the "preferred codec" list; if we aren't or don't find the preferred codec, then the master list is the remote. There may still be an issue here somewhere, especially if there are multiple responses. It *looks* like it should upport multiple answer codecs - but other parts linking it to videoconduits/etc might not.

Is this still broken?

Apologies for the delayed response. Tested against FF 38 and all seems ok now.