Hi,
I've been experiencing the exact same problem myself. Within the call a count
of files being played is maintained, and this number will only be decremented
when calling sipxCallAudioPlayFileStop. If this number is nonzero when
sipxCallDestroy is called, the call will not be torn down properly. One could
argue that sipxtapi should decrement the number automatically when the file has
been played, but this isn't currently the case.
Regarding the MEDIA_PLAYFILE_STOP event, there was a discussion about this a
couple of weeks back, and a workaround was suggested. I implemented this, but
haven't created a patch for this yet. I would also like to add additional data
to this notification (a "cookie" value indicating *what* file was stopped
playing, and a number indicating how much was played, which would be useful in
my case at least). I believe the notification system in sipxtapi is being
rewritten, so I think it's probably better to wait for that to be completed
before requesting other changes to it.
Regards,
Daníel
> Date: Sat, 9 Jun 2007 16:58:56 +0800> From: [EMAIL PROTECTED]> To:
> [email protected]> Subject: [sipxtapi-dev]
> sipxCallAudioPlayFileStop required before new sipxCallAudioPlayFileStart> >
> Hello,> > I have been working with the sipxtapi for a short period.> > I have
> re-discovered an existing bug when playing audio files - no>
> MEDIA_PLAYFILE_STOP event is ever received. I have worked around this> with a
> function to calculate the play time of a file and then wait for> that period
> before performing other actions.> > I have now discovered a new bug (I
> think).> > If a sipxCallAudioPlayFileStart call is made and then a second one
> made> - after the first file play has finished - then the call will never>
> receive a CALLSTATE_DESTROYED event> > It is necessary to prefix the second
> (sipxCallAudioPlayFileStart( call> with a sipxCallAudioPlayFileStop call. In
> this case the> CALLSTATE_DESTROYED event is received.> > The simplest
> workaround is simply to always code:> > sipxCallAudioPlayFileStop ( _hCall );
> // Somehow required for> correct operation> if (sipxCallAudioPlayFileStart(
> _hCall, _szFile, loop, local, remote )> == SIPX_RESULT_SUCCESS)> {> ...> > Is
> this a (new) bug?> > I have also run valgrind on my application and so there
> seem to be a> number of memory management problems within the api.> > What is
> the memory safety of the present release of the API?> > Thanks> > Jeremy> > >
> > _______________________________________________> sipxtapi-dev mailing list>
> [email protected]> List Archive:
> http://list.sipfoundry.org/archive/sipxtapi-dev/
_________________________________________________________________
Play free games, earn tickets, get cool prizes! Join Live Search Club.
http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
