https://origsvn.digium.com/svn/asterisk/trunk
........
r177162 | jpeeler | 2009-02-18 14:11:57 -0600 (Wed, 18 Feb 2009) | 14 lines
Modify h323 to build against PTLib as well as the older PWLib
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@177164 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r176705 | dhubbard | 2009-02-17 15:59:38 -0600 (Tue, 17 Feb 2009) | 11 lines
create a UDPTL structure in create_addr_from_peer() if it does not already exist for T38
This is required to create a UDPTL structure in create_addr_from_peer() to handle the
scenario where 't38pt_udptl=yes' is not defined in the [general] section of sip.conf but
is defined the peer's context. I tested this patch by enabling t38pt_udptl in the
[general] section on one system and only enabling t38pt_udptl in a peer's context on
the system sending a fax. Without the patch, the sending system will fail to initiate
T38 negotiation with the warning message, "No way to add SDP without an UDPTL structure".
When this patch is applied the sending side will successfully initiate T38 negotiation.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@176731 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r176592 | tilghman | 2009-02-17 12:49:20 -0600 (Tue, 17 Feb 2009) | 4 lines
Add assertions in the quest to track down a refcount leak.
(closes issue #14485)
Reported by: davevg
........
r176642 | tilghman | 2009-02-17 15:14:18 -0600 (Tue, 17 Feb 2009) | 8 lines
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@176644 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r176459 | tilghman | 2009-02-16 19:58:39 -0600 (Mon, 16 Feb 2009) | 17 lines
Merged revisions 176426 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r176426 | tilghman | 2009-02-16 18:49:22 -0600 (Mon, 16 Feb 2009) | 10 lines
After a 'sip reload', qualifies for realtime peers weren't immediately
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@176461 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r176355 | dvossel | 2009-02-16 17:33:55 -0600 (Mon, 16 Feb 2009) | 13 lines
Merged revisions 176354 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r176354 | dvossel | 2009-02-16 17:30:52 -0600 (Mon, 16 Feb 2009) | 8 lines
Fixes issue with AST_CONTROL_SRCUPDATE not being relayed correctly during 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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@176362 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r176248 | dvossel | 2009-02-16 15:30:17 -0600 (Mon, 16 Feb 2009) | 11 lines
Merged revisions 175597 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
........
r175597 | dvossel | 2009-02-13 14:11:55 -0600 (Fri, 13 Feb 2009) | 4 lines
Fixed iax2 key rotation backwards compatibility
Turns key rotation back on by default. Added bit into encryption IE to indicate whether or not key rotation is supported or not. If it is not supported then it is not enabled, which insures backwards compatibility. This eliminates the need for the keyrotate option in iax.conf, so it has been removed.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@176251 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r176030 | file | 2009-02-16 11:36:19 -0400 (Mon, 16 Feb 2009) | 16 lines
Merged revisions 176029 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r176029 | file | 2009-02-16 11:33:53 -0400 (Mon, 16 Feb 2009) | 9 lines
Don't have the Via header stored as a stringfield as it can change often 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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@176032 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r175829 | russell | 2009-02-15 14:56:27 -0600 (Sun, 15 Feb 2009) | 14 lines
Fix a number of problems with ast_sched_report().
1) It had numerous coding guidelines violations with regards to formatting.
2) It allocated memory using ast_calloc() that was never freed.
3) It didn't check for failure from the allocation.
4) It used sprintf() and strcat() to build the result, doing zero checking to
prevent writing past the end of the provided buffer.
The function also lacks API documentation, but that has not been addressed in
this commit.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@175831 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r175597 | dvossel | 2009-02-13 14:11:55 -0600 (Fri, 13 Feb 2009) | 4 lines
Fixed iax2 key rotation backwards compatibility
Turns key rotation back on by default. Added bit into encryption IE to indicate whether or not key rotation is supported or not. If it is not supported then it is not enabled, which insures backwards compatibility. This eliminates the need for the keyrotate option in iax.conf, so it has been removed.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@175662 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r175127 | dvossel | 2009-02-12 11:07:17 -0600 (Thu, 12 Feb 2009) | 4 lines
Setting key rotation to be off by default
Key rotation breaks compatibility between (trunk/1.6.1) and (1.2/1.4/1.6.0). As a follow up to this, I am investigating possible ways to allow key rotation to be on by default and not affect the other branches, but for now it must be turned off.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@175130 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r174543 | file | 2009-02-10 11:37:07 -0400 (Tue, 10 Feb 2009) | 6 lines
Make the logic for inuse and inringing manipluation match that of 1.4. The old broken logic would reset the values back to 0 during certain scenarios causing the wrong state to be reported.
(closes issue #14399)
Reported by: caspy
(issue #13238)
Reported by: kowalma
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@174545 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r174301 | mmichelson | 2009-02-09 11:20:55 -0600 (Mon, 09 Feb 2009) | 20 lines
Merged revisions 174282 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r174282 | mmichelson | 2009-02-09 11:11:05 -0600 (Mon, 09 Feb 2009) | 12 lines
Don't do an SRV lookup if a port is specified
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@174326 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r174084 | dhubbard | 2009-02-06 17:51:56 -0600 (Fri, 06 Feb 2009) | 13 lines
Merged revisions 174082 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r174082 | dhubbard | 2009-02-06 17:36:03 -0600 (Fri, 06 Feb 2009) | 5 lines
check ast_strlen_zero() before calling ast_strdupa() in sip_uri_headers_cmp()
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@174086 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r174041 | file | 2009-02-06 15:28:53 -0400 (Fri, 06 Feb 2009) | 4 lines
Don't subscribe to a mailbox on pseudo channels. It is futile. This solves an issue where duplicated pseudo channels would cause a crash because the first one would unsubscribe and the next one would also try to unsubscribe the same subscription.
(closes issue #14322)
Reported by: amessina
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@174043 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r173974 | file | 2009-02-06 13:18:35 -0400 (Fri, 06 Feb 2009) | 15 lines
Merged revisions 173967-173968 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r173967 | file | 2009-02-06 13:14:15 -0400 (Fri, 06 Feb 2009) | 4 lines
Some clients do not put the call-id for replaces at the beginning, so support it being anywhere in the string.
(closes issue #14350)
Reported by: fhackenberger
........
r173968 | file | 2009-02-06 13:15:01 -0400 (Fri, 06 Feb 2009) | 2 lines
Remove a debug message I put in by accident.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@173994 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r173502 | dvossel | 2009-02-04 15:25:14 -0600 (Wed, 04 Feb 2009) | 9 lines
Fixes issue with IAX2 transfer not handing off calls. Reverts changes in 116884
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. The changes reverted in 116884 caused backwards compatibility issues involving iax2 transfer with 1.6.0, 1.4, and 1.2.
(closes issue #13468)
Reported by: nicox
Tested by: dvossel
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@173506 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r172400 | rmudgett | 2009-01-29 14:38:34 -0600 (Thu, 29 Jan 2009) | 12 lines
channels/chan_dahdi.c
* Added doxygen comments to the major dahdi structures.
* Fixed PRI and SS7 using an incorrect string value if the extension
delimiter is not present in the Dial() function.
* Fixed SS7 not checking if the dialed extension is at least as long
as the stripmsd option.
* Fixed PRI not handling unknown TON/NPI prefix letters correctly.
* Fixed some uninitialized string variables on FXS ports.
configs/chan_dahdi.conf.sample
* Updated some documentation.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@172435 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r172234 | oej | 2009-01-29 12:19:29 +0100 (Tor, 29 Jan 2009) | 7 lines
Make sure register= line supports both port and expiry at the same time.
(closes issue #14185)
Reported by: Nick_Lewis
Patches:
chan_sip.c-expiryrequest6.patch uploaded by Nick (license 657)
Tested by: Nick_Lewis
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@172235 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r172173 | oej | 2009-01-29 10:18:01 +0100 (Tor, 29 Jan 2009) | 24 lines
Merged revisions 172169 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172169 | oej | 2009-01-29 09:48:18 +0100 (Tor, 29 Jan 2009) | 16 lines
Make sure that we always add the hangupcause headers. In some cases, the 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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@172231 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r171691 | mmichelson | 2009-01-27 15:58:39 -0600 (Tue, 27 Jan 2009) | 47 lines
Merged revisions 171689 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r171689 | mmichelson | 2009-01-27 15:55:08 -0600 (Tue, 27 Jan 2009) | 39 lines
Fix devicestate problems for "always-on" agent channels
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@171693 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r171528 | oej | 2009-01-27 16:00:19 +0100 (Tis, 27 Jan 2009) | 23 lines
Solving the same issue, but a bit different in trunk...
Merged revisions 171527 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r171527 | oej | 2009-01-27 15:33:20 +0100 (Tis, 27 Jan 2009) | 13 lines
Use the same branch tag in CANCEL as in INVITE
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@171540 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r169791 | mmichelson | 2009-01-21 15:53:55 -0600 (Wed, 21 Jan 2009) | 18 lines
Further fix some oddities in sip show users and sip show peers logic
ccesario on IRC pointed out that his sip peers were not displayed
properly when he would issue the command "sip show peers." The problem
was that the onlymatchonip field was used to determine if the endpoint
was a "peer" or "user." The tricky part is that a "friend" is supposed
to be treated as both a "user" and a "peer" but the logic would not allow
"friends" to show up as "peers" since onlymatchonip was set to FALSE
for friends.
I have modified the sip_peer structure to more explicitly keep track of
what type endpoint it is so that the various manager and CLI commands
will display the expected information
Reported by ccesario via IRC
Tested by ccesario
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@169792 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r169557 | mmichelson | 2009-01-20 14:10:31 -0600 (Tue, 20 Jan 2009) | 19 lines
Convert the character pointers in a sip_request to be pointer offsets
When an ast_str expands to hold more data, any pointers that were pointing
to the data prior to the expansion will be pointing at invalid memory. This
change makes such pointers used in chan_sip.c instead be offsets from the
beginning of the string so that the same math may be applied no matter where
in memory the string resides.
To help ease this transition, a macro called REQ_OFFSET_TO_STR has been added
to chan_sip.c so that given a sip_request and an offset, the string at that
offset is returned.
(closes issue #14220)
Reported by: riksta
Tested by: putnopvut
Review http://reviewboard.digium.com/r/126/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@169559 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r169211 | mmichelson | 2009-01-19 09:54:06 -0600 (Mon, 19 Jan 2009) | 21 lines
Merged revisions 169210 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r169210 | mmichelson | 2009-01-19 09:52:15 -0600 (Mon, 19 Jan 2009) | 13 lines
Prevent a crash in chan_local due to a potential NULL pointer dereference
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@169213 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r168976 | mmichelson | 2009-01-16 16:43:09 -0600 (Fri, 16 Jan 2009) | 26 lines
Merged revisions 168975 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r168975 | mmichelson | 2009-01-16 16:42:13 -0600 (Fri, 16 Jan 2009) | 18 lines
Account for possible NULL pointer when we receive a 408 in response to a 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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@168979 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r168725 | mmichelson | 2009-01-15 13:00:06 -0600 (Thu, 15 Jan 2009) | 17 lines
Remove an unneeded condition for line addition to a SIP request/response
In Asterisk 1.4 and 1.6.0, the sip_request structure had a statically
allocated buffer to hold the text of the request. There was a check in the
add_line function to not attempt to write the line into the buffer if we
did not have room for it.
In trunk and Asterisk versions starting with 1.6.1, an expandable ast_str
structure is used to hold the text. Since it may grow to fit an arbitrarily
sized string, this check in add_line is no longer valid.
I found this oddity while attempting to fix issue #14220; however, I do not
believe that this is the fix for that issue since the output supplied by the
reporter did not contain the warning message that would be printed had this
condition been satisfied.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@168726 65c4cc65-6c06-0410-ace0-fbb531ad65f3