Repository navigation
Conversation
A TLS record can carry more than one WebSocket frame. tport_recv_stream_ws() reads one frame per call, so a second frame that arrived in the same record stays in OpenSSL's buffer. Nothing on the socket wakes the poll for it, and it is processed only when the peer sends something else: a "180 Ringing" sent right behind a "100 Trying" waits until the next message, often seconds later or never. This is common behind a TLS-terminating WebSocket proxy (nginx re-encrypting towards FreeSWITCH writes back-to-back frames into one record). Return 2 while SSL_pending() reports buffered data, so the transport reads again at once, as tport_recv_stream_tls() already does with tls_pending(). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A TLS record can carry more than one WebSocket frame.
tport_recv_stream_ws()reads one frame per call. A secondframe that arrived in the same record stays in OpenSSL's buffer, and nothing on the socket wakes the poll for it, so
it is processed only when the peer sends something else.
Symptom. A browser phone (SIP.js) answers an INVITE with
100 Tryingand180 Ringingback to back. Behind aTLS-terminating WebSocket proxy (nginx re-encrypting towards FreeSWITCH), both frames land in one TLS record. The 180
is seen only when the next message arrives: seconds later, or never if the call is cancelled first. The B-leg is then
reported as never ringing.
Fix. Return 2 while
SSL_pending()reports buffered data, so the transport reads again at once. This is whattport_recv_stream_tls()already does withtls_pending().Measured (FreeSWITCH 1.11.3, sofia-sip
d636a9f, Debian 13): a WSS client wrote two SIP OPTIONS in one TLS record.Two messages written 50 ms apart (separate records) are answered at once either way.
🤖 Generated with Claude Code