[Freeswitch-dev] ftdm_call_place and caller_data.call_id

[Moises Silva]

On Mon, Jan 30, 2012 at 7:12 AM, Juraj Fabo <juraj.fabo at 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 at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20120130/61b3dc9f/attachment-0001.html