https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r52952 | russell | 2007-01-30 13:33:12 -0600 (Tue, 30 Jan 2007) | 5 lines
Only set the DTMF flag on the rtp structure if the DTMF mode is actually
RFC2833, not just that it is not INFO. This makes it get set for inband DTMF
as well, which is not valid.
(issue #8936)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@52953 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r51328 | russell | 2007-01-19 13:08:25 -0600 (Fri, 19 Jan 2007) | 5 lines
Fix VLDTMF support in chan_gtalk. AST_FRAME_DTMF and AST_FRAME_DTMF_END are
actually the same thing. So, a digit would have been interpreted incorrectly
here. Since the channel driver will always have the begin and end callbacks
called for a digit, only support the button-down and button-up messages.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51329 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@51314 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r51204 | russell | 2007-01-17 16:09:52 -0600 (Wed, 17 Jan 2007) | 4 lines
Instead of dividing the offset by 2 directly, make it more clear that the
offset is being scaled by the size of the elements in the buffer.
(Inspired by a discussing on the asterisk-dev list about this code)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51206 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r51087 | file | 2007-01-16 00:55:23 -0500 (Tue, 16 Jan 2007) | 10 lines
Merged revisions 51085 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r51085 | file | 2007-01-16 00:53:31 -0500 (Tue, 16 Jan 2007) | 2 lines
Add none as a valid callgroup/pickupgroup option. I consider it a bug that it would inherit it all the way down and not have any way to reset it to nothing - so that's why it is in 1.2. (issue #8296 reported by gkloepfer)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51090 65c4cc65-6c06-0410-ace0-fbb531ad65f3
selectable by how it is called in the dialplan. This allows a speaker
system hooked up to the soundcard to be used for both ring notification,
as well as paging.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@50847 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r50468 | file | 2007-01-11 00:53:09 -0500 (Thu, 11 Jan 2007) | 2 lines
Remove check for channel state as it can definitely be something other then ring, and also clean up the code a bit. This should solve the parking issues and maybe some attended transfer issues people have been seeing.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@50469 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r50466 | file | 2007-01-11 00:19:39 -0500 (Thu, 11 Jan 2007) | 2 lines
Add support to see whether NAT was detected (yay symmetric RTP) and also add a check in chan_sip so that if NAT has been detected and the reinvite behind nat option has been turned off, then just do partial bridge. (issue #8655 reported by mnicholson)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@50467 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r50006 | oej | 2007-01-08 15:26:14 +0100 (Mon, 08 Jan 2007) | 11 lines
Issue #8677 - Handle failure of T.38 re-invite
This is not a fix, but adding an error message to tell the admin that
we have a bad configuration. We should not send T.38 re-invites to devices
that can't handle it (with the current architecture where you have to
hard-code t.38 support per device).
To really fix this, we need to figure out a way to tell the incoming
call that the re-invite failed, so we can signal failure on that
end and go back to the original call.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@50007 65c4cc65-6c06-0410-ace0-fbb531ad65f3
