Comments regarding reconserver_0.9.0-1_amd64.changes

[Daniel Pocock]

On 02/09/13 08:53, Daniel Pocock wrote:
>
> On 02/09/13 00:09, Paul Richards Tagliamonte wrote:
>> Hey Dan,
>>
>> Where's the source to record_prompt.h and playback_prompt.h?
>>
>> There's a *HUGE* binary payload in there.
>
> It is easy to find where they are used, they are used as audio tracks:
>
> grep _prompt * finds the following code:
>
>       // Load 2 items into cache for testing
>       {
>          resip::Data buffer(Data::Share, (const char*)playback_prompt,
> sizeof(playback_prompt));
>          resip::Data name("playback");
>          addBufferToMediaResourceCache(name, buffer, 0);
>       }
>       {
>          resip::Data buffer(Data::Share, (const char *)record_prompt,
> sizeof(record_prompt));
>          resip::Data name("record");
>          addBufferToMediaResourceCache(name, buffer, 0);
>       }
>
> There is no attempt to execute them as code.
>
> We could potentially extract them to audio files and generate the
> *_prompt.h files at build time, but is it really necessary for something
> like this?
>

Just having a look at where they come from, it appears they originate in
the sipXtapi source tree

reConServer and reSIProcate use sipXtapi as the underlying media
framework for RTP

In the sipXtapi repository, we have the WAV files at this location:

https://github.com/sipXtapi/sipXtapi-svn-mirror/tree/master/sipXmediaAdapterLib/

Other packages contain WAV data too, it is not generally perceived as a
high risk for carrying embedded executable code