Libjingle roll 129:132.

Libjingle roll 129:132.

Also update P2PPortAllocator for compatibility with the latest libjingle
changes.

BUG=121613
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=132307

[Sergey Ulanov, 2012-04-13 02:26:46]

New version of the previous reverted CL (
http://codereview.chromium.org/10024032/ )

The current libjingle behavior is intentional. We just need PortAllocator
changes for it to work correctly with the new libjingle.

[Wez, 2012-04-13 02:49:49]

http://codereview.chromium.org/10069046/diff/1/content/renderer/p2p/port_allo...
File content/renderer/p2p/port_allocator.cc (right):

http://codereview.chromium.org/10069046/diff/1/content/renderer/p2p/port_allo...
content/renderer/p2p/port_allocator.cc:197: "&password=" + password();
Are username() and password() URL-escaped, or guaranteed URL-friendly?

http://codereview.chromium.org/10069046/diff/1/content/renderer/p2p/port_allo...
content/renderer/p2p/port_allocator.cc:255: " user name that was specified in
the query";
I don't understand this error message.

This is the case where we've sent a request to a relay server to set up a
session, and it's responded with different username & password to the ones we
supplied it - you're now warning in that case rather than respecting the new
values.  Can you not set_username() to keep the original behaviour?

http://codereview.chromium.org/10069046/diff/1/content/renderer/p2p/port_allo...
content/renderer/p2p/port_allocator.cc:260: " user name that was specified in
the query";
typo: "user name" -> "password"

http://codereview.chromium.org/10069046/diff/1/third_party/libjingle/README.c...
File third_party/libjingle/README.chromium (right):

http://codereview.chromium.org/10069046/diff/1/third_party/libjingle/README.c...
third_party/libjingle/README.chromium:4: Version: 0.6.17
Has the libjingle version not changed?

http://codereview.chromium.org/10069046/diff/1/third_party/libjingle/README.c...
third_party/libjingle/README.chromium:5: Revision: 131
The version in DEPS is 132.

[Sergey Ulanov, 2012-04-13 19:50:37]

http://codereview.chromium.org/10069046/diff/1/content/renderer/p2p/port_allo...
File content/renderer/p2p/port_allocator.cc (right):

http://codereview.chromium.org/10069046/diff/1/content/renderer/p2p/port_allo...
content/renderer/p2p/port_allocator.cc:197: "&password=" + password();
On 2012/04/13 02:49:49, Wez wrote:
> Are username() and password() URL-escaped, or guaranteed URL-friendly?
That's a good catch! PortAllocator uses Base64 alphabet to generate these values
- they may contain plus sign, which needs to be encoded. Looks like there is
similar bug in libjingle's.

http://codereview.chromium.org/10069046/diff/1/content/renderer/p2p/port_allo...
content/renderer/p2p/port_allocator.cc:255: " user name that was specified in
the query";
On 2012/04/13 02:49:49, Wez wrote:
> I don't understand this error message.
> 
> This is the case where we've sent a request to a relay server to set up a
> session, and it's responded with different username & password to the ones we
> supplied it - you're now warning in that case rather than respecting the new
> values.  Can you not set_username() to keep the original behaviour?

Right. Previously username/password were generated on the relay server. Now we
specify them when creating relay session and expect to receive the same values
in the response. This warning is just so that we can see when the server returns
values that are different from we expected.

There are no set_username() and set_password() in the base PortAllocator() and
we shouldn't be changing them because they must be fixed per channel.

http://codereview.chromium.org/10069046/diff/1/content/renderer/p2p/port_allo...
content/renderer/p2p/port_allocator.cc:260: " user name that was specified in
the query";
On 2012/04/13 02:49:49, Wez wrote:
> typo: "user name" -> "password"

Done.

http://codereview.chromium.org/10069046/diff/1/third_party/libjingle/README.c...
File third_party/libjingle/README.chromium (right):

http://codereview.chromium.org/10069046/diff/1/third_party/libjingle/README.c...
third_party/libjingle/README.chromium:4: Version: 0.6.17
On 2012/04/13 02:49:49, Wez wrote:
> Has the libjingle version not changed?

No.

http://codereview.chromium.org/10069046/diff/1/third_party/libjingle/README.c...
third_party/libjingle/README.chromium:5: Revision: 131
On 2012/04/13 02:49:49, Wez wrote:
> The version in DEPS is 132.

Done.

[Wez, 2012-04-13 22:26:03]

http://codereview.chromium.org/10069046/diff/1/content/renderer/p2p/port_allo...
File content/renderer/p2p/port_allocator.cc (right):

http://codereview.chromium.org/10069046/diff/1/content/renderer/p2p/port_allo...
content/renderer/p2p/port_allocator.cc:255: " user name that was specified in
the query";
On 2012/04/13 19:50:38, sergeyu wrote:
> On 2012/04/13 02:49:49, Wez wrote:
> > I don't understand this error message.
> > 
> > This is the case where we've sent a request to a relay server to set up a
> > session, and it's responded with different username & password to the ones
we
> > supplied it - you're now warning in that case rather than respecting the new
> > values.  Can you not set_username() to keep the original behaviour?
> 
> Right. Previously username/password were generated on the relay server. Now we
> specify them when creating relay session and expect to receive the same values
> in the response. This warning is just so that we can see when the server
returns
> values that are different from we expected.
> 
> There are no set_username() and set_password() in the base PortAllocator() and
> we shouldn't be changing them because they must be fixed per channel.

In that case, should we fail this port allocator if we detect that they were
changed by the relay?

[Wez, 2012-04-13 22:27:04]

LGTM as-is, but I think it's worth aborting the port allocation if the
username/password change, as previously suggested.

[Sergey Ulanov, 2012-04-13 22:30:28]

http://codereview.chromium.org/10069046/diff/1/content/renderer/p2p/port_allo...
File content/renderer/p2p/port_allocator.cc (right):

http://codereview.chromium.org/10069046/diff/1/content/renderer/p2p/port_allo...
content/renderer/p2p/port_allocator.cc:255: " user name that was specified in
the query";
On 2012/04/13 22:26:04, Wez wrote:
> On 2012/04/13 19:50:38, sergeyu wrote:
> > On 2012/04/13 02:49:49, Wez wrote:
> > > I don't understand this error message.
> > > 
> > > This is the case where we've sent a request to a relay server to set up a
> > > session, and it's responded with different username & password to the ones
> we
> > > supplied it - you're now warning in that case rather than respecting the
new
> > > values.  Can you not set_username() to keep the original behaviour?
> > 
> > Right. Previously username/password were generated on the relay server. Now
we
> > specify them when creating relay session and expect to receive the same
values
> > in the response. This warning is just so that we can see when the server
> returns
> > values that are different from we expected.
> > 
> > There are no set_username() and set_password() in the base PortAllocator()
and
> > we shouldn't be changing them because they must be fixed per channel.
> 
> In that case, should we fail this port allocator if we detect that they were
> changed by the relay?

Done.

[commit-bot: I haz the power, 2012-04-13 22:30:55]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/sergeyu@chromium.org/10069046/11002

[commit-bot: I haz the power, 2012-04-13 22:54:11]

Try job failure for 10069046-11002 (retry) on linux_chromeos for step "compile"
(clobber build).
It's a second try, previously, step "compile" failed.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_chro...

[commit-bot: I haz the power, 2012-04-13 22:56:02]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/sergeyu@chromium.org/10069046/4008