2648 Commits (88f1d1476628c40a72a64a0ead06c389e198d682)

Author	SHA1	Message	Date
Mark Michelson	88f1d14766	Merged revisions 208386 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r208386 | mmichelson | 2009-07-23 14:24:21 -0500 (Thu, 23 Jul 2009) | 17 lines Fix a problem where a 491 response could be sent out of dialog. This generalizes the fix for issue 13849. The initial fix corrected the problem that Asterisk would reply with a 491 if a reinvite were received from an endpoint and we had not yet received an ACK from that endpoint for the initial INVITE it had sent us. This expansion also allows Asterisk to appropriately handle an INVITE with authorization credentials if Asterisk had not received an ACK from the previous transaction in which Asterisk had responded to an unauthorized INVITE with a 407. (closes issue #14239) Reported by: klaus3000 Patches: 14239.patch uploaded by mmichelson (license 60) Tested by: klaus3000 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208388 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	bacf6ab51e	Merged revisions 208312 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r208312 | mmichelson | 2009-07-23 11:29:18 -0500 (Thu, 23 Jul 2009) | 3 lines Remove inaccurate XXX comment. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208314 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	98b4bdc1b9	Merged revisions 208262 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r208262 | mmichelson | 2009-07-23 10:43:07 -0500 (Thu, 23 Jul 2009) | 8 lines Properly handle 183 responses which do not contain an SDP. (closes issue #15442) Reported by: ffloimair Patches: 15442.patch uploaded by mmichelson (license 60) Tested by: tkarl, ffloimair ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208263 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	3843480b8f	Fix potential crash if p->owner is NULL. ... Problem was observed when a call-forwarding loop was accidentally configured. ABE-1906 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208229 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	3f8059f87d	reg->username is parsed only once on sip reload ... The registration string can contain an expanded user portion of the form user@domain. This expanded user portion was stored in reg->username and parsed each time there is a registration refresh. Now, the domain portion of the user is parsed and stored separately in the regdomain field. (closes issue #14331) Reported by: Nick_Lewis Patches: chan_sip.c.domainparse3.patch uploaded by Nick (license 657) Tested by: Nick_Lewis, dvossel git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@207484 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	bec894cbe5	Merged revisions 207423 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r207423 | mmichelson | 2009-07-20 14:39:59 -0500 (Mon, 20 Jul 2009) | 33 lines Answer video SDP offers properly when videosupport is not enabled. Copied from Review board: In issue 12434, the reporter describes a situation in which audio and video is offered on the call, but because videosupport is disabled in sip.conf, Asterisk gives no response at all to the video offer. According to RFC 3264, all media offers should have a corresponding answer. For offers we do not intend to actually reply to with meaningful values, we should still reply with the port for the media stream set to 0. In this patch, we take note of what types of media have been offered and save the information on the sip_pvt. The SDP in the response will take into account whether media was offered. If we are not otherwise going to answer a media offer, we will insert an appropriate m= line with the port set to 0. It is important to note that this patch is pretty much a bandage being applied to a broken bone. The patch *only* helps for situations where video is offered but videosupport is disabled and when udptl_pt is disabled but T.38 is offered. Asterisk is not guaranteed to respond to every media offer. Notable cases are when multiple streams of the same type are offered. The 2 media stream limit is still present with this patch, too. In trunk and the 1.6.X branches, things will be a bit different since Asterisk also supports text in SDPs as well. (closes issue #12434) Reported by: mnnojd Review: https://reviewboard.asterisk.org/r/311 Review: https://reviewboard.asterisk.org/r/313 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@207424 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	65388d4e21	sip option flags handled incorrectly ... (closes issue #15376) Reported by: Takehiko Ooshima Tested by: dvossel, Takehiko_Ooshima git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@207029 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	0ce3fa1c22	Merged revisions 206938 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r206938 | dvossel | 2009-07-17 11:05:06 -0500 (Fri, 17 Jul 2009) | 14 lines SIP incorrect From: header information when callpres is prohib Some ITSP make use of the "Anonymous" display name to detect a requirement to withhold caller id across the PSTN. This does not work if the display name is "Unknown". (closes issue #14465) Reported by: Nick_Lewis Patches: chan_sip.c-callerpres.patch uploaded by Nick (license 657) chan_sip.c-callerpres_trunk.patch uploaded by dvossel (license 671) Tested by: Nick_Lewis, dvossel ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@206939 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	f91bc197cd	Session timer were not activated if Supported header field in INVITE had both "timer" and other options. ... (closes issue #15403) Reported by: makoto Patches: sip-session-timer.patch uploaded by makoto (license 38) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@206768 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	3402f34e9b	callerid(num) is wrong when username is missing ... A domain only sip uri <sip:123.123.123.123> would return 123.123.123.123 as callid num. Now, if the username is missing from a uri, the callerid num field is left empty. (closes issue #15476) Reported by: viraptor git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@206702 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	6891ccad28	dns lookup of peername rather than peer's host in transmit_register() ... (closes issue #15052) Reported by: fsantulli Patches: chan_sip_bug_15052_[20090626204511].patch uploaded by fsantulli (license 818) Tested by: fsantulli git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@206280 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	c01286976a	SIP register not using peer's outbound proxy ... If callbackextension is defined for a peer it successfully causes a registration to occur, but the registration ignores the outboundproxy settings for the peer. This patch allows the peer to be passed to obproxy_get() in transmit_register(). (closes issue #14344) Reported by: Nick_Lewis Patches: callbackextension_peer_trunk.diff uploaded by dvossel (license 671) Tested by: dvossel Review: https://reviewboard.asterisk.org/r/294/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205985 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	5aab96f0b7	Merged revisions 205877 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ................ r205877 | mmichelson | 2009-07-10 12:39:13 -0500 (Fri, 10 Jul 2009) | 23 lines Merged revisions 205776 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r205776 | mmichelson | 2009-07-10 10:56:45 -0500 (Fri, 10 Jul 2009) | 16 lines Merged revisions 205775 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r205775 | mmichelson | 2009-07-10 10:51:36 -0500 (Fri, 10 Jul 2009) | 10 lines Ensure that outbound NOTIFY requests are properly routed through stateful proxies. With this change, we make note of Record-Route headers present in any SUBSCRIBE request that we receive so that our outbound NOTIFY requests will have the proper Route headers in them. (closes issue #14725) Reported by: ibc ........ ................ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205878 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	fe493cf85e	Merged revisions 205804 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r205804 | dvossel | 2009-07-10 11:23:59 -0500 (Fri, 10 Jul 2009) | 31 lines SIP registration auth loop caused by stale nonce If an endpoint sends two registration requests in a very short period of time with the same nonce, both receive 401 responses from Asterisk, each with a different nonce (the second 401 containing the current nonce and the first one being stale). If the endpoint responds to the first 401, it does not match the current nonce so Asterisk sends a third 401 with a newly generated nonce (which updates the current nonce)... Now if the endpoint responds to the second 401, it does not match the current nonce either and Asterisk sends a fourth 401 with a newly generated nonce... This loop goes on and on. There appears to be a simple fix for this. If the nonce from the request does not match our nonce, but is a good response to a previous nonce, instead of sending a 401 with a newly generated nonce, use the current one instead. This breaks the loop as the nonce is not updated until a response is received. Additional logic has been added to make sure no nonce can be responded to twice though. (closes issue #15102) Reported by: Jamuel Patches: patch-bug_0015102 uploaded by Jamuel (license 809) nonce_sip.diff uploaded by dvossel (license 671) Tested by: Jamuel Review: https://reviewboard.asterisk.org/r/289/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205840 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	aafa57cf4b	Merged revisions 205775 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r205775 | mmichelson | 2009-07-10 10:51:36 -0500 (Fri, 10 Jul 2009) | 10 lines Ensure that outbound NOTIFY requests are properly routed through stateful proxies. With this change, we make note of Record-Route headers present in any SUBSCRIBE request that we receive so that our outbound NOTIFY requests will have the proper Route headers in them. (closes issue #14725) Reported by: ibc ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205776 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Kevin P. Fleming	67d1957e60	Repair ability of SendFAX/ReceiveFAX to respond to T.38 switchover. ... Recent changes in T.38 negotiation in Asterisk caused these applications to not respond when the other endpoint initiated a switchover to T.38; this resulted in the T.38 switchover failing, and the FAX attempt to be made using an audio connection, instead of T.38 (which would usually cause the FAX to fail completely). This patch corrects this problem, and the applications will now correctly respond to the T.38 switchover request. In addition, the response will include the appopriate T.38 session parameters based on what the other end offered and what our end is capable of. (closes issue #14849) Reported by: afosorio git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205696 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Tilghman Lesher	e76a0e92d2	Permit setting custom headers from the peer definition. ... (closes issue #14059) Reported by: fnordian git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205086 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	320c8d27b9	Move the masquerade in local_attended_transfer to a point where we hold the channel lock. ... Masquerading without the channel's lock held is a *horrible* idea. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204532 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	ab2b9bd16d	Remove some bogus deadlock avoidance code from local_attended_transfer. ... First of all, the code was unnecessary. The goal was to lock a channel which was already locked. Second, the assumption of the deadlock avoidance loop was that the sip_pvt was already locked and we were trying to get the channel lock. The problem is that the sip_pvt was unlocked a few lines above. Basically, I'm removing 5 lines of no-op. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204530 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	a4dc276ed9	Merged revisions 204300 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r204300 | mmichelson | 2009-06-29 17:45:34 -0500 (Mon, 29 Jun 2009) | 9 lines Add error message so that it is clear why a SIP peer was not processed when a DNS lookup fails on a host or outboundproxy. (closes issue #13432) Reported by: p_lindheimer Patches: outboundproxy.patch uploaded by p (license 558) ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204301 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	200f1dc19e	Merged revisions 204243,204246 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r204243 | mmichelson | 2009-06-29 16:23:43 -0500 (Mon, 29 Jun 2009) | 22 lines Fix a problem where chan_sip would ignore "old" but valid responses. chan_sip has had a problem for quite a long time that would manifest when Asterisk would send multiple SIP responses on the same dialog before receiving a response. The problem occurred because chan_sip only kept track of the highest outgoing sequence number used on the dialog. If Asterisk sent two requests out, and a response arrived for the first request sent, then Asterisk would ignore the response. The result was that Asterisk would continue retransmitting the requests and ignoring the responses until the maximum number of retransmissions had been reached. The fix here is to rearrange the code a bit so that instead of simply comparing the sequence number of the response to our latest outgoing sequence number, we walk our list of outstanding packets and determine if there is a match. If there is, we continue. If not, then we ignore the response. In doing this, I found a few completely useless variables that I have now removed. (closes issue #11231) Reported by: flefoll Review: https://reviewboard.asterisk.org/r/298 ........ r204246 | mmichelson | 2009-06-29 16:37:05 -0500 (Mon, 29 Jun 2009) | 3 lines Fix build oops. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204247 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Russell Bryant	92f0cdfce7	Ensure the TCP read buffer is fully initialized before handling each packet. ... (closes issue #14452) Reported by: umberto71 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203779 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Joshua Colp	48f7381af0	Fix the 'nat' option to actually do RFC3581 as expected and extend the configurable values for finer control. ... (closes issue #8855) Reported by: mikma Tested by: klaus3000, file git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203735 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Joshua Colp	59c1998d67	Improve T.38 negotiation by exchanging session parameters between application and channel. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203699 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Russell Bryant	0264eef115	Merge the new Channel Event Logging (CEL) subsystem. ... CEL is the new system for logging channel events. This was inspired after facing many problems trying to represent what is possible to happen to a call in Asterisk using CDR records. For more information on CEL, see the built in HTML or PDF documentation generated from the files in doc/tex/. Many thanks to Steve Murphy (murf) and Brian Degenhardt (bmd) for their hard work developing this code. Also, thanks to Matt Nicholson (mnicholson) and Sean Bright (seanbright) for their assistance in the final push to get this code ready for Asterisk trunk. Review: https://reviewboard.asterisk.org/r/239/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203638 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Russell Bryant	c6a986222e	Merged revisions 203115 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r203115 | russell | 2009-06-25 11:02:16 -0500 (Thu, 25 Jun 2009) | 11 lines Resolve a crash related to a T.38 reinvite race condition. This change resolves a crash observed locally during some T.38 testing. A call was set up using a call file, and when the T.38 reinvite came in, the channel state was still AST_STATE_DOWN. The reason is explained by a comment in the code that previously lived in the handling of AST_STATE_RINGING. This change modifies the logic to handle the same race condition for any channel state that is not UP. (closes ABE-1895) ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203116 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	0a915a84e6	Merged revisions 202966 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r202966 | mmichelson | 2009-06-24 13:28:47 -0500 (Wed, 24 Jun 2009) | 3 lines Use the handy UNLINK macro instead of hand-coding the same thing in-line. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@202967 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Joshua Colp	4c07c7a6b2	Ensure the default settings are applied for T.38 when we set it up for a peer. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@202925 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	5f73ab9f4e	Merged revisions 202671 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r202671 | dvossel | 2009-06-23 11:28:46 -0500 (Tue, 23 Jun 2009) | 12 lines MWI NOTIFY contains a wrong URI if Asterisk listens to non-standard port and transport (closes issue #14659) Reported by: klaus3000 Patches: patch_chan_sip_fixMWIuri_1.4.txt uploaded by klaus3000 (license 65) mwi_port-transport_trunk.diff uploaded by dvossel (license 671) Tested by: dvossel, klaus3000 Review: https://reviewboard.asterisk.org/r/288/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@202672 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Russell Bryant	e2bfdbac0a	Merged revisions 202414 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r202414 | russell | 2009-06-22 11:00:00 -0500 (Mon, 22 Jun 2009) | 2 lines Make Polycom subscription type override check more explicit. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@202415 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	f142cbe10c	Merged revisions 202341-202342 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r202341 | mmichelson | 2009-06-22 09:42:55 -0500 (Mon, 22 Jun 2009) | 26 lines Fix a situation in which Asterisk would not stop retransmitting 487s. If a CANCEL were received by Asterisk, we would send a 487 in response to the original INVITE and a 200 OK for the CANCEL. If there were a network hiccup which caused the 200 OK and the 487 to be lost, then the UA communicating with Asterisk may try to retransmit its CANCEL. Asterisk's response to this used to be to try sending another 487 to the canceled INVITE and another 200 OK to the CANCEL. The problem here is that the originally-sent 487 was sent "reliably" meaning that it will be retransmitted until it is received properly. So when we receive the second CANCEL it is likely that the first batch of 487s we sent is still going strong and reaches the UA. The result was that the second set of 487s would be retransmitted constantly until the maximum number of retries had been reached. The fix for this is that if we receive a second CANCEL for an INVITE, then we cancel the retransmission of the first set of 487s and start a second set. This causes the dialog to be terminated reasonably. (closes issue #14584) Reported by: klaus3000 Patches: 14584_v2.patch uploaded by mmichelson (license 60) Tested by: klaus3000 ........ r202342 | mmichelson | 2009-06-22 09:44:58 -0500 (Mon, 22 Jun 2009) | 3 lines Remove an extra debug line left from previous commit. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@202343 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	e68e6f9d75	Merged revisions 202336 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r202336 | mmichelson | 2009-06-22 09:34:05 -0500 (Mon, 22 Jun 2009) | 25 lines Fix a possible infinite loop in SDP parsing during glare situation. There was a while loop in get_ip_and_port_from_sdp which was controlled by a call to get_sdp_iterate. The loop would exit either if what we were searching for was found or if the return was NULL. The problem is that get_sdp_iterate never returns NULL. This means that if what we were searching for was not present, the loop would run infinitely. This modification of the loop fixes the problem. (closes issue #15213) Reported by: schmidts (closes issue #15349) Reported by: samy (closes issue #14464) Reported by: pj (closes issue #15345) Reported by: aragon Patches: sip_inf_loop.patch uploaded by mmichelson (license 60) Tested by: aragon ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@202337 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Matthew Nicholson	55c6789f74	Use sched_yield() instead of usleep(1) ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@202039 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Joshua Colp	e85296e244	Add support for allowing an RTP engine to decide on whether it is possible for specific formats to be transcoded for an RTP instance. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@201902 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Matthew Nicholson	21ad428d0d	Added deadlock protection to try_suggested_sip_codec in chan_sip.c. ... Review: https://reviewboard.asterisk.org/r/285/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@201717 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	dce6a54a4a	Trunk implementation of setting an alternate RTP source. ... This contains the interface by which we can let an rtp instance know that it might start receiving audio from a new source. This is similar in nature to revision 197588 of Asterisk 1.4. Review: https://reviewboard.asterisk.org/r/276 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@201583 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	a11ac5ae2f	parsing extension correctly from sip register lines ... If a transport type was specified, but no extension, parsing of the extension would return whatever was after the transport rather than defaulting to 's'. (closes issue #15111) Reported by: ffs Patches: chan_sip.c_register-parser.patch uploaded by ffs (license 730) Tested by: ffs, dvossel git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@201570 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	99b98d8f9a	Fix problem with no audio due to ignoring the SDP. ... A recent change to our SDP version comparison made audio not function on some calls. This was because of a test wherein we were trying to see if an unsigned value was less than 0. This is a dumb comparison and arguably the compiler should have warned about it. Alas, though, it slipped past. Now it's fixed by changing the variable to be a signed type. Found by several developers. Tested by mnicholson and dbrooks. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@201462 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Brooks	ecfbab0782	Merged revisions 201380 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r201380 | dbrooks | 2009-06-17 13:45:50 -0500 (Wed, 17 Jun 2009) | 9 lines Checks for NULL sip_pvt pointer in chan_sip.c->acf_channel_read() Zombie channels could be passed, and chan_sip.c wasn't checking for it. Could crash Asterisk. Now checking for NULL pointer. (closes issue #15330) Reported by: okrief Tested by: dbrooks ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@201381 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	9bf67151c9	SIP registry ref count error ... During a sip reload, the list of sip_registry objects are supposed to be traversed, unlinked, and destroyed, but destruction never takes place due to a ref counting error. This causes a memory leak when registry items are removed from sip.conf and reloaded. While the registries are removed from the global list, they are not removed from the scheduler. Because of this, SIP register attempts continue to be sent out for the item even though it may no longer be in the .conf. (closes issue #15295) Reported by: amorsen Review: https://reviewboard.asterisk.org/r/282/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@201344 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	9a66b1dcdf	fix issue with build_contact introduced by the "SIP trasnport type issues" commit ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@201223 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Kevin P. Fleming	f1dc620467	Enable applications to enable/disable digit and tone detection. ... Some applications (notably app_fax) do not need digit detection nor FAX tone detection while they are running, and if Asterisk is using software DSPs to provide the detection, this consumes extra CPU cycles that could be better spent on the actual application. This patch allows applications to query and control the state of digit and tone detection on a channel, and modifies app_fax to disable them while the FAX operations are occurring (and re-enable digit detection afterwards). git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@201139 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	ee8cdd555f	SIP transport type issues ... What this patch addresses: 1. ast_sip_ouraddrfor() by default binds to the UDP address/port reguardless if the sip->pvt is of type UDP or not. Now when no remapping is required, ast_sip_ouraddrfor() checks the sip_pvt's transport type, attempting to set the address and port to the correct TCP/TLS bindings if necessary. 2. It is not necessary to send the port number in the Contact header unless the port is non-standard for the transport type. This patch fixes this and removes the todo note. 3. In sip_alloc(), the default dialog built always uses transport type UDP. Now sip_alloc() looks at the sip_request (if present) and determines what transport type to use by default. 4. When changing the transport type of a sip_socket, the file descriptor must be set to -1 and in some cases the tcptls_session's ref count must be decremented and set to NULL. I've encountered several issues associated with this process and have created a function, set_socket_transport(), to handle the setting of the socket type. (closes issue #13865) Reported by: st Patches: dont_add_port_if_tls.patch uploaded by Kristijan (license 753) 13865.patch uploaded by mmichelson (license 60) tls_port_v5.patch uploaded by vrban (license 756) transport_issues.diff uploaded by dvossel (license 671) Tested by: mmichelson, Kristijan, vrban, jmacz, dvossel Review: https://reviewboard.asterisk.org/r/278/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@200946 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Kevin P. Fleming	85e57521ab	Accept T.38 re-INVITE responses with invalid SDP versions. ... This commit changes the 'incoming SDP version' check logic a bit more; when 'ignoresdpversion' is *not* set for a peer, if we initiate a re-INVITE to switch to T.38, we'll always accept the peer's SDP response, even if they don't properly increment the SDP version number as they should. If this situation occurs, a warning message will be generated suggesting that the peer's configuration be changed to include the 'ignoresdpversion' configuration option (although ideally they'd fix their SIP implementation to be RFC compliant). AST-221 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@200689 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Kevin P. Fleming	4379249674	Convert a number of global module variables to 'static'. ... These modules all contained variables that are module-global but not system-global, but were not marked 'static'. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@200587 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Kevin P. Fleming	78ee46f13f	Some minor structure size improvements in sip_pvt and sip_peer. ... Using the 'pahole' tool, it is now quite easy to see where structure fields could be organized differently to keep the compiler from having to add padding to satisfy alignment requirements. These changes reduced the sizes of sip_pvt and sip_peer by a few bytes each (on 64-bit platforms), and also fixed a spelling error in a field name. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@200584 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	d224f78dd5	Merged revisions 200513 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r200513 | mmichelson | 2009-06-15 10:21:46 -0500 (Mon, 15 Jun 2009) | 5 lines Add INFO to our allowed methods so that endpoints know they may send it to us. AST-223 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@200514 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	616e85c95f	Fix a crash due to a potentially NULL p->options. ... Thanks to mnicholson for pointing it out. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@200146 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	28fe3938b7	Only try to use the invite_branch on outgoing INVITEs with auth credentials. ... I have added a comment to the code to help ease understanding of the logic here as well. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@199958 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	59d93c1e2d	CLI NOTIFY sending wrong transport type. ... SIP's cli NOTIFY command only used UDP rather than copying the transport type from the peer. (closes issue #15283) Reported by: jthurman Patches: sip-notify-tcp-svn199728.patch uploaded by jthurman (license 614) Tested by: jthurman, dvossel git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@199818 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago