22093 Commits (80efa3173315ba47b794e5c9f1b56f61a663a76c)

 

All Branches   

Search

Author	SHA1	Message	Date
Mark Michelson	80efa31733	Help mitigate potential reinvite glare scenarios. ... 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. For those who are having some deja vu, that's because this patch was originally committed to trunk since there is a new configuration option added. After seeing a bug report about audio being slow to set up on SIP calls, it became apparent that this patch would be the best solution for resolving the issue. The patch is unintrusive and will have no effect unless the option is explicitly enabled. (closes issue AST-896) reported by Thomas Arimont (closes issue ASTERISK-19857) reported by Matt Jordan git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@370618 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	395b4b4898	Release B channel allocation on error path in chan_misdn. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@370563 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Jonathan Rose	e0c0f9934d	res_agi: Add message indicating need for \n character in verbose message ... The while loop responsible for reading AGI messages from a fastAGI service can end up looping indefinitely when an AGI script fails to indicate the end of a message with a \n character. This patch adds an indication that we are expecting a \n character to end the message to make it more clear to users that this is necessary if they are receiving this warning over and over. (issue ASTERISK-20061) Reported by: Eike Kuiper git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@370494 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kevin P. Fleming	cb4bdd6531	Rewrite a comment that didn't adequately explain the code it was documenting. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@370429 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Tzafrir Cohen	4f5d328eca	chan_oss: fix "sample rate" error message ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@370428 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kevin P. Fleming	3e75c69c3b	Improve documentation for the SHELL() dialplan function. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@370383 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kevin P. Fleming	aac6e33ba4	Free any datastores attached to dummy channels. ... Revision 370205 added the use of a datastore attached to a dummy channel to resolve a memory leak, but ast_dummy_channel_destructor() in this branch did not free datastores, resulting in a continued (but slightly smaller) memory leak. This patch backports the change to free said datastores from the Asterisk trunk. (related to issue AST-916) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@370360 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	ad8a86bef0	Fix compiler warnings. ... gcc (GCC) 4.2.4 has problems casting away constness. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@370275 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	2660ebd91a	Fix compilation error when MALLOC_DEBUG is enabled ... To fix a memory leak in CEL, a channel datastore was introduced whose destruction function pointer was pointed to the ast_free macro. Without MALLOC_DEBUG enabled this compiles as fine, as ast_free is defined as free. With MALLOC_DEBUG enabled, however, ast_free takes on a definition from a different place then utils.h, and became undefined. This patch resolves this by using a reference to ast_free_ptr. When MALLOC_DEBUG is enabled, this calls ast_free; when MALLOC_DEBUG is not enabled, this is defined to be ast_free, which is defined to be free. (issue AST-916) Reported by: Thomas Arimont git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@370273 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	c545c76c87	Handle extremely out of order RFC 2833 DTMF ... The current implementation of RFC 2833 DTMF handling in res_rtp_asterisk will, if a packet arrives out of order, drop the packet. This is to prevent duplicate ton generation in the Asterisk core. Since the RTP layer does not buffer data itself, this is the only option the RTP layer currently has for handling packets that arrive out of order. For the most part, this doesn't matter. For a particular digit, so long as a BEGIN packet arrives before the first END packet, the digit will be produced. If subsequent BEGIN packets arrive interleaved with the ENDs, they will be dropped; likewise, if the BEGIN or END packets themselves are out of order, those packets are dropped but sufficient information is conveyed to the Asterisk core to produce the appropriate digit. For certain sequences of DTMF packets - most notably when, for a particular digit, an END packet arrives before any BEGIN packet for that digit - this is a real problem. When an END arrives before any BEGINs, the END packet is dropped - but at the same time, it causes subsequent BEGIN packets for that digit to be ignored. When the next in order END packet arrives, it too is dropped - Asterisk believes that there was no initial BEGIN. The solution this patch provides is to trust the END packet to convey the information needed for the Asterisk core to produce the DTMF digit. If we receive an END packet, and it: * Has a timestamp greater then the last timestamp received from an END packet * Does not have the same sequence number as the last received sequence number (and is thus not an END packet retransmission) Then we send the END frame up to the Asterisk core. It contains enough DTMF information for Asterisk to produce the digit. On the other hand, if we receive a BEGIN or continuation packet that occurs with a timestamp equal to or less then the last END timestamp, then we've received something out of order - but we already have received enough information to produce the digit. These packets are dropped. Much thanks goes to Olle Johansson (oej) for providing the idea for this solution. Review: https://reviewboard.asterisk.org/r/2033/ (closes issue ASTERISK-18404) Reported by: Stephane Chazelas Tested by: Matt Jordan git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@370252 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kevin P. Fleming	c81a9be09f	Resolve severe memory leak in CEL logging modules. ... A customer reported a significant memory leak using Asterisk 1.8. They have tracked it down to ast_cel_fabricate_channel_from_event() in main/cel.c, which is called by both in-tree CEL logging modules (cel_custom.c and cel_sqlite3_custom.c) for each and every CEL event that they log. The cause was an incorrect assumption about how data attached to an ast_channel would be handled when the channel is destroyed; the data is now stored in a datastore attached to the channel, which is destroyed along with the channel at the proper time. (closes issue AST-916) Reported by: Thomas Arimont Review: https://reviewboard.asterisk.org/r/2053/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@370205 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kevin P. Fleming	ecbaf1ee3f	Ensure that all ast_datastore_info structures are 'const'. ... While addressing a bug, I came across a instance of 'struct ast_datastore_info' that was not declared 'const'. Since the API already expects them to be 'const', this patch changes the declarations of all existing instances that were not already declared that way. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@370183 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Walter Doekes	3d331187af	Code cleanup and bugfix in chan_sip outboundproxy parsing. ... The bug was clearing the global outboundproxy when a peer-specific outboundproxy was bad. The cleanup reduces duplicate code. Review: https://reviewboard.asterisk.org/r/2034/ Reviewed by: Mark Michelson git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@370131 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	7ae8833eeb	Add comments about the BUILD_NATIVE change ... This is a significant change and mention of it should have gone into UPGRADE.txt and CHANGES. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@370081 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	d8ff69cb1b	Add missing ast_hangup() calls on some analog exception paths. ... Make starting analog_ss_thread() or __analog_ss_thread() failure paths hangup the channel. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@370017 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	c77948d604	Include Expires header for SIP PUBLISH requests ... RFC3903 requres SIP PUBLISH requests to have Expires headers, so add them. Review: https://reviewboard.asterisk.org/r/2003/ Patch-by: gareth git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@370014 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	bc4a0338e5	Prevent double uri_escaping in chan_sip when pedantic is enabled ... If pedantic mode is enabled, outbound invites will have double-escaped contacts. This avoids setting an already-escaped string into a field where it is expected to be unescaped. (closes issue ASTERISK-20023) Reported by: Walter Doekes git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369993 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Michael L. Young	84081cf8e5	Correct Documentation For DEC Function ... The documentation for DEC in func_math.c was incorrect. Looks like a copy and paste error. (Closes issue ASTERISK-20095) Reported by: Billy Chia Tested by: Michael L. Young Patches: func_math.patch uploaded by Billy Chia (license 6381) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369970 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Tilghman Lesher	be2a4c0d0d	Allow the REALTIME() function to report errors back to the caller. ... Also, do more error checking on the arguments specified to the REALTIME() function and clarify the documentation. While I was editing the file, a few coding guidelines fixups, as well. Review: https://reviewboard.asterisk.org/r/2031/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369937 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	913225a79a	Improve Goto and GotoIf related documentation ... Correct documentation on labeliftrue and labeliffalse parameters of GotoIf() and update several other locations that use the same syntax. (closes issue ASTERISK-20007) Patch-by: Leif Madsen Reported-by: WIMPy git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369869 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Jason Parker	66f69a53c3	Add Digium phones context to sip_notify sample config. ... This makes it so that they can be reconfigured remotely. (closes issue ASTERISK-19910) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369818 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Jonathan Rose	6b24019080	chan_sip: Fix small behavioral change accidentally introduced in r369750 ... When removing the warning for AST_CONTROL_FLASH from sip_indicate, I also inadvertently changed the return value, which would likely make the indication not be sent in audio. This fixes that while still removing the warning message. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369792 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Jonathan Rose	a611188a8d	chan_sip: Add case for FLASH control frames so that we don't display a warning. ... chan_sip channels can receive flash control frames when connected to analog phones and possibly for other reasons. There really isn't a reason to warn when these frames are received, we can safely ignore them. Patches: dahdi_sip_flash.diff uploaded by Jonathan Rose (license 6182) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369750 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Mark Michelson	a35a2ec1b5	Remove a superfluous and dangerous freeing of an SSL_CTX. ... The problem here is that multiple server sessions share a SSL_CTX. When one session ended, the SSL_CTX would be freed and set NULL, leaving the other sessions unable to function. The code being removed is superfluous because the SSL_CTX structures for servers will be properly freed when ast_ssl_teardown is called. (closes issue ASTERISK-20074) Reported by Trevor Helmsley Patches: ASTERISK-20074.diff uploaded by Mark Michelson (license #5049) Testers: Trevor Helmsley git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369731 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Mark Michelson	9a4ee83043	Fix bridging thread leak. ... The bridge thread was exiting but was never being reaped using pthread_join(). This has been fixed now by calling pthread_join() in ast_bridge_destroy(). (closes issue ASTERISK-19834) Reported by Marcus Hunger Review: https://reviewboard.asterisk.org/r/2012 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369708 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	8339cc9684	AST-2012-011: Resolve heap corruption issue with voicemail ... The heard and deleted arrays in the voicemail state structure were not handled properly following the memory leak fix in r354890 and a fix for an invalid free in r356797. This could result in accessing and writing into freed memory. The allocation for these arrays has been reworked to avoid the possibility of invalid frees, access of freed memory, and crashes that were occurring as a result of this. Locking around accesses and modifications of the voicemail state structure members dh_arraysize, heard, and deleted has been added to prevent simultaneous modification and access when IMAP storage is in use. If IMAP storage is not in use, this locking is not compiled in. Review: https://reviewboard.asterisk.org/r/1994/ (closes issue ASTERISK-19923) Reported by: Dan Delaney Tested by: Dan Delaney, Julian Yap Patches: vm_alloc_fix.diff uploaded by kmoore (license 6273) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369652 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	48667d72f1	Do not send a BYE when a provisional response arrives during a re-INVITE ... Commits r369557 and r369579 were done to improve handling of re-INVITEs when the UA that was supposed to receive the re-INVITE fails to respond. A limitation of those patches occurred when a UA sent a provisional response to the re-INVITE. This triggered a sending of a BYE in check_pending. This patch tweaks the handling of the re-INVITE such that a BYE is not sent in response to those messages. (issue ASTERISK-19992) Reported by: Steve Davies Tested by: Steve Davies patches: (reinvite_tweak.diff license #5012 by Steve Davies) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369626 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Terry Wilson	216c3f792b	More improvements to re-INVITEs timing out after a provisional response ... There is no need to call check_pendings() on a final response to an INVITE when destroying the scheduler entry as it will be done later during normal processing. (issue ASTERISK-19992) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369579 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Terry Wilson	dff0057eba	Better handle re-INVITEs with provisional but no final repsonses ... A previous attempt at fixing this issue had negative side effects related to attended transfers which this patch should resolve. Many thanks to Steve Davies for all of the good suggestions and testing. (closes issue ASTERISK-19992) Reported by: Steve Davies Tested by: Steve Davies, Terry Wilson Review: https://reviewboard.asterisk.org/r/2009/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369557 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Joshua Colp	24d87b984e	With some configurations a transport is not actually specified so assume UDP in these cases. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369490 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Joshua Colp	74c0706e93	Make the address family filter specific to the transport. ... (closes issue ASTERISK-16618) Reported by: Leif Madsen Review: https://reviewboard.asterisk.org/r/1667/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369471 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
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
Matthew Jordan	02fb0d8d28	Fix crash in unloading of res_adsi module ... When res_adsi is unloaded, it removes the ADSI functions that it previously installed by passing a NULL adsi_funcs pointer to ast_adsi_install_funcs. This function was not checking whether or not the adsi_funcs pointer passed in was NULL before dereferencing it to check whether or not the version of the functions matches what the core was expecting it. This patch makes it so that the version is only checked if a potentially valid adsi_funcs pointer was passed in. Passing in NULL removes the installed functions, bypassing the version check. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369390 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	5a77cbe00c	Tweak CDR change in r369351 ... As Tilghman pointed out on review 1996, the check to see if a CDR end time has been set is sufficient to know whether or not the duration value can be used. The check-in done for r369351 forgot to include this change. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369366 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
Matthew Jordan	87e212e120	Fix incorrect duration reporting in CDRs created in batch mode ... Certain places in core/cdr.c would, if the duration value were 0, calculate the duration as being the delta between the current time and the time at which the CDR record was started. While this does not typically cause a problem in non-batch mode, this can cause an issue in batch mode where CDR records are gathered and written long after those calls have ended. In particular, this affects calls that were never answered, as those are expected to have a duration of 0. Often, this would result in CDR logs with a significant number of calls with lengthy durations, but dispositions of "BUSY". Note that this does not affect cdr_csv, as that backend does not use ast_cdr_getvar and instead directly reports the duration value. The affected core backends include cdr_apative_odbc and cdr_custom; other extended or deprecated CDR backends may potentially still directly manipulate the duration values. (issue ASTERISK-19860) Reported by: Thomas Arimont (issue AST-883) Reported by: Thomas Arimont Tested by: Matt Jordan Review: https://reviewboard.asterisk.org/r/1996/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369351 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	dd1390e777	Fix Bridge application occasionally returning to the wrong location. ... * Fix do_bridge_masquerade() getting the resume location from the zombie channel. The code must not touch a clone channel after it has masqueraded it. The clone channel has become a zombie and is starting to hangup. (closes issue ASTERISK-19985) Reported by: jamicque Patches: jira_asterisk_19985_v1.8.patch (license #5621) patch uploaded by rmudgett Tested by: jamicque git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369327 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Mark Michelson	65c1d24e29	Forgot to svn add this file in my last commit. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369324 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Mark Michelson	bd11706d8e	Eliminate embedding of res_adsi.so module. ... The way this is done is to stop using the optional API. Instead, res_adsi.so, when loaded fills in a table of function pointers. Review: https://reviewboard.asterisk.org/r/1991 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369323 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	8d8f318272	Fix Bridge application and AMI Bridge action error handling. ... * Fix AMI Bridge action disconnecting the AMI link on error. * Fix AMI Bridge action and Bridge application not checking if their masquerades were successful. * Fix Bridge application running the h-exten when it should not. * Made do_bridge_masquerade() return if the masquerade was successful so the Bridge application and AMI Bridge action could deal with it correctly. * Made bridge_call_thread_launch() hangup the passed in channels if the bridge_call_thread fails to start. Those channels would have been orphaned. * Made builtin_atxfer() check the success of the transfer masquerade setup. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369282 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	5e54864c5c	Explicitly check caller hangup in app Queue rather than a polluted res2 value. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369262 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	9f3ce626fe	Check if PBX was started and fix F and F(x) action logic in Dial application. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369258 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	8139102c83	Check if PBX was started for generic CCSS recall. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369238 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
Alexandr Anikin	c1bafc8f9f	fix locking issue on empty callList ... (issue ASTERISK-19298) Reported by: Dmitry Melekhov Patches: ASTERISK-18322-2.patch git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369146 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Alexandr Anikin	71fbf1a748	fix compile error (1.8 don't have ast_channel_name macro) ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369130 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Michael L. Young	c0e57ac429	Fix NULL pointer segfault in ast_sockaddr_parse() ... While working with ast_parse_arg() to perform a validity check, a segfault occurred. The segfault occurred due to passing a NULL pointer to ast_sockaddr_parse() from ast_parse_arg(). According to the documentation in config.h, "result pointer to the result. NULL is valid here, and can be used to perform only the validity checks." This patch fixes the segfault by checking for a NULL pointer. This patch also adds documentation to netsock2.h about why it is necessary to check for a NULL pointer. (Closes issue ASTERISK-20006) Reported by: Michael L. Young Tested by: Michael L. Young Patches: asterisk-20006-netsock-null-ptr.diff uploaded by Michael L. Young (license 5026) Review: https://reviewboard.asterisk.org/r/1990/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369108 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago