3263 Commits (16a61aecde0ba2a4e0926d2bd999343938f85ed7)

Author	SHA1	Message	Date
Terry Wilson	16a61aecde	AST-2012-010: Clean up after a reinvite that never gets a final response ... The basic problem is that if a re-INVITE is sent by Asterisk and it receives a provisional response, but no final response, then the dialog is never torn down. In addition to leaking memory, this also leaks file descriptors and will eventually lead to Asterisk no longer being able to process calls. This patch just keeps track of whether there is an outstanding re-INVITE, and if there is goes ahead and cleans up everything as though there was no outstanding reinvite. Review: https://reviewboard.asterisk.org/r/2009/ (closes issue ASTERISK-19992) Reported by: Steve Davies Tested by: Steve Davies, Terry Wilson git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369436 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Mark Michelson	9b9a84740b	Re-fix how local tag is generated when sending a 481 to an INVITE. ... Match our local tag to whatever to-tag was sent in the initial INVITE. Because the size of the to-tag may not fit in the buffer in the sip_pvt, it has been changed to a string field. (closes issue ASTERISK-19892) reported by Walter Doekes Review: https://reviewboard.asterisk.org/r/1977 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369352 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Mark Michelson	37a606f526	Be more consistent with the return code for requests received from invalid 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) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369302 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	3fd1ede7fc	Change incorrect chan_sip zombie hangup debug message. They are all zombies now. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369235 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Terry Wilson	4151dff715	Don't crash on a guest directmedia call ... 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 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369214 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	c842a8c145	Don't parse media stream state for SIP video streams ... 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. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369195 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Mark Michelson	5e5564b041	Fix request routing issue when outboundproxy is used. ... 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) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369066 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Mark Michelson	5919aa6cf4	Set the Caller ID "tag" on peers even if remote party information is present. ... 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 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@368807 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	3863d34cdf	Fix deadlock potential with ast_set_hangupsource() calls. ... 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 ASTERISK-19801) Reported by: Alec Davis (closes issue AST-891) Reported by: Guenther Kelleter Tested by: Guenther Kelleter git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@368759 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	0353a57671	Fix coverity UNUSED_VALUE findings in core support level files ... 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) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@368738 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Mark Michelson	e52f2967de	Fix a specific scenario where ACKs are not matched. ... 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 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@368625 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	b563128877	Ensure overlapping hold flags do not conflict ... 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 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@368586 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Mark Michelson	503fc9458a	Relay proper SIP responses on calling side. ... 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) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@368498 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kevin P. Fleming	871cef109a	Improve SDP parsing warning messages ... * '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/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@368218 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	bd85d458a2	Coverity Report: Fix issues for error type REVERSE_INULL (core modules) ... * Fixes findings: 0-2,5,7-15,24-26,28-31 (issue ASTERISK-19648) Reported by: Matt Jordan git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@368039 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Michael L. Young	20b362fa4b	Fix pvt_sip for inbound call to use peer's allowtransfer setting ... 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/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@367730 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	f26d22b563	Update a peer's LastMsgsSent when the peer is notified of waiting messages ... 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. However, the value was still presented when, either by AMI or CLI, a 'sip show peer [peer]' command was executed. The output of the command would always display the erroneous value of 32767/65535 for 'LastMsgsSent'. This patch 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 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@367362 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Terry Wilson	c191395381	Resolve crash in subscribing for MWI notifications ... 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/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@367266 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Mark Michelson	eef4c09787	Fix memory leak of SSL_CTX structures in TLS core. ... 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) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@367002 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	67268d9198	Fix more memory leaks ... 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 (issue ASTERISK-19665) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/1922/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@366944 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	3edf245601	Fix a variety of memory leaks ... 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 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@366880 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Jonathan Rose	a7733c579b	chan_sip: Fix missed locking of opposing pvt for directmedia acl from r366547 ... It also required deadlock avoidance since two sip_pvts structs needed to be locked simultaneously. Trunk handles it differently, so this is a 1.8 and 10 patch only. (issue AST-876) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@366791 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Mark Michelson	5e7f34fa05	Correct misuse of ast_strip_quoted() when getting a Diversion header's 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. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@366597 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Jonathan Rose	923a66d764	chan_sip: Check the right channel's host address for directmediapermit/deny ... Prior to this patch, when checking the addresses for directmediapermit and directmediadeny, Asterisk would check the host address of the channel permit/deny was specified, which differs from the expectations of both our users and the development team. Instead, directmediapermit/deny now checks against the address of the channel that the peer with the ACL is connected to. (issue AST-876) Review: https://reviewboard.asterisk.org/r/1899/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@366547 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Mark Michelson	fd520e0d19	Fix broken reinvite glare scenario. ... 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 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@366389 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	a94fcae21b	Resolve FORWARD_NULL static analysis warnings ... 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) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@366167 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Jonathan Rose	ae528efea3	Coverity Report: Fix issues for error type CHECKED_RETURN for core ... (issue ASTERISK-19658) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/1905/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@366094 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Mark Michelson	965dd3a7d8	Close the proper tcptls_session when session creation fails. ... (issue AST-998) Reported by: Thomas Arimont Tested by: Thomas Arimont git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@366052 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Mark Michelson	3a9a0b9cea	Prevent sip_pvt refleak when an ast_channel outlasts its corresponding sip_pvt. ... 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 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@365896 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Mark Michelson	2cb787371c	Send more accurate identification information in dialog-info SIP NOTIFYs. ... 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 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@365574 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	83d3444284	Fix many issues from the NULL_RETURNS Coverity report ... 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) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@365398 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Mark Michelson	dba70c1340	Revert improved identities sent in dialog-info NOTIFY requests in r360862 ... 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) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@364706 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Mark Michelson	139a7459cd	Don't attempt to make use of the dynamic_exclude_static ACL if DNS lookup fails. ... (closes issue ASTERISK-18321) Reported by Dan Lukes Patches: ASTERISK-18321.patch by Mark Michelson (license #5049) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@364341 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	0536634ff1	Allow SIP pvts involved in Replaces transfers to fall out of reference sooner ... 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 Karjewski git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@364258 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	3ef885b576	Allow for reloading SRTP crypto keys within the same SIP dialog ... 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/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@364203 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	c4ed0550e8	Fix reference leaks involving SIP Replaces transfers ... 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) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@363986 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Alec L Davis	2ecce90e93	chan_sip: [general] maxforwards, not checked for a value greater than 255 ... 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/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@363934 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	88f80c1d54	AST-2012-006: Fix crash in UPDATE handling when no channel owner exists ... 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) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@363106 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Michael L. Young	d84e70a95c	Turn off warning message when bind address is set to any. ... When a bind address is set to an ANY address (udpbindport=::), a warning message is displayed stating that "Address remapping activated in sip.conf but we're using IPv6, which doesn't need it. Please remove 'localnet' and/or 'externaddr' settings." But if one is running dual stack, we shouldn't be told to turn those settings off. This patch checks if the bind address is an ANY address or not. The warning message will now only be displayed if the bind address is NOT an ANY address and IPv6 is being used. Also, updated the copyright year. (closes issue ASTERISK-19456) Reported by: Michael L. Young Tested by: Michael L. Young Patches: chan_sip_ipv6_message.diff uploaded by Michael L. Young (license 5026) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@362253 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	4148e51555	Add missing newlines to CLI logging ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@361471 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	5c318b19c2	Fix a typo in the warning messages for an ignored media stream ... Added a '\n' to the warning messages when we ignore a media stream due to the port number being '0'. (closes issue ASTERISK-19646) Reported by: Badalian Vyacheslav git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@361332 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Jonathan Rose	ed76cdda72	Replace GNU old-style field designator extensions to fix clang warnings ... (issue ASTERISK-19540) Reported by: Makoto Dei Patches: clang-gnu-designator.patch uploaded by Makoto Dei (license 5027) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@361142 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	063aa93c46	Stop sending out RTCP if RTP is inactive ... This change prevents Asterisk from sending RTCP receiver reports during a remote bridge since it is no longer receiving media and should not be reporting anything. (related to ASTERISK-19366) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@360987 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Mark Michelson	58565827e6	Improve accuracy of identifying information sent in dialog-info SIP NOTIFY requests. ... This change makes use of connected party information in addition to caller ID in order to populate local and remote XML elements in the dialog-info NOTIFYs. (closes issue ASTERISK-16735) Reported by: Maciej Krajewski Tested by: Maciej Krajewski Patches: local_remote_hint2.diff uploaded by Mark Michelson (license 5049) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@360862 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Mark Michelson	390e8c1f73	Make a debug message regarding subscription changes more accurate. ... I was getting confused during some testing why Asterisk was saying that a subscription was being added when it was clearly being removed. This fixes that confusion. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@360625 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	f9246f83c9	Add missing initialization of update_redirecting in chan_sip.c ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@360262 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	cfdc12387b	Ensure Asterisk sends a BYE when pending on the final response to a re-INVITE ... When Asterisk detects a hangup and cannot send a BYE due to a pending INVITE, it sets the pendingbye flag and waits for the final response to that INVITE. When the response is received, it transmits the BYE. If, however, that INVITE request is a pending re-INVITE, it needs to first send a CANCEL request to terminate the pending re-INVITE. In that circumstance, Asterisk was, in some scenarios, clearing the pendingbye flag after processing the CANCEL request and not checking for a pending BYE when receiving the final 487 response to the INVITE. This patch ensures that if the pendingbye flag is set, it is honored regardless of the nature of the INVITE request currently in flight. (closes issue ASTERISK-19365) Reported by: Thomas Arimont Tested by: Thomas Arimont Patches: bugASTERISK-19365_2012_03_08.patch uploaded by mjordan (license 6283) Review: https://reviewboard.asterisk.org/r/1807 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@360086 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Terry Wilson	7622a34c89	Make hints for invalid SIP devices return Unavail, not idle ... This patch drastically simplifies the device state aggegation code. The old method was not only overly complex, but also made it impossible to return AST_DEVICE_INVALID from the aggregation code. The unit test update is as a result of fixing that bug. The SIP change stems from a bug introduced by removing a DNS lookup for hostname-based SIP channels. (closes issue ASTERISK-16702) Review: https://reviewboard.asterisk.org/r/1808/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@358943 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Jonathan Rose	8e2e2bf059	Make transfer not ignore port information with SIP. ... Attempting to transfer with SIP to an address like 1XXXXX@ip.ad.re.ss:5061 would fail because port would be cut from the host string and ignored. This simply keeps chan_sip from cutting off the port number during these kinds of transfers. (closes issue ASTERISK-19321) Reported by: Federico Alves Review: https://reviewboard.asterisk.org/r/1790/diff/#index_header git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@358643 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Joshua Colp	ffa247ce6c	Defer sending the connected line reinvite if a reinvite is already in progress. ... (issue ASTERISK-19355) Reported by: tomaso (closes issue AST-825) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@358162 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago