- Add CLI aliases module to asterisk.
- Remove all deprecated CLI commands from the code
Initial work done by file.
Junk-Y and lmadsen did a lot of work and testing to
get the list of deprecated commands into the configuration file.
Deprecated CLI commands are now handled by this new module,
see cli_aliases.conf for more info about that.
ok russellb@ via reviewboard
(closes issue #13735)
Reported by: mvanbaak
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@156120 f38db490-d61c-443f-a65b-d21fe96a405b
Reported by: nickpeirson
Patches:
pbx.c.patch uploaded by nickpeirson (license 579)
replace_bzero+bcopy.patch uploaded by nickpeirson (license 579)
Tested by: nickpeirson, murf
1. replaced all refs to bzero and bcopy to memset and memmove instead.
2. added a note to the CODING-GUIDELINES
3. add two macros to asterisk.h to prevent bzero, bcopy from creeping
back into the source
4. removed bzero from configure, configure.ac, autoconfig.h.in
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@147807 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r143337 | mmichelson | 2008-09-17 13:24:15 -0500 (Wed, 17 Sep 2008) | 6 lines
Allow for "G.729" if offered in an SDP even though
it is not RFC 3551 compliant. Some Cisco switches
will send this in an SDP, and it doesn't hurt to
be able to accept this.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@143340 f38db490-d61c-443f-a65b-d21fe96a405b
when a file is invalid from when a file is missing. This is most important when
we have two configuration files. Consider the following example:
Old system:
sip.conf users.conf Old result New result
======== ========== ========== ==========
Missing Missing SIP doesn't load SIP doesn't load
Missing OK SIP doesn't load SIP doesn't load
Missing Invalid SIP doesn't load SIP doesn't load
OK Missing SIP loads SIP loads
OK OK SIP loads SIP loads
OK Invalid SIP loads incompletely SIP doesn't load
Invalid Missing SIP doesn't load SIP doesn't load
Invalid OK SIP doesn't load SIP doesn't load
Invalid Invalid SIP doesn't load SIP doesn't load
So in the case when users.conf doesn't load because there's a typo that
disrupts the syntax, we may only partially load users, instead of failing with
an error, which may cause some calls not to get processed. Worse yet, the old
system would do this with no indication that anything was even wrong.
(closes issue #10690)
Reported by: dtyoo
Patches:
20080716__bug10690.diff.txt uploaded by Corydon76 (license 14)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@142992 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r136062 | mmichelson | 2008-08-06 10:58:40 -0500 (Wed, 06 Aug 2008) | 16 lines
Since adding the AST_CONTROL_SRCUPDATE frame type,
there are places where ast_rtp_new_source may be called
where the tech_pvt of a channel may not yet have an
rtp structure allocated. This caused a crash in chan_skinny,
which was fixed earlier, but now the same crash has been
reported against chan_h323 as well. It seems that the best
solution is to modify ast_rtp_new_source to not attempt to
set the marker bit if the rtp structure passed in is NULL.
This change to ast_rtp_new_source also allows the removal
of what is now a redundant pointer check from chan_skinny.
(closes issue #13247)
Reported by: pj
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@136063 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r129436 | mmichelson | 2008-07-09 14:32:20 -0500 (Wed, 09 Jul 2008) | 13 lines
Fix a problem where inbound rfc2833 audio would be sent to the
core instead of being P2P bridged. When the core regenerated
the rfc2833 packet for the outbound leg, the SSRC would be different
than the RTP audio on the call leg causing DTMF detection issues on
the far end.
(closes issue #12955)
Reported by: tonyredstone
Patches:
dynamic_rtp.patch uploaded by tsearle (license 373)
Tested by: tonyredstone
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@129437 f38db490-d61c-443f-a65b-d21fe96a405b
and not use the p2p rtp bridge). I could not find a way to detect us using the p2p bridge, which
would be nice.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@128197 f38db490-d61c-443f-a65b-d21fe96a405b
and normal deviations. Currently this is implemented for chan_sip, but could be added to the func_channel_read callbacks for the CHANNEL function
for any channel that uses RTP.
(closes issue #10590)
Reported by: gasparz
Patches:
chan_sip_c.diff uploaded by gasparz (license 219)
rtp_c.diff uploaded by gasparz (license 219)
rtp_h.diff uploaded by gasparz (license 219)
audioqos-trunk.diff uploaded by snuffy (license 35)
rtpqos-trunk-r119891.diff uploaded by sergee (license 138)
Tested by: jsmith, gasparz, snuffy, marsosa, chappell, sergee
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@120635 f38db490-d61c-443f-a65b-d21fe96a405b
- make data member of the ast_frame struct a named union instead of a void
Recently the ast_queue_hangup function got a new parameter, the hangupcause
Feedback came in that this is no good and that instead a new function should be created.
This I did.
The hangupcause was stored in the seqno member of the ast_frame struct. This is not very
elegant, and since there's already a data member that one should be used.
Problem is, this member was a void *.
Now it's a named union so it can hold a pointer, an uint32 and there's a padding in case someone
wants to store another type in there in the future.
This commit is so massive, because all ast_frame.data uses have to be
altered to ast_frame.data.data
Thanks russellb and kpfleming for the feedback.
(closes issue #12674)
Reported by: mvanbaak
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@117802 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114100 | file | 2008-04-14 10:52:49 -0300 (Mon, 14 Apr 2008) | 4 lines
Don't change the SSRC when a new source comes into play, this might happen quite often and depending on the remote side... they might not like this.
(closes issue #12353)
Reported by: dimas
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@114101 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r112209 | file | 2008-04-01 15:02:43 -0300 (Tue, 01 Apr 2008) | 4 lines
Disable Packet2Packet bridging when we need to feed DTMF frames into the core. Some implementations do not like how we switch between things.
(closes issue #12212)
Reported by: bamby
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@112210 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r110019 | file | 2008-03-19 15:20:28 -0300 (Wed, 19 Mar 2008) | 6 lines
Make sure that the mark bit does not incorrectly cause video frame timestamps to be calculated as if they are audio frames.
(closes issue #11429)
Reported by: sperreault
Patches:
11429-frametype.diff uploaded by qwell (license 4)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@110020 f38db490-d61c-443f-a65b-d21fe96a405b
Fix a number of other places where the number of samples in a G722 frame was
not properly handled because of various reasons.
main/rtp.c:
- When a G722 frame is read from the smoother, the number of samples in the
frame must be divided by 2 before being sent out over the network. Even
though G722 is 16 kHz, an error in some previous spec has made it so that
we have to list the number of samples such as if it was 8 kHz.
main/file.c:
- When scheduling the next time to expect a frame, take into account that the
format of the file we're reading from may not be 8 kHz.
codecs/codec_g722.c:
- When converting from G722 to slinear, g722_decode() expects its samples
parameter to be in the silly (real samples / 2) format. Make it so.
- When converting from slinear to G722, properly set the number of samples in
the frame to be the number of bytes of output * 2.
formats/format_pcm.c:
- This format module handles G722, among a number of other formats. However,
the read() and seek() functions did not account for the fact that G722 has
2 samples per byte.
(closes issue #12130, reported by rickross, patched by me)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@106501 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r106235 | file | 2008-03-05 18:32:10 -0400 (Wed, 05 Mar 2008) | 4 lines
Add a control frame to indicate the source of media has changed. Depending on the underlying technology it may need to change some things.
(closes issue #12148)
Reported by: jcomellas
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@106239 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105932 | russell | 2008-03-04 19:52:18 -0600 (Tue, 04 Mar 2008) | 5 lines
Fix a bug that I just noticed in the RTP code. The calculation for setting the
len field in an ast_frame of audio was wrong when G.722 is in use. The len field
represents the number of ms of audio that the frame contains. It would have
set the value to be twice what it should be.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@105933 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105674 | file | 2008-03-04 14:05:28 -0400 (Tue, 04 Mar 2008) | 8 lines
When a new source of audio comes in (such as music on hold) make sure the marker bit gets set.
(closes issue #10355)
Reported by: wdecarne
Patches:
10355.diff uploaded by file (license 11)
(closes issue #11491)
Reported by: kanderson
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@105675 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r103780 | tilghman | 2008-02-18 11:31:52 -0600 (Mon, 18 Feb 2008) | 9 lines
When a SIP channel is being auto-destroyed, it's possible for it to still be
in bridge code. When that happens, we crash. Delay the RTP destruction until
the bridge is ended.
(closes issue #11960)
Reported by: norman
Patches:
20080215__bug11960__2.diff.txt uploaded by Corydon76 (license 14)
Tested by: norman
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@103781 f38db490-d61c-443f-a65b-d21fe96a405b
(closes issue #8925)
About a year ago, as Leif Madsen and Jim van Meggelen were going over the CLI
commands in Asterisk 1.4 for the next version of their book, they documented
a lot of inconsistencies. This set of changes addresses all of these issues
and has been reviewed by Leif.
While this does introduce even more changes to the CLI command structure, it
makes everything consistent, which is the most important thing.
Thanks to all that helped with this one!
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@103171 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r100465 | tilghman | 2008-01-27 15:59:53 -0600 (Sun, 27 Jan 2008) | 11 lines
When deleting a task from the scheduler, ignoring the return value could
possibly cause memory to be accessed after it is freed, which causes all
sorts of random memory corruption. Instead, if a deletion fails, wait a
bit and try again (noting that another thread could change our taskid
value).
(closes issue #11386)
Reported by: flujan
Patches:
20080124__bug11386.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76, flujan, stuarth`
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@100488 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r98943 | russell | 2008-01-15 17:26:52 -0600 (Tue, 15 Jan 2008) | 25 lines
Commit a fix for some memory access errors pointed out by the valgrind2.txt
output on issue #11698.
The issue here is that it is possible for an instance of a translator to get
destroyed while the frame allocated as a part of the translator is still being
processed. Specifically, this is possible anywhere between a call to ast_read()
and ast_frame_free(), which is _a lot_ of places in the code. The reason this
happens is that the channel might get masqueraded during this time. During a
masquerade, existing translation paths get destroyed.
So, this patch fixes the issue in an API and ABI compatible way. (This one is
for you, paravoid!)
It changes an int in ast_frame to be used as flag bits. The 1 bit is still used
to indicate that the frame contains timing information. Also, a second flag has
been added to indicate that the frame came from a translator. When a frame with
this flag gets released and has this flag, a function is called in translate.c to
let it know that this frame is doing being processed. At this point, the flag gets
cleared. Also, if the translator was requested to be destroyed while its internal
frame still had this flag set, its destruction has been deffered until it finds out
that the frame is no longer being processed.
Admittedly, this feels like a hack. But, it does fix the issue, and I was not able
to think of a better solution ...
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@98944 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r98325 | file | 2008-01-11 15:51:10 -0400 (Fri, 11 Jan 2008) | 6 lines
If the incoming RTP stream changes codec force the bridge to break if the other side does not support it.
(closes issue #11729)
Reported by: tsearle
Patches:
new_codec_patch_udiff.patch uploaded by tsearle (license 373)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@98334 f38db490-d61c-443f-a65b-d21fe96a405b
- Refer to the proper documentation
- Implement separate signalling/media QoS/CoS in many channels using RTP
- Improve warnings and verbose messages
- Deprecate some old settings
Minor modifications by me, a big effort from IgorG.
Thanks!
Reported by: IgorG
Patches:
qoscleanup-89394-4-trunk.patch uploaded by IgorG (license 20)
Tested by: IgorG
(closes issue #11145)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@93163 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r92204 | file | 2007-12-10 12:36:15 -0400 (Mon, 10 Dec 2007) | 6 lines
Add G729A as another possible payload name for G729. Some devices use this instead of G729, which is perfectly normal since the payload number itself is defined and can't be used by anything else so the name doesn't matter that much.
(closes issue #11483)
Reported by: revolution
Patches:
rtp.diff uploaded by revolution (license 346)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@92205 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91637 | tilghman | 2007-12-06 18:52:17 -0600 (Thu, 06 Dec 2007) | 5 lines
At the end of a call, when we're reporting, RTCP may already be partially torn down, so check for NULL dereference
Reported by: blitzrage
Patch by: tilghman
(Closes issue #11450)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@91638 f38db490-d61c-443f-a65b-d21fe96a405b
Also by accident fixed a bad typo by a previous committer, which actually made video calls
not work fully...
Merged revisions 89630 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r89630 | oej | 2007-11-27 16:23:17 +0100 (Tis, 27 Nov 2007) | 12 lines
If we get a codec offer using a well-known payload type, but using it for another
codec that we don't know, Asterisk did not remove that codec from the list.
With this patch, we remove the codec from audio and video rtp objects and
deny it ever existed. Thanks to lasse for testing.
(closes issue #11376)
Reported by: lasse
Patches:
bug11376.txt uploaded by oej (license 306)
Tested by: lasse
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89698 f38db490-d61c-443f-a65b-d21fe96a405b
mvanbaak