3484 Commits (3232e23ca7c30a143203e29e74ffe86787531acc)

Author	SHA1	Message	Date
Alec L Davis	f7f58b7bc2	chan_sip: Session-Expires: Set timer to correctly expire at (~2/3) of the interval when not the refresher ... RFC 4028 Section 10 if the side not performing refreshes does not receive a session refresh request before the session expiration, it SHOULD send a BYE to terminate the session, slightly before the session expiration. The minimum of 32 seconds and one third of the session interval is RECOMMENDED. Prior to this asterisk would refresh at 1/2 the Session-Expires interval, or if the remote device was the refresher, asterisk would timeout at interval end. Now, when not refresher, timeout as per RFC noted above. (closes issue ASTERISK-21742) Reported by: alecdavis Tested by: alecdavis alecdavis (license 585) Review https://reviewboard.asterisk.org/r/2488/ ........ Merged revisions 387344 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 387345 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387369 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Alec L Davis	7f0f53958b	chan_sip: Honor Session-Expires in 200OK response when it's a RE-INVITE when asterisk is the refresher. ... RFC 4028 Section 7.2 "UACs MUST be prepared to receive a Session-Expires header field in a response, even if none were present in the request." What changed After ASTERISK-20787, inbound calls to asterisk with no Session-Expires in the INVITE are now are offered a Session-Expires (1800 asterisk default) in the response, with asterisk as the refresher. Symptom: After 900 seconds (asterisk default refresher period 1800), asterisk RE-INVITEs the device, the device may respond with a much lower Session-Expires (180 in our case) value that it is now using. Asterisk ignores this response, as it's deemed both an INBOUND CALL, and a RE-INVITE. After 180 seconds the device times out and sends BYE (hangs up), asterisk is still working with the refresher period of 1800 as it ignored the 'Session Expires: 180' in the previous 200OK response. Fix: handle_response_invite() when 200OK, remove check for outbound and reinvite. (closes issue ASTERISK-21664) Reported by: alecdavis Tested by: alecdavis alecdavis (license 585) Review https://reviewboard.asterisk.org/r/2463/ ........ Merged revisions 387312 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 387319 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387327 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	b693a72378	Prevent crash in 'sip show peers' when the number of peers on a system is large ... When you have lots of SIP peers (according to the issue reporter, around 3500), the 'sip show peers' CLI command or AMI action can crash due to a poorly placed string duplication that occurs on the stack. This patch refactors the command to not allocate the string on the stack, and handles the formatting of a single peer in a separate function call. (closes issue ASTERISK-21466) Reported by: Guillaume Knispel patches: fix_sip_show_peers_stack_overflow_asterisk_11.3.0-v2.patch uploaded by gknispel (License 6492) ........ Merged revisions 387134 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387135 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Jonathan Rose	8e257fe819	Stasis Core: Refactor ACL Change events to go out over the stasis core msg bus ... (issue ASTERISK-21103) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2481/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387037 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Michael L. Young	b4c881c86e	Fix Displaying Symmetric RTP Global Setting ... * Use comedia_string() to display correctly the symmetric rtp setting when running "sip show settings" ........ Merged revisions 386486 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386487 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Michael L. Young	735026ccf6	Change Case On Forcerport For Consistency ... * Change "ForcerPort" to "Forcerport" to match everywhere else it is displayed ........ Merged revisions 386483 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 386484 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386485 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Michael L. Young	fcbb9f0c8d	Fix One-Way Audio With auto_* NAT Settings When SIP Calls Initiated By PBX ... When we reload Asterisk or chan_sip, the flags force_rport and comedia that are turned on and off when using the auto_force_rport and auto_comedia nat settings go back to the default setting off. These flags are turned on when needed or off when not needed at the time that a peer registers, re-registers or initiates a call. This would apply even when only the default global setting "nat=auto_force_rport" is being used, which in this case would only affect the force_rport flag. Everything is good except for the following: The nat setting is set to auto_force_rport and auto_comedia. We reload Asterisk and the peer's registration has not expired. We load in the settings for the peer which turns force_rport and comedia back to off. Since the peer has not re-registered or placed a call yet, those flags remain off. We then initiate a call to the peer from the PBX. The force_rport and comedia flags stay off. If NAT is involved, we end up with one-way audio since we never checked to see if the peer is behind NAT or not. This patch does the following: * Moves the checking of whether a peer is behind NAT into its own function * Create a function to set the peer's NAT flags if they are using the auto_* NAT settings * Adds calls in sip_request_call() to these new functions in order to setup the dialog according to the peer's settings (closes issue ASTERISK-21374) Reported by: Michael L. Young Tested by: Michael L. Young Patches: asterisk-21374-auto-nat-outgoing-fix_v2.diff Michael L. Young (license 5026) Review: https://reviewboard.asterisk.org/r/2421/ ........ Merged revisions 385473 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385474 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	caf4a5f605	Fix crash in chan_sip when a core initiated op occurs at the same time as a BYE ... When a BYE request is processed in chan_sip, the current SIP dialog is detached from its associated Asterisk channel structure. The tech_pvt pointer in the channel object is set to NULL, and the dialog persists for an RFC mandated period of time to handle re-transmits. While this process occurs, the channel is locked (which is good). Unfortunately, operations that are initiated externally have no way of knowing that the channel they've just obtained (which is still valid) and that they are attempting to lock is about to have its tech_pvt pointer removed. By the time they obtain the channel lock and call the channel technology callback, the tech_pvt is NULL. This patch adds a few checks to some channel callbacks that make sure the tech_pvt isn't NULL before using it. Prime offenders were the DTMF digit callbacks, which would crash if AMI initiated a DTMF on the channel at the same time as a BYE was received from the UA. This patch also adds checks on sip_transfer (as AMI can also cause a callback into this function), as well as sip_indicate (as lots of things can queue an indication onto a channel). Review: https://reviewboard.asterisk.org/r/2434/ (closes issue ASTERISK-20225) Reported by: Jeff Hoppe ........ Merged revisions 385170 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 385173 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385174 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Michael L. Young	03286cf23f	Fix For Not Overriding The Default Settings In chan_sip ... The initial report was that the "nat" setting in the [general] section was not having any effect in overriding the default setting. Upon confirming that this was happening and looking into what was causing this, it was discovered that other default settings would not be overriden as well. This patch works similar to what occurs in build_peer(). We create a temporary ast_flags structure and using a mask, we override the default settings with whatever is set in the [general] section. In the bug report, the reporter who helped to test this patch noted that the directmedia settings were being overriden properly as well as the nat settings. This issue is also present in Asterisk 1.8 and a separate patch will be applied to it. (issue ASTERISK-21225) Reported by: Alexandre Vezina Tested by: Alexandre Vezina, Michael L. Young Patches: asterisk-21225-handle-options-default-prob_v4.diff Michael L. Young (license 5026) Review: https://reviewboard.asterisk.org/r/2385/ ........ Merged revisions 384827 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384828 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	1a2a4578d2	Convert MWI state message type to the new stasis naming convention ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384219 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	72bccf69c3	Address uninitialized conditional that valgrind found ... ........ Merged revisions 384162 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 384163 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384164 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	0ffce56f1b	AST-2013-003: Prevent username disclosure in SIP channel driver ... When authenticating a SIP request with alwaysauthreject enabled, allowguest disabled, and autocreatepeer disabled, Asterisk discloses whether a user exists for INVITE, SUBSCRIBE, and REGISTER transactions in multiple ways. The information is disclosed when: * A "407 Proxy Authentication Required" response is sent instead of a "401 Unauthorized" response * The presence or absence of additional tags occurs at the end of "403 Forbidden" (such as "(Bad Auth)") * A "401 Unauthorized" response is sent instead of "403 Forbidden" response after a retransmission * Retransmission are sent when a matching peer did not exist, but not when a matching peer did exist. This patch resolves these various vectors by ensuring that the responses sent in all scenarios is the same, regardless of the presence of a matching peer. This issue was reported by Walter Doekes, OSSO B.V. A substantial portion of the testing and the solution to this problem was done by Walter as well - a huge thanks to his tireless efforts in finding all the ways in which this setting didn't work, providing automated tests, and working with Kinsey on getting this fixed. (closes issue ASTERISK-21013) Reported by: wdoekes Tested by: wdoekes, kmoore patches: AST-2013-003-1.8 uploaded by kmoore, wdoekes (License 6273, 5674) AST-2013-003-10 uploaded by kmoore, wdoekes (License 6273, 5674) AST-2013-003-11 uploaded by kmoore, wdoekes (License 6273, 5674) ........ Merged revisions 384003 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384019 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	58ee2b7d11	Resolve deadlock between SIP registration and channel based functions ... In r373424, several reentrancy problems in chan_sip were addressed. As a result, the SIP channel driver is now properly locking the channel driver private information in certain operations that it wasn't previously. This exposed two latent problems either in register_verify or by functions called by register_verify. This includes: * Holding the private lock while calling sip_send_mwi_to_peer. This can create a new sip_pvt via sip_alloc, which will obtain the channel container lock. This is a locking inversion, as any channel related lock must be obtained prior to obtaining the SIP channel technology private lock. Note that this issue was already fixed in Asterisk 11. * Holding the private lock while calling sip_poke_peer. In the same vein as sip_send_mwi_to_peer, sip_poke_peer can create a new SIP private, causing the same locking inversion. Note that this locking inversion typically occured when CLI commands were run while a SIP REGISTER request was being processed, as many CLI commands (such as 'sip show channels', 'core show channels', etc.) have to obtain the channel container lock. (issue ASTERISK-21068) Reported by: Nicolas Bouliane (issue ASTERISK-20550) Reported by: David Brillert (issue ASTERISK-21314) Reported by: Badalian Vyacheslav (issue ASTERISK-21296) Reported by: Gabriel Birke ........ Merged revisions 383863 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 383878 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383879 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	99aa02d17f	Transition MWI to Stasis-core ... Remove MWI's dependency on the event system by moving it to Stasis-core. This also introduces forwarding topic pools in Stasis-core which aggregate many dynamically allocated topics into a single primary topic. Review: https://reviewboard.asterisk.org/r/2368/ (closes issue ASTERISK-21097) Patch-by: Kinsey Moore git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383284 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	ad5f3a5759	tcptls: Prevent unsupported options from being set ... AMI, HTTP, and chan_sip all support TLS in some way, but none of them support all the options that Asterisk's TLS core is capable of interpreting. This prevents consumers of the TLS/SSL layer from setting TLS/SSL options that they do not support. This also gets tlsverifyclient closer to a working state by requesting the client certificate when tlsverifyclient is set. Currently, there is no consumer of main/tcptls.c in Asterisk that supports this feature and so it can not be properly tested. Review: https://reviewboard.asterisk.org/r/2370/ Reported-by: John Bigelow Patch-by: Kinsey Moore (closes issue AST-1093) ........ Merged revisions 383165 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 383166 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383167 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	cacc356bbe	When a session timer expires during a T.38 call, re-invite with correct SDP ... When a session timer expires during a dialog that has re-negotiated to T.38 and Asterisk is the refresher, Asterisk will send a re-INVITE with an SDP containing audio media only. This causes some hilarity with the poor fax session under weigh. This patch corrects that by sending T.38 parameters if we are in the middle of a T.38 session. (closes issue ASTERISK-21232) Reported by: Nitesh Bansal patches: dont-send-audio-reinvite-for-sess-timer-in-t38-call.patch uploaded by nbansal (License 6418) ........ Merged revisions 383124 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 383125 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383126 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	00e9ffb907	Include the Username field in SIP Registry events when Status is registered ... In ASTERISK-17888, the AMI Registry event during SIP registrations was supposed to include the Username field. Somehow, one of the events was missed. This patch corrects that - the Username field should be included in all AMI Registry events involving SIP registrations. (issue ASTERISK-17888) (closes issue ASTERISK-21201) Reported by: Dmitriy Serov patches: chan_sip.c.diff uploaded by Dmitriy Serov (license 6479) ........ Merged revisions 382847 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 382848 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382852 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kevin Harwell	09ecb25e08	Added an option to disallow music on hold ... Added an option "discard_remote_hold_retrieval" (default "no") that if set does not trigger the music on hold event. This essentially stops telling the peer to start music on hold. (issue ABE-2899) Reported by: Denis Alberto Martinez Review: https://reviewboard.asterisk.org/r/2336/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382787 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Jonathan Rose	b4a010e958	chan_sip: Update the via header when relaying SMS MESSAGE ... Prior to this change, certain conditions for sending the message would result in an address of '(null)' being used in the via header of the SIP message because a NULl value of pvt->ourip was used when initially generating the via header. This is fixed by adding a call to build_via when the address is set before sending the message. (closes issue ASTERISK-21148) Reported by: Zhi Cheng Patches: 700-sip_msg_send_via_fix.patch uploaded by Zhi Cheng (license 6475) ........ Merged revisions 382739 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382746 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	f6f6bc7b59	Remove unused function ... After r382670, get_ip_and_port_from_sdp was no longer used. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382671 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	12748bc735	Don't reset the RTP address on a glare re-INVITE ... Originally, way back in r201583, we added the alternate RTP address so that the RTP engine would expect to receive audio from a new source when a glare re-INVITE occurred. In r382589, we remove the alternate RTP source, as the 'secret' probation mode allows for switching to a new RTP source when a previous source stops sending RTP. At the time, it seemed appropriate to set the RTP source based on the information in the glared re-INVITE. Unfortunately, that doesn't work so well - in a glared re-INVITE that occurs with no SDP - such as in a connected line update that glances - we'll set the RTP source to an invalid address. In subsequent re-INVITE requests from this Asterisk instance, we'll then send an invalid media address, which will result in the remote side sending a 488. Whoops. There isn't any need to reset the RTP source - if we're using strictrtp, we'll simply synchronize to a new source when we stop getting packets from the old one. If we aren't using strictrtp, then again there shouldn't be a problem. Note that the Asterisk Test Suite's connectedline test caught this error. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382670 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	80b8c2349c	Add a 'secret' probation strictrtp mode to handle delayed changes in RTP source ... Often, Asterisk may realize that a change in the source of an RTP stream is about to occur and ask that the RTP engine reset it's lock on the current RTP source. In certain scenarios, it may take awhile for the new remote system to send RTP packets, while the old remote system may continue providing RTP during that time period. This causes Asterisk to re-lock onto the old source, thereby rejecting the new source when the old source stops sending RTP and the new source begins. This patch prevents that by having a constant secondary, 'secret' probation mode enabled when an RTP source has been chosen. RTP packets from other sources are always considered, but never chosen unless the current RTP source stops sending RTP. Review: https://reviewboard.asterisk.org/r/2364 (closes issue AST-1124) Reported by: John Bigelow Tested by: John Bigelow (closes issue AST-1125) Reported by: John Bigelow Tested by: John Bigelow ........ Merged revisions 382573 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382589 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	8d5c36c9bb	Add RFC 3327 Path header support to chan_sip ... This patch adds support for RFC 3327 "Path" headers. This can be enabled in sip.conf using the 'supportpath' setting, either on a global basis or on a peer basis. This setting enables Asterisk to route outgoing out-of-dialog requests via a set of proxies by using a pre-loaded route-set defined by the Path headers in the REGISTER request. This patch also adds Realtime support for dynamically updating the Path information for a peer. A huge thank-you to Klaus Darillion and Olle E Johansson for their efforts in writing this patch. Review: https://reviewboard.asterisk.org/r/2235/ Review: https://reviewboard.asterisk.org/r/991/ (closes issue ASTERISK-16884) Reported by: klaus3000 Tested by: klaus3000, oej, mjordan patches: path-1.8.0-patch.txt uploaded by klaus3000 (License 5054) oolong-path-support-trunk in team branch by oej (License 5267) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382440 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Michael L. Young	a3ad8b28e6	Fix / Clean Up Some Items To Handle The New auto_* NAT Options ... The original report had to do with a realtime peer behind NAT being pruned and the peer's private address being used instead of its external address. Upon debugging, it was discovered that this was being caused by the addition of the auto_force_rport and auto_comedia settings. This patch does the following: * Adds a missing note to the CHANGES file indicating that the default global nat setting is auto_force_rport * Constify the 'req' parameter for check_via() * Add calls to check_via() in a couple of places in order for the auto_* settings to do their job in attempting to determine if NAT is involved * Set the flags SIP_NAT_FORCE_RPORT and SIP_PAGE2_SYMMETRICRTP if the auto_* settings are in use where it was needed * Moves the copying of peer flags up in build_peer() to before they are used; this fixes the realtime prune issue * Update the contrib/realtime schemas to allow the nat column to handle the different nat setting combinations we have This patch received a review and "Ship It!" on the issue itself. (closes issue ASTERISK-20904) Reported by: JoshE Tested by: JoshE, Michael L. Young Patches: asterisk-20904-nat-auto-and-rt-peersv2.diff Michael L. Young (license 5026) ........ Merged revisions 382322 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382323 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Joshua Colp	e0b49e7331	Relax dialog checking in get_sip_pvt_byid_locked so it works when the dialog is forked. ... (closes issue ASTERISK-20638) Reported by: eelcob Patches: pedantic-call-pickup-from-tag.patch uploaded by eelcob (license 6442) ........ Merged revisions 382171 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 382174 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382182 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Walter Doekes	d33d9c1781	Correct RPID parsing for unquoted display-name. ... Parsing Remote-Party-ID will now succeed if display-name is of the *(token LWS) kind and not just the quoted-string kind. Review: https://reviewboard.asterisk.org/r/2341/ ........ Merged revisions 382107 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 382108 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382109 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	2ebb9863ea	Don't send presencestate information if the state is invalid ... Previously, presencestate information was sent whenever the state was not NOT_SET. When r381594 actually returned INVALID presence state in all the places it was supposed to, it caused chan_sip to start adding presence state information to NOTIFY requests that it previously would not have added. chan_sip shouldn't be adding presence state information when the provider is in an invalid state; users can't set the state to invalid and an invalid state always implies that the provider is in an error condition. (issue AST-1084) ........ Merged revisions 381613 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@381615 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Mark Michelson	8a7dd2f408	Fix a crash that occurred when a BYE was received on a replaced dialog. ... Reference counting for the channel and its tech_pvt got messed up at some point between 1.8 and 11. The result was that if a BYE for a dialog that had been replaced (via an INVITE with Replaces) was received, Asterisk would crash due to trying to access data on a channel that was no longer there. The fix I introduced is to remove code that both unrefs the sip_pvt and sets the channel's tech_pvt to NULL when an INVITE with Replaces is handled. This way when a BYE is received, the tech_pvt will be non-NULL and so the BYE can be processed and not cause a crash. (closes issue ASTERISK-20929) reported by Kristopher Lalletti patches: ASTERISK-20929.patch uploaded by Mark Michelson (License #5049) ........ Merged revisions 381566 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@381568 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Jonathan Rose	f008baddac	chan_sip: Use video and text crypto attributes to append RTP profiles to SDP ... Some bad copy/pasting resulted in using the audio crypto attribute for both text and video RTP. Also the audio crypto isn't set until after these, so it was really just bad all around. (closes ASTERISK-20905) Reported by: Kristopher Lalletti patches: rtp_crypto_video_text.diff uploaded by Jonathan Rose (license 6182) ........ Merged revisions 381553 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@381556 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	81fa307af7	Fix some more REF_DEBUG-related build errors ... When sip_ref_peer and sip_unref_peer were exported to be usable in channels/sip/security_events.c, modifications to those functions when building under REF_DEBUG were not taken into account. This change moves the necessary defines into sip.h to make them accessible to other parts of chan_sip that need them. ........ Merged revisions 381282 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@381285 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	5b236ee647	Make ast_do_masquerade() a void function. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@381086 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
David M. Lee	345253a50e	Fixed failing test from r380696. ... When I added my extensive suite of session timer unit tests, apparently one of them was failing and I never noticed. If neither Min-SE nor Session-Expires is set in the header, it was responding with a Session-Expires of the global maxmimum instead of the configured max for the endpoint. (issue ASTERISK-20787) ........ Merged revisions 380973 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 380974 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@380977 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
David M. Lee	5899e13112	Process session timers, even if Session-Expires header is missing ... Previously, Asterisk only processed session timer information if both the 'Supported: timer' and 'Session-Expires' headers were present. However, the Session-Expires header is optional. If we were to receive a request with a Min-SE greater than our configured session-expires, we would respond with a 'Session-Expires' header that was too small. This patch cleans the situation up a bit, always processing timer information if the 'Supported: timer' header is present. (closes issue ASTERISK-20787) Reported by: Mark Michelson Review: https://reviewboard.asterisk.org/r/2299/ ........ Merged revisions 380696 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 380698 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@380699 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	01309cf41e	Unregister SIP provider API if module load is declined ... A user in #asterisk ran into a problem where a configuration error prevented the chan_sip module from being loaded. Upon fixing their configuratione error, they could no longer load the chan_sip module. This was because the configuration checking happened after the SIP provider was registered with the Asterisk core, and subsequent attempts to load the SIP module failed as the provider was already registered. Since we want to detect any failure in registering chan_sip as early as possible (as that could be emblematic of a deeper mismatch between module and Asterisk core), this patch does not change the registration location, but does ensure that if a module load is declined, we unregister the module as the SIP api provider. ........ Merged revisions 380480 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@380500 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	8018bdd8e1	Perform case insensitive comparisons for T.38 attributes ... RFC5347 section 2.5.2 states the following: ... The attribute "T38MaxBitRate" was once incorrectly registered with IANA as "T38maxBitRate" (lower-case "m"). In accordance with T.38 examples and common implementation practice, the form "T38MaxBitRate" SHOULD be generated by implementations conforming to this package. In general, it is RECOMMENDED that implementations of this package accept lowercase, uppercase, and mixed upper/lowercase encodings of all the T.38 attributes. ... Asterisk currently does not perform case insensitive matching on the T.38 attributes. This causes the T38MaxBitRate attribute to be negotiated at 2400 baud instead of 14400 (or whatever value you actually wanted). This patch makes it so that when we compare T.38 attributes, we do so in a case insensitive fashion. Note that while the issue reporter did not directly write the patch, they contributed to it (and would have provided one themselves if the license had gone through a tad faster), and hence get attribution for it. Review: https://reviewboard.asterisk.org/r/2298/ (closes issue ASTERISK-20897) Reported by: Eric Hill Tested by: Eric Hill patches: -- uploaded by Eric Hill ........ Merged revisions 380458 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 380465 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@380479 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	126060042e	Ensure that a declined media stream is terminated with a '\r\n' ... In r369028, chan_sip's processing of media streams in an SDP was modified to better handle multiple offered media streams. Part of that change modified how streams were declined. Previously, declined media streams were not handled in an RFC compliant manner; now, we set the port number to 0 in the media stream definition and proceed on with the next media stream. Unfortunately, the formatting of the declined media stream forgot to append a '\r\n' to the end of the media stream. This is normally added to the accepted media streams later on in the processing of the SDP. Since the declined media stream uses a different buffer than the accepted media streams (and is a malloc'd buffer as opposed to a struct ast_str), it's easier to just slap the '\r\n' on the declined media stream buffer rather than attempt to append it later on. So, that's what we do. And now some devices (and probably some providers) will be a bit happier (but probably not terribly happy, since we just rejected something they offered). Review: https://reviewboard.asterisk.org/r/2297/ (closes issue ASTERISK-20908) Reported by: Dennis DeDonatis Tested by: Dennis DeDonatis ........ Merged revisions 380331 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@380332 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
David M. Lee	be727bf0d2	Fix Record-Route parsing for large headers. ... Record-Route parsing copied the header into a char[256] array, which can be a problem if the header is longer than that. This patch parses the header in place, without the copy, avoiding the issue. In addition to the original patch, I added a unit test for the new get_in_brackets_const function. (closes issue ASTERISK-20837) Reported by: Corey Farrell Patches: chan_sip-build_route-optimized-rev1.patch uploaded by Corey Farrell (license 5909) (with minor changes by dlee) ........ Merged revisions 379392 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 379393 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@379394 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
David M. Lee	a91a289154	Fix XML encoding of 'identity display' in NOTIFY messages, continued. ... When r378933 was merged into 1.8, it should have also escaped remote_display, since it will have the same XML encoding problem when the caller/callee roles are reversed. (closes issue ABE-2902) Reported by: Guenther Kelleter ........ Merged revisions 379001 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 379020 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@379021 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
David M. Lee	aecd2429bd	Fix XML encoding of 'identity display' in NOTIFY messages. ... XML encoding in chan_sip is accomplished by naively building the XML directly from strings. While this usually works, it fails to take into account escaping the reserved characters in XML. This patch adds an 'ast_xml_escape' function, which works similarly to 'ast_uri_encode'. This is used to properly escape the local_display attribute in XML formatted NOTIFY messages. Several things to note: * The Right Thing(TM) to do would probably be to replace the ast_build_string stuff with building an ast_xml_doc. That's a much bigger change, and out of scope for the original ticket, so I refrained myself. * It is with great sadness that I wrote my own ast_xml_escape function. There's one in libxml2, but it's knee-deep in libxml2-ness, and not easily used to one-off escape a string. * I only escaped the string we know is causing problems (local_display). At least some of the other strings are URI-encoded, which should be XML safe. Rather than figuring out what's safe and escaping what's not, it would be much cleaner to simply build an ast_xml_doc for the messages and let the XML library do the XML escaping. Like I said, that's out of scope. (closes issue ABE-2902) Reported by: Guenther Kelleter Tested by: Guenther Kelleter Review: http://reviewboard.digium.internal/r/365/ ........ Merged revision 378919 from https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier ........ Merged revisions 378933 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 378934 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378935 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Michael L. Young	209373262d	Fix SIP Notify Messages To Have The Proper IP Address In The FROM Field ... On a multihomed server when sending a NOTIFY message, we were not figuring out which network should be used to contact the peer. This patch fixes the problem by calling ast_sip_ouraddrfor() and then build_via() so that our NOTIFY message contains the correct IP address. Also, a debug message is being added to help follow the call-id changes that occur. This was helpful for confirming that the IP address was set properly since the call-id contains the IP address. It also will be helpful for troubleshooting purposes when following a call in the debug logs. (closes issue ASTERISK-20805) Reported by: Bryan Hunt Tested by: Bryan Hunt, Michael L. Young Patches: asterisk-20805-notify-ip-v2.diff uploaded by Michael L. Young (license 5026) Review: https://reviewboard.asterisk.org/r/2255/ ........ Merged revisions 378554 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 378559 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378565 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	8fb5bdce9a	Prevent exhaustion of system resources through exploitation of event cache ... Asterisk maintains an internal cache for devices in the event subsystem. The device state cache holds the state of each device known to Asterisk, such that consumers of device state information can query for the last known state for a particular device, even if it is not part of an active call. The concept of a device in Asterisk can include entities that do not have a physical representation. One way that this occurred was when anonymous calls are allowed in Asterisk. A device was automatically created and stored in the cache for each anonymous call that occurred; this was possible in the SIP and IAX2 channel drivers and through channel drivers that utilized the res_jabber/res_xmpp resource modules (Gtalk, Jingle, and Motif). These devices are never removed from the system, allowing anonymous calls to potentially exhaust a system's resources. This patch changes the event cache subsystem and device state management to no longer cache devices that are not associated with a physical entity. (issue ASTERISK-20175) Reported by: Russell Bryant, Leif Madsen, Joshua Colp Tested by: kmoore patches: event-cachability-3.diff uploaded by jcolp (license 5000) ........ Merged revisions 378303 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 378320 from http://svn.asterisk.org/svn/asterisk/branches/10 ........ Merged revisions 378321 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378322 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	1fb06fde95	Resolve crashes due to large stack allocations when using TCP ... Asterisk had several places where messages received over various network transports may be copied in a single stack allocation. In the case of TCP, since multiple packets in a stream may be concatenated together, this can lead to large allocations that overflow the stack. This patch modifies those portions of Asterisk using TCP to either favor heap allocations or use an upper bound to ensure that the stack will not overflow: * For SIP, the allocation now has an upper limit * For HTTP, the allocation is now a heap allocation instead of a stack allocation * For XMPP (in res_jabber), the allocation has been eliminated since it was unnecesary. Note that the HTTP portion of this issue was independently found by Brandon Edwards of Exodus Intelligence. (issue ASTERISK-20658) Reported by: wdoekes, Brandon Edwards Tested by: mmichelson, wdoekes patches: ASTERISK-20658_res_jabber.c.patch uploaded by mmichelson (license 5049) issueA20658_http_postvars_use_malloc2.patch uploaded by wdoekes (license 5674) issueA20658_limit_sip_packet_size3.patch uploaded by wdoekes (license 5674) ........ Merged revisions 378269 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 378286 from http://svn.asterisk.org/svn/asterisk/branches/10 ........ Merged revisions 378287 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378288 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	32472eca70	Ensure chan_sip rejects encrypted streams without crypto info ... This ensures that Asterisk rejects encrypted media streams (RTP/SAVP audio and video) that are missing cryptographic keys and ensures that the incoming SDP is consistent with RFC4568 as far as having a crypto attribute present for any SAVP streams. Review: https://reviewboard.asterisk.org/r/2204/ ........ Merged revisions 378217 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 378218 from http://svn.asterisk.org/svn/asterisk/branches/10 ........ Merged revisions 378219 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378220 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Brent Eagles	ab894d5af9	This change adds a SIP peer configuration feature to allow the peer's ... configured codecs to take precedence on an outgoing call. This change introduces a new peer configuration property named 'ignore_requested_pref' that causes the requested codec to be ignored when determining the preferred codec for an outgoing call leg. The consequence is that Asterisk's usual efforts to prefer avoiding transcoding can be overridden on a peer-by-peer basis where appropriate. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@377971 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	4f6064584d	Ensure Min-SE is included in outbound INVITEs ... Asterisk now includes Min-SE in outbound INVITEs when the value is not 90 (the default) and session timers are not disabled. This has the effect of Asterisk following RFC4028 more closely with regard to 422 responses and preventing situations in which Asterisk would be forced to temporarily accept a call to tear it down based on a Session-Expires below the locally configured Min-SE. (issue SWP-5051) Review: https://reviewboard.asterisk.org/r/2222/ Reported-by: Kinsey Moore Patch-by: Kinsey Moore ........ Merged revisions 377946 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 377947 from http://svn.asterisk.org/svn/asterisk/branches/10 ........ Merged revisions 377948 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@377966 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Mark Michelson	607a5d898c	Fix a potential deadlock in chan_sip during transfers. ... The issue comes from the fact that transfers may perform a redirecting update on a channel. The issue is that lock inversion between the channel and its tech_pvt occurs since the channel lock is released during the transfer process. The fix is to move when the redirecting update occurs to a place where neither the tech_pvt or the channel is locked so that the two can be locked in the proper order. (closes issue ASTERISK-20708) reported by Mark Michelson patches: ASTERISK-20708-3.patch uploaded by Mark Michelson (License #5049) Tested by: Tim Ringenbach at Asteria Solutions Group ........ Merged revisions 377910 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@377911 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	1c1faa1380	Handle Session-Expires less than local Min-SE in 200 OK ... Ensure that a call is immediately torn down if a Session-Expires value received in a 200 OK is less than the local Min-SE. This also prevents Asterisk from allowing calls with Session-Expires below the RFC4028-mandated minimum (90s). (closes issue ASTERISK-20653) Review: https://reviewboard.asterisk.org/r/2237/ Patch-by: Kinsey Moore ........ Merged revisions 377623 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 377624 from http://svn.asterisk.org/svn/asterisk/branches/10 ........ Merged revisions 377625 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@377626 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Joshua Colp	b206511914	Fix a SIP request memory leak with TLS connections. ... During the TLS re-work in chan_sip some TLS specific code was moved into a separate function. This function operates on a copy of the incoming SIP request. This copy was never deinitialized causing a memory leak for each request processed. This function is now given a SIP request structure which it can use to copy the incoming request into. This reduces the amount of memory allocations done since the internal allocated components are reused between packets and also ensures the SIP request structure is deinitialized when the TLS connection is torn down. (closes issue ASTERISK-20763) Reported by: deti ........ Merged revisions 377257 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 377258 from http://svn.asterisk.org/svn/asterisk/branches/10 ........ Merged revisions 377259 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@377260 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Olle Johansson	712aaa9828	Move functions to AFTER the block of forward declarations of functions. ... It was a mess. The first part of chan_sip.c is constants, declarations, structures and stuff, then forward declarations and then actual code. It's still a mess, but a bit less messy ;-) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@377018 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Olle Johansson	1b47dbe991	Formatting changes ... Found a large amount of missing {} in the code before patching in another branch git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@376998 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago