thing that is used for more than webrtc; do you want
to disable that also?
Best regards,
Byron Campen
On 9/14/19 4:27 AM, sabi.oxo7...@gmail.com wrote:
I have question... I am using Mozilla Firefox 56 beta 2 version... i try to
disable my webrtc but I fail... I added some extensions and use m
I recommend using addTrack at all times unless you care about the
particulars of how send/receive tracks are paired up, or unless you have to
set the sendEncodings on the transceiver (eg; you want to use simulcast).
Best regards,
Byron Campen
On Tue, Aug 6, 2019 at 9:05 PM SPChan wrote
*
Best regards,
Byron Campen
On 8/6/19 10:01 AM, Richard Chan wrote:
MDN have recently updated the WebRTC demo webrtc-from-chat
https://github.com/mdn/samples-server/commits/master
to use addTransceiver. What is observed is that call setup requires an
extra roundtrip because the
answer SDP con
Yes, the order in which transceivers are created (ie; the order
that you add tracks) dictates the order of the media sections, and
answers must have exactly the same number of media sections in the same
order as the offer.
Best regards,
Byron Campen
On 3/20/19 4:33 AM, sha
ust put mids in your SDP, because mids are
crucially important to the latest RTCRtpTransceiver-based specifications.
Best regards,
Byron Campen
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
Opened a bug for this:
https://bugzilla.mozilla.org/show_bug.cgi?id=1448846
Best regards,
Byron Campen
On 3/23/18 10:14 AM, sha wrote:
Hello all,
I am facing a very strange error with ICE negotiation during WebRTC call setup.
Firefox(58.0.2 - 64bit) fails to respond to STUN
us
m-section will have its send bit cleared.
Best regards,
Byron Campen
On 2/23/18 8:50 AM, Lorenzo Miniero wrote:
Hi,
I noticed what may be an issue in Firefox > 58. In my client side renegotiation
code, if I replace, let's say, a webcam with another on an existing PeerConnection
and d
No, it is not possible to use an offer as an answer. What problem
are you trying to solve by doing this? There might be another way that
will work.
Best regards,
Byron Campen
On 7/11/17 6:19 PM, arye...@gmail.com wrote:
The server create SDP offer.
Is it possible to create SDP offer on
g encodings. We would need to implicitly set a max-bitrate
based on the resolution of the encoding for this to work.
Best regards,
Byron Campen
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
RFC 5245 does not allow the priority for a candidate to be 0:
"
: is a positive integer between 1 and (2**31 - 1).
"
Best regards,
Byron Campen
On 6/7/17 2:09 AM, Michael Zak wrote:
Hi
This candidate is accepted by Chrome.
I placed below the Firefox connectivity log where
I doubt this has anything to do with IPV6, but there could be a lot
of things going on here. Looking at the ICE logging would be the next
step in figuring this out.
Best regards,
Byron Campen
On 4/17/17 12:40 PM, Alexander Abagian wrote:
Hi,
I've got a case where a local Fi
efault, so we ignore it. 18 is G729,
which we do not support. 9 is G722, which we _do_ support, and so we
answer with that. PCMA (8) and PCMU (0) are at the end of the list, so
their priority is quite low.
Best regards,
Byron Campen
On 3/22/17 6:58 PM, Alexander Abagian wrote:
I guess, Firefo
pening with the addstream ?
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
Can you file a bug?
Best regards,
Byron Campen
___
dev-media mailing
On 7/22/16 4:52 AM, nskhair...@gmail.com wrote:
On Thursday, March 24, 2016 at 6:34:51 PM UTC+5:30, Byron Campen wrote:
I believe we'll tolerate that.
Best regards,
Byron Campen
On 3/24/16 6:10 AM, Alexander Abagian wrote:
Would it be OK if I use 0.0.0.0 as a raddr ?
On Thursday, Mar
Could you open a bug and attach the logs and packet captures?
Best regards,
Byron Campen
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
I believe we'll tolerate that.
Best regards,
Byron Campen
On 3/24/16 6:10 AM, Alexander Abagian wrote:
Would it be OK if I use 0.0.0.0 as a raddr ?
On Thursday, March 17, 2016 at 8:31:57 PM UTC+3, Byron Campen wrote:
On 3/17/16 12:18 PM, Alexander Abagian wrote:
Hi,
I'
1 UDP 2130706430
91.224.14.66 8001 typ srflx generation 0
What's wrong with this ICE candidate ? Firefox wants raddr & rport ?
Yes, raddr and rport are required on srflx, prflx, and relay
candidates according to RFC 5245.
Best regards
Having duplicate ssrcs for just SRTCP is still really problematic
from a crypto perspective. You'll either need to fix your media server,
or perhaps work around by using multiple PeerConnections.
Best regards,
Byron Campen
On 2/22/16 8:55 AM, Alexander Abagian wrote:
The server i
breaks if they aren't unique (including compromising the security
of SRTP).
What problem are you trying to solve here?
Best regards,
Byron Campen
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
On 2/12/16 12:15 PM, Randell Jesup wrote:
On 2/12/2016 11:58 AM, Byron Campen wrote:
On 2/12/16 9:26 AM, Alexander Abagian wrote:
Thank you for the answer.
I've changed the order of m-sections from all-audio-first (I've done
it so because have seen this requirement it in some RFC)
es of SDP offer/answer.
Best regards,
Byron Campen
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
I am surprised that reoffer wasn't rejected outright; you cannot
reorder m-sections like this. I will need to look into why you did not
hit an error sooner.
Best regards,
Byron Campen
On 2/11/16 10:54 AM, Alexander Abagian wrote:
Does Firefox support partial offers and answers
On 2/2/16 9:15 AM, Byron Campen wrote:
On 2/2/16 9:03 AM, Kevin Canévet wrote:
Hello,
I was wondering what this figure (1024 in the example below) means
and I could not found the relevent specification.
> a=sctpmap:5000 webrtc-datachannel 1024
Any hints ?
Thanks,
Ke
That's not what that number means. This is the number of incoming
streams that is supported (see
https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-05#section-5.1)
Best regards,
Byron Campen
On 2/2/16 9:06 AM, Bruno Magalhães wrote:
Hello,
Following the link
https://tools.iet
dia mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
This is from draft-ietf-mmusic-sctp-sdp-06. That spec has since
changed in major (non-backward-compatible) ways, and as such we have not
adopted the newer spec yet.
Best regards,
Byron Cam
ut it is moot since bundle is in use (meaning that the transport
info from the first audio m-section is authoritative). It is still a bug
though.
Best regards,
Byron Campen
On 1/28/16 7:31 AM, Alexander Abagian wrote:
Byron,
What would you recommend for the established ICE connection
Maybe a problem with packetization mode 0? That is the codec
preferred by janus in its answer.
Best regards,
Byron Campen
On 1/27/16 3:09 PM, Adam Roach wrote:
Byron --
Running through the testcase they put up for us, I get this for the
SDP that does not work:
Local SDP
v=0
o=mozilla
Can you send the full SDP?
Best regards,
Byron Campen
On 1/27/16 12:53 PM, Christian wrote:
Hi,
We are trying to analyze a problem with a RTCPeerConnection between
Firefox 44.0 and a Cisco 8520 MCU (connected via the Janus WebRTC
Gateway (https://github.com/meetecho/janus-gateway
Thanks. So the port 9 on the video m-sections is normal, since
they're new and in their own bundle. The port on the audio m-sections
should have been the same on the second go-round, since at that point we
knew that bundle was in use. There's a bug to fix there.
Best regards,
By
I suppose I should also point out that if the video m-sections are
new, and are in a brand new bundle, they will have port 9 until a
candidate is gathered. I'm more interested in why the two bundled audio
m-sections have different ports.
Best regards,
Byron Campen
On 1/26/16 1:
It would help if I could see the initial offer/answer as well (this
looks like a renegotiation to me). There may be some bug in multiple
bundle groups and renegotiation.
Best regards,
Byron Campen
On 1/26/16 1:31 PM, Alexander Abagian wrote:
Hi,
Does Firefox supports multple BUNDLEs ? I
ings like offerToReceiveVideo on
createAnswer (if it did, you would see a=inactive in the case you
describe). I think you could munge the SDP to be a=inactive though. I
doubt we will end up implementing these things in createAnswer, since
they've been removed entirel
This is very strange. getAudioTracks() and getVideoTracks() do not
seem to be working for you. Please open a bug in WebRTC : Audio/Video
and we'll continue over in bugzilla.
Best regards,
Byron Campen
On 11/27/15 6:16 AM, Alexander Abagian wrote:
I can't provide a service for r
I would not expect that to ever happen. Could you file a bug under
Webrtc: Signaling and link to a service that has this problem (or attach
a test-case)?
Best regards,
Byron Campen
On 11/20/15 8:43 AM, Alexander Abagian wrote:
Hi,
Could someone give me an idea for which case onaddstream
Could you open a bug in Webrtc: Networking and attach a pcap?
Best regards,
Byron Campen
On 11/20/15 8:31 AM, aabag...@gmail.com wrote:
Hi guys,
I have problem with video channel DTLS starting. I'm implementing a WebRTC
client for mediaserver and I have to split currently multistr
x27;t support ICE. Webrtc endpoints must support
ICE (since the DTLS handshake is not allowed to begin until ICE
completes), so they should not be using that address. However, for the
sake of interop we're making this change over here:
https://bugzilla.mozilla.org/show_bug.cgi?id=119281
verify that their implementation/service
can cope with this change. Firefox will permit the protocol to be changed
back to RTP/SAVPF via SDP munging in JS, as a work around.
Best regards,
Byron Campen
___
dev-media mailing list
dev-media@lists.mozilla.org
-media
We're aware of this, we just haven't gotten around to it yet.
https://bugzilla.mozilla.org/show_bug.cgi?id=852665
Best regards,
Byron Campen
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
You can also rewrite the local SDP to alter the priority.
Best regards,
Byron Campen
On 6/26/15 9:53 AM, Ethan Hugg wrote:
You can make it prefer H264 by adding the about:config parameter "media.
navigator.video.preferred_codec" as an integer type and setting its value
to 126.
code to use constrained baseline.
Best regards,
Byron Campen
On 6/2/15 5:57 AM, asla...@amaryllo.eu wrote:
Hi all,
My device doesn't work again with FF39 webrtc. After tracing FF39 source, I
find my sdp is denied because my profile-level-id=4d0028. This profile-level-id
indicates main pr
Can you check about:webrtc and send me the connection log, the
table of ICE stats, and the SDP?
Best regards,
Byron Campen
On 5/22/15 9:32 AM, jon.peter.dav...@gmail.com wrote:
I am using JsSIP on Firefox 38 and making calls via Kamailio SIP proxy and
media relay. With an inbound call
this
is no longer necessary. stun.services.mozilla.com will continue to be
around, so if you are using it explicitly this will continue to work;
you only need to take action if you have a Firefox-only demo that relied
on this default being there.
Best regards,
Byron Campen
Yeah, sorry about that. New patch coming in a moment.
Best regards,
Byron Campen
On 5/18/15 8:17 AM, James Criscuolo wrote:
Upon closer inspection, I hit the compile failure that Randell referred to in
his review.
On Friday, May 15, 2015 at 7:25:21 PM UTC-4, Byron Campen wrote:
I have a
I have a fix here: https://bugzilla.mozilla.org/show_bug.cgi?id=1165520
Best regards,
Byron Campen
On 5/15/15 7:21 AM, Randell Jesup wrote:
On 5/14/2015 2:23 PM, ja...@onsip.com wrote:
Hello,
I've been doing a lot of research into this, but I figured I'd post
what I've di
ble there was a regression in 38. Did 37 (or 36)
answer in the same way to a "ccm fir"-only offer?
I'm pretty sure this was the behavior all along;
signaling_unittests has several test-cases that require the answerer to
add rtcp-fbs that weren't in the
I think you may be running into bug 1152093
(https://bugzilla.mozilla.org/show_bug.cgi?id=1152093). Try changing the
case on the codec names (eg; G722, PCMU, PCMA, etc).
Best regards,
Byron Campen
On 4/27/15 9:09 AM, Rajarshi Chaudhuri wrote:
Hi -
We have a WebRTC Gateway and that&#
t we have completely
rewritten our JSEP engine, and one of the things the old one did was
break spec and assume a missing level-asymmetry-allowed param had a
default value of 1, instead of 0.
Best regards,
Byron Campen
___
dev-media mailin
ither
onSetRemoteDescriptionError/Success?
Best regards,
Byron Campen
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
yllo.eu:3478) and
candidate srflx(IP4:192.168.0.146:51606/UDP|stun.services.mozilla.com:3478)
The ip address(192.168.0.146) is my PC, and also mean FF37. Therefore, I think the error
is occurring when "FF37 makes candidates by asking STUN Server". This may not
causing any incorrect information from my device, right? (not sure)
Does a
e, and I can point you at a binary.
Best regards,
Byron Campen
On 12/4/14 2:03 PM, Nils Ohlmeier wrote:
I'm assuming the topmost call is the problematic one: Your local SDP
does not show even any host candidates.
Does your service live.amaryllo.eu support trickle ICE at all? E.g
That download link is not working for me. Can you forward it directly?
Best regards,
Byron Campen
On 12/3/14 6:07 PM, asla...@amaryllo.eu wrote:
Here is a full logging message
(https://mega.co.nz/#!lNckgIwD!wFL9yXHbH-U79iaOYHp_MphuKol3-14tA_yRQokWylk)
Actually, I am very sure I had set
oving that default stun.services.mozilla.com sometime
this coming year. Don't count on it being around forever.
Can you get us some logging for the failure you're seeing, and
perhaps a packet trace?
Best regards,
Byron Campen
On 12/2/14 11:53 PM, asla...@amaryllo.eu wrote:
Hi a
to see whether USE-CANDIDATE was set and setting the
nominated flag if so
(https://tools.ietf.org/html/rfc5245#section-7.2.1.5). It should not
need a second STUN request on that pair to perform these steps.
Best regards,
Byron Campen
On 11/18/14 5:39 AM, asla...@amaryllo.eu wrote:
Like the
We are never seeing a candidate from the other side, nor do we
appear to be receiving STUN checks.
Best regards,
Byron Campen
On 11/17/14 10:48 AM, Frank Coco wrote:
On Monday, November 17, 2014 11:34:28 AM UTC-5, Frank Coco wrote:
I am having an issue in the following call flow when
So what was on about:webrtc (including the ICE connection log)?
That's going to be a better diagnostic tool than the JS logging for ICE
problems.
Best regards,
Byron Campen
On 11/17/14 8:30 AM, Frank Coco wrote:
I am having an issue in the following call flow when trickle ICE is
uot;
candidate, and what the string "prflx" stands for in the candidate you
did not expect).
Best regards,
Byron Campen
On 11/17/14 9:23 AM, Nils Ohlmeier wrote:
Hi Aslan,
Neither the SDP nor the ICE candidates below are from Firefox. Firefox
does not (yet) support Bundle or labels.
Lots of things could happen. NATs could be letting STUN through but
not RTP, the DTLS handshake could have failed due to an interop problem,
media packets could be going to the wrong port, etc. Packet captures
would tell us what is going on, I think.
Best regards,
Byron Campen
On 11/11
Packet captures (one taken on each device) would go a long way toward
diagnosing the problem.
Best regards,
Byron Campen
On Nov 11, 2014 6:19 PM, wrote:
> Here are more information:
>
> 1. Airport, means https://www.apple.com/tw/airport-extreme/ (This device)
> 2. 10.0.1.
On 11/11/14 10:06 AM, Randell Jesup wrote:
On 11/11/2014 11:45 AM, Byron Campen wrote:
Do you get audio? What implementation is the other side? If the
other
side is also Firefox, what does about:webrtc show there? What webrtc
service are you using? From an ICE perspective things look OK
can still fail after that though.
Best regards,
Byron Campen
On Nov 11, 2014 8:14 AM, wrote:
> Hi,
>
> I found a strange problem on my side. I have a PC under Airport WiFi AP
> (but connected by wire), and try to use RTCPeerConnection to connect the
> other device. However, th
Might be this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=935806
Best regards,
Byron Campen
On 11/4/14 7:50 AM, Lorenzo Miniero wrote:
Hi,
we encountered a weird issue with both Firefox stable and Firefox Nightly in
our setup. Specifically, some sessions involving TURN seem to stop
Can you get a PCAP and the full log? Also, what version of firefox
are you using?
Best regards,
Byron Campen
On 10/16/14 1:36 AM, regno...@temasys.com.sg wrote:
Hi all,
I'm working with a MCU and I encounter a problem only and only when the MCU is
online (on the cloud - Amazon).
A couple of questions; does this still fail on the latest nightly, and what
do we see on about:webrtc?
Best regards,
Byron Campen
On Jun 9, 2014 6:50 AM, wrote:
> We are experiencing the same problem. We have a TURN server specified in
> the PeerConnection settings, and yet, none
You know, we might be able to have our cake and eat it too. Just
call it PTS, and pretend it is an acronym.
Byron
On 2/20/14 9:55 AM, Christopher Lee wrote:
Hi all,
I would say that *if* the majority of the team agreed to this, let's move
forward with this name.
I know it's unlikely we'
Ultimately, we're going to need to hand out a URL that causes a call
to happen. To make sure you are understood, are you proposing making it
more "nouny" by doing something like passing out /contact/... URLs that
lead to a page with enough smarts to create a call (using the same
token) with
65 matches
Mail list logo
