sorry, I forgot to check if this would conflict with regexes having [] and it does conflict so please disregard this last patch.
I'll keep digging but as I said feel free to use and/or include any of the previous patches.

H

On 04/11/2013 01:48 PM, Horaci Macias wrote:
ok I'll try again :)

Now "from the outside" of action, everything looks the same when it comes to using regex. The regex is set while parsing the scenario and is executed while running the call.
The regex is stored as a SendingMessage that is resolved when executing the regex, using the call in order to resolve it.
This is working for me with both variables and fields on the regexp:
    <ereg regexp="[$1][field0]" search_in="hdr" header="Server:" check_it="true" assign_to="2" />

Please have a look and let me know what you think. I believe it's cleaner than before, although still not exactly what you said.
Feel free to use and/or include any of my 3 suggestions.

H

On 04/10/2013 10:56 PM, Rob Day wrote:
On Monday 08 Apr 2013 13:53:42 Macias, Horaci wrote:
Hi Rob,

thanks. I think I found a way to overcome this although perhaps not as
generic/clean as we'd hope. The attached patch calls setMessage (not
setRegex) whenever the action is being parsed. Once the action is executed,
I call setRegex with the result of
"createSendingMessage(currentAction->getMessage(), -2 /* do not add
crlf*/);" Doing this, whatever setRegex recieves is already "resolved" and
the [field] references are working. Do you see any problem doing this?

H
Hi Horaci,

Well, I imagine it will work - but as you say, it's not really a clean 
approach, and I think including the patch as-is will make it too difficult to 
understand that part of SIPp in the future.

You haven't really said whether you mean to release this patch under the GPL 
to go into the main SIPp code - is that your intention? If it is, and if the 
current patch works well enough for you and you aren't able to work on it 
further, I might either include it in its original form (i.e. only with 
variables, not CSV fields) or take the more general approach I outlined in my 
last email if I have more time to work on it.

Best,
Rob