[Home]

Summary:ASTERISK-17944: Display names with '\' characters near quotes make Asterisk fail to parse the quotation marks correctly.
Reporter:Jonathan Rose (jrose)Labels:chan-sip-message-parsing
Date Opened:2011-05-31 10:05:30Date Closed:
Priority:MinorRegression?No
Status:Open/NewComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
is related toASTERISK-27045 Issue with Parsing Contact Header without Brackets and with additional HeaderParameters seperated with semicolon
Environment:Attachments:
Description:What I am about to describe is a parsing as well as possibly a config reading issue.

Asterisk box A has a SIP user with a display name of
"Super Bob\" set via callerid in sip.conf

Super Bob calls Asterisk Box B, which fails to make a connection due to the following error:

[May 31 09:44:39] WARNING[12931]: sip/reqresp_parser.c:1023 get_in_brackets_full: No closing quote found in '"Super Bob\" <sip:snowball@10.24.20.132>;tag=as48569096'
[May 31 09:44:39] WARNING[12931]: chan_sip.c:14803 get_destination: Not a SIP header ("Super Bob\" <sip:snowball)?
tmp = <sip:snowball@10.24.20.132:5060>

This will also happen with the display-name:
"Super Bob\\"

****** ADDITIONAL INFORMATION ******

First, if we are going to read '\' as an escape character in the display name, it would probably be best to reflect that in how we read callerid from sip.conf.  As is, \" is treated as a backslash and a quote and not as an escaped quotation mark, so a sip user can't be defined (at least not without DB, but I don't know much about astdb) with escaped quotes in the display name.  Second, in order to search for a closing set of quotes to go with an opening set of quotes, reqresp_parser.c uses find_closing_quote(...) in chan_sip.c, which is either just the wrong function to use for the job or is just broken, because its way of searching for a closing quote is to search for the nearest quote and to just check if there is a backslash in front of it, which is somewhat irreverent of how escape characters function.  This isn't the correct approach to take for this sort of thing and it isn't simply a matter of going back and looking at the character before that one either.

"Test string\\" - closing quote will be considered escaped, but shouldn't be.

Meanwhile if you were to simply try and examine the previous two characters, this would become a problem:

"Test string\\\"... - in this case, if it read the previous two characters and decided that it wasn't escaped when it really was escaped.

Of course, thinking of a good way to check if a quotation mark should be escaped for not without going to the trouble of interpreting all the escape characters is its own special puzzle.  It's probably not a necessary one to solve since this isn't an operation that is going to be needing performed frequently on a real-time basis.
Comments:By: Jonathan Rose (jrose) 2011-05-31 10:37:24

Actually, in retrospect, I'm not 100% sure whether '\' is actually an allowed character in the display-name, so this might not be a problem for actually reading SIP messages.

By: Walter Doekes (wdoekes) 2011-05-31 16:31:41

\\ is legit in the display name.

Look at https://issues.asterisk.org/view.php?id=16299 for lots of fun reading and ignored patches ;)

By: David Woolley (davidw) 2011-12-16 06:13:01.128-0600

RFC 822 (presumably the same for its successors):

quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
                                           ;   quoted chars.

qtext       =  <any CHAR excepting <">,     ; => may be folded
               "\" & CR, and including
               linear-white-space>

quoted-pair =  "\" CHAR                     ; may quote any char




So backslash is not permitted in display names, unless doubled.