|Summary:||ASTERISK-17121: Problems with Escaping Characters on SIP Calls in Dial() and Transfer() Applications|
|Reporter:||John Lochridge (john4asterisk)||Labels:|
|Date Opened:||2010-12-16 12:21:56.000-0600||Date Closed:||2012-02-09 13:55:19.000-0600|
|Description:||There is an inability to escape characters and send certain characters in Dial() and Transfer().|
(1) Using Transfer(), Semicolons cannot be sent without using a backslash to escape them. If you send the semicolon without a preceding backslash, the Transfer() application ignores anything to the right of the semicolon as if you are desiginating a comment to be ignored in execution.
The problem is that when using a backslash to send a semicolon or other character, the Transfer() application embeds the backslash in the SIP dialog.
(2) In both the Dial() and Transfer() applications, you can no longer embed a % to create an escaped character in the SIP dialog. (This seemed to work in Asterisk 1.6) Asterisk converts the % to %25 in the SIP dialog. So, there is no way to escape other characters in a SIP dialog. My tests show that ncluding a preceding backslash does not prevent the conversion of the % to %25 in the SIP dialog.
****** ADDITIONAL INFORMATION ******
SVN: Main Release
Platform: CentOs release 5.4 (Final)
Semicolons are used in destination phone numbers which have isdn subaddress, extension, or other parameters.
Escaping is necessary inside destination URIs when there is a need to imbed special characters in a SIP URI. For example, if an Asterisk server is registered with a peer that has call forwarding capability for SIP DIDs, Asterisk can designate that the peer forward calls to a SIP URI by encoding the @ sign as follows: Dial(SIP/peername/*722028446611%40example.com) This worked in Asterisk 1.6 but fails in 1.8 because the SIP message escapes the % and shows the following: *722028446611%2540example.com
|Comments:||By: Kinsey Moore (kmoore) 2012-02-07 15:09:05.382-0600|
After some investigation, the problem you describe with % appears to have been fixed. The problem you describe with ; and \, however, appears to be a dialplan parsing issue and affects ANY attempt to use a ; (try using it with NoOp).
By: Kinsey Moore (kmoore) 2012-02-07 15:57:06.115-0600
Further checking indicates that Asterisk's config parser lacks real '\' escape support. Part of the config parser will have to be rewritten to properly support escapes. The quick and incorrect fix would be to drop a memmove() just below the only use of COMMENT_META to remove the '\'.