asterisk

Commit Graph

Author	SHA1	Message	Date
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
Mark Michelson	5965e276a7	Fix a deadlock that could occur when setting rtp stats on SIP calls. (closes issue #15143) Reported by: cristiandimache Patches: 15143.patch uploaded by mmichelson (license 60) Tested by: cristiandimache git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@199588 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Joshua Colp	5fcf193d7b	Correct documentation for the register line, specifically where the domain should be specified. (closes issue #14367) Reported by: Nick_Lewis git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@198791 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	298d745fb4	Add the ability to execute connected line interception macros. When connected line updates are received or generated in the middle of an application call, it is now possible to execute a macro to manipulate the connected line data. This way, phone numbers may be manipulated to be more presentable to users, names may be changed for...whatever reason, or whatever else needs to be done may be. Review: https://reviewboard.asterisk.org/r/256 AST-165 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@198727 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Joshua Colp	6e1bd8aad7	Fix a bug where the Event and Content-Type headers were added twice to outgoing SIP NOTIFY messages. (closes issue #15239) Reported by: pj git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@198498 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Joshua Colp	5c8626e315	When removing all packets from a dialog we also need to free the data if present. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@198248 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Joshua Colp	9944bce43c	Fix a bug where the default setting did not perform a remote bridge when it should have. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@197996 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	14d05f57d7	A few fixes to SIP with regards to connected line updates during transfers. * Set the invitestate to INV_CALLING when we send a connected line reinvite. This prevents us from potentially rapid-firing reinvites to a single peer. * Use the astdb to store a peer's allowed methods. This prevents us from sending an UPDATE during the interval between startup and the peer's first registration if the peer does not support the UPDATE method. * Handle Polycom's method of indicating allowed methods in REGISTER. Instead of using an Allow header, they place the allowed methods in a methods= parameter in the Contact header. ABE-1873 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@197959 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	3eab939301	Treat 405 responses the same way we would a 501. This makes sure that we mark a method as being unallowed if we receive a 405 response so that we don't continue to try to send that same type of message. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@197740 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Eliel C. Sardanons	a109652532	Merged revisions 197562 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r197562 \| eliel \| 2009-05-28 11:21:32 -0400 (Thu, 28 May 2009) \| 13 lines Use the address we already know when reloading a peer with nat=yes. If we already have an address for a peer, and we are reloading the sip configuration, try to use that address to contact the peer, instead of getting it from the Contact. (closes issue #15194) Reported by: ibc Patches: sip.patch uploaded by eliel (license 64) Tested by: manwe ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@197621 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Joshua Colp	318929b75f	Merged revisions 197466 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r197466 \| file \| 2009-05-28 10:44:58 -0300 (Thu, 28 May 2009) \| 8 lines Fix a bug where the flag indicating the presence of rport would get overwritten by the nat setting. The presence of rport is now stored as a separate flag. Once the dialog is setup and authenticated (or it passes through unauthenticated) the proper nat flag is set. (closes issue #13823) Reported by: dimas ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@197467 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Olle Johansson	b6d95bef99	Adding some generic handling of error codes sent to us in replys to requests. Previously they always set hangupcause 0, which is generally wrong. With this change, we're setting some generic hangup causes. For 5xx errors, which indicate some sort of problem with the remote server, we're now setting CONGESTION. EDVX002 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@197266 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	83500e9b06	Remove some redundant or unnecessary connected line-related function calls. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@196893 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Joshua Colp	d4efe15c09	Fix a bug where the sip unregister CLI command did not completely unregister the peer. (closes issue #15118) Reported by: alecdavis Patches: chan_sip_unregister.diff2.txt uploaded by alecdavis (license 585) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@196721 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	f50bb3bfa4	SIP set outbound transport type from Registration In sip.conf the transport option allows for the configuration of what transport types (udp, tcp, and tls) a peer will accept, but only the first type listed was used for outbound connections. This patch changes this. Now the default transport type is only used until the peer registers. When registration takes place the transport type is parsed out of the Contact header. If the Contact header's transport type is equal to one that the peer supports, the peer's default transport type for outbound connections is set to match the Contact header's type. If the Contact header's transport type is not present, then the peer's default transport type is set to match the one the peer registered with. When a peer unregisters or the registration expires, the default transport type for that peer is reset. (closes issue #12282) Reported by: rjain Patches: reg_patch_1.diff uploaded by dvossel (license 671) Tested by: dvossel (closes issue #14727) Reported by: pj Patches: reg_patch_3.diff uploaded by dvossel (license 671) Tested by: pj, dvossel Review: https://reviewboard.asterisk.org/r/249/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@196416 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Eliel C. Sardanons	2c882626a0	Implement a new element in AstXML for AMI actions documentation. A new xml element was created to manage the AMI actions documentation, using AstXML. To register a manager action using XML documentation it is now possible using ast_manager_register_xml(). The CLI command 'manager show command' can be used to show the parsed documentation. Example manager xml documentation: <manager name="ami action name" language="en_US"> <synopsis> AMI action synopsis. </synopsis> <syntax> <xi:include xpointer="xpointer(...)" /> <-- for ActionID <parameter name="header1" required="true"> <para>Description</para> </parameter> ... </syntax> <description> <para>AMI action description</para> </description> <see-also> ... </see-also> </manager> git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@196308 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	ee4f11cd24	s/it's/its/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@196268 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Kevin P. Fleming	e6b2e9a750	Const-ify the world (or at least a good part of it) This patch adds 'const' tags to a number of Asterisk APIs where they are appropriate (where the API already demanded that the function argument not be modified, but the compiler was not informed of that fact). The list includes: - CLI command handlers - CLI command handler arguments - AGI command handlers - AGI command handler arguments - Dialplan application handler arguments - Speech engine API function arguments In addition, various file-scope and function-scope constant arrays got 'const' and/or 'static' qualifiers where they were missing. Review: https://reviewboard.asterisk.org/r/251/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@196072 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	56903a7485	Get rid of some duplicated code and correct a connected line error. When receiving a 200 OK response to an INVITE, it was possible to transmit two connected line updates instead of a single one. Furthermore, the second did not have the proper information present. Now the two have been combined into a single update and the correct information is presented. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@195798 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	7b4eeed257	Add basic support for handling connected line-related UPDATE requests. SIP purists may want to look the other way... When COLP/CONP support for SIP was committed, there was a condition under which Asterisk may transmit a SIP UPDATE in order to communicate the change in connected line information. The issue here is that while we could send a SIP UPDATE message, we were not prepared to receive such an UPDATE and would always responde with a 501 when we received an UPDATE. The situation was a bit rough. We really want to be able to receive UPDATEs having to do with connected line changes, but the amount of effort involved in properly supporting RFC 3311 was staggering. This commit represents a compromise. First, it was decided that it is important to only send a SIP UPDATE to an endpoint that is able to handle one. So, now we have added parsing of the Allow header into SIP. We store the allowed methods on SIP peers so that when we communicate with them, we already will know what we can and cannot send to them. We will parse the peer's allowed methods when he registers with us. If the peer is not the type to register with us, but the qualify option is enabled, then we will use the response to the OPTIONS request we send the peer to determine the peer's allowed methods. When the peer's registration expires, or when qualify deems the peer to be unreachable, we clear the allowed methods from the peer. For an actual call, we will copy the peer's allowed methods to the sip_pvt representing the call leg. If we are communicating with an endpoint which is not a peer, then we will just parse the Allow header from the first message we receive during the call and store the information in the sip_pvt. If, during communication with a peer, we receive a 501 response, then we will make sure to save the fact that we cannot use that method when communicating with that peer. Now, with all that infrastructure in place, the only actual place we use this information currently is when attempting to send a connected line change using an UPDATE request. If we cannot send the change immediately using an UPDATE, we will set the SIP_NEEDREINVITE flag so that we can send a REINVITE as soon as it is allowed. The second part of the changes here is for Asterisk to accept UPDATE requests that have connected line changes. Since we are not fully supporting RFC 3311, Asterisk will NOT place the UPDATE method in Allow headers it sends. Instead, if you are communicating with what you know to be another Asterisk box, you may set the rpid_update parameter in sip.conf so that we will send UPDATEs to that Asterisk box. When we send a connected line update, we set a custom header called "X-Asterisk-rpid-update." On the receiving end, if Asterisk receives an UPDATE that does not have the "X-Asterisk-rpid-update" header present, then Asterisk will respond with a 501 since media-changing UPDATEs are not supported. We should never get such UPDATEs, since as was stated earlier, Asterisk does not put UPDATE in its Allow header. If the custom header is present in the received UPDATE, though, then we will check the incoming request for connected line updates and queue the update on the channel where the change occurred. ABE-1840 ABE-1822 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@195589 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Joshua Colp	99a1e0ce01	Merged revisions 195448 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r195448 \| file \| 2009-05-19 11:41:45 -0300 (Tue, 19 May 2009) \| 7 lines Fix a bug where direct RTP setup would partially occur even when disabled if the calling channel was answered. (issue #13545) Reported by: davidw (issue #14244) Reported by: mbnwa ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@195449 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Joshua Colp	9f4e8a5bda	Fix a bug where specifying an empty outboundproxy would cause packets to get sent to ourself. (closes issue #15106) Reported by: timeshell git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@195089 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	64c6397bd0	Merged revisions 194484 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r194484 \| mmichelson \| 2009-05-14 17:17:55 -0500 (Thu, 14 May 2009) \| 24 lines Fix a race condition where a reinvite could trigger a 482 response. The loop detection/spiral detection code in chan_sip used the owner channel's state as a criterion for determining if the incoming INVITE is a looped request. The problem with this is that the INVITE-handling code happens in a different thread than the thread that marks the owner channel as being up. As a result, if a reinvite were to come in very quickly, say from another Asterisk on the same LAN, it was possible for the reinvite to arrive before the owner channel had been set to the up state. This patch corrects the problem by using the invitestate of the sip_pvt instead, since that can be guaranteed to be set correctly by the time the reinvite arrives. Since there is a switch statement further in the INVITE-handling code, the AST_STATE_RINGING state also checks the invitestate of the sip_pvt in case we should actually be treating the channel as if it were up already. (closes issue #12215) Reported by: jpyle Patches: 12215_confirmed.patch uploaded by mmichelson (license 60) Tested by: lmadsen ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@194496 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	56275abb32	Update spiral support in trunk and 1.6.X to match what is in 1.4. In 1.4, a SIP spiral is treated the same way as a call forward. This works much better than what is currently in trunk and 1.6.X. The code in trunk and 1.6.X did not create a new call to the recipient of the spiral, instead trying to continue the same call. In addition to just being plain wrong, this also had the side effect of only being able to spiral calls to other SIP channels. With this in place, as long as call forwards are honored, SIP spirals will work properly. This means that it will work for outbound calls made by the Queue, Dial, and Page applications. For originated calls and spool calls, however, the spiral will not work properly until a generic call forward mechanism is introduced into Asterisk. (relates to issue #13630) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@193954 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	fbad7a508d	TCP not matching valid peer. find_peer() does not find a valid peer when using pvt->recv as the sockaddr_in argument. Because of the way TCP works, the port number in pvt->recv is not what we're looking for at all. There is currently only one place that find_peer searches for a peer using the sockaddr_in argument. If the peer is not found after using pvt->recv (works for UDP since the port number will be correct), a temp sockaddr_in struct is made using the Contact header in the sip_request. This has the correct port number in it. Review: http://reviewboard.digium.com/r/236/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@193387 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Tilghman Lesher	01e5a86e1a	Merged revisions 192932 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r192932 \| tilghman \| 2009-05-07 11:29:08 -0500 (Thu, 07 May 2009) \| 10 lines Eliminate repetition of fullcontact during reconstruction. If the fullcontact field appears in both the sippeers and the sipregs table, then during reconstruction of the field, it will otherwise be doubled. (closes issue #14754) Reported by: Alexei Gradinari Patches: 20090506__bug14754.diff.txt uploaded by tilghman (license 14) Tested by: lmadsen ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@192933 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Joshua Colp	19916d118d	Merged revisions 192633 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r192633 \| file \| 2009-05-06 10:30:51 -0300 (Wed, 06 May 2009) \| 7 lines Update some old logic to stop both begin and end DTMF frames from reaching the core if rfc2833 is not enabled. (closes issue #15036) Reported by: dimas Patches: v1-15036.patch uploaded by dimas (license 88) ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@192634 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Richard Mudgett	7019ff68db	Fixed crashes from issue8824 review board channel locking changes. The local struct ast_party_connected_line connected_caller variable was uninitialized when the copy function was called. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@192590 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Joshua Colp	2e7c1e3613	Fix a bug with setting t38pt_udptl at the user or peer level. If an incoming call authenticated as a user or peer and t38pt_udptl was not set to yes in general then no UDPTL session would be present and any T38 related things would fail. This commit changes it so that if after authenticating T38 is enabled but no UDPTL session is present one will be created. (issue AST-215) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@192387 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Tilghman Lesher	a3229fd3e2	Merged revisions 191559 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r191559 \| tilghman \| 2009-05-01 15:00:23 -0500 (Fri, 01 May 2009) \| 6 lines SIP Response 410 maps to cause code 22 (or 23), not 1. (closes issue #14993) Reported by: BigJimmy Patches: causepatch uploaded by BigJimmy (license 371) ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@191560 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	ca138fc807	Consistent SSL/TLS options across conf files ast_tls_read_conf() is a new api call for handling SSL/TLS options across all conf files. Before this change, SSL/TLS options were not consistent. http.conf and manager.conf required the 'ssl' prefix while sip.conf used options with the 'tls' prefix. While the options had different names in different conf files, they all did the exact same thing. Now, instead of mixing 'ssl' or 'tls' prefixes to do the same thing depending on what conf file you're in, all SSL/TLS options use the 'tls' prefix. For example. 'sslenable' in http.conf and manager.conf is now 'tlsenable' which matches what already existed in sip.conf. Since this has the potential to break backwards compatibility, previous options containing the 'ssl' prefix still work, but they are no longer documented in the sample.conf files. The change is noted in the CHANGES file though. Review: http://reviewboard.digium.com/r/237/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@191028 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	8f0b88c8c8	TLS/SSL private key option Adds option to specify a private key .pem file when configuring TLS or SSL in AMI, HTTP, and SIP. Before this, the certificate file was used for both the public and private key. It is possible for this file to hold both, but most configurations allow for a separate private key file to be specified. Clarified in .conf files how these options are to be used. The current conf files do not explain how the private key is handled at all, so without knowledge of Asterisk's TLS implementation, it would be hard to know for sure what was going on or how to set it up. Review: http://reviewboard.digium.com/r/234/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190545 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Russell Bryant	cba19c8a67	Convert the ast_channel data structure over to the astobj2 framework. There is a lot that could be said about this, but the patch is a big improvement for performance, stability, code maintainability, and ease of future code development. The channel list is no longer an unsorted linked list. The main container for channels is an astobj2 hash table. All of the code related to searching for channels or iterating active channels has been rewritten. Let n be the number of active channels. Iterating the channel list has gone from O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1). Searching for a channel by extension is still O(n), but uses a new method for doing so, which is more efficient. The ast_channel object is now a reference counted object. The benefits here are plentiful. Some benefits directly related to issues in the previous code include: 1) When threads other than the channel thread owning a channel wanted access to a channel, it had to hold the lock on it to ensure that it didn't go away. This is no longer a requirement. Holding a reference is sufficient. 2) There are places that now require less dealing with channel locks. 3) There are places where channel locks are held for much shorter periods of time. 4) There are places where dealing with more than one channel at a time becomes _MUCH_ easier. ChanSpy is a great example of this. Writing code in the future that deals with multiple channels will be much easier. Some additional information regarding channel locking and reference count handling can be found in channel.h, where a new section has been added that discusses some of the rules associated with it. Mark Michelson also assisted with the development of this patch. He did the conversion of ChanSpy and introduced a new API, ast_autochan, which makes it much easier to deal with holding on to a channel pointer for an extended period of time and having it get automatically updated if the channel gets masqueraded. Mark was also a huge help in the code review process. Thanks to David Vossel for his assistance with this branch, as well. David did the conversion of the DAHDIScan application by making it become a wrapper for ChanSpy internally. The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch. Review: http://reviewboard.digium.com/r/203/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Joshua Colp	f314c5f13f	Fix nat setting on RTP instances. (closes issue #14827) Reported by: pj git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190421 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Russell Bryant	bbcf30787d	Merged revisions 190356 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r190356 \| russell \| 2009-04-23 16:07:07 -0500 (Thu, 23 Apr 2009) \| 2 lines Remove a bogus ast_channel_unlock(). ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190357 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	00d7c4fefc	Fixes segfault when switching UDP to TCP in sip.conf after reload. If transport in sip.conf is switched from UDP to TCP, Asterisk segfaults right after issuing a sip reload. The problem is the socket type is changed to TCP but the fd may still be present for UDP. Later, when the TCP session should be created or set using an existing one, it isn't because the old file descriptor is still present. Now every time transport is changed during a sip.conf reload, the file descriptor is set to -1, signifying it must be created or found. (closes issue #14727) Reported by: pj Tested by: dvossel Review: http://reviewboard.digium.com/r/229/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@189771 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Joshua Colp	b5b18b7810	Fix a bug with non-UDP connections that caused dialogs to not get freed. This issue crept up because of a reference count issue on non-UDP based dialogs. The dialog reference count was increased when transmitting a packet reliably but never decreased. This caused the dialog structure to hang around despite being unlinked from the dialogs container. (closes issue #14919) Reported by: vrban git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@189350 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	4bf5e1b805	Prevent a crash when SIP blonde transferring an unbridged call. If one attempts to use the attended transfer button on a SIP phone to transfer an unbridged call (such as a call to an IVR) but hangs up while the target of the transfer is still ringing, we need to not crash. The problem was that ast_hangup was called from outside the channel thread. AST-211 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@189097 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Joshua Colp	6d2b446384	Merged revisions 188946 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r188946 \| file \| 2009-04-17 11:41:25 -0300 (Fri, 17 Apr 2009) \| 15 lines Fix a bug where a value used to create the channel name was bogus. This commit fixes the scenario where an incoming call is authenticated using a peer entry. Previously the channel name was created using either the username setting from the sip.conf entry or the IP address that the call came from. Now the channel name will be created using the peer name itself. This commit will not change the way the channel name is generated for users or friends. (closes issue #14256) Reported by: Nick_Lewis Patches: chan_sip.c-chname.patch uploaded by Nick (license 657) Tested by: Nick_Lewis, file ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@188947 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Tilghman Lesher	ecc3c7c4a6	Merged revisions 188835 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r188835 \| tilghman \| 2009-04-16 16:41:13 -0500 (Thu, 16 Apr 2009) \| 7 lines Only update realtime, if global option rtupdate != false (closes issue #14885) Reported by: deepesh Patches: 20090413__bug14885.diff.txt uploaded by tilghman (license 14) Tested by: deepesh ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@188836 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	a9895c6833	SIP state notify reorganization What I've done here is simply break up how a state NOTIFY is built. Originally both the XML and sip header information were built within the same function. While this does work, it does not allow for the creation of multipart/related message bodies that can contain multiple XML entries with only one sip header. Now a separate function builds the XML for each notify. This patch also makes maintaining and modifying state notifications in the future much less of a pain. Review: http://reviewboard.digium.com/r/224/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@188742 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Joshua Colp	84fd750c10	Fix a bug with the change I made yesterday to outbound proxy support. Per discussion with oej on IRC we need the actual IP address, not the outbound proxy IP address, in the sa field. This change matches the already existing code for all other uses of the outbound proxy setting. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@188247 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Joshua Colp	75dba8ca1d	Fix a bug where using an outbound proxy would cause the local address to be 127.0.0.1. Copy the outbound proxy IP address into the SIP dialog structure as the IP address we will be sending to. This has to be done because the logic that determines what local IP address to use in the SIP messages is not aware of an outbound proxy being in place. It only knows what IP address we are sending to. (closes issue #12006) Reported by: mnicholson git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@188067 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Joshua Colp	8e4b5df187	Fix some uninitialized memory notices that appeared under valgrind. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187772 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Tilghman Lesher	15e040d3f3	Ensure pvt is not NULL before dereferencing it. (closes issue #14784) Reported by: pj git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187674 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	4d74179f20	Add a new option, mwi_from, to sip.conf. This allows for you to change the From header for outgoing MWI NOTIFY requests. Prior to this, the best you could do was to set a callerid in the general section of sip.conf. The problem was that this was used for all outbound requests, not just MWI NOTIFY requests. AST-201 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187560 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	e53bd994d0	Merged revisions 187484 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r187484 \| mmichelson \| 2009-04-09 13:51:20 -0500 (Thu, 09 Apr 2009) \| 18 lines Handle a SIP race condition (reinvite before an ACK) properly. RFC 5047 explains the proper course of action to take if a reINVITE is received before the ACK from a previous invite transaction. What we are to do is to treat the reINVITE as if it were both an ACK and a reINVITE and process it normally. Later, when we receive the ACK we had been expecting, we will ignore it since its CSeq is less than the current iseqno of the sip_pvt representing this dialog. (closes issue #13849) Reported by: klaus3000 Patches: 13849_v2.patch uploaded by mmichelson (license 60) Tested by: mmichelson, klaus3000 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187488 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Tilghman Lesher	7304ac444e	Allow '/' in username portion of register; this is a regression. (closes issue #14668) Reported by: Netview git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187381 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago

1 2 3 4 5 ...

2601 Commits (616e85c95f7ff9c226dea9fce10060d5c1fbc5d8)