| Age | Commit message (Collapse) | Author |
|---|
|
The same code was repeated in lots of different places, so I made a utility
fuction for it. This should make the merge in the v6-new branch easier.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264905 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
directmediapermit/directmediadeny support to restrict which peers can do
directmedia based on ip address. In some networks not all phones are fully
routed, i.e. not all phones can ping each other. This patch adds a way to
restrict directmedia for certain peers between certain networks.
(closes issue #16645)
Reported by: raarts
Patches:
directmediapermit.patch uploaded by raarts (license 937)
Tested by: raarts
Review: https://reviewboard.asterisk.org/r/467/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264626 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
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: https://origsvn.digium.com/svn/asterisk/trunk@264452 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
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: https://origsvn.digium.com/svn/asterisk/trunk@264331 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263860 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Thanks to Richard for pointing this out.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263810 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
From reviewboard:
Digium has a commercial customer who has made extensive use of the connected party and
redirecting information present in later versions of Asterisk Business Edition and which
is to be in the upcoming 1.8 release. Through their use of the feature, new problems and solutions
have come about. This patch adds several enhancements to maximize usage of the connected party
and redirecting information functionality.
First, Asterisk trunk already had connected line interception macros. These macros allow you to
manipulate connected line information before it was sent out to its target. This patch adds the
same feature except for redirecting information instead.
Second, the ast_callerid and ast_party_id structures have been enhanced to provide a "tag." This
tag can be set with func_callerid, func_connectedline, func_redirecting, and in the case of DAHDI,
mISDN, and SIP channels, can be set in a configuration file. The idea behind the callerid tag is
that it can be set to whatever value the administrator likes. Later, when running connected line
and redirecting macros, the admin can read the tag off the appropriate structure to determine what
action to take. You can think of this sort of like a channel variable, except that instead of having
the variable associated with a channel, the variable is associated with a specific identity within
Asterisk.
Third, app_dial has two new options, s and u. The s option lets a dialplan writer force a specific
caller ID tag to be placed on the outgoing channel. The u option allows the dialplan writer to force
a specific calling presentation value on the outgoing channel.
Fourth, there is a new control frame subclass called AST_CONTROL_READ_ACTION added. This was added
to correct a very specific situation. In the case of SIP semi-attended (blond) transfers, the party
being transferred would not have the opportunity to run a connected line interception macro to
possibly alter the transfer target's connected line information. The issue here was that during a
blond transfer, the SIP transfer code has no bridged channel on which to queue the connected line
update. The way this was corrected was to add this new control frame subclass. Now, we queue an
AST_CONTROL_READ_ACTION frame on the channel on which the connected line interception macro should
be run. When ast_read is called to read the frame, ast_read responds by calling a callback function
associated with the specific read action the control frame describes. In this case, the action taken
is to run the connected line interception macro on the transferee's channel.
Review: https://reviewboard.asterisk.org/r/652/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Clean up chan_sip.c to use new AST_CLI functions
(closes issue #17287)
Reported by: pabelanger
Patches:
issue17287.patch uploaded by pabelanger (license 224)
Tested by: russell
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@262613 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue #17238)
Reported by: pprindeville
Patches:
chan_sip-bug17238.patch uploaded by pprindeville (license 347)
Tested by: pprindeville
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@262414 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The Refer-To header field containing the Replaces header in the URI
was not being decoded properly. This caused invalid parsing between
the caller id field and the domain resulting in a failed transfer.
(closes issue #17284)
Reported by: dvossel
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@261316 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
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: https://origsvn.digium.com/svn/asterisk/trunk@261314 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(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: https://origsvn.digium.com/svn/asterisk/trunk@259957 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue #16988)
Reported by: frawd
Patches:
chan_sip_sdp_verbose_fix.diff uploaded by frawd (license 610)
Tested by: russell
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@258934 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
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: https://origsvn.digium.com/svn/asterisk/trunk@258305 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
SUBSCRIBE.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@257646 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
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: https://origsvn.digium.com/svn/asterisk/trunk@257493 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(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: https://origsvn.digium.com/svn/asterisk/trunk@257191 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
To guarantee the channel is valid when calling setvar on the MASTER_CHANNEL
dialplan function, a channel reference must be taken before unlocking. Thanks
to russell for pointing out the error.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256823 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256661 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
From Review Board:
There are two interrelated changes here.
First, there is the introduction of func_srv. This adds two new read-only
dialplan functions, SRVQUERY and SRVRESULT. They work very similarly to the
ENUMQUERY and ENUMRESULT functions, except that this allows one to query SRV
records instead. In order to facilitate this work, I added a couple of new API
calls to srv.h. ast_srv_get_record_count tells the number of records returned
by an SRV lookup. This number is calculated at the time of the SRV lookup.
ast_srv_get_nth_record allows one to get a numbered SRV record.
Second, there is the modification to chan_sip that allows one to specify a
hostname or IP address (along with a port) to send an outgoing INVITE to when
dialing a SIP peer. This goes hand-in-hand with func_srv. You can query SRV
records and then use the host and port from the results to dial via a specific
host instead of what is configured in sip.conf.
Review: https://reviewboard.asterisk.org/r/608
SWP-1200
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256485 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue #16767)
Reported by: lmsteffan
Patches:
deadlock_16767v3.diff uploaded by dvossel (license 671)
Review: https://reviewboard.asterisk.org/r/606/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256319 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
SWP-1229
ABE-2161
* Ensure chan_local.c:local_call() will not leak cid.cid_dnid when
copying.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256104 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
There was a bug where we split the URI on the @ sign and then attempted
to compare to "anonymous@anonymous.invalid" afterwards. This comparison
could never evaluate true. So now we keep a copy of the URI prior to the
split so that the comparison is valid.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@255701 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
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: https://origsvn.digium.com/svn/asterisk/trunk@254450 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Peer reviewed out-of-band by file.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@252627 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue #17025)
Reported by: smurfix
Patches:
sip.patch uploaded by smurfix (license 547)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@252442 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
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: https://origsvn.digium.com/svn/asterisk/trunk@252089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The first real test added to the external test suite found a pretty nasty crash
that occurred in Asterisk trunk. The crash was due to a race condition between
the REFER handling and channel destruction in the channel thread. After the
transfer has been completed, we go back to the transferrer channel and try to
lock it so we can fire off a CEL event. However, there was no guarantee that
the channel was still around at that point since it's racing against the channel
thread.
Since ast_channel is a reference counted object, the fix is simple. The code
unlocks the transferrer channel before finally completing the transfer with
an async goto. At this point the channel thread is going to start call tear
down and the channel will eventually be destroyed. To ensure that the channel
is valid when we want to fire off the CEL event, increase the channel's
reference count.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@251137 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The get_local_address() function for an RTP instance was used when building an
SDP, but the results were not honored. The RTP engine activate() function was
not being used once we have determined that media will now flow.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@250917 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@250246 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
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: https://origsvn.digium.com/svn/asterisk/trunk@249893 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
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: https://origsvn.digium.com/svn/asterisk/trunk@249101 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
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: https://origsvn.digium.com/svn/asterisk/trunk@248397 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Uncommenting the REF_DEBUG definition where it was in the source
resulted in only a small part of the astobj2 references being logged
to a file. Moving this up higher in the include list causes all references
to be logged as they should be.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@248347 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
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: https://origsvn.digium.com/svn/asterisk/trunk@247915 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
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: https://origsvn.digium.com/svn/asterisk/trunk@247787 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
CHANNEL function.
Also includes a test for retrieving rtpqos parameters, including a NULL RTP
driver. Additionally, some further separation of the SIP internal API into
headers was necessary.
(closes issue #16652)
Reported by: kkm
Patches:
20100204__issue16652.diff.txt uploaded by tilghman (license 14)
Review: https://reviewboard.asterisk.org/r/501/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@247124 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
warn) in comparison to Timer T1.
(closes issue #16643)
Reported by: nahuelgreco
Patches:
20100204__issue16643.diff.txt uploaded by tilghman (license 14)
Tested by: oej
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@246724 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Code Refactoring Changes
- read_to_parts() moved to reqresp_parser.c and has been renamed as
get_name_and_number()
- get_in_brackets() moved to reqresp_parser.c
- find_closing_quotes() added to sip_utils.h
Logic Changes
- get_name_and_number() now uses parse_uri() and get_calleridname()
for parsing. Before this change only names within quotes were
found, when names not within quotes are possible.
New Unit Tests
-sip_get_name_and_number_test
-sip_get_in_brackets_test
(closes issue #16707)
Reported by: Nick_Lewis
Patches:
issue16706.diff uploaded by dvossel (license 671)
Review: https://reviewboard.asterisk.org/r/499/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@246627 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
A patch was committed recently that converted duplicate uri parsing
code to use the parse_uri function. There were two instances where
this conversion did not mimic previous behavior exactly because the
port was not being parsed off the end of the domain. In order to do
this, a dummy pointer argument needs to be passed into parse_uri so
it will know it must parse out the port from the domain. If a port
output paramenter is not present, the domain is returned with the
port still attached.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@246420 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
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: https://origsvn.digium.com/svn/asterisk/trunk@245727 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This config option is already handled by the function handle_common_options
and it is unnecessary to parse the value again.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@245230 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
First off, these options weren't actually doing anything.
By the time the options were parsed, the peer and dialog
containers had already been allocated with their default
values.
Second, hash table size is something that doesn't really
make sense to change in a config file. If a user is that
interested in changing the hashtable size, he can modify
the source itself.
I have removed the parsing of the hash_peer, hash_user,
and hash_dialog options. I have removed the hash_user_size
variable altogether since it is not used at all. I also
changed hash_peer_size and hash_dialog_size to be constant,
and have changed the symbols to be in all caps as constants
typically are. I have also removed the entire section in
sip.conf.sample regarding configurable hashtable sizes.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@245192 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
default expiry was not being set correctly for a registry object.
Thanks to ebroad for reporting the issue and testing the patch.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@244924 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
parse_moved_contact attempts to remove a quoted string
twice, and the first try wasn't even being done correctly.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@244769 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
New files
- channels/sip/sip.h – A new header for shared #define, enum, and struct
definitions.
- channels/sip/include/sip_utils.h – sip util functions shared among
the all the sip APIs
- channels/sip/include/config_parser.h – sip config-parser API
- channels/sip/config_parser.c – Contains sip.conf parsing helper functions
with unit tests.
- channels/sip/include/reqresp_parser.h – sip request response parser API
- channels/sip/reqresp_parser.c – Contains sip request and response parsing
helper functions with unit tests.
New Unit Tests
- sip_parse_uri_test
- sip_parse_host_test
- sip_parse_register_line_test
Code Refactoring
- All reusable #define, enum, and struct definitions were moved out of chan_sip.c
into sip.h. During this process formatting changes were made to comments
in both sip.h and chan_sip.c in order to better adhere to the coding guidelines.
- The beginnings of three new sip APIs, sip-utils.h, config-parser.h,
reqresp-parser.h using existing chan_sip.c functions.
- parse_uri() and get_calleridname() were moved from chan_sip.c to request-parser.c
along with unit tests for both functions.
- sip_parse_host() and sip_parse_register_line() were moved from chan_sip.c to
config-parser.c along with unit tests for both functions.
Changes to parse_uri()
-removal of the options parameter. It was never used and did not behave correctly.
-additional check for [?header] field. When this field was present, the transport
type was not being set correctly.
----- Overview -----
This patch is introduced with the hope that unit tests for all our sip parsing
functions will be written soon. chan_sip is a huge file, and with the addition of
each unit test chan_sip is going to grow larger and harder to maintain. I'm proposing
we begin refactoring chan_sip, starting with the parsing functions. With each parsing
function we move into a separate helper file, a unit test should accompany it. I've
attempted to lay down the ground work for this change by creating two new parser
helper files (config-parser.c and reqresp-parser.c) and moving all shared structs,
enums, and defines from chan_sip.c into a shared sip.h file. We can't verify everything
in Asterisk using unit tests, but string parsing is one area where unit tests make
the most sense. By beginning to restructure the code in this way, chan_sip not only
becomes less bloated, but Asterisk as a whole will become more stable.
Review: https://reviewboard.asterisk.org/r/477/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@244597 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
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: https://origsvn.digium.com/svn/asterisk/trunk@244443 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@243860 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
