| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@180010 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Now prune_users() and prune_peers() are called instead of reload_config() to prune all users/peers that are realtime. These functions remove all users/peers with the rtfriend and delme flags set. iax2_prune_realtime() also lacked the code to properly delete a single friend. For example. if iax2 prune realtime <friend> was called, only the peer instance would be removed. The user would still remain.
(closes issue #14479)
Reported by: mousepad99
Review: http://reviewboard.digium.com/r/176/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@178838 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Since the remote side is not actually subscribing to a specific extension when
subscribing for MWI just skip the check to see if the extension exists. They can't use it
to specify the mailbox either since we require configuration of that in sip.conf
(closes issue #14531)
Reported by: festr
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@178205 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
During iax2 call negotiation, supported codecs are passed in an Information Element containing a 2 byte field where each bit correlates to a specific codec. In 1.4 only audio codec bits 0-12 are defined, leaving bits 13-15 undefined. By default all bits are enabled unless specified otherwise. Since its a 2 byte field and 13-15 are not defined, these bits are never turned off. In trunk, bits 13-15 are defined, which means 1.4 is advertising support for codecs it does not have when talking to trunk. I fixed this by adding #define for undefined audio codec bits. These bits are then removed from iax2's full bandwidth capabilities.
(closes issue #14283)
Reported by: jcovert
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@177696 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Resiprocate dev team. Thanks!
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@177450 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Several changes in PTLib have occurred requiring build time detection. Changes
accounted for include the library name change, config option change, install
location change, and a boolean type change which is handled by ast_ptlib.h.
Also, the sed check has been modified to properly work with autoconf >= 2.62.
(closes issue #14224)
Reported by: bergolth
Patches:
asterisk-autoconf-sed.patch uploaded by bergolth (license 661)
asterisk-pwlib-v3.patch uploaded by bergolth (license 661)
Tested by: jpeeler
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@177160 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Prior to masquerade, move the group definitions to the channel performing the
masq, so that the group count lingers past the bridge.
(closes issue #14275)
Reported by: kowalma
Patches:
20090216__bug14275.diff.txt uploaded by Corydon76 (license 14)
Tested by: kowalma
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@176661 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
restarted, instead waiting until the next registration. We're now
caching the qualify across a reload/restart and starting the qualify
immediately upon loading the peer.
(closes issue #14196)
Reported by: pdf
Patches:
20090120__bug14196_1.4.diff.txt uploaded by pdf (license 663)
Tested by: pdf
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@176426 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
bridging
This should have been committed with rev176247, but I missed it. srcupdate frames no longer break out of the native bridge, but are not being sent to the other call leg either. This fixs that.
issue #13749
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@176354 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
In iax2, when a AST_CONTROL_SRCUPDATE is received it breaks from the native bridge, but since there is no code path to handle srcupdate it just goes to be beginning of the loop. This was causing packet storms of srcupdate frames between servers. Now srcupdate frames do not break the native bridge for processing.
(closes issue #13749)
Reported by: adiemus
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@176247 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
during the lifetime of a dialog.
This issue crept up with subscriptions on the AA50. When an outgoing NOTIFY is sent a new branch value
is created and the Via header is changed to reflect it. Since this was a stringfield a new spot in the
pool was used for the value while the old was left untouched/unused. If the current pool was full a new
pool was created. This would cause memory usage to increase steadily.
(issue #AA50-2332)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@176029 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by De_Mon on #asterisk-dev.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@175921 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@175777 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This attribute contains a JID that identifies the initiator of the GoogleTalk
voice session. The GoogleTalk client discards Asterisk's replies if the
initiator attribute contains uppercase characters.
(closes issue #13984)
Reported by: jcovert
Patches:
chan_gtalk.2.patch uploaded by jcovert (license 551)
Tested by: jcovert
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@175029 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14448)
Reported by: frawd
Patches:
hold_invite_nosdp.patch uploaded by frawd (license 610)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@174644 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
RFC 3263 says to do A record lookups on a hostname
if a port has been specified, so that's what we're
going to do. See section 4.2.
(closes issue #14419)
Reported by: klaus3000
Patches:
patch_chan_sip_nosrvifport_1.4.23.txt uploaded by klaus3000 (license 65)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@174282 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
and sip_uri_params_cmp()
The reporter didn't actually upload a properly-formed patch, instead a
modified chan_sip.c file was uploaded. I created a patch to determine the
changes, then modified the suggested changes to create a proper fix. The
summary above is a complete description of the changes.
(closes issue #13547)
Reported by: tecnoxarxa
Patches:
chan_sip.c.gz uploaded by tecnoxarxa (license 258)
Tested by: tecnoxarxa
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@174082 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@173968 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
support it being anywhere in the string.
(closes issue #14350)
Reported by: fhackenberger
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@173967 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
SIP RFCs.
(closes issue #13602)
Reported by: hjourdain
Tested by: mnicholson
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@173917 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
With this fix, we only will perform an SRV lookup at the following times:
* The first time we register with a remote registrar
* If we send a REGISTER but do not receive a response
* If the sendto() function returns an error
While I wrote the patch that fixes this issue, a huge amount of credit is due
to Brett Bryant, who wrote the initial patch on which I based this one.
(closes issue #12312)
Reported by: jrast
Patches:
12312.patch uploaded by putnopvut (license 60)
Tested by: blitzrage
Review: http://reviewboard.digium.com/r/132/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@173770 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Fixes issue with IAX2 transfers not taking place. As it was, a call that was being transfered would never be handed off correctly to the call ends because of how call numbers were stored in a hash table. The hash table, "iax_peercallno_pvt", storing all the current call numbers did not take into account the complications associated with transferring a call, so a separate hash table was required. This second hash table "iax_transfercallno_pvt" handles calls being transfered, once the call transfer is complete the call is removed from the transfer hash table and added to the peer hash table resuming normal operations. Addition functions were created to handle storing, removing, and comparing items in the iax_transfercallno_pvt table.
(issue #13468)
Review: http://reviewboard.digium.com/r/140/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@173248 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
* Added doxygen comments to the major dahdi structures.
* Fixed PRI using an incorrect string value if the extension
delimiter is not present in the Dial() function.
* Fixed some uninitialized string variables on FXS ports.
configs/chan_dahdi.conf.sample
* Updated some documentation.
These changes are already in trunk -r172400
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@172962 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
owner was disconnected before we checked for the cause.
This patch implements a temporary storage in the pvt and use that instead.
The code is based on ideas from code from Adomjan in issue #13385 (Add support for Reason: header)
Thanks to Klaus Darillion for testing!
(closes issue #14294)
related to issue #13385
Reported by: klaus3000 and adomjan
Patches:
bug14294b.diff uploaded by oej (license 306)
Based on 20080829_chan_sip.c-q850reason_header.patch uploaded by adomjan (license 487)
Tested by: oej, klaus3000
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@172169 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@171963 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
A revision to chan_agent attempted to "inherit" the device
state of the underlying channel in order to report the
device state of an agent channel more accurately.
The problem with the logic here is that it makes no sense to
use this for always-on agents. If the agent is logged in, then
to the underlying channel, the agent will always appear to be
"in use," no matter if the agent is on a call or not. The reason
is that to the underlying channel, the channel is currently in use
on a call to the AgentLogin application.
The most common cause that I found for this issue to occur was for
a SIP channel to be the underlying channel type for an Agent channel.
If the SIP phone re-registers, then the registration will cause the
device state core to query the device state of the SIP channel. Since the
SIP channel is in use, the Agent channel would also inherit this status.
Once the agent channel was set to "in use" there was no way that the device
state could change on that channel unless the agent logged out.
The solution for this problem is a bit different in 1.4 than it is in the
other branches. In 1.4, there will be a one-line fix to make sure that only
callback agents will inherit device state from their underlying channel type.
For the other branches of Asterisk, since callback support has been removed, there
is also no need for device state inheritance in chan_agent, so I will simply be
removing it from the code.
In addition, the 1.4 source is getting a new comment to help the next person who
edits chan_agent.c. I'm adding a comment that a agent_pvt's loginchan field may be
used to determine if the agent is a callback agent or not.
(closes issue #14173)
Reported by: nathan
Patches:
14173.patch uploaded by putnopvut (license 60)
Tested by: nathan, aramirez
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@171689 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Originally putnopvut implemented some changes in revision 142079 that according to the bug report seemed to have worked then, but somehow fails now.
I guess code, as humans, get old and forget stuff. Anyway, this bug caused CANCEL not to work with picky systems.
Thanks Fredrik for pointing out where the bug in the SIP messaging was.
(closes issue #14346)
Reported by: oej
Patches:
bug14346.diff uploaded by oej (license 306)
Tested by: oej
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@171527 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
The important changes here are related to the synchronization between threads
adding items into the scheduler and the scheduler handling thread. By adjusting
the lock and condition handling, we ensure that the scheduler thread sleeps no
longer and no less than it is supposed to. We also ensure that it does not
wake up more often than it has to.
There is no bug report associated with this. It is just something that I found
while putting scheduler thread handling into a reusable form (review 129).
Review: http://reviewboard.digium.com/r/131/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@171452 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14284)
Reported by: klaus3000
Patches:
patch_chan_sip_unreliable_1.4.23_14284.txt uploaded by klaus3000 (license 65)
Tested by: klaus3000
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@171264 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #13686)
Reported by: itiliti
Patches:
20081013__bug13686.diff.txt uploaded by Corydon76 (license 14)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@171187 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@170588 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
that our address for them will still be valid even though they are on hold.
(closes issue #14295)
Reported by: klaus3000
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@170504 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Move the check for if both channels on a local_pvt have generators to below
where p->chan is checked for NULLity (NULLness?). This prevents a crash from
occurring if p->chan is NULL.
(closes issue #14189)
Reported by: sascha
Patches:
14189.patch uploaded by putnopvut (license 60)
Tested by: sascha
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@169210 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
REGISTER
It may be that by the time we receive a reply to a REGISTER request, the attempt has
timed out and thus the registry structure pointed to by the corresponding sip_pvt has
gone away. This situation was handled properly for a 200 OK response, but the 408
case assumed that the sip_registry struct was non-NULL, thus potentially causing a crash
This commit fixes this assumption and prints out a message to the console if we should
receive a late 408 response to a REGISTER
(closes issue #14211)
Reported by: aborghi
Patches:
14211.diff uploaded by putnopvut (license 60)
Tested by: aborghi
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168975 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
The allocated process IDs could overflow their respective
NT and TE fields. Affects outgoing calls.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168622 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
I found that the allow_multiple_logins function would never return
0 due to an incorrect comparison being used when traversing the
list of agents. While I was modifying this function, I also did
a little bit of coding guidelines cleanup, too.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168598 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168561 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14176)
Reported by: paraeco
Patches:
chan_sip.c.diff uploaded by paraeco (license 658)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168551 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: IgorG
Tested by: denisgalvao
This gits rid of the notion of an owning_app allowing the request and hangup to be initiated by different threads. Originating from an active agent channel requires this. The implementation primarily changes __login_exec to wait on a condition variable rather than a lock.
Review: http://reviewboard.digium.com/r/35/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168507 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
after being contacted by Olle Johansson and being shown how this fix is
incorrect. Thanks to Olle for clearing this up for me.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168482 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
* Miscellaneous doxygen comments added.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168191 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
INFO, NOTIFY, OPTIONS, REFER, and MESSAGE requests
were not checking the topmost Via to determine where
to send the response. Adding check_via calls to those
request handlers solves this.
(closes issue #13071)
Reported by: baron
Patches:
check_via.patch uploaded by baron (license 531)
Tested by: baron
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168128 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@167714 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Asterisk channel, and the lock on that channel cannot be obtained because it is held by another thread, instead of dropping the request/response, queue it for later processing when the channel lock becomes available.
http://reviewboard.digium.com/r/117/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@167620 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r167259 | tilghman | 2009-01-06 14:44:03 -0600 (Tue, 06 Jan 2009) | 2 lines
Security fix AST-2009-001.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@167260 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
There are some boolean attributes for T.38 such
as T38FaxFillBitRemoval, T38FaxTranscodingMMR, and
T38FaxTranscodingJBIG. By simply being present, we
should treat these as a "true" value. The current
code, however, was requiring a 1 or 0 as the value
of the attribute in order to parse it. This is due
to the fact that there are some T.38 endpoints and
gateways that also transmit this information
incorrectly. This patch follows the "be liberal in
what you accept and strict in what you send"
philosophy by accepting both the correctly- and
incorrectly-formatted attributes, but only sending
information as it is supposed to be sent.
It was also discovered that a particular type of
T.38 gateway sends some non-standard T.38 SDP
attributes. Instead of using T38FaxMaxDatagram
and T38MaxBitRate, it used T38MaxDatagram and
T38FaxMaxRate respectively. We now will properly
accept these attributes as well.
Note that there are a lot of patches cited in
the below commit message template. This is
because the person who submitted these patches is
an awesome person and wrote 1.4, 1.6.0, and 1.6.1
variants.
(closes issue #13976)
Reported by: linulin
Patches:
chan_sip.c.1.4-update1.diff uploaded by arcivanov (license 648)
chan_sip.c.1.6.0-update1.diff uploaded by arcivanov (license 648)
chan_sip.c.1.6.1-update1.diff uploaded by arcivanov (license 648)
chan_sip.c.1.4-relaxedT38_update1.diff uploaded by arcivanov (license 648)
chan_sip.c.1.6.0-relaxedT38_update1.diff uploaded by arcivanov (license 648)
chan_sip.c.1.6.1-relaxedT38_update1.diff uploaded by arcivanov (license 648)
Tested by: arcivanov
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@167179 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
in the ALSA sample code (see http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_8c-example.html#a32)
Reported by: Jerry Geis (via the -users list)
Fixed by: me (license 14)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@167095 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(Closes #14153)
Reported by: Jerry Geis, via the users list.
Patch by: me (license 14)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@166953 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
http://lists.digium.com/pipermail/asterisk-dev/2008-December/035919.html
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@166772 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(Closes issue #14120)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@166592 f38db490-d61c-443f-a65b-d21fe96a405b
|
