| Age | Commit message (Collapse) | Author |
|---|
|
domain.
When Asterisk receives an INVITE from an external domain when allowexternaldomains=no
send a 403 instead of a 404. This is consistent with Asterisk's behavior when receiving
a REGISTER in this situation.
(Closes issue ASTERISK-19601)
Reported by Matthew Jordan
Patches:
ASTERISK-19601-no401.patch uploaded by Mark Michelson (License #5049)
........
Merged revisions 369302 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 369303 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369304 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
now.
........
Merged revisions 369235 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 369236 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369237 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
A sip_pvt may not have relatedpeer set if a call doesn't match up
with a peer. If there is no relatedpeer, there is no direct media
ACL to apply, so just return that it is allowed.
(closes issue ASTERISK-20040)
Reported by: Terry Wilson
........
Merged revisions 369214 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 369215 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369217 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The sendonly/recvonly/sendrecv/inactive media stream attributes were
parsed for video, but nothing was ever done with them. With this code
removed, an UNSUPPORTED message is produced when these attributes are
used in conjunction with a video stream which is the better behavior
since they were never really supported in the first place.
........
Merged revisions 369195 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 369206 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369207 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Asterisk was incorrectly setting the destination of CANCELs
and ACKs for error responses to the URI of the initial INVITE.
This resulted in further requests, such as INVITEs with authentication
credentials, to be routed incorrectly. Instead, when these CANCEL
or ACKs are to be sent, we should simply keep the destination the
same as what it previously was. There is no need to alter it any.
(closes issue ASTERISK-20008)
Reported by Marcus Hunger
Patches:
ASTERISK-20008.patch uploaded by Mark Michelson (license #5049)
........
Merged revisions 369066 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 369067 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369068 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This change replaces the static array of four representable media
streams with an AST_LIST so that chan_sip can keep track of offered
media streams. This allows chan_sip to deal with offers containing
multiple same-type streams and many other situations without rejecting
the SDP offer in its entirety, yet still generating a valid response.
This also covers cases where Asterisk can not comprehend the offer if
it is in the correct format.
Previously, chan_sip would reject SDP offers or entirely ignore
individual stream offers in an effort to be more compatible which
would often result in invalid SDP responses.
Review: https://reviewboard.asterisk.org/r/1988/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369028 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
On incoming calls, we were setting the cid_tag on the dialog only if there was
no remote party information (Remote-Party-ID or P-Asserted-Identity) present.
The Caller ID tag is an invented parameter, though, and should be set no matter
the circumstance.
(closes issue ASTERISK-19859)
Reported by Thomas Arimont
(closes issue AST-884)
Reported by Trey Blancher
........
Merged revisions 368807 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 368808 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
In r367163, "send to voicemail" functionality was added to the SIP channel
driver. This required updating the party redirecting information for the
channel based on the headers provided in the REFER request. When the
redirecting party information is updated on the channel, a call to
ast_indicate_data occurs. Because handle_request_refer still had the sip_pvt
locked, a deadlock could occur between the pbx_thread and the do_monitor thread
servicing the REFER request.
This patch preserves the proper locking order between the channel and the
sip_pvt by ensuring that the sip_pvt is unlocked prior to updating the party
redirecting information on the channel.
(closes issue AST-903)
Reported by: Matt Jordan
patches:
jira_ast_903_trunk.patch by rmudgett (license 5621)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368793 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
ANI2 information is now parsed out of SIP From headers when present in
the oli, isup-oli, and ss7-oli parameters and is available via the
CALLERID(ani2) dialplan function.
(closes issue ASTERISK-19912)
Patch-by: Rob Gagnon
Review: https://reviewboard.asterisk.org/r/1947/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368784 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Calling ast_set_hangupsource() with the channel lock held can result in a
deadlock because the function also locks the bridged channel.
(issue ASTERISK-19537)
(closes issue AST-891)
Reported by: Guenther Kelleter
Tested by: Guenther Kelleter
(closes issue ASTERISK-19801)
Reported by: Alec Davis
........
Merged revisions 368759 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 368760 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368772 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Most of these were just saving returned values without using them and
in some cases the variable being saved to could be removed as well.
(issue ASTERISK-19672)
........
Merged revisions 368738 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 368739 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368751 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
If a dialog-starting INVITE contains a to-tag, then Asterisk
will respond with a 481. In this case, the resulting incoming
ACK would not be matched, so Asterisk would continue retransmitting
the 481 until the transaction times out.
There were two issues. Asterisk, upon creating a sip_pvt would generate
a local tag. However, when the time came to transmit the 481, since there
was a to-tag in the INVITE, Asterisk would place this original to-tag
in the 481 response. When the ACK came in, Asterisk would attempt to
match the to-tag in the ACK to the generated local tag. Unfortunately,
Asterisk never actually transmitted a response with the generated local
tag, so the to-tag in the ACK would not match.
The other problem was that when the 481 was sent, nothing was set
on the sip_pvt to indicate what CSeq is expected in the ACK.
To fix the first problem, we zero out the to-tag seen in the incoming
INVITE. This way, Asterisk, when time to send a response, will send
its generated local tag instead.
To fix the second problem, we set the sip_pvt's pendinginvite to the
CSeq of the INVITE when we send a 481.
(closes issue ASTERISK-19892)
Reported by Mark Michelson
........
Merged revisions 368625 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 368629 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368637 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When changing between different modes of hold, the flags were not being
cleared out properly causing a failure to change hold states.
(closes issue ASTERISK-19919)
Patch-by: Morten Tryfoss
Reported-by: Morten Tryfoss
........
Merged revisions 368586 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 368587 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368588 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This was essentially duplicated functionality where normal channels used
AST_CAUSE_ANSWERED_ELSEWHERE while local channels and queues used
AST_FLAG_ANSWERED_ELSEWHERE. This removes the flag and converts that usage
into AST_CAUSE_ANSWERED_ELSEWHER usage.
Review: https://reviewboard.asterisk.org/r/1944
(closes issue ASTERISK-19865)
Patch-by: Birger Harzenetter
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368519 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Revision 351130 broke corect HANGUPCAUSE setting
for the 404 case in chan_sip. Other cases were also
potentially broken. This patch fixes the relaying
of causes to be what they used to be.
(closes issue ASTERISK-19914)
Reported by Pavel Troller
Tested by Walter Doekes (via a reviewboard test to be committed later)
Patches:
chan_sip.diff uploaded by Pavel Troller (license #6302)
........
Merged revisions 368498 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 368499 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368500 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Presence support has been added. This is accomplished by
allowing for presence hints in addition to device state
hints. A dialplan function called PRESENCE_STATE has been
added to allow for setting and reading presence. Presence
can be transmitted to Digium phones using custom XML
elements in a PIDF presence document.
Voicemail has new APIs that allow for moving, removing,
forwarding, and playing messages. Messages have had a new
unique message ID added to them so that the APIs will work
reliably. The state of a voicemail mailbox can be obtained
using an API that allows one to get a snapshot of the mailbox.
A voicemail Dialplan App called VoiceMailPlayMsg has been
added to be able to play back a specific message.
Configuration hooks have been added. Configuration hooks
allow for a piece of code to be executed when a specific
configuration file is loaded by a specific module. This is
useful for modules that are dependent on the configuration
of other modules.
chan_sip now has a public method that allows for a custom
SIP INFO request to be sent mid-dialog. Digium phones use
this in order to display progress bars when files are played.
Messaging support has been expanded a bit. The main
visible difference is the addition of an AMI action
MessageSend.
Finally, a ParkingLots manager action has been added in order
to get a list of parking lots.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368435 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Asterisk should not accept SDP offers that contain unknown RTP profiles (for
audio/video streams) or unknown top-level media types. When it does, it answers
with an SDP that does not match the offer properly, and this will nearly
always result in a broken call. This patch causes such offers to be rejected.
Review: https://reviewboard.asterisk.org/r/1811/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368269 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
* 'Unsupported media type' is only reported when that is in fact the case,
not when a supported media type is included in an 'm' line that has an
invalid format.
* All warning messages related to parsing 'm' lines now include the 'm' line contents.
* (minor bugfix) newline added to port-number-zero warning messages.
* Warning messages improved to use RFC-specified terminology for various items.
* Warnings for offers that include more than one port for a single media type now
include the media type.
Review: https://reviewboard.asterisk.org/r/1811/
........
Merged revisions 368218 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 368267 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368268 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When Asterisk servers are set up back-to-back, and
direct media is to be used betweeen endpoints, it is
fairly common for the two Asterisk servers to send
direct media reinvites to each other simultaneously.
This results in 491s and ACKs being exchanged between
the servers. While the media eventually gets set up
properly, the problem is that there can be a noticeable
delay for the streams to stabilize.
This patch adds a new directmedia option called "outgoing".
With this set, an immediate direct media reinvite will only
be sent if the call direction is outgoing. For incoming
dialogs, an immediate direct media reinvite will not be sent,
but further "reactionary" direct media reinvites may be sent.
Review: https://reviewboard.asterisk.org/r/1954
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368143 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
* Fixes findings: 0-2,5,7-15,24-26,28-31
(issue ASTERISK-19648)
Reported by: Matt Jordan
........
Merged revisions 368039 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 368042 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368052 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The pvt_sip allowtransfer was not being set to that of the peer's setting.
Therefore, the global allowtransfer setting was being used instead which would
lead to calls not being transfered if the global setting was set to 'no' despite
the setting on the peer being 'yes' and vice versa, calls would be allowed to
transfer even if the peer's setting was 'no' but the global setting was 'yes'.
(Closes issue ASTERISK-19856)
Reported by: Jacek
Tested by: Michael L. Young, Jacek
Patches:
issue-asterisk-19856-branch10-v3.diff uploaded by
Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/1923/
........
Merged revisions 367730 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 367731 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367732 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When remotely bridging calls with directmedia, Asterisk would check
the address of the peers/users holding directmedia ACLs (set via
directmediapermit/directmediadeny) instead of the bridged peer. This
is similar to r366547, but trunk specific and involves changes to
the rtpengine instead of just chan_sip.
(closes issue AST-876)
review: https://reviewboard.asterisk.org/r/1924/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367640 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Previously, MWI logic utilized a counter called 'lastmsgssent' to know whether
or not MWI NOTIFY requests had been sent to a specific peer. When MWI
notifications were changed to use the internal event framework, this value was
no longer needed for its original purpose. Hence, it was no longer updated
with the new/old message counts for a peer. The value was previously removed
for Asterisk 10; however, since it was still present in Asterisk 1.8 and still
useful for reporting purposes, it was decided to re-add the value.
This patch re-adds the 'LastMsgsSent' field in the response to an AMI/CLI 'sip
show peer [peer]' command, and makes it so that the value of lastmsgssent is
updated appropriately. The value should now display the new/old message counts
for a particular peer.
(closes issue ASTERISK-17866)
Reported by: Steve Davies
patches by:
ast-17866-rb1272.patch (License #5041 by irroot)
Modified slightly for this commit
Review: https://reviewboard.asterisk.org/r/1939
........
Merged revisions 367362 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 367369 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367376 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
ASTOBJ_UNREF sets the variable to NULL after unreffing it, so the variable
should definitely not be used after that. To solve this in the two cases
that affect subscribing for MWI notifications, we instead save the ref
locally, and unref them in the error conditions.
(closes issue ASTERISK-19827)
Reported by: B. R
Review: https://reviewboard.asterisk.org/r/1940/
........
Merged revisions 367266 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 367267 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367274 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This should have been committed to my team trunk-digiumphones branch
instead of trunk.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367183 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This change accommodates two methods by which calls can be directed to
a user's voicemail.
* Incoming calls can be redirected to any user's voicemail.
* Established calls can be blind transferred to any user's voicemail.
Digium phones indicate the desire to direct a call to voicemail by using
a Diversion header with a reason parameter of "send_to_vm".
This patch adds the "send_to_vm" reason as a valid redirecting reason. In
addition, chan_sip.c has been modified to update redirecting information
on the transferred channel by reading a Diversion header on a REFER request.
(closes issue AST-871)
Reported by Malcolm Davenport
Review: https://reviewboard.asterisk.org/r/1925
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367163 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
SSL_CTX structures were allocated but never freed. This was a bigger
issue for clients than servers since new SSL_CTX structures could be
allocated for each connection. Servers, on the other hand, typically
set up a single SSL_CTX for their lifetime.
This is solved in two ways:
1. In __ssl_setup(), if a tcptls_cfg has an ssl_ctx on it, it is
freed so that a new one can take its place.
2. A companion to ast_ssl_setup() called ast_ssl_teardown() has
been added so that servers can properly free their SSL_CTXs.
(issue ASTERISK-19278)
........
Merged revisions 367002 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 367003 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367010 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch adds to what was fixed in r366880. Specifically, it addresses the
following:
* chan_sip: dispose of an allocated frame in off nominal code paths in
sip_rtp_read
* func_odbc: when disposing of an allocated resultset, ensure that any rows
that were appended to that resultset are also disposed of
* cli: free the created return string buffer in another off nominal code
path
* chan_dahdi: free a frame that was allocated by the dsp layer if we choose
not to process that frame
(issue ASTERISK-19665)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1922/
........
Merged revisions 366944 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 366948 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366955 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch addresses a number of memory leaks in a variety of modules that were
found by a static analysis tool. A brief summary of the changes:
* app_minivm: free ast_str objects on off nominal paths
* app_page: free the ast_dial object if the requested channel technology
cannot be appended to the dialing structure
* app_queue: if a penalty rule failed to match any existing rule list
names, the created rule would not be inserted and its memory
would be leaked
* app_read: dispose of the created silence detector in the presence of
off nominal circumstances
* app_voicemail: dispose of an allocated unique ID field for MWI event
un-subscribe requests in off nominal paths; dispose of
configuration objects when using the secret.conf option
* chan_dahdi: dispose of the allocated frame produced by ast_dsp_process
* chan_iax2: properly unref peer in CLI command "iax2 unregister"
* chan_sip: dispose of the allocated frame produced by sip_rtp_read's
call of ast_dsp_process; free memory in parse unit tests
* func_dialgroup: properly deref ao2 object grhead in nominal path of
dialgroup_read
* func_odbc: free resultset in off nominal paths of odbc_read
* cli: free match_list in off nominal paths of CLI match completion
* config: free comment_buffer/list_buffer when configuration file load
is unchanged; free the same buffers any time they were
created and config files were processed
* data: free XML nodes in various places
* enum: free context buffer in off nominal paths
* features: free ast_call_feature in off nominal paths of applicationmap
config processing
* netsock2: users of ast_sockaddr_resolve pass in an ast_sockaddr struct
that is allocated by the method. Failures in
ast_sockaddr_resolve could result in the users of the method
not knowing whether or not the buffer was allocated. The
method will now not allocate the ast_sockaddr struct if it
will return failure.
* pbx: cleanup hash table traversals in off nominal paths; free
ignore pattern buffer if it already exists for the specified
context
* xmldoc: cleanup various nodes when we no longer need them
* main/editline: various cleanup of pointers not being freed before being
assigned to other memory, cleanup along off nominal paths
* menuselect/mxml: cleanup of value buffer for an attribute when that attribute
did not specify a value
* res_calendar*: responses are allocated via the various *_request method
returns and should not be allocated in the various
write_event methods; ensure attendee buffer is freed if no
data exists in the parsed node; ensure that calendar objects
are de-ref'd appropriately
* res_jabber: free buffer in off nominal path
* res_musiconhold: close the DIR* object in off nominal paths
* res_rtp_asterisk: if we run out of ports, close the rtp socket object and free
the rtp object
* res_srtp: if we fail to create the session in libsrtp, destroy the
temporary ast_srtp object
(issue ASTERISK-19665)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1922
........
Merged revisions 366880 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 366881 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366917 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch improves the handling of call id logging significantly with regard
to transfers and adding APIs to better handle specific aspects of logging.
Also, changes have been made to chan_sip in order to better handle the creation
of callids and to enable the monitor thread to bind itself to a particular
call id when a dialog is determined to be related to a callid. It then unbinds
itself before returning to normal monitoring.
review: https://reviewboard.asterisk.org/r/1886/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366842 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
reason parameter.
The use here was assuming that the pointer would be updated, but the updated string
is actually returned by ast_strip_quoted() instead.
........
Merged revisions 366597 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 366598 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366599 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This is the starting point for the Asterisk 11: Who Hung Up work and provides
a framework which will allow channel drivers to report the types of hangup
cause information available in SIP_CAUSE without incurring the overhead of the
MASTER_CHANNEL dialplan function. The initial implementation only includes
cause generation for chan_sip and does not include cause code translation
utilities.
This change deprecates SIP_CAUSE and replaces its method of reporting cause
codes with the new framework. This change also deprecates the 'storesipcause'
option in sip.conf.
Review: https://reviewboard.asterisk.org/r/1822/
(Closes issue SWP-4221)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366408 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
To make a long story short, reinvite glares were broken
because Asterisk would invert the To and From headers
when ACKing a 491 response.
The reason was because the initreq of the dialog was being
changed to the incoming glared reinvite instead of being
set to the outgoing glared reinvite. This change has three
parts
* In handle_incoming, we never will reject an ACK because it
has a to-tag present, even if we think the request may be out
of dialog.
* In handle_request_invite, we do not change the initreq when
receiving a reinvite to which we will respond with a 491.
* In handle_request_invite, several superflous settings up
pendinginvite have been removed since this is dones automatically
by transmit_response_reliable
Review: https://reviewboard.asterisk.org/r/1911
........
Merged revisions 366389 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 366390 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366401 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This resolves core findings from ASTERISK-19650 numbers 0-2, 6, 7, 9-11, 14-20,
22-24, 28, 30-32, 34-36, 42-56, 82-84, 87, 89-90, 93-102, 104, 105, 109-111,
and 115. Finding numbers 26, 33, and 29 were already resolved. Those skipped
were either extended/deprecated or in areas of code that shouldn't be
disturbed.
(Closes issue ASTERISK-19650)
........
Merged revisions 366167 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 366168 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366169 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(issue ASTERISK-19658)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1905/
........
Merged revisions 366094 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 366106 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366126 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(issue AST-998)
Reported by: Thomas Arimont
Tested by: Thomas Arimont
........
Merged revisions 366052 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 366053 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366062 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
chan_sip was coded under the assumption that a SIP dialog with an owner channel
will always be destroyed after the owner channel has been hung up.
However, there are situations where the SIP dialog can time out and auto destruct
before the corresponding channel has hung up. A typical example of this would be
if the 'h' extension in the dialplan takes a long time to complete. In such cases,
__sip_autodestruct() would complain about the dialog being auto destroyed with
an owner channel still in place. The problem is that even once the owner channel
was hung up, the sip_pvt would still be linked in its ao2_container because nothing
would ever unlink it.
The fix for this is that if __sip_autodestruct() is called for a sip_pvt that still
has an owner channel in place, the destruction is rescheduled for 10 seconds in the
future. This will continue until the owner channel is finally hung up.
(closes issue ASTERISK-19425)
reported by David Cunningham
Patches:
ASTERISK-19425.patch uploaded by Mark Michelson (License #5049)
(closes issue ASTERISK-19455)
reported by Dean Vesvuio
Tested by Dean Vesvuio
........
Merged revisions 365896 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 365898 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@365913 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This uses the calling channel's caller ID and connected line information
to populate the remote and local identities in the dialog-info NOTIFY when
an extension is ringing.
There is a bit of an oddity here, and that is that we seed the remote target
with the To header of the outbound call rather than the from header. This
is because it was reported that seeding with the from header caused hints
to be broken with certain SNOM devices. A comment has been added to the code
to explain this.
(closes issue ASTERISK-16735)
reported by Maciej Krajewski
patches:
local_remote_hint2.diff uploaded by Mark Michelson (license #5049)
16735_tweak1.diff uploaded by Mark Michelson (license #5049)
Tested by Niccolo Belli
........
Merged revisions 365574 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 365575 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@365576 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Most of the changes here are trivial NULL checks. There are a couple
optimizations to remove the need to check for NULL and outboundproxy parsing
in chan_sip.c was rewritten to avoid use of strtok. Additionally, a bug was
found and fixed with the parsing of outboundproxy when "outboundproxy=," was
set.
(Closes issue ASTERISK-19654)
........
Merged revisions 365398 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 365399 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@365400 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This is useful in cases where chan_sip may be listening on multiple addresses.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@365011 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The reason I'm removing this is that Coverity reported a STRAY_SEMICOLON
issue here. Since the function has been unused for so long, I just elected
to remove it altogether.
(closes issue ASTERISK-19660)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364915 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Revision 360862 was intended to improve identities sent in dialog-info
NOTIFY requests. Some users reported that hint became broken once this
was done. It's not clear exactly what part of the patch has caused this
regression, but broken hints are bad.
For now, this revision is being reverted so that the next releases of
Asterisk do not have bad behavior in them. The original reported issue
will have to be fixed differently in the next version of Asterisk.
(issue ASTERISK-16735)
........
Merged revisions 364706 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 364707 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364708 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
If enabled using the keepalive option in sip.conf a small packet will be sent
at a regular interval to keep the NAT mapping open. This is lightweight as the
remote side does not need to parse and handle a SIP message.
(closes issue AST-783)
Review: https://reviewboard.asterisk.org/r/1756/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364500 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue ASTERISK-18321)
Reported by Dan Lukes
Patches:
ASTERISK-18321.patch by Mark Michelson (license #5049)
........
Merged revisions 364341 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 364342 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364343 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Unref the SIP pvt stored in the refer structure as soon as it is no longer
needed so that the pvt and associated file descriptors can be freed sooner.
This change makes a reference decrement unnecessary in code that handles SIP
BYE/Also transfers which should not touch the reference anyway.
(Closes issue ASTERISK-19579)
Reported by: Maciej Krajewski
Tested by: Maciej Krajewski
........
Merged revisions 364258 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 364259 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
As a continuation of the patch in r356604, which allowed for the
reloading of SRTP keys in re-INVITE transfer scenarios, this patch
addresses the more common case where a new key is requested within
the context of a current SIP dialog. This can occur, for example, when
certain phones request a SIP hold.
Previously, once a dialog was associated with an SRTP object, any
subsequent attempt to process crypto keys in any SDP offer - either
the current one or a new offer in a new SIP request - were ignored. This
patch changes this behavior to only ignore subsequent crypto keys within
the current SDP offer, but allows future SDP offers to change the keys.
(issue ASTERISK-19253)
Reported by: Thomas Arimont
Tested by: Thomas Arimont
Review: https://reviewboard.asteriskorg/r/1885/
........
Merged revisions 364203 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 364204 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364205 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The reference held for SIP blind transfers using the Replaces header in an
INVITE was never freed on success and also failed to be freed in some error
conditions. This caused a file descriptor leak since the RTP structures in use
at the time of the transfer were never freed. This reference leak and another
relating to subscriptions in the same code path have now been corrected.
(closes issue ASTERISK-19579)
........
Merged revisions 363986 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 363987 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@363988 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The peer maxforwards is checked for both '< 1' and '> 255',
but the default 'maxforwards' in the [general] section is only checked for '< 1'
alecdavis (license 585)
Reported by: alecdavis
Tested by: alecdavis
Review: https://reviewboard.asterisk.org/r/1888/
........
Merged revisions 363934 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 363935 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@363936 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
If Asterisk receives a SIP UPDATE request after a call has been terminated and
the channel has been destroyed but before the SIP dialog has been destroyed, a
condition exists where a connected line update would be attempted on a
non-existing channel. This would cause Asterisk to crash. The patch resolves
this by first ensuring that the SIP dialog has an owning channel before
attempting a connected line update. If an UPDATE request is received and no
channel is associated with the dialog, a 481 response is sent.
(closes issue ASTERISK-19770)
Reported by: Thomas Arimont
Tested by: Matt Jordan
Patches:
ASTERISK-19278-2012-04-16.diff uploaded by Matt Jordan (license 6283)
........
Merged revisions 363106 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 363107 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@363108 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Patch by: junky
Review: https://reviewboard.asterisk.org/r/1743/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362307 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
