Age | Commit message (Collapse) | Author |
|
I've been working in this function a bunch lately, and
these huge debug strings are getting annoying.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276392 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
merge mistake from IPv6
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276389 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The purpose of this patch is to eliminate struct ast_callerid since it has
turned into a miscellaneous collection of various party information.
Eliminate struct ast_callerid and replace it with the following struct
organization:
struct ast_party_name {
char *str;
int char_set;
int presentation;
unsigned char valid;
};
struct ast_party_number {
char *str;
int plan;
int presentation;
unsigned char valid;
};
struct ast_party_subaddress {
char *str;
int type;
unsigned char odd_even_indicator;
unsigned char valid;
};
struct ast_party_id {
struct ast_party_name name;
struct ast_party_number number;
struct ast_party_subaddress subaddress;
char *tag;
};
struct ast_party_dialed {
struct {
char *str;
int plan;
} number;
struct ast_party_subaddress subaddress;
int transit_network_select;
};
struct ast_party_caller {
struct ast_party_id id;
char *ani;
int ani2;
};
The new organization adds some new information as well.
* The party name and number now have their own presentation value that can
be manipulated independently. ISDN supplies the presentation value for
the name and number at different times with the possibility that they
could be different.
* The party name and number now have a valid flag. Before this change the
name or number string could be empty if the presentation were restricted.
Most channel drivers assume that the name or number is then simply not
available instead of indicating that the name or number was restricted.
* The party name now has a character set value. SIP and Q.SIG have the
ability to indicate what character set a name string is using so it could
be presented properly.
* The dialed party now has a numbering plan value that could be useful to
have available.
The various channel drivers will need to be updated to support the new
core features as needed. They have simply been converted to supply
current functionality at this time.
The following items of note were either corrected or enhanced:
* The CONNECTEDLINE() and REDIRECTING() dialplan functions were
consolidated into func_callerid.c to share party id handling code.
* CALLERPRES() is now deprecated because the name and number have their
own presentation values.
* Fixed app_alarmreceiver.c write_metadata(). The workstring[] could
contain garbage. It also can only contain the caller id number so using
ast_callerid_parse() on it is silly. There was also a typo in the
CALLERNAME if test.
* Fixed app_rpt.c using ast_callerid_parse() on the channel's caller id
number string. ast_callerid_parse() alters the given buffer which in this
case is the channel's caller id number string. Then using
ast_shrink_phone_number() could alter it even more.
* Fixed caller ID name and number memory leak in chan_usbradio.c.
* Fixed uninitialized char arrays cid_num[] and cid_name[] in
sig_analog.c.
* Protected access to a caller channel with lock in chan_sip.c.
* Clarified intent of code in app_meetme.c sla_ring_station() and
dial_trunk(). Also made save all caller ID data instead of just the name
and number strings.
* Simplified cdr.c set_one_cid(). It hand coded the ast_callerid_merge()
function.
* Corrected some weirdness with app_privacy.c's use of caller
presentation.
Review: https://reviewboard.asterisk.org/r/702/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276347 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
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275816 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue #17600)
Reported by: minaguib
Patches:
ast_unistim_height_v2.patch uploaded by minaguib (license 1078)
Tested by: minaguib
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275466 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
It was essentially an off-by-one error. The easiest way
to fix this was to use the handy-dandy AST_NONSTANDARD_RAW_ARGS
macro to parse the pieces of the registration string out. Tested
and it works wonderfully.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275385 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275312 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
If a Via header contained an IPv6 address, we would not properly parse
the port. We would instead get the information after the first colon in
the address.
(closes issue #17614)
Reported by: oej
Patches:
diff uploaded by sperreault (license 252)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275308 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This should fix all the CDR tests that were not passing. When they would
originate a call, all fields in the INVITE that contained the source port would
have the port set to 0. Most troubling of these was the Contact header. Tests
are passing locally now and should also pass on the bamboo build agents.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275294 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r275241 | pabelanger | 2010-07-09 15:20:00 -0400 (Fri, 09 Jul 2010) | 8 lines
Fix logging message for stale nonce.
(closes issue #17582)
Reported by: kenner
Patches:
chan_sip.c.diff uploaded by kenner (license 1040)
Tested by: lmadsen
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275249 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275227 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
tracking down the source.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275105 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275104 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
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274828 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
|
|
midterm evaluation.
Review: https://reviewboard.asterisk.org/r/757/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274727 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274686 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274639 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r274579 | rmudgett | 2010-07-07 13:12:41 -0500 (Wed, 07 Jul 2010) | 1 line
Close the DAHDI FD on error when processing chan_dahdi toneduration config parameter.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274595 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Review: https://reviewboard.asterisk.org/r/629
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274539 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r274280 | twilson | 2010-07-06 17:08:20 -0500 (Tue, 06 Jul 2010) | 9 lines
Add option to not do a call forward on 482 Loop Detected
Asterisk has always set up a forwarded call when receiving a 482 Loop Detected.
This prevents handling the call failure by just continuing on in the dialplan.
Since this would be a change in behavior, the new option to disable this
behavior is forwardloopdetected which defaults to 'yes'.
Review: https://reviewboard.asterisk.org/r/764/
........
(no option for trunk, just changing the behavior)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274284 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
bitfield.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r273793 | tilghman | 2010-07-02 16:36:39 -0500 (Fri, 02 Jul 2010) | 9 lines
Have the DEADLOCK_AVOIDANCE macro warn when an unlock fails, to help catch potentially large software bugs.
(closes issue #17407)
Reported by: pdf
Patches:
20100527__issue17407.diff.txt uploaded by tilghman (license 14)
Review: https://reviewboard.asterisk.org/r/751/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@273830 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(Also fix the typos in the comments)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@273641 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
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r273060 | tilghman | 2010-06-29 18:15:28 -0500 (Tue, 29 Jun 2010) | 10 lines
Allow the "useragent" value to be restored into memory from the realtime backend.
This value is purely informational. It does not alter configuration at all.
(closes issue #16029)
Reported by: Guggemand
Patches:
realtime-useragent.patch uploaded by Guggemand (license 897)
Tested by: Guggemand
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@273078 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
RFC 2361 section 24.4.1 send a 400 Bad Request if the request
can not be understood due to malformed syntax. Currently we
simply ignore a packet with a missing callid, to, from, or
via header. Instead of ignoring we now send the 400 Bad request.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272981 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
........
r272804 | mmichelson | 2010-06-28 12:31:40 -0500 (Mon, 28 Jun 2010) | 5 lines
Decode URI in contact header of 302 response.
ABE-2352
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272805 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
I am doing work in this function. I noticed a large number of
coding guidline fixes that needed to be made. Rather than have
those changes distract from my functional changes I decided
to separate these into a separate patch.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272652 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
RFC3261 states that Timer A should start at 500ms (T1) by default.
In chan_sip this value initially started at 1000ms and I changed
it to 500ms recently. After doing that I noticed in my packet
captures that it still occasionally retransmitted starting at
1000ms instead of 500ms like I told it to. This occurs because
the scheduler runs in the do_monitor thread. If a new retransmission
is added while the do_monitor thread is sleeping then it may not
detect that retransmission for nearly 1000ms. To fix this I just
poke the do_monitor thread to wake up when a new packet is sent
reliably requiring retransmits. The thread then detects the new
scheduler entry and adjusts its sleep time to account for it.
Review: https://reviewboard.asterisk.org/r/747
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272557 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r272446 | rmudgett | 2010-06-24 16:58:49 -0500 (Thu, 24 Jun 2010) | 10 lines
ss_thread calls pri_grab without lock during overlap dial
Recent changes to chan_dahdi with relation to overlap dialing call
pri_grab without first obtaining a lock.
(closes issue #17414)
Reported by: pdf
Patches:
bug17414.patch uploaded by jpeeler (license 325)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272447 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The external test suite stops Asterisk using the "core stop gracefully" command.
The logs from the tests show that there are a number of problems with Asterisk
trying to cleanly shut down. This patch addresses the following type of error
that comes from chan_iax2:
[Jun 22 16:58:11] ERROR[29884]: lock.c:129 __ast_pthread_mutex_destroy:
chan_iax2.c line 11371 (iax2_process_thread_cleanup):
Error destroying mutex &thread->lock: Device or resource busy
For an example in the context of a build, see:
http://bamboo.asterisk.org/browse/AST-TRUNK-739/log
The primary purpose of this patch is to change the thread pool shutdown
procedure to be more explicit to ensure that the thread exits from a point
where it is not holding a lock. While testing that, I encountered various
crashes due to the order of operations in unload_module() being problematic.
I reordered some things there, as well.
Review: https://reviewboard.asterisk.org/r/736/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272370 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This command lets you request a "/n" local channel
optimize itself out of the way anyway.
Review: https://reviewboard.asterisk.org/r/732/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272218 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272150 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue #17144)
Reported by: nahuelgreco
Patches:
20100513__issue17144__trunk.diff.txt uploaded by tilghman (license 14)
Tested by: tilghman
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272145 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Testing proved that if Asterisk sent a connected line reinvite, and
the endpoint to which the reinvite were being sent sent a reinvite, Asterisk
would not properly respond with a 491 response.
The reason is that on connected line reinvites, we set the dialog's invitestate
to INV_CALLING to prevent Asterisk from sending a rapid flurry of connected line
reinvites. For other reinvites we do not do this. Because of the current invitestate,
when Asterisk received the reinvite, we interpreted this as a spiraled INVITE, and thus
did not behave properly.
The fix for this is to not enter the loop detection or spiral logic in handle_request_invite
if the channel state is currently up. This way, no mid-call reinvites will be misinterpreted,
no matter what the nature of the reinvite may have been.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272090 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This small changes prevents destroy_all_channels() from accessing a lock on an
unused dahdi_pri struct, resolving a ton of ERRORs that get spewed out when
shutting Asterisk down gracefully.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272052 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
RFC 3261 section 9 states that a CANCEL has no effect on a
request to a UAS that has already given a final response. This
patch checks to make sure there is a pending invite before
allowing a CANCEL request to be processed, otherwise it responds
to the CANCEL with a "481 Call/Transaction Does Not Exist".
Review: https://reviewboard.asterisk.org/r/697/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271977 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r271902 | mnicholson | 2010-06-22 12:31:57 -0500 (Tue, 22 Jun 2010) | 8 lines
Decrease the module ref count in sip_hangup when SIP_DEFER_BYE_ON_TRANSFER is set. This is necessary to keep the ref count correct.
(closes issue #16815)
Reported by: rain
Patches:
chan_sip-unref-fix.diff uploaded by rain (license 327) (modified)
Tested by: rain
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271903 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
|
|
(closes issue #17437)
Reported by: klaus3000
Patches:
sip_crash uploaded by dvossel (license 671)
Tested by: klaus3000
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271553 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271300 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
|