Re: [Freeswitch-dev] ftdm_call_place and caller_data.call_id
Hi, Thank you.
Hi,
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(..).
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 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. I've recently tested head from freeswitch git, but the caller_data.call_id is still zero after returning from ftdm_call_place_ex(). 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. 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); } 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? Thank you in advance Juraj
On Mon, Jan 30, 2012 at 7:12 AM, Juraj Fabo <juraj.fabo@gmail.com> wrote:
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 ... 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 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. 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 *Moises Silva **Software Engineer, Development Manager*** msilva@sangoma.com Sangoma Technologies 100 Renfrew Drive, Suite 100, Markham, ON L3R 9R6 Canada t. +1 800 388 2475 (N. America) t. +1 905 474 1990 x128 f. +1 905 474 9223 **<http://www.sangoma.com/contact?utm_source=signature&utm_medium=email&utm_campaign=email+signatures> Products<http://sangoma.com/products?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Solutions<http://sangoma.com/solutions?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Events<http://sangoma.com/about_us/events?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Contact<http://www.sangoma.com/contact?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Wiki<http://wiki.sangoma.com/?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Facebook<http://www.facebook.com/pages/Sangoma-VoIP-Cards/43578453335?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Twitter<http://www.twitter.com/sangoma?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures>`| | YouTube<http://www.youtube.com/sangomatechnologies?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures>
participants (2)
-
Juraj Fabo
-
Moises Silva