T.140/RFC 2793 is a live communication channel, originally
created for IP based text phones for hearing impaired.
Feels very much like the old Unix talk application.
This code is developed and disclaimed by John Martin of Aupix, UK.
Tested for interoperability by myself and Omnitor in Sweden,
the company that wrote most of the specifications.
A big thank you to everyone involved in this.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@54838 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r51848 | russell | 2007-01-23 18:59:58 -0600 (Tue, 23 Jan 2007) | 14 lines
Merged revisions 51843 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r51843 | russell | 2007-01-23 18:57:28 -0600 (Tue, 23 Jan 2007) | 6 lines
Fix an issue related to synchronization of recordings when using Monitor().
The bug is a miscalculation of the amount to seek the stream for writing to
disk when the number of samples coming in and out of a channel do not match up.
(issue #8298, #8887, report and patch by guillecabeza, patch files created and
testing done by whoiswes)
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@51850 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r51311 | russell | 2007-01-19 11:49:38 -0600 (Fri, 19 Jan 2007) | 23 lines
Merge the changes from the /team/group/vldtmf_fixup branch.
The main bug being addressed here is a problem introduced when two SIP
channels using SIP INFO dtmf have their media directly bridged. So, when a
DTMF END frame comes into Asterisk from an incoming INFO message, Asterisk
would try to emulate a digit of some length by first sending a DTMF BEGIN
frame and sending a DTMF END later timed off of incoming audio. However,
since there was no audio coming in, the DTMF_END was never generated. This
caused DTMF based features to no longer work.
To fix this, the core now knows when a channel doesn't care about DTMF BEGIN
frames (such as a SIP channel sending INFO dtmf). If this is the case, then
Asterisk will not emulate a digit of some length, and will instead just pass
through the single DTMF END event.
Channel drivers also now get passed the length of the digit to their digit_end
callback. This improves SIP INFO support even further by enabling us to put
the real digit duration in the INFO message instead of a hard coded 250ms.
Also, for an incoming INFO message, the duration is read from the frame and
passed into the core instead of just getting ignored.
(issue #8597, maybe others...)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@51314 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r50727 | file | 2007-01-13 01:00:24 -0500 (Sat, 13 Jan 2007) | 2 lines
Only write a frame out to the channel if one exists. There are cases where one may not and would therefore cause the channel driver to segfault. (issue #8434 reported by slimey)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@50728 f38db490-d61c-443f-a65b-d21fe96a405b
defined in indications.h to ind_tone_zone_sound and ind_tone_zone,
to avoid conflicts with the structs with the same names
defined in tonezone.h
Hope i haven't missed any instance.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@48958 f38db490-d61c-443f-a65b-d21fe96a405b
before calling it.
This allows generators to set it to NULL when they have nothing to
do there.
Later, the three copies of the code that releases a generator
should be moved to a function.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@48766 f38db490-d61c-443f-a65b-d21fe96a405b
be called for each thread specific object after they are allocated. Note that
there was already the ability to define a custom cleanup function. Also, if
the custom cleanup function is used, it *MUST* call free on the thread
specific object at the end. There is no way to have this magically done that
I can think of because the cleanup function registered with the pthread
implementation will only call the function back with a pointer to the
thread specific object, not the parent ast_threadstorage object.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@45623 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r45441 | russell | 2006-10-17 22:41:36 -0400 (Tue, 17 Oct 2006) | 7 lines
Don't attempt to access private data members of the pthread_mutex_t object,
because this does not work on all linux systems. Instead, just access
the reentrancy field in the ast_mutex_info struct when DEBUG_THREADS is
enabled. If DEBUG_CHANNEL_LOCKS is enabled, the developer probably has
DEBUG_THREADS on as well.
(issue #8139, me)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@45442 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r45408 | kpfleming | 2006-10-17 17:24:10 -0500 (Tue, 17 Oct 2006) | 3 lines
optimize the 'quick response' code a bit more... no more malloc() or memset() for each response
expand stringfields API a bit to allow reusing the stringfield pool on a structure when needed, and remove some unnecessary code when the structure was being freed
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@45409 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r43779 | russell | 2006-09-27 12:55:49 -0400 (Wed, 27 Sep 2006) | 50 lines
Merged revisions 43778 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r43778 | russell | 2006-09-27 12:54:30 -0400 (Wed, 27 Sep 2006) | 42 lines
Fix a problem that occurred if a user entered a digit that matched a bridge
feature that was configured using multiple digits, and the digit that was
pressed timed out in the feature digit timeout period. For example, if blind
transfer is configured as '##', and a user presses just '#'. In this situation,
the call would lock up and no longer pass any frames.
(issue #7977 reported by festr, and issue #7982 reported by michaels and
valuable input provided by mneuhauser and kuj. Fixed by me, with testing help
and peer review from Joshua Colp).
There are a couple of issues involved in this fix:
1) When ast_generic_bridge determines that there has been a timeout, it returned
AST_BRIDGE_RETRY. Then, when ast_channel_bridge gets this result, it calls
ast_generic_bridge over again with the same timestamp for the next event.
This results in an endless loop of nothing until the call is terminated.
This is resolved by simply changing ast_generic_bridge to return
AST_BRIDGE_COMPLETE when it sees a timeout.
2) I also changed ast_channel_bridge such that if in the process of calculating
the time until the next event, it knows a timeout has already occured, to
immediately return AST_BRIDGE_COMPLETE instead of attempting to bridge the
channels anyway.
3) In the process of testing the previous two changes, I ran into a problem in
res_features where ast_channel_bridge would return because it determined
that there was a timeout. However, ast_bridge_call in res_features would
then determine by its own calculation that there was still 1 ms before the
timeout really occurs. It would then proceed, and since the bridge broke
out and did *not* return a frame, it interpreted this as the call was over
and hung up the channels.
The reason for this was because ast_bridge_call in res_features and
ast_channel_bridge in channel.c were using different times for their
calculations. channel.c uses the start_time on the bridge config, which
is the time that the feature digit was recieved. However, res_features
had another time, 'start', which was set right before calling
ast_channel_bridge. 'start' will always be slightly after start_time in the
bridge config, and sometimes enough to round up to one ms.
This is fixed by making ast_bridge_call use the same time as
ast_channel_bridge for the timeout calculation.
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@43780 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r43695 | file | 2006-09-26 16:09:41 -0400 (Tue, 26 Sep 2006) | 2 lines
Slight overhaul of the whisper support. 1. We need to duplicate the frame from ast_translate 2. We need to ensure we always have signed linear coming in for signed linear combining. 3. We need to ensure we are always feeding signed linear out. 4. Properly store and restore write format when beeping on the channel we are whispering on. 5. Properly discontinue the stream on the channel for the beep. (issue #8019 reported by timkelly1980)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@43696 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r42600 | file | 2006-09-09 16:24:19 -0400 (Sat, 09 Sep 2006) | 2 lines
Only truly consider the channel in the same format if the format matches the raw format OR if a translation path already exists to translate between them. (issue #7887 reported by softins & issue #7803 reported by alvaro_palma_aste). Thanks goes to stubert for giving me access to a box and showing me a scenario where this occured.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@42601 f38db490-d61c-443f-a65b-d21fe96a405b
