https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r71063 | murf | 2007-06-22 08:10:24 -0600 (Fri, 22 Jun 2007) | 1 line
My conditions for merging amaflags info was naive; DOCUMENTATION is the default, although null is possible; theft of user-settable fields is not good. Just copy them, leave them alone.
This is for bug 10016. (plus a small fix to rtp, to elim a compiler warning (dev mode))
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@71093 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also adds a new "reporting" permission for manager, since it can be incredibly spammy.
This permission was discussed on the -dev mailing list some months back.
Issue 8613, patch by johann8384, with some minor changes by me.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@70961 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r65842 | russell | 2007-05-24 09:49:05 -0500 (Thu, 24 May 2007) | 5 lines
Fix the calculation of the RTT for RTCP. The previous code would result in
oscillating and incorrect data. Additionally, the RTT would sometimes report
negative values due to incorrect calculations.
(issue #9601, patch from davetroy)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@65843 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r61707 | qwell | 2007-04-20 16:35:27 -0500 (Fri, 20 Apr 2007) | 8 lines
Avoid invalid seqno cycling detection.
Per comment from Dave Troy:
This adds back in some simple typecasting I had in an earlier version
which I realize now may be breaking things.
Issue #9554.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61708 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r59358 | russell | 2007-03-29 12:17:41 -0500 (Thu, 29 Mar 2007) | 13 lines
Merged revisions 59357 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r59357 | russell | 2007-03-29 12:14:33 -0500 (Thu, 29 Mar 2007) | 5 lines
If an error occurs when reading from an RTP socket, and the error code does not
indicate that we should try again, then return NULL instead of a "null frame".
This will prevent Asterisk from trying over and over again, and eventually
causing the system to crash. (issue #8285, john)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@59359 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r59207 | russell | 2007-03-26 12:45:55 -0500 (Mon, 26 Mar 2007) | 7 lines
The AUDIORTPQOS and VIDEORTPQOS variables are not fully functional in some
because they get set in sip_hangup. So, there are common situations where
the variables will not be available in the dialplan at all. So, this patch
provides an alternate method for getting to this information by introducing
AUDIORTPQOS and VIDEORTPQOS dialplan functions.
(issue #9370, patch by Corydon76, with some testing by blitzrage)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@59208 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@54838 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r53429 | russell | 2007-02-07 11:39:31 -0600 (Wed, 07 Feb 2007) | 7 lines
When parsing the NTP timestamp in a sender report message, you are supposed to
take the low 16 bits of the integer part, and the high 16 bits of the
fractional part. However, the code here was erroneously taking the low 16 bits
of the fractional part. It then shifted the result 16 bits down, so the result
was always zero. This fix makes it grab the appropriate high 16 bits, instead.
(issue #8991, pointed out by andre_abrantes)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@53431 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r53052 | file | 2007-01-31 18:24:20 -0600 (Wed, 31 Jan 2007) | 2 lines
When going on hold have the side that was put on hold reinvite back to Asterisk. When going off hold have the side that was taken off hold reinvited back to the other party.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@53053 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r52645 | russell | 2007-01-29 15:26:27 -0600 (Mon, 29 Jan 2007) | 6 lines
Fix a problem with packet-to-packet bridging and DTMF mode translation. P2P
bridging can only be used when the DTMF modes don't match if the core is
monitoring DTMF in both directions. Then, the core will handle the translation.
Otherwise, this bridging method can not be used.
(issue #8936)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@52646 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
........
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
Jason Parker
Russell Bryant
Joshua Colp
Steve Murphy
Tilghman Lesher
Olle Johansson
Luigi Rizzo