Creating new peer; INVALID:ICE pwd has space
See original GitHub issueWhen creating a new peer, sometimes, the ICE password is created with a space, which throws an error as space character is not allowed.
Error: InvalidAccessError: Failed to execute 'setRemoteDescription' on 'RTCPeerConnection': Failed to set remote answer sdp: Failed to apply the description for 0: Invalid ICE parameters: ICE pwd must contain only alphanumeric characters, '+', and '/'.
I am stringifying the data to send through Pusher.io (as it doesn’t accept objects as the data). Could this be an issue with stringifying and then parsing, or is this an issue with simple-peer generating incorrectly formatted ICE password?
Issue Analytics
- State:
- Created 3 years ago
- Comments:6
Top Results From Across the Web
Is it possible to have bash escape spaces in pwd? - Ask Different
This command will escape spaces properly: printf "%q\n" "$(pwd)" | pbcopy. You can alias it using something with history like cwd if you ......
Read more >How to escape spaces in pwd path when creating a Boost ...
I want to compile Boost with some specific options (eg: using zlib from its latest source). So I try next bash code like:...
Read more >bash script fails if `pwd -P` contains folder name with space in it
Use quotes to include spaces and characters in filenames. CURRENTDIR=`pwd -P` function make_sym_link { ln -s "$CURRENTDIR/$1" "$HOME/.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I opted to check the SDP before its sent through Pusher. Turns out that the sdp being created generates the pwd: 1lkMoNSenQycEXa+aH7fAu0u
Whereas the sdp that get received after going through pusher.io comes back as: 1lkMoNSenQycEXa aH7fAu0u
The + is missing…
I am assuming that this is something to do with Pusher, and how they parse data. Anyways thanks for the info and help.
Go to
chrome://webrtc-internals
if it is Chrome orabout:webrtc
if it is Firefox and see what was actually generated by the browser and compare to what you see in signaling.