You are better off using mod_freetdm.c as the reference, the sample/test applications may be outdated.
Unfortunatelly in mod_freetdm.c there seems to be no need for the call_id from the ftdm_call_place_ex(..).
Yes, FreeSWITCH does not uses that call id for anything. I meant that in general, for anything else, try to use mod_freetdm.c as the reference ...
I though that the freetdm generates a new call ID (in context of freetdm) when new call is initated via ftdm_call_place_ex(..) and I was looking for the way how this call_id is announced to the caller application.ftdm_channel_t is an opaque type to API users. I don't remember what your exact question was. You should not use fchan.caller_data, you always get a copy of caller_data when you need it, the fact that is internally attached to the fchan pointer is not something you should rely on (and that's why is in a private header).
I've recently tested head from freeswitch git, but the caller_data.call_id is still zero after returning from ftdm_call_place_ex().
That depends on what caller data you are referring to. When returning from ftdm_call_place_ex(), if successful, the caller_data->call_id member should be valid assuming you got the pointer to caller_data from ftdm_channel_get_caller_data(). If you are talking about the caller_data that is provided as an argument to ftdm_call_place_ex() then the call id was not populated there, until now, I just committed a change to populate the call id there too for the user convenience.
Additionally, you could wait for the SIGEVENT_DIALING notification, which is the final confirmation that the call is really going out, that notification event contains a valid call id just as any other SIGEVENT_XX event inside the sigmsg structure. You should *always* receive SIGEVENT_DIALING if ftdm_call_place_ex() returned success. In fact, due to the fact we use separate threads, it could be possible that you receive SIGEVENT_DIALING *before* ftdm_call_place_ex() returns, and you should be prepared to handle that case ...
My problem is that the comment aroung _ftdm_call_place() in the freetdm api says:
* \note When this function returns FTDM_SUCCESS, the member .fchan from caller_data will be set to the channel used to place the call
* and .call_id to the generated call id for that call
*
but my applciation still receives zero. mod_freetdm seems to not care about this call_id at all.
This is because you are probably checking the caller_data variable that you provide to ftdm_call_place() not the one returned by ftdm_channel_get_caller_data(). I have improved ftdm_call_place_ex() now to also include the call id in the caller_data argument you provide.
So my workaround is stil following:
ftdmret = ftdm_call_place_ex(&caller_data, &hunting, usrmsg);
if (ftdmret == FTDM_SUCCESS)
{
callerData = ftdm_channel_get_caller_data(caller_data.fchan);
freetdmLibCallId = FtdmCallId(callerData->call_id);
}
Yes, that's how you were expected to do it before (or wait for SIGEVENT_DIALING)
and that was the trigger to my post.
Please, is the comment from the freetdm.h about the call_id within the caller_data valid? Is the zero also valid call_id?
The comment is correct, is just talking about the caller data returned by ftdm_channel_caller_data and not the caller data provided as argument to ftdm_call_place_ex(), but with the change I just committed both are valid now.
The value 0 is not a valid call_id, call ids start at 1