[asterisk-dev] Truncated appdata

[Tilghman Lesher]

On Monday 18 April 2011 19:10:36 Rob LaRubbio wrote:
> For a project I'm working on, we are using voiceglue to handle VXML
> interactions with asterisk.  The project is using the Java asterisk
> interface.  Running against both asterisk v1.6 and 1.8 we are seeing an
> issue with the url sent to voiceglue getting truncated.  Specifically if
> we send this message:
> 
> action: Originate
> actionid: 33517025_5#AJ_ORIGINATE_0
> application: Agi
> data:
> agi://localhost/url=http%3A%2F%2F192.168.1.107%3A8080%2Fm%2Fmodule%2Far%
> 2Fvxml%2Far%3Fr%3D1 async: true
> variable: __AJ_TRACE_ID=AJ_ORIGINATE_0
> channel: SIP/1000
> timeout: 10000
> 
> What gets passed to voiceglue is this URL:
> http://192.168.1.107:8080/m/module/ar/vxml%
> 
> I'm new to asterisk and this was my first glance into the code, but it
> looks like in main/manager.c in action_originate (Line 3907) it copies
> the data element of the message into a fast_orginate_helper struct:
> 
> ast_copy_string(fast->appdata, appdata, sizeof(fast->appdata));
> 
> However the struct definition for fast_originate_helper only provides 80
> characters for appdata (char appdata[AST_MAX_EXTENSION];) and that isn't
> big enough for a URL.  (elsewhere in the code I've seen appdata set to
> 1024)
> 
> I've searched through the issue system for 'appdata truncated' but
> didn't find anything.  Apolgies if this is a dupe.  Anyway is there
> another way to send urls to voiceglue through asterisk that accepts
> longer URLs, or should this appdata definition be larger?  (Or am I
> looking at the wrong part of the code?)  Thanks.

Yes, the buffer should probably be larger.  An alternative method would
be to set variables, then either originate an extension which retrieves
those variables or retrieve those variables directly in the AGI, before
doing anything else.

Please file a bug on this.  Not only should that buffer be larger, but the
app_tmp structure in main/pbx.c also needs to be increased (beyond the
256 character limit).

-- 
Tilghman