Re: [reSIProcate-users] TCP-connection closed when parsing fails
So, upon further reflection, the fact that there is a proxy out there that will pass on this sort of thing is very disturbing. The fact that framing the SIP message is dependent on successful parsing of the message does not bode well for networks where connections are being reused. I am betting that, given any pair of implementations, you will be able to create messages that can be framed by one, but not both. If one of these implementations will re-emit the message with the same error, persistent connections can be killed at will. This is why it is critical that proxy implementations ensure that the stuff they forward is at least correct with respect to the basic header/header-field-value grammar (fixing the grammar for individual header-field-values is not important). This is one side of Postel's maxim (be strict in what you send). But what can we do with respect to being tolerant of what we receive? We could try to have a failsafe parse that is just intended to extract the Content-Length header, and find the end of the message, but this doesn't really fix anything; this failsafe can probably be fooled into framing things differently than other implementations, leading us right back to our initial problem.
Thoughts? Has this been brought up in the sip (now sipcore) working group?
Best regards, Byron Campen Hi! We’re experiencing a problem with TCP-connections. An INVITE with incorrect Contact-header (Contact: <sip:sipp@xxxxxxxxxxxx>\rsip:sipp@xxxxxxxxxxxx) is received via a proxy to our reciprocate 1.3 based UA using TCP. The problem is that when the parser fails, the TCP-connection is torn down at the same time. Since the proxy fronting our application serves many remote destinations this hurts more than the user sending the incorrect INVITE. Also, the proxy lacks some logic to re-establish the connection which leads to a blacklist for some time. What is the reason for tearing down the connection when the parser fails? Is this error so severe that it’s considered to be unrecoverable? Please see the attachment for logs. I’m also working on this from the other direction, trying to get the proxy to re-establish the connection. Cheers, KJ _______________________________________________ resiprocate-users mailing list
|
Attachment:
smime.p7s
Description: S/MIME cryptographic signature