by default, you cannot change the spatial resolution of an ongoing call without renegotiating.
nothing prevents you from monitoring the bandwidth (through the stats API) and renegotiating when you want to. renegociation comes at a cost as you have to remove the stream from the peer connection, call again GUM with different constraints, and go through the SDP O/A and ICE checking again, during which no stream is sent.
now, the VP8 codec is adaptive which means, it will adapt the quality of the video (*without changing its resolution*) depending on network conditions. It actually starts very low (around50k) and slowly ramps up to 2M or the maximum bandwidth available whichever is smaller.
"work fine" is an ill-defined term here. By default you won't lose connection (ICE might disconnect and reconnect under super low bandwidth, video freezes, but it comes back). The quality of the video call will be lowered, but you might not actually perceive it. I'm not convinced that changing the spatial resolution is something you want to do practically.
try it yourself using
apprtc.appspot.com over a low bandwidth connection, and open chrome://webrtc-internals on a separate window to check the bandwidth usage. in that page you should shave a BWE-video graph, that illustrates what I just said. I attached two experiments I did several months ago to illustrate the ramp up, and the bandwidth adaptation.