Ignore "b=AS:-1" instead of treating as a hard error.

webrtc/pc/webrtcsdp.cc

Index: webrtc/pc/webrtcsdp.cc
diff --git a/webrtc/pc/webrtcsdp.cc b/webrtc/pc/webrtcsdp.cc
index bc2ec89645d37e1667444d38b29c837be0d8fd3a..70deabfd0632a899592d7425b32ad8d813eec836 100644
--- a/webrtc/pc/webrtcsdp.cc
+++ b/webrtc/pc/webrtcsdp.cc
@@ -2719,8 +2719,15 @@ bool ParseContent(const std::string& message,
           if (!GetValueFromString(line, bandwidth, &b, error)) {
             return false;
           }
+          // TODO(deadbeef): Historically, applications may be setting a value
+          // of -1 to mean "unset any previously set bandwidth limit", even
+          // though ommitting the "b=AS" entirely will do just that. Once we've
+          // transitioned applications to doing the right thing, it would be
+          // better to treat this as a hard error instead of just ignoring it.

[Zhi Huang, 2017/08/03 18:12:47]

Is -1 the only valid negative value? If so, should we treat other negative
values as errors?

[Taylor Brandstetter, 2017/08/03 21:44:33]

I guess so. I'll add back the "ParseFailed" here and make two unit tests, one
for -1 and one for values < -1.

           if (b < 0) {
-            return ParseFailed(line, "b=AS value can't be negative.", error);
+            LOG(LS_WARNING)
+                << "SDP contains negative value for b=AS; ignoring.";
+            continue;
           }
           // We should never use more than the default bandwidth for RTP-based
           // data channels. Don't allow SDP to set the bandwidth, because