https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r279568 | dvossel | 2010-07-26 14:59:03 -0500 (Mon, 26 Jul 2010) | 21 lines
transaction matching using top most Via header
This patch modifies the way chan_sip.c does transaction to dialog
matching. Asterisk now stores information in the top most Via header
of the initial incoming request and compares that against other Requests
that have the same call-id. This results in Asterisk being able to
detect a forked call in which it has received multiple legs of the
fork. I completely stripped out the previous matching code and made
the comparisons a little more explicit and easier to understand. My
comments in the code should offer all the details involving this patch.
This patch also fixes a bug with the usage of the OBJ-MULTIPLE flag to
find multiple dialogs with the same call-id. Since the callback
function was returning (CMP_MATCH | CMP_STOP) only the first item
found was being returned. I fixed this by making a new callback
function for finding multiple dialogs that only returns (CMP_MATCH)
on a match allowing for multiple items to be returned.
Review: https://reviewboard.asterisk.org/r/776/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@279569 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r279504 | mmichelson | 2010-07-26 11:04:09 -0500 (Mon, 26 Jul 2010) | 14 lines
Allow for systems without locale support to be usable.
A recent change to SIP URI comparison code added a locale-specific
string comparison to the mix, and certain systems do not support
such functions. This fix allows for those systems to still use
Asterisk 1.8
(closes issue #17697)
Reported by: pprindeville
Patches:
asterisk-trunk-bugid17697.patch uploaded by pprindeville (license 347)
Tested by: mmichelson
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@279533 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This initially was created to work around the issue of
using a string comparison instead of a binary comparison
for IP addresses. It evolved a bit when test cases were
created and it was discovered that comparison of URI
parameters was not working exactly as it should.
sip_uri_cmp() and its helpers have been moved to reqresp_parser.c
and a new test has been added.
(closes issue #17662)
Reported by: oej
Review: https://reviewboard.asterisk.org/r/792
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278980 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are two changes here:
1. Since the externip setting can now have a port attached
to it, calling it "externip" is misleading. The option is now
documented and parsed as "externaddr." This also extends to the
"matchexterniplocally" setting. It is now documented and parsed
as "matchexternaddrlocally." The old names for the options may
still be used, but they are no longer used in the sip.conf.sample
file.
2. If no port is set for the externaddr, and UDP is the transport
to be used, then we will set the port of the externaddr to that of
the udpbindaddr. This was how things worked prior to the IPv6 merge,
so this is a regression fix.
(closes issue #17665)
Reported by: mmichelson
Patches:
17665.diff#2 uploaded by pprindeville (license 347)
Tested by: pprindeville
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@277873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
sip.conf configuration for the channel and for devices.
The Max-Forwards header is used to prevent loops in a SIP network. Each intermediary,
like SIP proxys and SBCs, decrement this counter and detects when it reaches zero,
at which point the SIP request is nicely killed in a SIP-friendly way.
Review: https://reviewboard.asterisk.org/r/778/
Thanks to dvossel for the review and good advice.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276951 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Retransmission of packets should not be based on how many packets were
sent, but instead on a timeout period. Depending on whether or not the
packet is for a INVITE or NON-INVITE transaction, the number of packets
sent during the retransmission timeout period will be different, so
timing out based on the number of packets sent is not accurate.
This patch fixes this by removing the retransmit limit and only stopping
retransmission after a timeout period is reached. By default this
timeout period is 64*(Timer T1) for both INVITE and non-INVITE
transactions. For more information on sip timer values refer to
RFC3261 Appendix A.
Review: https://reviewboard.asterisk.org/r/749/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276219 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Some code improperly assumes that the sessions are still there, so revert the
change until I can find all of them and fix them.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276206 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since we are only keeping the dialog around for retransmissions at this point
and there is no possibility that we are still handling RTP, go ahead and
destroy the RTP sessions. Keeping them alive for 32 past when they are used
is unnecessary and can lead to problems with having too many open file
descriptors, etc.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275998 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Part of the change with the IPv6 changes is to treat a host:port as
a single 'domain' entity. This test was not updated to have the correct
expectation after calling parse_uri().
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274984 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds a generic API for accommodating IPv6 and IPv4 addresses
within Asterisk. While many files have been updated to make use of the
API, chan_sip and the RTP code are the files which actually support
IPv6 addresses at the time of this commit. The way has been paved for
easier upgrading for other files in the near future, though.
Big thanks go to Simon Perrault, Marc Blanchet, and Jean-Philippe Dionne
for their hard work on this.
(closes issue #17565)
Reported by: russell
Patches:
asteriskv6-test-report.pdf uploaded by russell (license 2)
Review: https://reviewboard.asterisk.org/r/743
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274783 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A failure when calling the get_destination can mean multiple things. If
the extension is not found, a 404 error is appropriate, but if the URI
scheme is incorrect, a 404 is not approperiate. This patch adds the
get_destination_result enum to differentiate between these and other failure
types. The only logical difference in this patch is that we now send a "416
Unsupported URI scheme" response instead of a "404" when the scheme is not
recognized. This indicates to the initiator of the INVITE to retry the request
with a correct URI.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@273427 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RFC 3261 section 8.2.2.3 states that if any unsupported options
are found in the Require header field, a "420 (Bad Extension)"
response should be sent with an Unsupported header field containing
only the unsupported options.
This is not currently being done correctly. Right now, if Asterisk
detects any unsupported sip options in a Require header the entire
list of options are returned in the Unsupported header even if some
of those options are in fact supported. This patch fixes that by
building an unsupported options character buffer when parsing the
options that can be sent with the 420 response. A unit test verifying
this functionality has been created. Some code refactoring was required.
Review: https://reviewboard.asterisk.org/r/680/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272880 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r271689 | mnicholson | 2010-06-22 07:52:27 -0500 (Tue, 22 Jun 2010) | 8 lines
Modify chan_sip's packet generation api to automatically calculate the Content-Length. This is done by storing packet content in a buffer until it is actually time to send the packet, at which time the size of the packet is calculated. This change was made to ensure that the Content-Length is always correct.
(closes issue #17326)
Reported by: kenner
Tested by: mnicholson, kenner
Review: https://reviewboard.asterisk.org/r/693/
........
This change also adds an ast_str_copy_string() function (similar to ast_copy_string), that copies one ast_str into another, properly handling embedded nulls.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271690 65c4cc65-6c06-0410-ace0-fbb531ad65f3
According to RFC 3261 section 17.2.2, which describes non-INVITE server
transaction, when a dialog enters the Completed state it must destroy
the dialog after Timer J (T1*64) fires. For a BYE transaction Asterisk
terminates the dialog immediately during sip_hangup() when it should be
waiting T1*64 ms. This results in some odd behavior. For instance if
Asterisk receives a BYE and transmits a 200ok in response, if the endpoint
never receives the 200ok it will retransmit the BYE to which Asterisk
responds with a "481 Call leg/transaction does not exist" because the
dialog is already gone.
To resolve this I made a function called sip_scheddestroy_final(). This
differs slightly from sip_schedestroy() in that it enables a flag that
will prevent the destruction from ever being rescheduled or canceled
afterwards. It also prevents the pvt's needdestroy flag from being set
which triggers the destruction of the dialog within the do_monitor thread().
By using this function we are guaranteed destruction will not occur
until the scheduled time. This allows Asterisk to respond to any possible
retransmits for a dialog after we process the initial BYE request for T1*64 ms.
Other changes: I removed two instances where sip_cancel_destroy is used
right before calling sip_scheddestroy. sip_scheddestroy always calls
sip_cancel_destroy before scheduling the new destruction so it is completely
unnecessary.
Review: https://reviewboard.asterisk.org/r/694/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271262 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After 5 years in mantis and over a year on reviewboard, SRTP support is finally
being comitted. This includes generic CHANNEL dialplan functions that work for
getting the status of whether a call has secure media or signaling as defined
by the underlying channel technology and for setting whether or not a new
channel being bridged to a calling channel should have secure signaling or
media. See doc/tex/secure-calls.tex for examples.
Original patch by mikma, updated for trunk and revised by me.
(closes issue #5413)
Reported by: mikma
Tested by: twilson, notthematrix, hemanshurpatel
Review: https://reviewboard.asterisk.org/r/191/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268894 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk Generic AOC Representation
- Generic AOC encode/decode routines.
(Generic AOC must be encoded to be passed on the wire in the AST_CONTROL_AOC frame)
- AST_CONTROL_AOC frame type to represent generic encoded AOC data
- Manager events for AOC-S, AOC-D, and AOC-E messages
Asterisk App Support
- app_dial AOC-S pass-through support on call setup
- app_queue AOC-S pass-through support on call setup
AOC Unit Tests
- AOC Unit Tests for encode/decode routines
- AOC Unit Test for manager event representation.
SIP AOC Support
- Pass-through of generic AOC-D and AOC-E messages to snom phones via the
snom AOC specification.
- Creation of chan_sip page3 flags for the addition of the new
'snom_aoc_enabled' sip.conf option.
IAX AOC Support
- Natively supports AOC pass-through through the use of the new
AST_CONTROL_AOC frame type
DAHDI AOC Support
- ETSI PRI full AOC Pass-through support
- 'aoc_enable' chan_dahdi.conf option for independently enabling
pass-through of AOC-S, AOC-D, AOC-E.
- 'aoce_delayhangup' option for retrieving AOC-E on disconnect.
- DAHDI A() dial string option for requesting AOC services.
example usage:
;requests AOC-S, AOC-D, and AOC-E on call setup
exten=>1111,1,Dial(DAHDI/g1/1112/A(s,d,e))
Review: https://reviewboard.asterisk.org/r/552/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267096 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch breaks up every part of the sip registry string during
config parsing and removes all parsing from transmit_register().
Thanks to Nick_Lewis for contributing this patch!
(closes issue #14331)
Reported by: Nick_Lewis
Patches:
chan_sip.c-domparse.patch uploaded by Nick Lewis (license 657)
chan_sip.c.patch uploaded by Nick Lewis (license 657)
chan_sip.c.domainparse3.patch uploaded by Nick Lewis (license 657)
chan_sip.c-domparse4.patch uploaded by Nick Lewis (license 657)
chan_sip.c-domparse5.patch uploaded by Nick Lewis (license 657)
nicklewispatch.diff uploaded by dvossel (license 671)
Tested by: Nick_Lewis, dvossel
Review: https://reviewboard.asterisk.org/r/628/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@266090 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:
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
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: https://origsvn.digium.com/svn/asterisk/trunk@261560 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a recognized media type was present, but the media type was not
enabled for the channel, then a warning would be emitted. For instance,
attempting to get CHANNEL(rtpsource,video) on a call with no video would
cause a warning message to appear.
With this change, the warning will only appear if the stream argument
is not recognized as being a media type that can be specified.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@261313 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From the original issue report opened by Nick Lewis:
Many sip headers in many sip methods contain the ABNF structure
name-andor-addr = name-addr / addr-spec
Examples include the to-header, from-header, contact-header, replyto-header
At the moment chan_sip.c makes various different attempts to parse this name-andor-addr structure for each header type and for each sip method with sometimes limited degrees of success.
I recommend that this name-andor-addr structure be parsed by a dedicated function and that it be used irrespective of the specific method or header that contains the name-andor-addr structure
Nick has also included unit tests for verifying these routines as well, so...heck yeah.
(closes issue #16708)
Reported by: Nick_Lewis
Patches:
reqresp_parser-nameandoraddr2.patch uploaded by Nick Lewis (license 657
Review: https://reviewboard.asterisk.org/r/549
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256530 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
This adds rtpsource options analogous to the rtpdest
functions that already exist. In addition, this fixes
potential crashes which could result due to trying to
read values from nonexistent RTP streams.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254551 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
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
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
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
1) It occurred to me that the difference in usage between the error ast_str and
the ast_test_update_status() usage has turned out to be a bit ambiguous in
practice. In a lot of cases, the same message was being sent to both.
In other cases, it was only sent to one or the other. My opinion now is that
in every case, I think it makes sense to do both; we should output it to the
CLI as well as save it off for logging purposes.
This change results in most of the changes in this diff, since it required
changes to all existing unit tests. It also allowed for some simplifications
of unit test API implementation code.
2) Update ast_test_status_update() to include the file, function, and line
number for the code providing the update.
3) There are some formatting tweaks here and there. Hopefully they aren't too
distracting for code review purposes. Reviewboard's diff viewer seems to do a
pretty good job of pointing out when something is a whitespace change.
4) I moved the md5_test and sha1_test into the test_utils module. It seemed
like a better approach since these tests are so tiny.
5) I changed the number of nodes used in heap_test_2 from 1 million to
100 thousand. The only reason for this was to reduce the time it took
for this test to run.
6) Remove an unused function prototype that was at the bottom of utils.h.
7) Simplify test_insert() using the LIST_INSERT_SORTALPHA() macro. The one
minor difference in behavior is that it no longer checks for a test registered
with the same name.
8) Expand the code in test_alloc() to provide specific error messages for each
failure case, to clearly inform developers if they forget to set the name,
summary, description, etc.
9) Tweak the output of the "test show registered" CLI command. I swapped the
name and category to have the category first. It seemed more natural since
that is the sort key.
10) Don't output the status ast_str in the "test show results" CLI command.
This is going to tend to be pretty verbose, so just leave that for the
detailed test logs (test generate results).
Review: https://reviewboard.asterisk.org/r/493/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@245864 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
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
David Vossel
Mark Michelson
Olle Johansson
Terry Wilson
Tilghman Lesher
Matthew Nicholson
Richard Mudgett
Jason Parker
Kevin P. Fleming
Russell Bryant