On Thursday, March 5, 2015 at 3:32:46 PM UTC, Eric Rescorla wrote: > This isn't going to work very well, with any version of Firefox. > > The semantics of this SDP is that you are offering a bunch of audio > streams, and that each of them is (for some unknown reason) with > a different codec. > > Firefox prior to 37 only supports one audio stream so it will try to > accept the first audio line, but will discover that it doesn't have > a compatible codec, so the negotiation will fail. > > Firefox after 37 will accept multiple audio streams, but will accept > *every* stream with a compatible codec, so in this case it would > probably accept PCMU and PCMA, with the result that you get > multiple incoming audio lines with (presumably) the same content. > > I also note that you haven't supplied any a=fingerprint lines which > are required for DTLS-SRTP but instead are supplying a=crypto > lines for SDES. This isn't compliant with the specification and Firefox > won't accept it, as will Chrome sometime in the future. > > -Ekr > > > > > > > On Thu, Mar 5, 2015 at 6:13 AM, <[email protected]> wrote: > > > I used Firefox 33.1, with JsSIP and Kamailio, with a call to our desktop > > video-conferencing application running on Windows. We were assessing > > interoperability between the audio and video codecs. Our application sent > > SDP with one media line per payload, rather than one media line containing > > a list of payload numbers, like this (simplified version): > > > > m=audio <port> RTP/SAVPF <payload-1> > > a=rtcp ... > > a=rtpmap:<payload-1> X-G72x1 > > a=ice... > > a=crypto... > > a=candidate... > > a=candidate... > > m=audio <port> RTP/SAVPF <payload-2> > > a=rtcp ... > > a=rtpmap:<payload-2> PCMA > > a=ice... > > a=crypto... > > a=candidate... > > a=candidate... > > m=audio <port> RTP/SAVPF <payload-3> > > a=rtcp ... > > a=rtpmap:<payload-3> PCMU > > a=ice... > > a=crypto... > > a=candidate... > > a=candidate... > > > > In the SIP INVITE, our application happened to have X-G72x1 as the first > > audio codec in the SDP, which I believe is not supported by firefox, and > > the call was rejected. My thoughts are that perhaps firefox is only > > expecting one m=audio, rather than multiple, and since the one at the top > > is an unsupported codec, it rejects it. Our application also listed PCMU > > and PCMA in following media lines, but perhaps these are simply ignored? > > _______________________________________________ > > dev-media mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-media > >
Many thanks for your reply. We do have fingerprint lines, I just hadn't included them in my blob - can I ask when will SDES support be removed? So, just to clarify, firefox after 37 will interpret multiple audio m lines as a request to supply multiple streams? _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
