Age | Commit message (Collapse) | Author | Files | Lines |
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r266292 | dvossel | 2010-05-28 12:55:38 -0500 (Fri, 28 May 2010) | 9 lines
fixes crash when creation of UDPTL fails
(closes issue #17264)
Reported by: falves11
Patches:
issue_17264_reviewboard_fix.diff uploaded by dvossel (license 671)
issue_17264_1.6.2_reviewboard_fix.diff uploaded by dvossel (license 671)
Tested by: falves11
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@266293 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r266006 | dvossel | 2010-05-26 13:32:51 -0500 (Wed, 26 May 2010) | 8 lines
fixes failed SIP Directed pickup resulting in dead channel
(closes issue #17339)
Reported by: one47
Patches:
sip_magic_pickup2 uploaded by one47 (license 23)
Tested by: one47, dvossel
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@266007 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r265842 | mmichelson | 2010-05-26 09:41:55 -0500 (Wed, 26 May 2010) | 9 lines
Re-enable "always" option for videosupport option in sip.conf.
(closes issue #17016)
Reported by: twilson
Patches:
17016.patch uploaded by mmichelson (license 60)
Tested by: devmod
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265890 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r265698 | mmichelson | 2010-05-25 15:59:04 -0500 (Tue, 25 May 2010) | 12 lines
Properly use peer's outboundproxy for outbound REGISTERs.
The logic used in transmit_register to get the outboundproxy for a peer
was flawed since this value would be overridden shortly afterwards when
create_addr was called.
In addition, this also fixes some logic used when parsing users.conf so
that the peer name is placed in the internally-generated register string
so that an outboundproxy set in the Asterisk GUI will be used for outbound
REGISTERs.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265699 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r265449 | mmichelson | 2010-05-24 16:44:30 -0500 (Mon, 24 May 2010) | 11 lines
Allow type=user SIP endpoints to be loaded properly from realtime.
(closes issue #16021)
Reported by: Guggemand
Patches:
realtime-type-fix.patch uploaded by Guggemand (license 897)
(altered by me slightly to avoid ref leaks)
Tested by: Guggemand
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265450 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r265087 | mmichelson | 2010-05-21 15:38:14 -0500 (Fri, 21 May 2010) | 7 lines
Be sure to set the sin_family on the proxy when allocating.
(closes issue #17157)
Reported by: stuarth
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265088 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r264452 | mmichelson | 2010-05-19 16:29:08 -0500 (Wed, 19 May 2010) | 86 lines
Fix transcode_via_sln option with SIP calls and improve PLC usage.
From reviewboard:
The problem here is a bit complex, so try to bear with me...
It was noticed by a Digium customer that generic PLC (as configured in
codecs.conf) did not appear to actually be having any sort of benefit when
packet loss was introduced on an RTP stream. I reproduced this issue myself
by streaming a file across an RTP stream and dropping approx. 5% of the
RTP packets. I saw no real difference between when PLC was enabled or disabled
when using wireshark to analyze the RTP streams.
After analyzing what was going on, it became clear that one of the problems
faced was that when running my tests, the translation paths were being set
up in such a way that PLC could not possibly work as expected. To illustrate,
if packets are lost on channel A's read stream, then we expect that PLC will
be applied to channel B's write stream. The problem is that generic PLC can
only be done when there is a translation path that moves from some codec to
SLINEAR. When I would run my tests, I found that every single time, read
and write translation paths would be set up on channel A instead of channel
B. There appeared to be no real way to predict which channel the translation
paths would be set up on.
This is where Kevin swooped in to let me know about the transcode_via_sln
option in asterisk.conf. It is supposed to work by placing a read translation
path on both channels from the channel's rawreadformat to SLINEAR. It also
will place a write translation path on both channels from SLINEAR to the
channel's rawwriteformat. Using this option allows one to predictably set up
translation paths on all channels. There are two problems with this, though.
First and foremost, the transcode_via_sln option did not appear to be working
properly when I was placing a SIP call between two endpoints which did not
share any common formats. Second, even if this option were to work, for PLC
to be applied, there had to be a write translation path that would go from
some format to SLINEAR. It would not work properly if the starting format
of translation was SLINEAR.
The one-line change presented in this review request in chan_sip.c fixed the
first issue for me. The problem was that in sip_request_call, the
jointcapability of the outbound channel was being set to the format passed to
sip_request_call. This is nativeformats of the inbound channel. Because of this,
when ast_channel_make_compatible was called by app_dial, both channels already
had compatibly read and write formats. Thus, no translation path was set up at
the time. My change is to set the jointcapability of the sip_pvt created during
sip_request_call to the intersection of the inbound channel's nativeformats and
the configured peer capability that we determined during the earlier call to
create_addr. Doing this got the translation paths set up as expected when using
transcode_via_sln.
The changes presented in channel.c fixed the second issue for me. First and
foremost, when Asterisk is started, we'll read codecs.conf to see the value of
the genericplc option. If this option is set, and ast_write is called for a
frame with no data, then we will attempt to fill in the missing samples for
the frame. The implementation uses a channel datastore for maintaining the
PLC state and for creating a buffer to store PLC samples in. Even when we
receive a frame with data, we'll call plc_rx so that the PLC state will have
knowledge of the previous voice frame, which it can use as a basis for when
it comes time to actually do a PLC fill-in.
So, reviewers, now I ask for your help. First off, there's the one line change
in chan_sip that I have put in. Is it right? By my logic it seems correct, but
I'm sure someone can tell me why it is not going to work. This is probably the
change I'm least concerned about, though. What concerns me much more is the
set of changes in channel.c. First off, am I even doing it right? When I run
tests, I can clearly see that when PLC is activated, I see a significant increase
in RTP traffic where I would expect it to be. However, in my humble opinion, the
audio sounds kind of crappy whenever the PLC fill-in is done. It sounds worse to
me than when no PLC is used at all. I need someone to review the logic I have used
to be sure that I'm not misusing anything. As far as I can see my pointer arithmetic
is correct, and my use of AST_FRIENDLY_OFFSET should be correct as well, but I'm
sure someone can point out somewhere where I've done something incorrectly.
As I was writing this review request up, I decided to give the code a test run under
valgrind, and I find that for some reason, calls to plc_rx are causing some invalid
reads. Apparently I'm reading past the end of a buffer somehow. I'll have to dig around
a bit to see why that is the case. If it's obvious to someone reviewing, speak up!
Finally, I have one other proposal that is not reflected in my code review. Since
without transcode_via_sln set, one cannot predict or control where a translation
path will be up, it seems to me that the current practice of using PLC only when
transcoding to SLINEAR is not useful. I recommend that once it has been determined
that the method used in this code review is correct and works as expected, then
the code in translate.c that invokes PLC should be removed.
Review: https://reviewboard.asterisk.org/r/622/
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@264453 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r264331 | dvossel | 2010-05-19 14:21:04 -0500 (Wed, 19 May 2010) | 13 lines
fixes crash in check_rtp_timeout
During deadlock avoidance the sip dialog pvt is locked and
unlocked. When this occurs we have no guarantee the pvt's owner
is still valid. We were trying to access the pvt's owner after
this without checking to see if it still existed first.
(closes issue #17271)
Reported by: under
Patches:
check_rtp_timeout.diff uploaded by under (license 914)
Tested by: dvossel
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@264332 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r262414 | pabelanger | 2010-05-11 15:26:17 -0400 (Tue, 11 May 2010) | 8 lines
Improve logging information for misconfigured contexts
(closes issue #17238)
Reported by: pprindeville
Patches:
chan_sip-bug17238.patch uploaded by pprindeville (license 347)
Tested by: pprindeville
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@262415 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r261560 | tilghman | 2010-05-06 10:39:10 -0500 (Thu, 06 May 2010) | 8 lines
Permit more lines within a SIP body to be parsed.
The example given within the related issue showed 120 lines, which was mostly
a result of the body being XML.
(closes issue #17179)
Reported by: khw
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@261563 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r261314 | pabelanger | 2010-05-05 14:43:03 -0400 (Wed, 05 May 2010) | 19 lines
Merged revisions 261274 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r261274 | pabelanger | 2010-05-05 12:42:22 -0400 (Wed, 05 May 2010) | 12 lines
Registration fix for SIP realtime.
Make sure realtime fields are not empty.
(closes issue #17266)
Reported by: Nick_Lewis
Patches:
chan_sip.c-realtime.patch uploaded by Nick Lewis (license 657)
Tested by: Nick_Lewis, sberney
Review: https://reviewboard.asterisk.org/r/643/
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@261315 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r254450 | kpfleming | 2010-03-25 10:27:31 -0500 (Thu, 25 Mar 2010) | 49 lines
Improve handling of T.38 re-INVITEs that arrive before a T.38-capable
application is executing on a channel.
This patch addresses an issue found during working with end-users
using res_fax. If an incoming call is answered in the dialplan, or
jumps to the 'fax' extension due to reception of a CNG tone (with
faxdetect enabled), and then the remote endpoint sends a T.38
re-INVITE, it is possible for the channel's T.38 state to be
'T38_STATE_NEGOTIATING' when the application starts up. Unfortunately,
even if the application wants to use T.38, it can't respond to the
peer's negotiation request, because the AST_CONTROL_T38_PARAMETERS
control frame that chan_sip sent originally has been lost, and the
application needs the content of that frame to be able to formulate a
reply.
This patch adds a new 'request' type to AST_CONTROL_T38_PARAMETERS,
AST_T38_REQUEST_PARMS. If the application sends this request, chan_sip
will re-send the original control frame (with
AST_T38_REQUEST_NEGOTIATE as the request type), and the application
can respond as normal. If this occurs within the five second timeout
in chan_sip, the automatic cancellation of the peer reinvite will be
stopped, and the application will 'own' the negotiation process from
that point onwards.
This also improves the code path in chan_sip to allow sip_indicate(),
when called for AST_CONTROL_T38_PARAMETERS, to be able to return a
non-zero response, which should have been in place before since the
control frame *can* fail to be processed properly. It also modifies
ast_indicate() to return whatever result the channel driver returned
for this control frame, rather than converting all non-zero results
into '-1'. Finally, the new request type intentionally returns a
positive value, so that an application that sends
AST_T38_REQUEST_PARMS can know for certain whether the channel driver
accepted it and will be replying with a control frame of its own, or
whether it was ignored (if the sip_indicate()/ast_indicate() path had
properly supported failure responses before, this would not be
necessary).
This patch also modifies res_fax to take advantage of the new request.
In addition, this patch makes sip_t38_abort() actually lock the
private structure before doing its work... bad programmer, no donut.
This patch also enhances chan_sip's 'faxdetect' support to allow
triggering on T.38 re-INVITEs received as well as CNG tone detection.
Review: https://reviewboard.asterisk.org/r/556/
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@260884 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r259957 | mmichelson | 2010-04-28 17:34:15 -0500 (Wed, 28 Apr 2010) | 11 lines
Don't override peer context with domain context.
(closes issue #17040)
Reported by: pprindeville
Patches:
asterisk-1.6-bugid17040.patch uploaded by pprindeville (license 347)
Tested by: pprindeville
Review: https://reviewboard.asterisk.org/r/565/
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@259959 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r258934 | lmadsen | 2010-04-26 10:59:34 -0500 (Mon, 26 Apr 2010) | 7 lines
Small error in the T.140 RTP port verbose log.
(closes issue #16988)
Reported by: frawd
Patches:
chan_sip_sdp_verbose_fix.diff uploaded by frawd (license 610)
Tested by: russell
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@258935 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r258305 | dvossel | 2010-04-21 13:13:36 -0500 (Wed, 21 Apr 2010) | 12 lines
fixes issue with double "sip:" in header field
This is a clear mistake in logic. Future discussions
about how to avoid having to handle uri's like this
should take place in the future, but this fix needs
to go in for now.
(closes issue #15847)
Reported by: ebroad
Patches:
doublesip.patch uploaded by ebroad (license 878)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@258314 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r257493 | tilghman | 2010-04-15 15:30:15 -0500 (Thu, 15 Apr 2010) | 20 lines
Merged revisions 257467 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r257467 | tilghman | 2010-04-15 15:24:50 -0500 (Thu, 15 Apr 2010) | 13 lines
Don't recreate peer, when responding to a repeated deregistration attempt.
When a reply to a deregistration is lost in transmit, the client retries the
deregistration. Previously, this would cause a realtime/autocreate peer to be
loaded back into memory, after it had already been correctly purged. Instead,
we just want to resend the reply without loading the peer.
(closes issue #16908)
Reported by: kkm
Patches:
20100412__issue16908.diff.txt uploaded by tilghman (license 14)
Tested by: kkm
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@257510 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r257191 | tilghman | 2010-04-13 14:17:48 -0500 (Tue, 13 Apr 2010) | 10 lines
Also unref the pvt when we delete the provisional keepalive job.
(closes issue #16774)
Reported by: kowalma
Patches:
20100315__issue16774.diff.txt uploaded by tilghman (license 14)
Tested by: falves11, jamicque
Review: https://reviewboard.asterisk.org/r/591/
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@257210 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@254548 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@254542 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This re-renames ast_rtp_update_source to ast_rtp_new_source
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@253158 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r252442 | tilghman | 2010-03-14 23:25:35 -0500 (Sun, 14 Mar 2010) | 7 lines
THIS IS NOT PYTHON. Indentation doesn't matter, only braces do.
(closes issue #17025)
Reported by: smurfix
Patches:
sip.patch uploaded by smurfix (license 547)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@252444 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r252089 | twilson | 2010-03-12 16:04:51 -0600 (Fri, 12 Mar 2010) | 20 lines
Only change the RTP ssrc when we see that it has changed
This change basically reverts the change reviewed in
https://reviewboard.asterisk.org/r/374/ and instead limits the
updating of the RTP synchronization source to only those times when we
detect that the other side of the conversation has changed the ssrc.
The problem is that SRCUPDATE control frames are sent many times where
we don't want a new ssrc, including whenever Asterisk has to send DTMF
in a normal bridge. This is also not the first time that this mistake
has been made. The initial implementation of the ast_rtp_new_source
function also changed the ssrc--and then it was removed because of
this same issue. Then, we put it back in again to fix a different
issue. This patch attempts to only change the ssrc when we see that
the other side of the conversation has changed the ssrc.
It also renames some functions to make their purpose more clear.
Review: https://reviewboard.asterisk.org/r/540/
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@252137 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r250246 | dvossel | 2010-03-02 18:18:28 -0600 (Tue, 02 Mar 2010) | 2 lines
fixes signed to unsigned int comparision issue for FaxMaxDatagram value.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@250253 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r249893 | dvossel | 2010-03-02 13:08:38 -0600 (Tue, 02 Mar 2010) | 11 lines
fixes adaptive jitterbuffer configuration
When configuring the adaptive jitterbuffer, the target_extra
value not only could not be set from the configuration, but was
not even being set to its proper default. This value is required
in order for the adaptive jitterbuffer to work correctly. To resolve
this a config option has been added to expose this value to the conf
files, and a default value is provided when no config specific value
is present.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@249895 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r249101 | mmichelson | 2010-02-26 11:04:58 -0600 (Fri, 26 Feb 2010) | 14 lines
Merged revisions 249100 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r249100 | mmichelson | 2010-02-26 11:04:29 -0600 (Fri, 26 Feb 2010) | 8 lines
For T.38 reINVITEs treat a 606 the same as a 488.
(closes issue #16792)
Reported by: vrban
Patches:
t38_606.patch uploaded by vrban (license 756)
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@249104 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r248397 | dvossel | 2010-02-23 10:34:39 -0600 (Tue, 23 Feb 2010) | 15 lines
Merged revisions 248396 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r248396 | dvossel | 2010-02-23 10:26:05 -0600 (Tue, 23 Feb 2010) | 9 lines
fixes invite with replaces deadlock
(closes issue #16862)
Reported by: pwalker
Patches:
replaces_deadlock_1.4 uploaded by dvossel (license 671)
Tested by: pwalker, dvossel
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@248398 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r247915 | dvossel | 2010-02-19 11:40:26 -0600 (Fri, 19 Feb 2010) | 7 lines
handle_request_invite revise comment, fix coding guideline issues
I'm working with this code right now trying to analyze a deadlock.
This change is just to clean up a few things before I make a more
complex patch.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@247916 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r247787 | tilghman | 2010-02-18 15:42:53 -0600 (Thu, 18 Feb 2010) | 17 lines
If the peer record is from realtime, it could be set to 0, due to MySQL not representing NULL well in integer columns.
NULL means the value is not specified for the column, which normally means
the driver uses whatever is the default value. However, on MySQL, placing
a NULL in either a float or integer column results in a retrieval of the 0
value. Hence, users get an errant error on load. This patch suppresses
that error and makes the value as if it was not there.
Note that this cannot be done in the realtime driver, because the lack of
difference between NULL and 0 can only be intepreted correctly by the
driver itself. If we did it in the realtime driver, then it would be
effectively impossible to set any realtime field to 0, because it would act
as if the field were unspecified and possibly take on a different value.
(closes issue #16683)
Reported by: wdoekes
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@247792 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r245727 | mnicholson | 2010-02-09 11:40:04 -0600 (Tue, 09 Feb 2010) | 2 lines
This commit removes an extra newline in T.38 generated SDP packets. This bug was caused by the fix introduced in r243860.
(closes issue #16766)
Reported by: raivisr
Patches:
t38-sdp-newline-fix1.diff uploaded by mnicholson (license 96)
Tested by: raivisr
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@245728 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r244443 | dvossel | 2010-02-02 16:27:23 -0600 (Tue, 02 Feb 2010) | 18 lines
fixes crash during T.38 negotiation caused by invalid or missing FaxMaxDatagram field
AST-2010-001
(closes issue #16634)
Reported by: krn
(closes issue #16724)
Reported by: barthpbx
(closes issue #16517)
Reported by: bklang
(closes issue #16485)
Reported by: elsto
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@244445 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r243860 | russell | 2010-01-28 12:35:15 -0600 (Thu, 28 Jan 2010) | 2 lines
Add a missing line terminator for T.38 SDP.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@243861 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r243780 | russell | 2010-01-28 09:07:23 -0600 (Thu, 28 Jan 2010) | 9 lines
Merged revisions 243779 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r243779 | russell | 2010-01-28 09:03:17 -0600 (Thu, 28 Jan 2010) | 2 lines
Fix a bogus third argument to ast_copy_string().
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@243854 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r242227 | oej | 2010-01-22 10:28:34 +0100 (Fre, 22 Jan 2010) | 11 lines
Merged revisions 242226 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r242226 | oej | 2010-01-22 10:19:30 +0100 (Fre, 22 Jan 2010) | 3 lines
Initialize notify_types to NULL
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@242234 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
SIP show channelstats show current RTCP statistics for calls - if we have it. Calls bridged
in RTP p2p bridge doesn't have any statistics. In calls where the remote end doesn't send
RTCP or we can't receive it due to NAT, there's no reliable data as well.
Thanks, Klaus, for the patch. Sorry for the delay.
(closes issue #15819)
Reported by: klaus3000
Patches:
asterisk-sip-show-channelstats-1.6.2.txt uploaded by klaus3000 (license 65)
Tested by: klaus3000, oej
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@239703 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r239427 | dvossel | 2010-01-12 10:14:41 -0600 (Tue, 12 Jan 2010) | 14 lines
fixes text support in sdp answer
The code that handled setting 'm=text' in the sdp was not executing
in the correct order. The check to see if text was needed came after
the check to add 'm=text' to the sdp, this resulted in 'm=text' always
being set to 0 because it looked like text was never required.
(closes issue #16457)
Reported by: peterj
Patches:
textportinsdp.diff uploaded by peterj (license 951)
issue16457.diff uploaded by dvossel (license 671)
Tested by: peterj
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@239428 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r209400 | kpfleming | 2009-07-28 08:49:46 -0500 (Tue, 28 Jul 2009) | 3 lines
Define side-effect-safe MIN and MAX macros and remove duplicate definitions from various files.
(closes issue #16251)
Reported by: asgaroth
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@238499 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r238405 | dvossel | 2010-01-07 14:00:31 -0600 (Thu, 07 Jan 2010) | 8 lines
Change in sip show channels display format allowing more digits for CID
(closes issue #16459)
Reported by: Rzadzins
Patches:
chan_sip_longer_cid.patch uploaded by Rzadzins (license 953)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@238406 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r237968 | tilghman | 2010-01-06 00:53:23 -0600 (Wed, 06 Jan 2010) | 2 lines
Whoa, duplicate setting (dead code).
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@237969 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r237136 | oej | 2010-01-02 10:54:22 +0100 (Lör, 02 Jan 2010) | 10 lines
Merged revisions 237135 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r237135 | oej | 2010-01-02 10:52:30 +0100 (Lör, 02 Jan 2010) | 2 lines
Release memory of the contact acl before unloading module
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@237139 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r236802 | tilghman | 2009-12-29 17:05:45 -0600 (Tue, 29 Dec 2009) | 7 lines
Shut down the SIP session timers more gracefully, in order to prevent a possible crash.
(closes issue #16452)
Reported by: corruptor
Patches:
20091221__issue16452.diff.txt uploaded by tilghman (license 14)
Tested by: corruptor
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@236804 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r236063 | dvossel | 2009-12-22 11:00:08 -0600 (Tue, 22 Dec 2009) | 18 lines
Merged revisions 236062 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r236062 | dvossel | 2009-12-22 10:58:19 -0600 (Tue, 22 Dec 2009) | 11 lines
fixes issue with p->method incorrectly set to ACK
It is possible for a second ACK to come in for a retransmitted message.
If an ack does not match an unacked message in our queue, restore the previous
p->method as this ACK is completely ignored.
(closes issue #16295)
Reported by: omolenkamp
Patches:
issue16295_v2.diff uploaded by dvossel (license 671)
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@236064 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r235521 | file | 2009-12-17 19:21:07 -0400 (Thu, 17 Dec 2009) | 3 lines
Remove some old code for going to the 'fax' extension when a T.38 switchover occurs. This would have
already happened when we detected the CNG tone so this was basically a noop.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@235522 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
reverses the changes caused by issue #15539. The
issue reported was expected behavior.
(issue #15539)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@235134 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r234526 | oej | 2009-12-14 11:46:20 +0100 (Mån, 14 Dec 2009) | 16 lines
Merged revisions 234492 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r234492 | oej | 2009-12-14 11:16:00 +0100 (Mån, 14 Dec 2009) | 8 lines
Stop sending 183's after call hangup.
There where still cases where the 183 keep-alive mechanism would not stop
sending 183's even though the Asterisk server had sent a final reply to
the invite.
EDVX-28
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@234559 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r234129 | tilghman | 2009-12-10 10:24:26 -0600 (Thu, 10 Dec 2009) | 16 lines
Merged revisions 234095 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r234095 | tilghman | 2009-12-10 10:08:20 -0600 (Thu, 10 Dec 2009) | 9 lines
When we receive no response at all to our INVITE, allow the channel to be destroyed.
(closes issue #15627)
Reported by: falves11
Patches:
20091209__issue15627__1.6.0.diff.txt uploaded by tilghman (license 14)
20091209__issue15627__1.4.diff.txt uploaded by tilghman (license 14)
Tested by: falves11
Review: https://reviewboard.asterisk.org/r/446/
(closes issue #15716)
Reported by: dant
(closes issue #16270)
Reported by: corruptor
(closes issue #15356)
Reported by: falves11
(issue #16382)
Reported by: lftsy
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@234133 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r233472 | dvossel | 2009-12-07 12:08:46 -0600 (Mon, 07 Dec 2009) | 15 lines
Merged revisions 233471 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r233471 | dvossel | 2009-12-07 12:07:38 -0600 (Mon, 07 Dec 2009) | 9 lines
fixes missing Contact header angle brackets
(closes issue #16298)
Reported by: mgernoth
Patches:
reg_parse_issue_1.4.diff uploaded by dvossel (license 671)
Tested by: dvossel
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@233473 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r233394 | mnicholson | 2009-12-07 10:14:42 -0600 (Mon, 07 Dec 2009) | 8 lines
Do not reject SDP packets describing only non audio streams.
(closes issue #16387)
Reported by: zalex1953
Patches:
media-level-c-fix1.diff uploaded by mnicholson (license 96)
Tested by: mnicholson, zalex1953
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@233396 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r232345 | file | 2009-12-02 12:40:14 -0400 (Wed, 02 Dec 2009) | 7 lines
Add support for handling the 415 Unsupported media type response like we do for a 488 Not acceptable here response.
(closes issue #16186)
Reported by: atis
Patches:
sip_t38_response_415.patch uploaded by atis (license 242)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@232348 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r232230 | file | 2009-12-02 10:54:28 -0400 (Wed, 02 Dec 2009) | 5 lines
Fix a bug where a scheduled item ID would get retained on registrations in a certain scenario
causing code to execute during reload that should not.
(issue AST-263)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@232232 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r231692 | kpfleming | 2009-11-30 15:47:42 -0600 (Mon, 30 Nov 2009) | 22 lines
Another round of UDPTL stack fixes/improvements:
1) Allow users of UDPTL stack to associate a character-string tag with a UDPTL
session, so that log/error/debug messages generated by the UDPTL stack can
be 'connected' to the endpoint that caused them to be generated.
2) Improve comments (and process) of calculating the far end's maximum IFP size
when redundancy mode is in use for error correction.
3) When an IFP larger than the calculated 'far max IFP' size is presented for
writing, truncate it rather than putting in the buffer and allowing the buffer
to overflow; this will cause the ends to retrain to a lower bit rate that
produces IFPs of an appropriate size if possible, and if not possible, the
FAX transfer will fail completely. In these cases, it is due to the one endpoint
supplying a T38FaxMaxDatagram value that is improperly calculated and is
too low to be of use; we have configuration options available to override
this behavior.
4) Eliminate use of T38FaxMaxDatagram value in udptl.conf; it is no longer
needed.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@231696 f38db490-d61c-443f-a65b-d21fe96a405b
|