Related to changes from 276571, I was accidentally testing with a port set in
my configuration causing me to miss this. Also moved the TCP handling as well
to occur before build_peer is called.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276788 65c4cc65-6c06-0410-ace0-fbb531ad65f3
MWI updates were not being sent if no messages were found in the event cache.
This was corrected since a phone may need to clear its MWI status configured
previously from another mailbox.
Upon module or sip reload, MWI updates could not be sent due to the sipsock
socket not being set early enough in reload_config. The code handling the
descriptor assignment and such has simply been moved before the call to
build_peer.
Issuing a sip reload cleared the IP address of the peer, but skipped checking
the database for registration information. The database is now checked both
for sip reload and actually reloading the module.
If a transmission occurs before the do_monitor thread has started, do not
attempt to send a signal to it.
(closes issue #17398)
Reported by: ip-rob
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276571 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_sockaddr_stringiy_fmt (which is call by all ast_sockaddr_stringify* functions)
uses thread-local storage for storing the string that it creates. In cases where
ast_sockaddr_stringify_fmt was being called twice within the same statement, the
result of one call would be overwritten by the result of the other call. This
usually was happening in printf-like statements and was resulting in the same
stringified addressed being printed twice instead of two separate addresses.
I have fixed this by using ast_strdupa on the result of stringify functions if
they are used twice within the same statement. As far as I could tell, there were
no instances where a pointer to the result of such a call were saved anywhere, so
this is the only situation I could see where this error could occur.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276570 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Unlike most responses, the 200 Ok to a pending INVITE Request is
acknowledged by an ACK Request. If the ACK Request for this Response is not received
the previous behavior was to immediately destroy the dialog and hangup
the channel. Now in an effort to be more RFC compliant, instead of immediately
destroying the dialog during this special case, termination is done with a BYE Request
as the dialog is technically confirmed when the 200 Ok is sent even if the ACK is
never received. The behavior of immediately hanging up the channel remains.
This only affects how dialog termination proceeds for this one special case.
RFC 3261 section 13.3.1.4
"If the server retransmits the 2xx response for 64*T1 seconds without receiving
an ACK, the dialog is confirmed, but the session SHOULD be terminated. This is
accomplished with a BYE, as described in Section 15."
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276439 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Change the documented pgsql schema to use "timestamp" instead of "time",
as the latter is only a time without a date.
Added some missing columns for cel's pgsql schema, and corrected spelling
on some others. Updated cel's uniqueid size to be the same as the cdr.
Added id column to cel's pgsql schema and updated code to allow unknown
columns to get their default value instead of forcing 0 or empty string.
Added microseconds to the timestamp cel logs to pgsql.
Review: https://reviewboard.asterisk.org/r/734
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276349 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
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r275773 | jpeeler | 2010-07-12 15:34:51 -0500 (Mon, 12 Jul 2010) | 12 lines
Make user removals and traversals thread safe in meetme.
Race conditions present in meetme involving the user list where a lack of
locking has the potential for a user to be removed during a traversal or as in
the case of the reporter after checking if the list is empty could cause a
crash. Fixing this was done by convering the userlist to an ao2 container.
(closes issue #17390)
Reported by: Vince
Review: https://reviewboard.asterisk.org/r/746/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276074 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
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r275994 | russell | 2010-07-13 11:51:18 -0500 (Tue, 13 Jul 2010) | 14 lines
Access peer->cdr directly instead of through a saved off reference.
At this point in the code, it is possible that peer_cdr may be invalid.
Specifically, in the blind transfer code, CDRs are swapped between channels.
So, peer_cdr is no longer == peer->cdr.
The scenario that exposed a crash in this code was a blind transfer that hit
the system call limit, causing the transferee channel to get destroyed after
the transfer attempt failed. Even if it succeeds and this code doesn't crash,
this code was still trying to reset a CDR on a channel that was now owned by
a different thread, which is a BadThing(tm).
(ABE-2417)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275995 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r275665 | jpeeler | 2010-07-12 11:58:39 -0500 (Mon, 12 Jul 2010) | 11 lines
Change ast_write to not stop generator when called from ast_prod.
For SIP channels configured with the progressinband option on, the ringback was
being immediately stopped. This problem was due to ast_prod being moved for a
deadlock fix in 259858. Prodding the channel after setting up the generator
triggered the check in ast_write to stop the generator. The fix here should
write the frame the same as was done before the call to ast_prod was moved.
(closes issue #17372)
Reported by: tech_admin
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275682 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change adds an ERROR message to let you know when a failure exists to
get the columns from the pgsql database, which typically means that the
table does not exist.
(closes issue #17478)
Reported by: kobaz
Patches:
cdr_pgsql.patch uploaded by kobaz (license 834)
Tested by: kobaz, russell, lmadsen
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275626 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The bridge handling code did not properly consider feature groups when setting
parameters that would affect whether or not a native bridge would be attempted.
If DYNAMIC_FEATURES only include a feature group, a native bridge would occur
that may prevent features from working.
Fix a bug in verbose output that would show the key mapping as empty if it was
using the default mapping and not a custom mapping in the feature group.
Add feature groups to the output of "features show".
Adjust the feature execution logic to match that of the logic when executing
a feature that was not configured through a feature group.
Update features.conf.sample to show that an '=' is still required if using
the default key mapping from [applicationmap].
Finally, clean up a little bit of formatting to better coform to coding
guidelines while in the area.
(closes issue #17589)
Reported by: lmadsen
Patches:
issue_17589.rev4.txt uploaded by russell (license 2)
Tested by: russell, lmadsen
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275424 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
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
Jeff Peeler
Tilghman Lesher
Russell Bryant
Mark Michelson
Richard Mudgett
Kevin P. Fleming
David Vossel
Tim Ringenbach
Leif Madsen
Terry Wilson
TransNexus OSP Development
Eliel C. Sardanons
Paul Belanger