3652 Commits (e126ab9eebc6db005df31280ff8e596ba6562426)

Author	SHA1	Message	Date
Corey Farrell	958bc84caf	chan_sip: Simplify dialog/peer references, improve REF_DEBUG output. ... * Replace functions for ref/undef of dialogs and peers with macro's to call ao2_t_bump/ao2_t_cleanup. * Enable passthough of REF_DEBUG caller information to sip_alloc and find_call. ASTERISK-24882 #close Reported by: Corey Farrell Review: https://reviewboard.asterisk.org/r/4189/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433115 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Corey Farrell	7fddae99dd	chan_sip: Fix dialog reference leaked to scheduler for reinvite_timeout. ... Release the scheduler reference to the dialog for reinvite timeout during dialog_unlink_all. ASTERISK-24876 #close Reported by: Corey Farrell Review: https://reviewboard.asterisk.org/r/4491/ ........ Merged revisions 433112 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433113 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Richard Mudgett	13e715b30c	chan_sip: Fix realtime locking inversion when poking a just built peer. ... When a realtime peer is built it can cause a locking inversion when the just built peer is poked. If the CLI command "sip show channels" is periodically executed then a deadlock can happen because of the locking inversion. * Push the peer poke off onto the scheduler thread to avoid the locking inversion of the just built realtime peer. AST-1540 ASTERISK-24838 #close Reported by: Richard Mudgett Review: https://reviewboard.asterisk.org/r/4454/ ........ Merged revisions 432526 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432528 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	34989bd9c8	channels/chan_sip: Don't send a BYE after final response when PBX thread fails ... When Asterisk fails to start a PBX thread for a new channel - for example, when the maxcalls setting in asterisk.conf is exceeded - we currently send a final response, and then attempt to send a BYE request to the UA. Since that's all sorts of wrong, this patch fixes that by setting sipalreadygone on the sip_pvt such that we don't get stuck sending BYE requests to something that does not want it. Note that this patch is a slight modification of the one on ASTERISK-15434. For clarity, it explicitly calls sipalreadygone with the calls to transmit a final response. ASTERISK-21845 ASTERISK-15434 #close Reported by: Makoto Dei Tested by: Matt Jordan patches: sip-pbxstart-failed.patch uploaded by Makoto Dei (License 5027) ........ Merged revisions 432320 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432321 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	ddff640f94	channels/chan_sip: Clarify WARNING message in mismatched SRTP scenario ... When we receive an SDP as part of an offer/answer for a peer/friend has been configured to require encryption, and that SDP offer/answer failed to provide acceptable crypto attributes, we currently issue a WARNING that uses the phrase "we" and "requested". In this case, both of those terms are ambiguous - the user will probably think "we" is Asterisk (it most likely isn't) and it may not be a "request", so much as an SDP that was received in some fashion. This patch makes the WARNING messages slightly less bad and a bit more accurate as well. ASTERISK-23214 #close Reported by: Rusty Newton ........ Merged revisions 432277 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432278 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	978649a568	channels/chan_sip: Fix crash when transmitting packet after thread shutdown ... When the monitor thread is stopped, its pthread ID is set to a specific value (AST_PTHREADT_STOP) so that later portions of the code can determine whether or not it is safe to manipulate the thread. Unfortunately, __sip_reliable_xmit failed to check for that value, checking instead only for AST_PTHREAD_STOP. Passing the invalid yet very specific value to pthread_kill causes a crash. This patch adds a check for AST_PTHREADT_STOP in __sip_reliable_xmit such that it doesn't attempt to poke the thread if the thread has already been stopped. ASTERISK-24800 #close Reported by: JoshE ........ Merged revisions 432198 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432199 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Richard Mudgett	feddab7944	HTTP: Stop accepting requests on final system shutdown. ... There are three CLI commands to stop and restart Asterisk each. 1) core stop/restart now - Hangup all calls and stop or restart Asterisk. New channels are prevented while the shutdown request is pending. 2) core stop/restart gracefully - Stop or restart Asterisk when there are no calls remaining in the system. New channels are prevented while the shutdown request is pending. 3) core stop/restart when convenient - Stop or restart Asterisk when there are no calls in the system. New calls are not prevented while the shutdown request is pending. ARI has made stopping/restarting Asterisk more problematic. While a shutdown request is pending it is desirable to continue to process ARI HTTP requests for current calls. To handle the current calls while a shutdown request is pending, a new committed to shutdown phase is needed so ARI applications can deal with the calls until the system is fully committed to shutdown. * Added a new shutdown committed phase so ARI applications can deal with calls until the final committed to shutdown phase is reached. * Made refuse new HTTP requests when the system has reached the final system shutdown phase. Starting anything while the system is actively releasing resources and unloading modules is not a good thing. * Split the bridging framework shutdown to not cleanup the global bridging containers when shutting down in a hurry. This is similar to how other modules prevent crashes on rapid system shutdown. * Moved ast_begin_shutdown(), ast_cancel_shutdown(), and ast_shutting_down(). You should not have to include channel.h just to access these system functions. ASTERISK-24752 #close Reported by: Matthew Jordan Review: https://reviewboard.asterisk.org/r/4399/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431692 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	29f3ff0b61	channels/chan_sip: Fix RealTime error during SIP unregistration with MariaDB ... When a SIP device that has its registration stored in RealTime unregisters, the entry for that device is updated with blank values, i.e., "", indicating that it is no longer registered. Unfortunately, one of those values that is 'blanked' is the device's port. If the column type for the port is not a string datatype (the recommended type is integer), an ODBC or database error will be thrown. MariaDB does not coerce empty strings to a valid integer value. This patch updates the query run from chan_sip such that it replaces the port value with a value of '0', as opposed to a blank value. This is the value that other database backends coerce the empty string ("") to already, and the handling of reading a RealTime registration value from a backend already anticipates receiving a port of '0' from the backends. ASTERISK-24772 #close Reported by: Richard Miller patches: chan_sip.diff uploaded by Richard Miller (License 5685) ........ Merged revisions 431673 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431674 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Mark Michelson	22fc3359da	Use SIPS URIs in Contact headers when appropriate. ... RFC 3261 sections 8.1.1.8 and 12.1.1 dictate specific scenarios when we are required to use SIPS URIs in Contact headers. Asterisk's non-compliance with this could actually cause calls to get dropped when communicating with clients that are strict about checking the Contact header. Both of the SIP stacks in Asterisk suffered from this issue. This changeset corrects the behavior in chan_sip. ASTERISK-24646 #close Reported by Stephan Eisvogel Review: https://reviewboard.asterisk.org/r/4346 ........ Merged revisions 431423 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431424 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kevin Harwell	e2b493b8f0	chan_sip: stale nonce causes failure ... When refreshing (with a small expiration) a registration that was sent to chan_sip the nonce would be considered stale and reject the registration. What was happening was that the initial registration's "dialog" still existed in the dialogs container and upon refresh the dialog match algorithm would choose that as the "dialog" instead of the newly created one. This occurred because the algorithm did not check to see if the from tag matched if authentication info was available after the 401. So, it ended up assuming the original "dialog" was a match and stopped the search. The old "dialog" of course had an old nonce, thus the stale nonce message. This fix attempts to leave the original functionality alone except in the case of a REGISTER. If a REGISTER is received if searches for an existing "dialog" matching only on the callid. If the expires value is low enough it will reuse dialog that is there, otherwise it will create a new one. ASTERISK-24715 #close Reported by: John Bigelow Review: https://reviewboard.asterisk.org/r/4367/ ........ Merged revisions 431187 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431194 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Walter Doekes	e23f07beb8	Fix typo's (retrieve, specified, address). ... ........ Merged revisions 430996 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430998 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Walter Doekes	9210648bbe	chan_sip: Case insensitive comparison of "defaultuser" parameter. ... All the other configuration options are case insensitive, so this one should be too. ASTERISK-24355 #close Reported by: HZMI8gkCvPpom0tM patches: ast.patch uploaded by HZMI8gkCvPpom0tM (License 6658) ........ Merged revisions 430993 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430994 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	74a13629e2	channels/chan_sip: Fix registration leak during reload ... When the SIP registrations were migrated to using ao2 in what was then trunk, the explicit destruction of the registrations on module reload was removed and not replaced with an ao2 equivalent. Debugging done by Stefan Engström, the issue reporter, on ASTERISK-24673 confirmed that the reference in the registry_list container was being leaked. Since the purpose of cleanup_all_regs is to prep a registration for destruction, this function now calls an ao2_callback function callback with the OBJ_MULTIPLE | OBJ_NODATA | OBJ_UNLINK flags used to remove the registrations. This cleans up each registration, and also removes it from the registration container registry_list. Review: https://reviewboard.asterisk.org/r/4355/ ASTERISK-24640 #close Reported by: Max Man ASTERISK-24673 #close Reported by: Stefan Engström Tested by: Stefan Engström git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430864 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Richard Mudgett	4b363688d4	AMI: Make AMI actions that generate event lists consistent. ... * Made the following AMI actions use list API calls for consistency: Agents BridgeInfo BridgeList BridgeTechnologyList ConfbridgeLIst ConfbridgeLIstRooms CoreShowChannels DAHDIShowChannels DBGet DeviceStateList ExtensionStateList FAXSessions Hangup IAXpeerlist IAXpeers IAXregistry MeetmeList MeetmeListRooms MWIGet ParkedCalls Parkinglots PJSIPShowEndpoint PJSIPShowEndpoints PJSIPShowRegistrationsInbound PJSIPShowRegistrationsOutbound PJSIPShowResourceLists PJSIPShowSubscriptionsInbound PJSIPShowSubscriptionsOutbound PresenceStateList PRIShowSpans QueueStatus QueueSummary ShowDialPlan SIPpeers SIPpeerstatus SIPshowregistry SKINNYdevices SKINNYlines Status VoicemailUsersList * Incremented the AMI version to 2.7.0. * Changed astman_send_listack() to not use the listflag parameter and always set the value to "Start" so the start capitalization is consistent. i.e., The FAXSessions used "Start" while the rest of the system used "start". The corresponding complete event always used "Complete". * Fixed ami_show_resource_lists() "PJSIPShowResourceLists" to output the AMI ActionID for all of its list events. * Fixed off-nominal AMI protocol error in manager_bridge_info(), manager_parking_status_single_lot(), and manager_parking_status_all_lots(). Use of astman_send_error() after responding to the original AMI action request violates the action response pattern by sending two responses. * Fixed minor protocol error in action_getconfig() when no requested categories are found. Each line needs to be formatted as "Header: text". * Fixed off-nominal memory leak in manager_build_parked_call_string(). * Eliminated unnecessary use of RAII_VAR() in ami_subscription_detail(). ASTERISK-24049 #close Reported by: Jonathan Rose Review: https://reviewboard.asterisk.org/r/4315/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430434 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	9735a13429	chan_sip: Send CANCEL via original INVITE destination even after UPDATE request ... Given the following scenario: * Three SIP phones (A, B, C), all communicating via a proxy with Asterisk * A call is established between A and B. B performs a SIP attended transfer of A to C. B sets the call on hold (A is hearing MOH) and dials the extension of C. While phone C is ringing, B transfers the call (that is, what we typically call a 'blond transfer'). * When the transfer completes, A hears the ringing of phone C, while B is idle. In the SIP messaging for the above scenario, a REFER request is sent to transfer the call. When "sendrpid=yes" is set in sip.conf, Asterisk may send an UPDATE request to phone C to update party information. This update is sent directly to phone C, not through the intervening proxy. This has the unfortunate side effect of providing route information, which is then set on the sip_pvt structure for C. If someone (e.g. B) is trying to get the call back (through a directed pickup), Asterisk will send a CANCEL request to C. However, since we have now updated the route set, the CANCEL request will be sent directly to C and not through the proxy. The phone ignores this CANCEL according to RFC3261 (Section 9.1). This patch updates reqprep such that the route is not updated if an UPDATE request is being sent while the INVITE state is INV_PROCEEDING or INV_EARLY_MEDIA. This ensures that a subsequent CANCEL request is still sent to the correct location. Review: https://reviewboard.asterisk.org/r/4279 ASTERISK-24628 #close Reported by: Karsten Wemheuer patches: issue.patch uploaded by Karsten Wemheuer (License 5930) ........ Merged revisions 429982 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@429983 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Walter Doekes	9ae57e0dd6	Fix printf problems with high ascii characters after r413586 (1.8). ... In r413586 (1.8) various casts were added to silence gcc 4.10 warnings. Those fixes included things like: -out += sprintf(out, "%%%02X", (unsigned char) *ptr); +out += sprintf(out, "%%%02X", (unsigned) *ptr); That works for low ascii characters, but for the high range that yields e.g. FFFFFFC3 when C3 is expected. This changeset: - fixes those casts to use the 'hh' unsigned char modifier instead - consistently uses %02x instead of %2.2x (or other non-standard usage) - adds a few 'h' modifiers in various places - fixes a 'replcaes' typo - dev/urandon typo (in 13+ patch) Review: https://reviewboard.asterisk.org/r/4263/ ASTERISK-24619 #close Reported by: Stefan27 (on IRC) ........ Merged revisions 429673 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 429674 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@429675 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Joshua Colp	f26d4618eb	chan_sip: Allow T.38 switch-over when SRTP is in use. ... Previously when SRTP was enabled on a channel it was not possible to switch to T.38 as no crypto attributes would be present. This change makes it so it is now possible. If a T.38 re-invite comes in SRTP is terminated since in practice you can't encrypt a UDPTL stream. Now... if we were doing T.38 over RTP (which does exist) then we'd have a chance but almost nobody does that so here we are. ASTERISK-24449 #close Reported by: Andreas Steinmetz patches: udptl-ignore-srtp-v2.patch submitted by Andreas Steinmetz (license 6523) ........ Merged revisions 429632 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@429633 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Joshua Colp	fb768ec33a	res_http_websocket: Fix crash due to double freeing memory when receiving a payload length of zero. ... Frames with a payload length of 0 were incorrectly handled in res_http_websocket. Provided a frame with a payload had been received prior it was possible for a double free to occur. The realloc operation would succeed (thus freeing the payload) but be treated as an error. When the session was then torn down the payload would be freed again causing a crash. The read function now takes this into account. This change also fixes assumptions made by users of res_http_websocket. There is no guarantee that a frame received from it will be NULL terminated. ASTERISK-24472 #close Reported by: Badalian Vyacheslav Review: https://reviewboard.asterisk.org/r/4220/ Review: https://reviewboard.asterisk.org/r/4219/ ........ Merged revisions 429270 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 429272 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@429273 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kevin Harwell	525c823b4b	Direct Media calls within private network sometimes get one way audio ... When endpoints with direct_media enabled, behind a firewall (Asterisk on a separate network) and were bridged sometimes Asterisk would send the ip address of the firewall in the sdp to one of the phones in the reinvite resulting in one way audio. When sending the reinvite Asterisk will retrieve the media address from the associated rtp instance, but if frames were being read this can be overwritten with another address (in this case the firewall's). This patch ensures that Asterisk uses the original device address when using direct media. ASTERISK-24563 Reported by: Steve Pitts Review: https://reviewboard.asterisk.org/r/4216/ ........ Merged revisions 429195 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@429196 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	d79c68d3fb	main/stasis: Allow subscriptions to use a threadpool for message delivery ... Prior to this patch, all Stasis subscriptions would receive a dedicated thread for servicing published messages. In contrast, prior to r400178 (see review https://reviewboard.asterisk.org/r/2881/), the subscriptions shared a thread pool. It was discovered during some initial work on Stasis that, for a low subscription count with high message throughput, the threadpool was not as performant as simply having a dedicated thread per subscriber. For situations where a subscriber receives a substantial number of messages and is always present, the model of having a dedicated thread per subscriber makes sense. While we still have plenty of subscriptions that would follow this model, e.g., AMI, CDRs, CEL, etc., there are plenty that also fall into the following two categories: * Large number of subscriptions, specifically those tied to endpoints/peers. * Low number of messages. Some subscriptions exist specifically to coordinate a single message - the subscription is created, a message is published, the delivery is synchronized, and the subscription is destroyed. In both of the latter two cases, creating a dedicated thread is wasteful (and in the case of a large number of peers/endpoints, harmful). In those cases, having shared delivery threads is far more performant. This patch adds the ability of a subscriber to Stasis to choose whether or not their messages are dispatched on a dedicated thread or on a threadpool. The threadpool is configurable through stasis.conf. Review: https://reviewboard.asterisk.org/r/4193 ASTERISK-24533 #close Reported by: xrobau Tested by: xrobau ........ Merged revisions 428681 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@428687 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Richard Mudgett	524588c345	ast_str: Fix improper member access to struct ast_str members. ... Accessing members of struct ast_str outside of the string manipulation API routines is invalid since struct ast_str is supposed to be treated as opaque. Review: https://reviewboard.asterisk.org/r/4194/ ........ Merged revisions 428244 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 428245 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@428246 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Corey Farrell	e8286df19c	chan_sip: Fix theoretical leak of p->refer. ... If transmit_refer is called when p->refer is already allocated, it leaks the previous allocation. Updated code to always free previous allocation during a new allocation. Also instead of checking if we have a previous allocation, always create a clean record. ASTERISK-15242 #close Reported by: David Woolley Review: https://reviewboard.asterisk.org/r/4160/ ........ Merged revisions 428117 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 428118 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@428119 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	906c7f4b97	channels/chan_sip: Add improved support for 4xx error codes ... This patch adds support for 414, 493, 479, and a stray 400 response in REGISTER response handling. This helps interoperability in a number of scenarios. Review: https://reviewboard.asterisk.org/r/3437 patches: rb3437.patch uploaded by oej (License 5267) ........ Merged revisions 426599 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 426600 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 426601 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@426602 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	ab07cf71f8	channels/chan_sip: Support mutltiple Supported and Required headers ... A SIP request may contain multiple Supported: and Required: headers. Currently, chan_sip only parses the first Supported/Required header it finds. This patch adds support for multiple Supported/Required headers for INVITE requests. Review: https://reviewboard.asterisk.org/r/2478 ASTERISK-21721 #close Reported by: Olle Johansson patches: rb2478.patch uploaded by oej (License 5267) ........ Merged revisions 426594 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 426595 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 426596 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@426597 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	97b5c22f07	channels/chan_sip: Respect outboundproxy setting when sending qualify requests ... The outboundproxy setting is currently ignored when sending OPTIONS requests as a result of the qualify setting. This means that if an Asterisk server is unable to send the packet directly to a peer, it is unable to qualify any non-inbound registered peer (e.g. a peer SIP Trunk). This patch grabs the outboundproxy information for a peer when a qualify attempt is being constructed and, if it finds the information, uses it when sending the OPTIONS request. Review: https://reviewboard.asterisk.org/r/3948 ASTERISK-24063 #close Reported by: Damian Ivereigh patches: outboundproxy-dai.patch uploaded by Damian Ivereigh (License 6632) ........ Merged revisions 425818 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 425819 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 425820 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425821 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Walter Doekes	0ebe3d78bc	chan_sip: Fix so asterisk won't send reINVITE after a BYE. ... After a reINVITE glare situation, Asterisk would re-send the reINVITE even though the call had been hung up in the mean time. This patch unschedules the reinvite when handling the BYE. ASTERISK-22791 #close Reported by: Paolo Compagnini Tested by: Paolo Compagnini Review: https://reviewboard.asterisk.org/r/4056/ (testcase is in review r4055) ........ Merged revisions 425296 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 425297 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 425298 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425299 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Walter Doekes	4c2aef333c	chan_sip: Fix dialog leak resulting from missing ACK to re-INVITE. ... If a device re-INVITEs at the same time as the dialog is hung up, and if then the ACK to the re-INVITE never reaches Asterisk, chan_sip would fail to destroy the dialog after a while. This resulted in (most prominently) file handle leaks. (Patch reindented by me.) ASTERISK-20784 #close ASTERISK-15879 #close Reported by: Torrey Searle, Nitesh Bansal Patches: reinvite_ack_timeout.patch uploaded by Torrey Searle (License #5334) patch_asterisk_20784.txt uploaded by Nitesh Bansal (License #6418) Reviewboard: https://reviewboard.asterisk.org/r/4052/ (testcase can be found at r4051) ........ Merged revisions 425068 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 425069 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 425070 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425071 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Richard Mudgett	6a844be566	chan_pjsip: Fix deadlock when masquerading PJSIP channels. ... Performing a directed call pickup resulted in a deadlock when PJSIP channels were involved. A masquerade needs to hold onto the channel locks while it swaps channel information between the two channels involved in the masquerade. With PJSIP channels, the fixup routine needed to push a fixup task onto the PJSIP channel's serializer. Unfortunately, if the serializer was also processing a task that needed to lock the channel, you get deadlock. * Added a new control frame that is used to notify the channels that a masquerade is about to start and when it has completed. * Added the ability to query taskprocessors if the current thread is the taskprocessor thread. * Added the ability to suspend/unsuspend the PJSIP serializer thread so a masquerade could fixup the PJSIP channel without using the serializer. ASTERISK-24356 #close Reported by: rmudgett Review: https://reviewboard.asterisk.org/r/4034/ ........ Merged revisions 424471 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424472 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Walter Doekes	303547231e	chan_sip: Simplify some unref code by removing unlink_peer_from_tables. ... ASTERISK-22945 #related Reported by: ibercom Patches: asterisk11-chan_sip-simplifies.patch uploaded by ibercom (License #6599) ........ Merged revisions 424181 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 424182 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 424183 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424184 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Walter Doekes	45e32e4b8c	chan_sip: Remove excess ref of realtime peer before sip_poke_peer. ... The peer is referenced at the end of sip_poke_peer, it should not get an extra ref before the call to sip_poke_peer. This fixes a memory leak. ASTERISK-22945 #close Reported by: ibercom Tested by: Yuriy Gorlichenko Patches: asterisk11.patch uploaded by ibercom (License #6599) Review: https://reviewboard.asterisk.org/r/4031/ ........ Merged revisions 424176 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 424177 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 424178 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424179 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Walter Doekes	20f4ea0df7	chan_sip: Unref outbound proxy structure on dialog/pvt destruction. ... Make sure outbound proxy refs are always unreffed on dialog destruction. Review: https://reviewboard.asterisk.org/r/4016/ ........ Merged revisions 423800 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 423801 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 423802 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@423803 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Walter Doekes	0f3540553d	chan_sip: On INVITE retransmission, don't add an extra 503 response. ... INVITE arrives to asterisk, asterisk responds Busy(). If the INVITE is retransmitted, asterisk would generate a 503 in addition to the 486. Thanks Torrey Searle for providing a working regression test. ASTERISK-24335 #close Review: https://reviewboard.asterisk.org/r/4003/ Patches: retrans_486_invite.patch uploaded by Torrey Searle (License #5334) ........ Merged revisions 423720 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 423721 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 423722 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@423723 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Scott Griepentrog	bd99a96b21	The assertion that peer was not found on final event ... message was being triggered on configuration reload. This patch changes that case to just return instead. Review: https://reviewboard.asterisk.org/r/3953/ Commited in trunk revision 422358 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@422359 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kinsey Moore	a4a58c2771	CallerID: Fix parsing of malformed callerid ... This allows the callerid parsing function to handle malformed input strings and strings containing escaped and unescaped double quotes. This also adds a unittest to cover many of the cases where the parsing algorithm previously failed. Review: https://reviewboard.asterisk.org/r/3923/ Review: https://reviewboard.asterisk.org/r/3933/ ........ Merged revisions 422112 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 422113 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 422114 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@422154 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Joshua Colp	6fa02d1bfd	chan_sip: Use the server reflexive ICE candidate RTCP port as provided. ... This code originally worked around an issue within res_rtp_asterisk itself. The wrong socket was being used for the STUN check for RTCP, causing the port to be the same as RTP. This was subsequently fixed and the RTCP port provided for the ICE candidate is correct and does not need to be incremented. ASTERISK-23997 #close Reported by: Badalian Vyacheslav Patches: plus1.diff submitted by Badalian Vyacheslav (license 5249) ........ Merged revisions 421909 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 421910 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421911 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	47c37abb93	chan_sip: Don't use port derived from fromdomain if it isn't set ... If a user does not provide a port in the fromdomain setting, chan_sip will set the fromdomainport to STANDARD_SIP_PORT (5060). The fromdomainport value will then get used unilaterally in certain places. This causes issues with TLS, where the default port is expected to be 5061. This patch modifies chan_sip such that fromdomainport is only used if it is not the standard SIP port; otherwise, the port from the SIP pvt's recorded self IP address is used. Review: https://reviewboard.asterisk.org/r/3893/ ASTERISK-24178 #close Reported by: Elazar Broad patches: fromdomainport_fix.diff uploaded by Elazar Broad (License 5835) ........ Merged revisions 421717 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 421718 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 421719 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421720 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Richard Mudgett	f0a65379f5	chan_sip: Fix type mismatch when the format is changed. ... Symptom is most likely an invalid ao2 object bad magic number message or a less likely crash. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@420881 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	02fc8e2449	chan_sip: Mark chan_sip and its files as extended support ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@420562 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Richard Mudgett	a1424a2f1a	chan_sip: Replace sip_tls_read() and resolve the large SDP poll issue. ... Replace sip_tls_read() and sip_tcp_read() with a single function and resolve the poll/wait issue with large SDP payloads. ASTERISK-18345 #close Reported by: Stephane Chazelas Patches: tcptls_pollv4.diff (license #5835) patch uploaded by Elazar Broad Review: https://reviewboard.asterisk.org/r/3882/ ........ Merged revisions 420434 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 420435 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 420436 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420437 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	47bf7efc4d	Multiple revisions 420089-420090,420097 ... ........ r420089 | mjordan | 2014-08-05 15:10:52 -0500 (Tue, 05 Aug 2014) | 72 lines ARI: Add channel technology agnostic out of call text messaging This patch adds the ability to send and receive text messages from various technology stacks in Asterisk through ARI. This includes chan_sip (sip), res_pjsip_messaging (pjsip), and res_xmpp (xmpp). Messages are sent using the endpoints resource, and can be sent directly through that resource, or to a particular endpoint. For example, the following would send the message "Hello there" to PJSIP endpoint alice with a display URI of sip:asterisk@mycooldomain.org: ari/endpoints/sendMessage?to=pjsip:alice&from=sip:asterisk@mycooldomain.org&body=Hello+There This is equivalent to the following as well: ari/endpoints/PJSIP/alice/sendMessage?from=sip:asterisk@mycooldomain.org&body=Hello+There Both forms are available for message technologies that allow for arbitrary destinations, such as chan_sip. Inbound messages can now be received over ARI as well. An ARI application that subscribes to endpoints will receive messages from those endpoints: { "type": "TextMessageReceived", "timestamp": "2014-07-12T22:53:13.494-0500", "endpoint": { "technology": "PJSIP", "resource": "alice", "state": "online", "channel_ids": [] }, "message": { "from": "\"alice\" <sip:alice@127.0.0.1>", "to": "pjsip:asterisk@127.0.0.1", "body": "Watson, come here.", "variables": [] }, "application": "testsuite" } The above was made possible due to some rather major changes in the message core. This includes (but is not limited to): - Users of the message API can now register message handlers. A handler has two callbacks: one to determine if the handler has a destination for the message, and another to handle it. - All dialplan functionality of handling a message was moved into a message handler provided by the message API. - Messages can now have the technology/endpoint associated with them. Various other properties are also now more easily accessible. - A number of ao2 containers that weren't really needed were replaced with vectors. Iteration over ao2_containers is expensive and pointless when the lifetime of things is well defined and the number of things is very small. res_stasis now has a new file that makes up its structure, messaging. The messaging functionality implements a message handler, and passes received messages that match an interested endpoint over to the app for processing. Note that inadvertently while testing this, I reproduced ASTERISK-23969. res_pjsip_messaging was incorrectly parsing out the 'to' field, such that arbitrary SIP URIs mangled the endpoint lookup. This patch includes the fix for that as well. Review: https://reviewboard.asterisk.org/r/3726 ASTERISK-23692 #close Reported by: Matt Jordan ASTERISK-23969 #close Reported by: Andrew Nagy ........ r420090 | mjordan | 2014-08-05 15:16:37 -0500 (Tue, 05 Aug 2014) | 2 lines Remove automerge properties :-( ........ r420097 | mjordan | 2014-08-05 16:36:25 -0500 (Tue, 05 Aug 2014) | 2 lines test_message: Fix strict-aliasing compilation issue ........ Merged revisions 420089-420090,420097 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420098 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Mark Michelson	dcf1ad14da	Add module support level to ast_module_info structure. Print it in CLI "module show" . ... ASTERISK-23919 #close Reported by Malcolm Davenport Review: https://reviewboard.asterisk.org/r/3802 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419592 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Corey Farrell	5bea6c1b1c	chan_sip: complete upgrade to ao2 ... This change upgrades sip_registry and sip_subscription_mwi to astobj2. ASTERISK-24067 #close Reported by: Corey Farrell Review: https://reviewboard.asterisk.org/r/3759/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419438 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	bb87796f67	ARI: Fix endpoint/channel subscription issues; allow for subscriptions to tech ... This patch serves two purposes: (1) It fixes some bugs with endpoint subscriptions not reporting all of the channel events (2) It serves as the preliminary work needed for ASTERISK-23692, which allows for sending/receiving arbitrary out of call text messages through ARI in a technology agnostic fashion. The messaging functionality described on ASTERISK-23692 requires two things: (1) The ability to send/receive messages associated with an endpoint. This is relatively straight forwards with the endpoint core in Asterisk now. (2) The ability to send/receive messages associated with a technology and an arbitrary technology defined URI. This is less straight forward, as endpoints are formed from a tech + resource pair. We don't have a mechanism to note that a technology that *may* have endpoints exists. This patch provides such a mechanism, and fixes a few bugs along the way. The first major bug this patch fixes is the forwarding of channel messages to their respective endpoints. Prior to this patch, there were two problems: (1) Channel caching messages weren't forwarded. Thus, the endpoints missed most of the interesting bits (such as channel creation, destruction, state changes, etc.) (2) Channels weren't associated with their endpoint until after creation. This resulted in endpoints missing the channel creation message, which limited the usefulness of the subscription in the first place (a major use case being 'tell me when this endpoint has a channel'). Unfortunately, this meant another parameter to ast_channel_alloc. Since not all channel technologies support an ast_endpoint, this patch makes such a call optional and opts for a new function, ast_channel_alloc_with_endpoint. When endpoints are created, they will implicitly create a technology endpoint for their technology (if one does not already exist). A technology endpoint is special in that it has no state, cannot have channels created for it, cannot be created explicitly, and cannot be destroyed except on shutdown. It does, however, have all messages from other endpoints in its technology forwarded to it. Combined with the bug fixes, we now have Stasis messages being properly forwarded. Consider the following scenario: two PJSIP endpoints (foo and bar), where bar has a single channel associated with it and foo has two channels associated with it. The messages would be forwarded as follows: channel PJSIP/foo-1 -- \ --> endpoint PJSIP/foo -- / \ channel PJSIP/foo-2 -- \ ---- > endpoint PJSIP / channel PJSIP/bar-1 -----> endpoint PJSIP/bar -- ARI, through the applications resource, can: - subscribe to endpoint:PJSIP/foo and get notifications for channels PJSIP/foo-1,PJSIP/foo-2 and endpoint PJSIP/foo - subscribe to endpoint:PJSIP/bar and get notifications for channels PJSIP/bar-1 and endpoint PJSIP/bar - subscribe to endpoint:PJSIP and get notifications for channels PJSIP/foo-1,PJSIP/foo-2,PJSIP/bar-1 and endpoints PJSIP/foo,PJSIP/bar Note that since endpoint PJSIP never changes, it never has events itself. It merely provides an aggregation point for all other endpoints in its technology (which in turn aggregate all channel messages associated with that endpoint). This patch also adds endpoints to res_xmpp and chan_motif, because the actual messaging work will need it (messaging without XMPP is just sad). Review: https://reviewboard.asterisk.org/r/3760/ ASTERISK-23692 ........ Merged revisions 419196 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419203 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	a2c912e997	media formats: re-architect handling of media for performance improvements ... In the old times media formats were represented using a bit field. This was fast but had a few limitations. 1. Asterisk was limited in how many formats it could handle. 2. Formats, being a bit field, could not include any attribute information. A format was strictly its type, e.g., "this is ulaw". This was changed in Asterisk 10 (see https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal for notes on that work) which led to the creation of the ast_format structure. This structure allowed Asterisk to handle attributes and bundle information with a format. Additionally, ast_format_cap was created to act as a container for multiple formats that, together, formed the capability of some entity. Another mechanism was added to allow logic to be registered which performed format attribute negotiation. Everywhere throughout the codebase Asterisk was changed to use this strategy. Unfortunately, in software, there is no free lunch. These new capabilities came at a cost. Performance analysis and profiling showed that we spend an inordinate amount of time comparing, copying, and generally manipulating formats and their related structures. Basic prototyping has shown that a reasonably large performance improvement could be made in this area. This patch is the result of that project, which overhauled the media format architecture and its usage in Asterisk to improve performance. Generally, the new philosophy for handling formats is as follows: * The ast_format structure is reference counted. This removed a large amount of the memory allocations and copying that was done in prior versions. * In order to prevent race conditions while keeping things performant, the ast_format structure is immutable by convention and lock-free. Violate this tenet at your peril! * Because formats are reference counted, codecs are also reference counted. The Asterisk core generally provides built-in codecs and caches the ast_format structures created to represent them. Generally, to prevent inordinate amounts of module reference bumping, codecs and formats can be added at run-time but cannot be removed. * All compatibility with the bit field representation of codecs/formats has been moved to a compatibility API. The primary user of this representation is chan_iax2, which must continue to maintain its bit-field usage of formats for interoperability concerns. * When a format is negotiated with attributes, or when a format cannot be represented by one of the cached formats, a new format object is created or cloned from an existing format. That format may have the same codec underlying it, but is a different format than a version of the format with different attributes or without attributes. * While formats are reference counted objects, the reference count maintained on the format should be manipulated with care. Formats are generally cached and will persist for the lifetime of Asterisk and do not explicitly need to have their lifetime modified. An exception to this is when the user of a format does not know where the format came from *and* the user may outlive the provider of the format. This occurs, for example, when a format is read from a channel: the channel may have a format with attributes (hence, non-cached) and the user of the format may last longer than the channel (if the reference to the channel is released prior to the format's reference). For more information on this work, see the API design notes: https://wiki.asterisk.org/wiki/display/AST/Media+Format+Rewrite Finally, this work was the culmination of a large number of developer's efforts. Extra thanks goes to Corey Farrell, who took on a large amount of the work in the Asterisk core, chan_sip, and was an invaluable resource in peer reviews throughout this project. There were a substantial number of patches contributed during this work; the following issues/patch names simply reflect some of the work (and will cause the release scripts to give attribution to the individuals who work on them). Reviews: https://reviewboard.asterisk.org/r/3814 https://reviewboard.asterisk.org/r/3808 https://reviewboard.asterisk.org/r/3805 https://reviewboard.asterisk.org/r/3803 https://reviewboard.asterisk.org/r/3801 https://reviewboard.asterisk.org/r/3798 https://reviewboard.asterisk.org/r/3800 https://reviewboard.asterisk.org/r/3794 https://reviewboard.asterisk.org/r/3793 https://reviewboard.asterisk.org/r/3792 https://reviewboard.asterisk.org/r/3791 https://reviewboard.asterisk.org/r/3790 https://reviewboard.asterisk.org/r/3789 https://reviewboard.asterisk.org/r/3788 https://reviewboard.asterisk.org/r/3787 https://reviewboard.asterisk.org/r/3786 https://reviewboard.asterisk.org/r/3784 https://reviewboard.asterisk.org/r/3783 https://reviewboard.asterisk.org/r/3778 https://reviewboard.asterisk.org/r/3774 https://reviewboard.asterisk.org/r/3775 https://reviewboard.asterisk.org/r/3772 https://reviewboard.asterisk.org/r/3761 https://reviewboard.asterisk.org/r/3754 https://reviewboard.asterisk.org/r/3753 https://reviewboard.asterisk.org/r/3751 https://reviewboard.asterisk.org/r/3750 https://reviewboard.asterisk.org/r/3748 https://reviewboard.asterisk.org/r/3747 https://reviewboard.asterisk.org/r/3746 https://reviewboard.asterisk.org/r/3742 https://reviewboard.asterisk.org/r/3740 https://reviewboard.asterisk.org/r/3739 https://reviewboard.asterisk.org/r/3738 https://reviewboard.asterisk.org/r/3737 https://reviewboard.asterisk.org/r/3736 https://reviewboard.asterisk.org/r/3734 https://reviewboard.asterisk.org/r/3722 https://reviewboard.asterisk.org/r/3713 https://reviewboard.asterisk.org/r/3703 https://reviewboard.asterisk.org/r/3689 https://reviewboard.asterisk.org/r/3687 https://reviewboard.asterisk.org/r/3674 https://reviewboard.asterisk.org/r/3671 https://reviewboard.asterisk.org/r/3667 https://reviewboard.asterisk.org/r/3665 https://reviewboard.asterisk.org/r/3625 https://reviewboard.asterisk.org/r/3602 https://reviewboard.asterisk.org/r/3519 https://reviewboard.asterisk.org/r/3518 https://reviewboard.asterisk.org/r/3516 https://reviewboard.asterisk.org/r/3515 https://reviewboard.asterisk.org/r/3512 https://reviewboard.asterisk.org/r/3506 https://reviewboard.asterisk.org/r/3413 https://reviewboard.asterisk.org/r/3410 https://reviewboard.asterisk.org/r/3387 https://reviewboard.asterisk.org/r/3388 https://reviewboard.asterisk.org/r/3389 https://reviewboard.asterisk.org/r/3390 https://reviewboard.asterisk.org/r/3321 https://reviewboard.asterisk.org/r/3320 https://reviewboard.asterisk.org/r/3319 https://reviewboard.asterisk.org/r/3318 https://reviewboard.asterisk.org/r/3266 https://reviewboard.asterisk.org/r/3265 https://reviewboard.asterisk.org/r/3234 https://reviewboard.asterisk.org/r/3178 ASTERISK-23114 #close Reported by: mjordan media_formats_translation_core.diff uploaded by kharwell (License 6464) rb3506.diff uploaded by mjordan (License 6283) media_format_app_file.diff uploaded by kharwell (License 6464) misc-2.diff uploaded by file (License 5000) chan_mild-3.diff uploaded by file (License 5000) chan_obscure.diff uploaded by file (License 5000) jingle.diff uploaded by file (License 5000) funcs.diff uploaded by file (License 5000) formats.diff uploaded by file (License 5000) core.diff uploaded by file (License 5000) bridges.diff uploaded by file (License 5000) mf-codecs-2.diff uploaded by file (License 5000) mf-app_fax.diff uploaded by file (License 5000) mf-apps-3.diff uploaded by file (License 5000) media-formats-3.diff uploaded by file (License 5000) ASTERISK-23715 rb3713.patch uploaded by coreyfarrell (License 5909) rb3689.patch uploaded by mjordan (License 6283) ASTERISK-23957 rb3722.patch uploaded by mjordan (License 6283) mf-attributes-3.diff uploaded by file (License 5000) ASTERISK-23958 Tested by: jrose rb3822.patch uploaded by coreyfarrell (License 5909) rb3800.patch uploaded by jrose (License 6182) chan_sip.diff uploaded by mjordan (License 6283) rb3747.patch uploaded by jrose (License 6182) ASTERISK-23959 #close Tested by: sgriepentrog, mjordan, coreyfarrell sip_cleanup.diff uploaded by opticron (License 6273) chan_sip_caps.diff uploaded by mjordan (License 6283) rb3751.patch uploaded by coreyfarrell (License 5909) chan_sip-3.diff uploaded by file (License 5000) ASTERISK-23960 #close Tested by: opticron direct_media.diff uploaded by opticron (License 6273) pjsip-direct-media.diff uploaded by file (License 5000) format_cap_remove.diff uploaded by opticron (License 6273) media_format_fixes.diff uploaded by opticron (License 6273) chan_pjsip-2.diff uploaded by file (License 5000) ASTERISK-23966 #close Tested by: rmudgett rb3803.patch uploaded by rmudgetti (License 5621) chan_dahdi.diff uploaded by file (License 5000) ASTERISK-24064 #close Tested by: coreyfarrell, mjordan, opticron, file, rmudgett, sgriepentrog, jrose rb3814.patch uploaded by rmudgett (License 5621) moh_cleanup.diff uploaded by opticron (License 6273) bridge_leak.diff uploaded by opticron (License 6273) translate.diff uploaded by file (License 5000) rb3795.patch uploaded by rmudgett (License 5621) tls_fix.diff uploaded by mjordan (License 6283) fax-mf-fix-2.diff uploaded by file (License 5000) rtp_transfer_stuff uploaded by mjordan (License 6283) rb3787.patch uploaded by rmudgett (License 5621) media-formats-explicit-translate-format-3.diff uploaded by file (License 5000) format_cache_case_fix.diff uploaded by opticron (License 6273) rb3774.patch uploaded by rmudgett (License 5621) rb3775.patch uploaded by rmudgett (License 5621) rtp_engine_fix.diff uploaded by opticron (License 6273) rtp_crash_fix.diff uploaded by opticron (License 6273) rb3753.patch uploaded by mjordan (License 6283) rb3750.patch uploaded by mjordan (License 6283) rb3748.patch uploaded by rmudgett (License 5621) media_format_fixes.diff uploaded by opticron (License 6273) rb3740.patch uploaded by mjordan (License 6283) rb3739.patch uploaded by mjordan (License 6283) rb3734.patch uploaded by mjordan (License 6283) rb3689.patch uploaded by mjordan (License 6283) rb3674.patch uploaded by coreyfarrell (License 5909) rb3671.patch uploaded by coreyfarrell (License 5909) rb3667.patch uploaded by coreyfarrell (License 5909) rb3665.patch uploaded by mjordan (License 6283) rb3625.patch uploaded by coreyfarrell (License 5909) rb3602.patch uploaded by coreyfarrell (License 5909) format_compatibility-2.diff uploaded by file (License 5000) core.diff uploaded by file (License 5000) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419044 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Scott Griepentrog	f91989d44e	media formats: fix ref leak of peer for mwi subscription ... Holding a reference to the peer during mwi subscriptions resulted in a circular reference because the final event message would not be sent until destruction of the peer. Instead, pass the name of the peer to the event callback so that it can fail gracefully after the peer has gone. ASTERISK-23959 Review: https://reviewboard.asterisk.org/r/3754/ ........ Merged revisions 418636 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418962 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	1ce23d4534	chan_sip: Make progressinband=never really mean 'never' ... progressinband=never in sip.conf is easily defeated if an onward trunk sends a progress indication of its own. This is almost certain to happen if the onward trunk is ISDN or IAX as these technologies send a progress indication even if early media is not required. This progress message is passed to the caller, and causes the "never" option to be rather badly named. This patch changes the behaviour of this setting in the following ways: 1) In sip_write(), do not pass the media unless we have either progressed beyond INV_EARLY_MEDIA, or we are in INV_EARLY_MEDIA state, and early media is both set-up and wanted. This helps resolve double-ringing on some buggy handsets. 2) In sip_indicate(), if we see AST_CONTROL_PROGRESS, but SIP_PROG_INBAND_NEVER is set, send a 180 Ringing instead to avoid implicitly enabling early media. Avoid sending double ring indications. NOTE: the meaning of the SIP_PROGRESS_SENT flag changes slightly in this patch to also encapsulate the fact that a channel has *sent or received* a 183 Progress indication. This makes the updated code in sip_write() much more simple. Review: https://reviewboard.asterisk.org/r/3700 ASTERISK-23972 #close Reported by: Steve Davies patches: inband_never_present_early_media2 uploaded by Steve Davies (License 5012) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418868 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	97834718c2	Remove many deprecated modules ... Billing records are fair, To get paid is quite bright, You should really use ODBC; Good-bye cdr_sqlite. Microsoft did once push H.323, Hell, we all remember NetMeeting. But try to compile chan_h323 now And you will take quite a beating. The XMPP and SIP war was fierce, And in the distant fray Was birthed res_jabber/chan_jingle; But neither to stay. For everyone did care and chase what Google professed. "Free Internet Calling" was what devotees cried, But Google did change the specs so often That the developers were happy the day chan_gtalk died. And then there was that odd application Dedicated to the Polish tongue. app_saycountpl was subsumed by Say; One could say its bell was rung. To read and parse a file from the dialplan You could (I guess) use an application. app_readfile did fill that purpose, but I think A function is perhaps better in its creation. Barging is rude, I'm not sure why we do it. Inwardly, the caller will probably sigh. But if you really must do it, Don't use app_dahdibarge, use ChanSpy. We all despise the sound of tinny robots It makes our queues so cold. To control such an abomination It's better to not use Wait/SetMusicOnHold. It's often nice to know properties of a channel It makes our calls right We have a nice function called CHANNEL And so SIPCHANINFO is sent off into the night. And now things get odd; Apparently one could delimit with a colon Properties from the SIPPEER function! Commas are in; all others are done. Finally, a word on pipes and commas. We're sorry. We can't say it enough. But those compatibility options in asterisk.conf; To maintain them forever was just too tough. This patch removes: * cdr_sqlite * chan_gtalk * chan_jingle * chan_h323 * res_jabber * app_saycountpl * app_readfile * app_dahdibarge It removes the following applications/functions: * WaitMusicOnHold * SetMusicOnHold * SIPCHANINFO It removes the colon delimiter from the SIPPEER function. Finally, it also removes all compatibility options that were configurable from asterisk.conf, as these all applied to compatibility with Asterisk 1.4 systems. Review: https://reviewboard.asterisk.org/r/3698/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418019 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Joshua Colp	6e60f5d317	Recorded merge of revisions 417677 from http://svn.asterisk.org/svn/asterisk/branches/11 ... ........ res_rtp_asterisk: Add SHA-256 support for DTLS and perform DTLS negotiation on RTCP. This change fixes up DTLS support in res_rtp_asterisk so it can accept and provide a SHA-256 fingerprint, so it occurs on RTCP, and so it occurs after ICE negotiation completes. Configuration options to chan_sip and chan_pjsip have also been added to allow behavior to be tweaked (such as forcing the AVP type media transports in SDP). ASTERISK-22961 #close Reported by: Jay Jideliov Review: https://reviewboard.asterisk.org/r/3679/ Review: https://reviewboard.asterisk.org/r/3686/ ........ Merged revisions 417678 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417679 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	44dba37bd1	chan_sip: be more tolerant of whitespace between attributes in SDP fmtp line ... This patch is essentially a backport of a small portion of r397526 from ASTERISK-21981. In that patch, pass through support and format attribute negotiation was added for Opus. Part of that included being more tolerant to whitespace in the fmtp line of an SDP; that part of the patch is being applied here. As the author of the backport pointed out, in SDP, the fmtp line is allowed to include whitespace between attributes. RFC 3267 chapter 8.3 (from 2001) includes an example for this. This was not removed in the updated RFC 4867 in 2007. Review: https://reviewboard.asterisk.org/r/3658 #ASTERISK-23916 #close Reported by: Alexander Traud patches: sdpFMTPspace_Asterisk11.patch uploaded by Alexander Traud (License 6520) ........ Merged revisions 417587 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 417588 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 417589 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417590 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	365ae7523b	res_http_websocket: Close websocket correctly and use careful fwrite ... When a client takes a long time to process information received from Asterisk, a write operation using fwrite may fail to write all information. This causes the underlying file stream to be in an unknown state, such that the socket must be disconnected. Unfortunately, there are two problems with this in Asterisk's existing websocket code: 1. Periodically, during the read loop, Asterisk must write to the connected websocket to respond to pings. As such, Asterisk maintains a reference to the session during the loop. When ast_http_websocket_write fails, it may cause the session to decrement its ref count, but this in and of itself does not break the read loop. The read loop's write, on the other hand, does not break the loop if it fails. This causes the socket to get in a 'stuck' state, preventing the client from reconnecting to the server. 2. More importantly, however, is that the fwrite in ast_http_websocket_write fails with a large volume of data when the client takes awhile to process the information. When it does fail, it fails writing only a portion of the bytes. With some debugging, it was shown that this was failing in a similar fashion to ASTERISK-12767. Switching this over to ast_careful_fwrite with a long enough timeout solved the problem. Note that this version of the patch, unlike r417310 in Asterisk 11, exposes configuration options beyond just chan_sip's sip.conf. Configuration options to configure the write timeout have also been added to pjsip.conf and ari.conf. #ASTERISK-23917 #close Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/3624/ ........ Merged revisions 417310 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 417311 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417317 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago