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/trunk@174301 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@174084 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is very similar to the DAHDI immediate=yes option. When the phone is picked up, instead of giving a dialtone it connects directly to the "s" extension. Changes where implemented in chan_iax2.c to directly connect to the "s" extension in the appropriate context when this option is enabled. Examples explaining its use are added to iax2.conf.sample. CHANGES has been updated as well.
(closes issue #14266)
Reported by: jcovert
Patches:
chan_iax2.c.patch-trunk uploaded by jcovert (license 551)
iax.conf.sample.patch uploaded by jcovert (license 551)
Tested by: jcovert, dvossel
Review: http://reviewboard.digium.com/r/143/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@174046 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@173974 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit expands the Asterisk scheduler API to include a common implementation
of a scheduler context being processed by a dedicated thread. chan_iax2 has been
updated to use this new code. Also, as a result, this resolves some race
conditions related to the previous chan_iax2 scheduler handling.
Related to rev 171452 which resolved the same issues in 1.4.
Code from team/russell/sched_thread2
Review: http://reviewboard.digium.com/r/129/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@173858 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@173502 65c4cc65-6c06-0410-ace0-fbb531ad65f3
supporting devices. The devices (snoms, specifically) need to receive a SIP
URI instead of just an extension. This adds that functionality.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172778 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* 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/trunk@172400 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also, implement a private cause code (as suggested by Tilghman). This works with
chan_sip, but doesn't propagate through chan_local.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172318 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Also, change a function in app.c to return a userful value instead of always returning 0.
Patch by fnordian, changed by Corydon76 and myself.
This does not close the bug report, as fnordian had an additional change we're still discussing.
(related to issue #14059)
Reported by: fnordian
Patches:
chan_sip_hfield.patch uploaded by fnordian (license 110)
20090116__bug14059.diff.txt uploaded by Corydon76 (license 14)
Tested by: fnordian, Corydon76, oej
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172268 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@172173 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@171691 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@171528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@169791 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@169557 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Dan saw regular segfaults with the old implementation and
rewrote it to make it really eventbased.
I altered it to be trunk compatible and wedhorn gave some feedback
and ideas how to make it even better.
(closes issue #13821)
Reported by: DEA
Patches:
chan_skinny-mwi-events.txt uploaded by DEA (license 3)
Tested by: mvanbaak, DEA
"no probs by me" from wedhorn
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@169367 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@169211 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This prevents the situation when MWI messages are added to caller ID spills causing the channel to be hung up
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@169153 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@168976 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@168725 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With this commit, a register => line in sip.conf may contain a port number in the
"user" section of the line. Please see CHANGES and sip.conf.sample for more
details regarding this.
(closes issue #14198)
Reported by: Nick_Lewis
Patches:
chan_sip.c-domainport2.patch uploaded by Nick (license 657)
Tested by: Nick_Lewis
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@168575 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r168507 | jpeeler | 2009-01-12 14:26:22 -0600 (Mon, 12 Jan 2009) | 9 lines
(closes issue #12269)
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: https://origsvn.digium.com/svn/asterisk/trunk@168508 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r168482 | mmichelson | 2009-01-12 08:58:25 -0600 (Mon, 12 Jan 2009) | 5 lines
I am reverting the fix made in revision 168128 (and its upward merges)
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: https://origsvn.digium.com/svn/asterisk/trunk@168485 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r168128 | mmichelson | 2009-01-09 14:08:04 -0600 (Fri, 09 Jan 2009) | 13 lines
Add check_via calls to more request handlers
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: https://origsvn.digium.com/svn/asterisk/trunk@168193 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds the functionality to app_queue of calculating
the average amount of time that channels are bridged for a
queue. The algorithm used to calculate the average is the same
exponential average currently used to calculate the average holdtime.
See the CHANGES file to see the methods you may use to view this
information.
(closes issue #13960)
Reported by: coolmig
Patches:
app_queue.c.diff.trunk-r158840 uploaded by coolmig (license 621)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@167792 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r167620 | kpfleming | 2009-01-07 17:32:21 -0600 (Wed, 07 Jan 2009) | 5 lines
When a SIP request or response arrives for a dialog with an associated 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/123/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@167700 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r167179 | mmichelson | 2009-01-05 10:51:59 -0600 (Mon, 05 Jan 2009) | 41 lines
A couple of changes to T.38 SDP attribute handling
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: https://origsvn.digium.com/svn/asterisk/trunk@167180 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Note that in the SIPS URI scheme, transport is independent of TLS,
and thus "sips:alice@atlanta.com;transport=tcp" and
"sips:alice@atlanta.com;transport=sctp" are both valid (although
note that UDP is not a valid transport for SIPS). The use of
"transport=tls" has consequently been deprecated, partly because
it was specific to a single hop of the request. This is a change
since RFC 2543.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166731 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r166380 | mmichelson | 2008-12-22 14:56:29 -0600 (Mon, 22 Dec 2008) | 36 lines
Fix a deadlock relating to channel locks and autoservice
It has been discovered that if a channel is locked prior
to a call to ast_autoservice_stop, then it is likely that
a deadlock will occur. The reason is that the call to
ast_autoservice_stop has a check built into it to be sure
that the thread running autoservice is not currently trying
to manipulate the channel we are about to pull out of
autoservice.
The autoservice thread, however, cannot advance beyond where
it currently is, though, because it is trying to acquire
the lock of the channel for which autoservice is attempting
to be stopped.
The gist of all this is that a channel MUST NOT be locked
when attempting to stop autoservice on the channel.
In this particular case, the channel was locked by a call
to ast_read. A call to ast_exists_extension led to autoservice
being started and stopped due to the existence of dialplan
switches.
It may be that there are future commits which handle the same
symptoms but in a different location, but based on my looks through
the code, it is very rare to see a construct such as this one.
(closes issue #14057)
Reported by: rtrauntvein
Patches:
14057v3.patch uploaded by putnopvut (license 60)
Tested by: rtrauntvein
Review: http://reviewboard.digium.com/r/107/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166382 65c4cc65-6c06-0410-ace0-fbb531ad65f3
enabled (either globally or for a specific peer), chan_sip will treat any SDP
data it receives as new data and update the media stream accordingly. By
default, Asterisk will only modify the media stream if the SDP session version
received is different from the current SDP session version. This option is
required to interoperate with devices that have non-standard SDP session
version implementations (observed by toc on the bug tracker with Microsoft OCS
which always uses 0 as the session version).
http://reviewboard.digium.com/r/94/
(closes issue #13958)
Reported by: toc
Tested by: toc
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@165180 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r164977 | mmichelson | 2008-12-16 17:04:27 -0600 (Tue, 16 Dec 2008) | 7 lines
After looking through SIP registration code most of the day, this
is one of the few things I could find that was just plain wrong.
Even though it probably isn't possible for it to happen, it seems weird
to have code that checks if a pointer is NULL and then immediately dereferences
that pointer if it was NULL.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@164978 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r164672 | russell | 2008-12-16 09:56:37 -0600 (Tue, 16 Dec 2008) | 11 lines
Fix a memory leak related to the use of the "setvar" configuration option.
The problem was that these variables were being appended to the list of vars
on the sip_pvt every time a re-registration or re-subscription came in.
Since it's just a waste of memory to put them there unless the request was an
INVITE, then the fix is to check the request type before copying the vars.
(closes issue #14037)
Reported by: marvinek
Tested by: russell
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@164675 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The name "ser" was used in a lot of places. However, it is a relic from when
the struct was a server_instance, not a session_instance. It was renamed since
it represents both a server or client connection.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@163670 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Behaviour now is that general codec config flows to default_line and default_device. [devices] stuff amends default_device and similar for [lines]. These are copied to individual device and line as they are created.
Added confcapability and confprefs for the configured stuff which doesn't change as device and so on are connected. prefs are based on line prefs if they exist, else the device prefs are used (prefs identifies codec order).
(closes issue #13806)
Reported by: pj
Patches:
codecs.diff uploaded by wedhorn (license 30)
Tested by: pj and me
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@163582 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r162804 | file | 2008-12-10 15:01:17 -0400 (Wed, 10 Dec 2008) | 6 lines
Fix subscription based MWI up a bit. We only want to put sip: at the beginning of the URI if it is not already there and revert code to ignore destination check if subscribing for MWI.
(closes issue #12560)
Reported by: vsauer
Patches:
patch001.diff uploaded by ramonpeek (license 266)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@162805 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r162738 | file | 2008-12-10 13:50:43 -0400 (Wed, 10 Dec 2008) | 6 lines
When a SIP peer unregisters set the expiry time back to 0 so that the 200 OK contains an expires of 0.
(closes issue #13599)
Reported by: hjourdain
Patches:
chan_sip.c.diff uploaded by hjourdain (license 583)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@162739 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Terry Wilson created the original patch for this functionality, which I slightly modified and added
the faxdetect=yes|no configuration option. This patch is only for T38 fax detection and does not
do anything for G711 over SIP fax detection. By default, this option is disabled.
Reviewboard: http://reviewboard.digium.com/r/69/
This functionality is for issue AST-140.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@161115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We dont want to scare users with this, so we added a devmode compile flag
(closes issue #13952)
Reported by: wedhorn
Patches:
packetdebug3.diff uploaded by wedhorn (license 30)
Tested by: mvanbaak, wedhorn
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@160938 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Move the code to start using the LIST macros.
Review: http://reviewboard.digium.com/r/72
(closes issue #13232)
Reported by: eliel
Patches:
iax2-provision.patch.txt uploaded by eliel (license 64)
(with minor changes pointed by Mark Michelson on review board)
Tested by: eliel
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@160663 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r160480 | tilghman | 2008-12-03 08:09:35 -0600 (Wed, 03 Dec 2008) | 7 lines
Jon Bonilla (Manwe) pointed out on the -dev list:
"I guess that having only ip-phones in mind is not a good approach. Since it is
possible to have a sip proxy connected to asterisk we could receive a 407
(unauthorized) or 483 (too many hops) as response and dialog ending would not be
a good behavior."
So modified.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@160481 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r160297 | tilghman | 2008-12-02 11:42:09 -0600 (Tue, 02 Dec 2008) | 10 lines
When the text does not match exactly (e.g. RTP/SAVP), then the %n conversion
fails, and the resulting integer is garbage. Thus, we must initialize the
integer and check it afterwards for success.
(closes issue #14000)
Reported by: folke
Patches:
asterisk-sipbg-sscanf-1.4.22.diff uploaded by folke (license 626)
asterisk-sipbg-sscanf-1.6.0.1.diff uploaded by folke (license 626)
asterisk-sipbg-sscanf-trunk-r159896.diff uploaded by folke (license 626)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@160308 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r160003 | russell | 2008-12-01 11:27:30 -0600 (Mon, 01 Dec 2008) | 6 lines
Apply some logic used in iax2_indicate() to iax2_setoption(), as well, since they
both have the potential to send control frames in the middle of call setup. We
have to wait until we have received a message back from the remote end before
we try to send any more frames. Otherwise, the remote end will consider it
invalid, and we'll get stuck in an INVAL/VNAK storm.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@160004 65c4cc65-6c06-0410-ace0-fbb531ad65f3
------------------------------------------------------------------------
r159808 | kpfleming | 2008-11-29 10:58:29 -0600 (Sat, 29 Nov 2008) | 7 lines
update dev-mode compiler flags to match the ones used by default on Ubuntu Intrepid, so all developers will see the same warnings and errors
since this branch already had some printf format attributes, enable checking for them and tag functions that didn't have them
format attributes in a consistent way
------------------------------------------------------------------------
in addition:
move some format attributes from main/utils.c to the header files they belong in, and fix up references to the relevant functions based on new compiler warnings
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@159818 65c4cc65-6c06-0410-ace0-fbb531ad65f3
because SPRINTF() use non-literal format strings (which cannot be checked), move it into its own module so the rest of func_strings can benefit from format string checking
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@159774 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r159316 | murf | 2008-11-25 15:41:10 -0700 (Tue, 25 Nov 2008) | 15 lines
(closes issue #12694)
Reported by: yraber
Patches:
12694.2nd.diff uploaded by murf (license 17)
Tested by: murf, laurav
Thanks to file (Joshua Colp) for his IAX fix.
the change to cdr.c allows no-answer to percolate
up into CDR's, and feels like the right place to
locate this fix; if BUSY is done here, no-answer
should be, too.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@159360 65c4cc65-6c06-0410-ace0-fbb531ad65f3
it would be best to maintain API compatibility. Instead, this commit introduces
ao2_callback_data() which is functionally identical to ao2_callback() except
that it allows you to pass arbitrary data to the callback.
Reviewed by Mark Michelson via ReviewBoard:
http://reviewboard.digium.com/r/64
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@158959 65c4cc65-6c06-0410-ace0-fbb531ad65f3
is only found if it dialed the extension that was subscribed to. You can now
specify 'ignore-context' for the 'notifycid' option in sip.conf which will, as
it's value implies, ignore the current context of the caller when doing the
lookup.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@158756 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Without this reorder tone will play after hangup and both wedhorn's and my wife have threatened to use an axe on our asterisk box
(closes issue #13948)
Reported by: wedhorn
Patches:
switch.diff uploaded by wedhorn (license 30)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@158694 65c4cc65-6c06-0410-ace0-fbb531ad65f3