[Freeswitch-dev] ftdm_call_place and caller_data.call_id
Hi I have a question on the API delivering the generated call_id in outgoing and incoming calls. When my application makes call to ftdm_call_place status = ftdm_call_place_ex(&caller_data, &hunting, &usrmsg); caller_data.call_id is set to zero. freetdm.h description about ftdm_caller_data.call_id member explicitely states, that after the ftdm_channel_call_place() call the user can use the caller_data.call_id, otherwise the call_id from sigmsg should be used I'd like to ask only a few questions: - from sources I see, that after the ftdm_call_place_ex(..) application could use caller_data.fchan->caller_data.call_id I tested it and it was ok, please is this a proper way how to use this API function? - sigmsg's delivered to signalling callback seems again not to provide the call_id directly. From sources I found this approach to be usable when handling FTDM_SIGEVENT_START ftdm_caller_data_t * callerData = ftdm_channel_get_caller_data(p->channel); call_id = callerData->call_id; However some other events delivered the call_id directly (as p->call_id) Please, is my handling for _START event correct (despite that call to API from the callback handler is tabu) I'm working with freeswitch-snapshot 25th of May, compiling a standalone freetdm, using sangoma a102de and a104d cards. thank you very much Juraj
Hello, On Sat, Aug 27, 2011 at 10:37 AM, Juraj Fabo <juraj.fabo@gmail.com> wrote:
- from sources I see, that after the ftdm_call_place_ex(..) application could use caller_data.fchan->caller_data.call_id I tested it and it was ok, please is this a proper way how to use this API function?
Yes that is the proper way.
- sigmsg's delivered to signalling callback seems again not to provide the call_id directly. From sources I found this approach to be usable when handling FTDM_SIGEVENT_START
ftdm_caller_data_t * callerData = ftdm_channel_get_caller_data(p->channel); call_id = callerData->call_id;
However some other events delivered the call_id directly (as p->call_id)
Please, is my handling for _START event correct (despite that call to API from the callback handler is tabu)
You just found a bug. I just fixed it. Please do "git pull" and you should be all set. You should NOT use the callerData->call_id, is not thread-safe and can change when you less expect it. Please use the call_id that comes in the SIGEVENT_XX message. Moises Silva Senior Software Engineer, Software Development Manager Sangoma Technologies Inc. | 100 Renfrew Drive, Suite 100, Markham ON L3R 9R6 Canada t. 1 905 474 1990 x128 | e. moy@sangoma.com
participants (2)
-
Juraj Fabo
-
Moises Silva