Hi, Mark!
If that's the case, the problem is not the blank line the client is
sending (that's fine, as it means there's no body), but the fact that it
sends the garbage text - that text is indeed considered by OpenSIPS as
part of a new message (what else can it be after all?) and is appended
to the next message, hence the parsing fails.
Best regards,
Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com
On 6/2/21 12:45 PM, Mark Allen wrote:
Hi Răzvan - thanks for the reply
Looking into it, our working theory is that the problem is as follows...
UAC (WebRTC dialer) is sending a corrupted SIP 200OK to an OPTIONS
message over WebSocket. Message has a blank line in it and the content
length is 0. OpenSIPS sees the blank line as the end of the SIP message
but UAC is sending more (garbage text) after the blank line. I assume
that what comes after the blank line is buffered and seen as the start
of a new SIP message? When the next SIP message comes in it gets
appended to the corrupt message segment and when OpenSIPS tries to parse
it, it sees it as nonsense (which it is).
Just waiting on testing a new version of UAC which will hopefully
confirm that this is the problem.
cheers,
M
On Wed, 2 Jun 2021 at 08:57, Răzvan Crainea <[email protected]
<mailto:[email protected]>> wrote:
Hi, Mark!
Most likely the problem appear prior to that Contact header you're
seeing - somehow OpenSIPS thinks the packet starts with the Contact
token, whereas, most likely, the Contact is part of a previous message,
not shown in this report.
There's no such thing as SIP message fragmentation - it's either UDP or
TCP fragmentation. However, fragmentation only appears when the package
is higher than MTU. I don't think this is the case here - What I think
there is, is a broken UA which is not setting a correct Content-Length,
or is sending garbage after sending the packet. But the only way to
figure out is to make a pcap for the entire connection and see where it
starts breaking.
Best regards,
Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com <http://www.opensips-solutions.com>
On 5/26/21 2:15 PM, Mark Allen wrote:
> I'm seeing a weird, intermittent error. The most common
occurrence is
> with a 200OK returned by Mid-Registrar on a re-REGISTER using
> registration throttling, but we see it elsewhere. It appears that
the
> 200OK message is getting garbled.
>
> We have a bit of a weird setup to overcome issues we were having
with
> Mid-Registrar and WebSocket addressing. Mid-Registrar is looping
back
> 200OK to OpenSIPS before it then gets sent down the WebSocket.
90+% of
> the time it's absolutely fine, but occasionally the 200OK seems
to be
> corrupted.
>
> Here's an example. What we are seeing in this message is...
>
> Contact: <sip:[email protected]:5060
<http://sip:[email protected]:5060> <http://sip:[email protected]:5060
<http://sip:[email protected]:5060>>>
> User-Agent: MWWRTC 3.4.21042#015#012Accept:
> application/sdp,application/dtmf-relay,text/plain
>
> ...preceding...
>
> SIP/2.0 200 OK
> Via: SIP/2.0/TCP
>
192.168.1.23:5060;received=192.168.1.23;rport=42385;branch=z9hG4bK22a8.4fa6d127.0;i=b4986fe4
> ...etc...
>
> ...so OpenSIPS is failing to parse the message.
>
> What I'd like to know is, is this a sign of SIP message
fragmentation?
>
>
>
> Log entries (IP addresses, domains, and extensions changed to
protect
> the innocent!):
>
> ERROR:core:parse_method: invalid character :
> DBG:core:tcp_read_req: tcp_read_req end
> INFO:core:parse_first_line: failed to parse the method
> INFO:core:parse_first_line: bad message
> DBG:core:parse_msg: invalid message
> ERROR:core:parse_msg: message=<Contact:
<sip:[email protected]:5060 <http://sip:[email protected]:5060>
> <http://sip:[email protected]:5060
<http://sip:[email protected]:5060>>>#015#012User-Agent: MWWRTC
> 3.4.21042#015#012Accept:
> application/sdp,application/dtmf-relay,text/plain#015#012SIP/2.0 200
> OK#015#012Via: SIP/2.0/TCP
>
192.168.1.23:5060;received=192.168.1.23;rport=42385;branch=z9hG4bK22a8.4fa6d127.0;i=b4986fe4#015#012Via:
> SIP/2.0/WSS
>
98kaag0xmybq.invalid;received=4.56.78.110;branch=z9hG4bKU6O3fJQGeLvuACMTXTArJgJW73rOD5dU;rport=52570#015#012From:
> <sip:[email protected] <mailto:sip%[email protected]>
> <mailto:sip%[email protected]
<mailto:sip%[email protected]>>>;tag=Lyk010G476K7xcKrE84M#015#012To:
> <sip:[email protected] <mailto:sip%[email protected]>
> <mailto:sip%[email protected]
<mailto:sip%[email protected]>>>;tag=af78-6213d386c3edcd02707b0c0aa8423d3a#015#012Call-ID:
> 666b5e7c-cef3-f306-4b79-60d3160dc5d0#015#012CSeq: 28825
> REGISTER#015#012Contact:
>
<sips:[email protected];transport=wss>;expires=60;received="sip:4.56.78.110:52570
<http://4.56.78.110:52570>
> <http://4.56.78.110:52570
<http://4.56.78.110:52570>>"#015#012Server: OpenSIPS (3.1.1
> (x86_64/linux))#015#012Content-Length: 0#015#012#015#012>
> ERROR:core:receive_msg: Unable to parse msg received from
> [192.168.1.23:5060 <http://192.168.1.23:5060>
<http://192.168.1.23:5060 <http://192.168.1.23:5060>>]
> ERROR:core:tcp_handle_req: receive_msg failed
> DBG:core:tcp_read_req: tcp_read_req end
>
> _______________________________________________
> Users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
