https://origsvn.digium.com/svn/asterisk/branches/1.4
(closes issue #10690)
........
r92696 | qwell | 2007-12-12 18:11:09 -0600 (Wed, 12 Dec 2007) | 7 lines
If a typo is found in a config file, we previous continued on with what was already loaded.
We do not want to do this (see bug below for details).
This makes it so that if a [ is found without a ], the entire config will fail, and nothing in it will be loaded.
Issue 10690.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@92697 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r92158 | oej | 2007-12-10 15:04:44 +0100 (MÃ¥n, 10 Dec 2007) | 16 lines
Avoid reinvite race situations with two Asterisks trying
to reinvite each other in 1.4 and trunk.
This patch implements support for the 491 error code that
Asterisk 1.4 generates on situations where we get an
incoming INVITE and already has one in progress.
Thanks to mavetju for reporting and to Raj Jain for an
excellent explanation of the problem.
Patch by myself. Tested with 8 Asterisk servers connected
to each other in a training network.
Closes issue #10481
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@92159 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@89698 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and we now have the groupcount system to implement call-limits in the dialplan. You
can use the "setvar" option in realtime/sip.conf to set limits per device.
- Implement "callcounter" as a new option to enable the call counting we need to
report device status to queue, manager and SIP subscriptions.
The call counter setting is now enabled in the code by setting the device call-limit
to 999. When we remove the call limit, we can simply enable this with a boolean
setting.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89554 65c4cc65-6c06-0410-ace0-fbb531ad65f3
make the format explicit in a debug message;
print the audio instead of aggregated peer capability in a debugging msg.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89532 65c4cc65-6c06-0410-ace0-fbb531ad65f3
with the SIPPEER() argument of the same name. The deprecation procedure is not
being used here since this is a trunk-only option.
(closes issue #11307, reported by pj, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89441 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With this, you can control the peer in the dialplan, so you avoid placing outbound
calls when the device has reached busy-level.
Reported by pj.
Closes bug #11180
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89406 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the bug tracker. Since we don't authenticate devices (peers/users) on OPTIONS we don't
have the proper context set for the user/peer.
However, we might not want to process an authentication for every OPTIONS, so we could
have a config option for this, "optionsforceok" to always answer 200 OK on the request
and not check device or destination, nor add a SDP. If Asterisk sends the OPTIONs request,
it doesn't care about the reply. Some devices use OPTIONs to discover capabilities,
since we should answer like an INVITE from the device and we need to support that properly
too, which we don't today.
So much to do :-)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89404 65c4cc65-6c06-0410-ace0-fbb531ad65f3
build times - tested, there is no measureable difference before and
after this commit.
In this change:
use asterisk/compat.h to include a small set of system headers:
inttypes.h, unistd.h, stddef.h, stddint.h, sys/types.h, stdarg.h,
stdlib.h, alloca.h, stdio.h
Where available, the inclusion is conditional on HAVE_FOO_H as determined
by autoconf.
Normally, source files should not include any of the above system headers,
and instead use either "asterisk.h" or "asterisk/compat.h" which does it
better.
For the time being I have left alone second-level directories
(main/db1-ast, etc.).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89333 65c4cc65-6c06-0410-ace0-fbb531ad65f3
solution, it breaks communication.
Rizzo - you need to implement a configuration option for this
code. It's good, but maybe should be off by default.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89285 65c4cc65-6c06-0410-ace0-fbb531ad65f3
way of handling DTMF in SIP. Totally undocumented, but implemented
in enough devices so we have to support it.
Code by sergee, small changes by oej.
Closes issue #11049
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89278 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This prevents modifying the strings in the stored variables,
and catched a few instances where this was actually done.
Given the differences between trunk and 1.4 (and the fact that this
is effectively an API change) it is better to fix 1.4 independently.
These are
chan_sip.c::sip_register()
chan_skinny.c:: near line 2847
config.c:: near line 1774
logger.c::make_components()
res_adsi.c:: near line 1049
I may have missed some instances for modules that do not build here.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89268 65c4cc65-6c06-0410-ace0-fbb531ad65f3
