User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20140722 Firefox/24.0 Iceweasel/24.7.0 (Nightly/Aurora) Build ID: 20140723000133 Steps to reproduce: createOffer() Actual results: offer contains RTP/SAVPF Expected results: offer contains UDP/TLS/RTP/SAVPF

This comment in the Chrome bug tracker: http://code.google.com/p/webrtc/issues/detail?id=2796#c15 suggests that in future, Chrome should send "UPD/TLS/RTP/SAVPF" by default. However, Firefox chokes on that. Asterisk is also sending "UPD/TLS/RTP/SAVPF" by default, it can be tweaked by the "force_avp=yes" setting in sip.conf. Without that workaround, Firefox can't parse SDP from Asterisk. a) Firefox should accept an SDP that uses either convention, the current approach (e.g. RTP/SAVPF) or the newer values (UDP/TLS/RTP/SAVPF and other permutations) b) Firefox should consider creating SDP with UDP/TLS/RTP/SAVPF by default

Yes to both of these. This is soon to be a specification requirement: https://github.com/rtcweb-wg/jsep/pull/81

Thanks for the fast response on this. JSCommunicator and SIPml5 have workarounds in place in JavaScript for linking Firefox to Asterisk with this issue. That may also help for the situation when new browser meets old. The new PyRoute plugin in the repro SIP proxy can also do transforms on the message body, this is also a very quick and easy way for people to work around any mismatch without changing their JavaScript.

We will probably do this in two stages: 1. Make Firefox be more accepting. 2. Make Firefox generate the new stuff.