Summary:ASTERISK-04675: Error from get_in_brackets from chan_sip 1.789, truncated line?
Reporter:Andrew Lindh (andrew)Labels:
Date Opened:2005-07-25 16:15:22Date Closed:2005-07-25 17:34:06
Versions:Frequency of
Description:I get an error from get_in_brackes that is spraying errors at me now
about all my polycoms. I just started seeing this error in chan_sip 1.789.

Jul 25 17:04:29 WARNING[3015]: chan_sip.c:1335 get_in_brackets: No closing quote in '<sip:302c@>;methods="INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, ME'

It seems to truncate or be using a truncated string and not finding the
closing quote. I don't know if this is a new warning for a problem
that was always there, or a new error using a short string.

The SIP debug shows the whole string as it should be...but now asterisk
only seems to be using 80 characters of it (an interesting number...)

From the SIP debug it looks like it's acting on this line:

Comments:By: Andrew Lindh (andrew) 2005-07-25 16:33:07

(yes...above I see the error and SIP debug are not exactly the same, but
that's the message it was parsing, just from a different device)

I see a LOT of static buffers (temp strings, etc) that are defined as 80
bytes (ie. char temp[80]) in chan_sip.c.

I changed all of them from [80] to [256] and the error message is gone.

I now get other error messages that may be a result of larger strings where
they are not expected. (I get "parse_contact: '' is not a valid SIP
contact..." but that's for a different bug may be...?)

By: Russell Bryant (russell) 2005-07-25 16:50:54

The parse_contact function only has an 80 character buffer for the contact.  :)

By: Russell Bryant (russell) 2005-07-25 16:55:04

The new get_in_brackets function is not going to work here.  The first thing that the function does is skip past the quoted section if there is one.  In this case, the quoted section comes after the information that we want.

By: Andrew Lindh (andrew) 2005-07-25 17:26:50

So is this a new problem or just a new error message about a problem
that was always there and we did not hear about it?

Was 80 bytes just a "good number" or was there a real reason to
limit it to something that small? (RFC?)

By: Kevin P. Fleming (kpfleming) 2005-07-25 17:33:54

Fixed in CVS HEAD... sorry for the breakage :-(