This issue first occurred in M56, the problem occurs when the host or client sends a session-terminate jingle message and then closes the P2P channels, but the jingle message is either not sent or arrives after the other end registers the closure of the P2P channels (which is unexpected).

Prior to M56, the call to send the jingle message took long enough that the message would frequently be sent before the P2P channels were closed.  However the following CL changed the timing in the underlying socket and made this race condition occur more frequently:
commit 3418e81ff9636db1d9e0de7c60e002788b51f5ea
Author: davidben <davidben@chromium.org>
Date:   Tue Oct 18 17:09:45 2016 -0700

    Drop buffers in idle SSLClientSockets (and SSLServerSockets).

    <description removed to save space>

    Review-Url: https://codereview.chromium.org/2411033003

I investigated this problem (crbug.com/692165) and found that the CL above changed some timing, but was a legit change.  The problem does seem to be a race condition on our side.  I made a change so that P2P channel closure without an error is treated as a proper disconnect (regardless of reception of the session-terminate message) but we should still see if there is a way to make transmission of this message more reliable.