https://origsvn.digium.com/svn/asterisk/trunk
........
r201570 | dvossel | 2009-06-18 10:16:05 -0500 (Thu, 18 Jun 2009) | 11 lines
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/branches/1.6.1@201601 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r201462 | mmichelson | 2009-06-17 15:10:01 -0500 (Wed, 17 Jun 2009) | 12 lines
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/branches/1.6.1@201464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r201344 | dvossel | 2009-06-17 10:20:26 -0500 (Wed, 17 Jun 2009) | 16 lines
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/branches/1.6.1@201365 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r200946 | dvossel | 2009-06-16 11:03:30 -0500 (Tue, 16 Jun 2009) | 32 lines
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/branches/1.6.1@200987 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r165180 | mnicholson | 2008-12-17 12:49:12 -0600 (Wed, 17 Dec 2008) | 14 lines
This patch adds a new 'ignoresdpversion' option to sip.conf. When this is
enabled (either globally or for a specific peer), chan_sip will treat any SDP
data it receives as new data and update the media stream accordingly. By
default, Asterisk will only modify the media stream if the SDP session version
received is different from the current SDP session version. This option is
required to interoperate with devices that have non-standard SDP session
version implementations (observed by toc on the bug tracker with Microsoft OCS
which always uses 0 as the session version).
http://reviewboard.digium.com/r/94/
(closes issue #13958)
Reported by: toc
Tested by: toc
........
r200689 | kpfleming | 2009-06-15 15:42:38 -0500 (Mon, 15 Jun 2009) | 12 lines
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/branches/1.6.1@200707 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r199818 | dvossel | 2009-06-09 15:47:57 -0500 (Tue, 09 Jun 2009) | 11 lines
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/branches/1.6.1@199820 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r197621 | eliel | 2009-05-28 12:01:48 -0400 (Thu, 28 May 2009) | 19 lines
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/branches/1.6.1@197696 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r197606 | mmichelson | 2009-05-28 10:32:19 -0500 (Thu, 28 May 2009) | 22 lines
Recorded merge of revisions 197588 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r197588 | mmichelson | 2009-05-28 10:27:49 -0500 (Thu, 28 May 2009) | 16 lines
Allow for media to arrive from an alternate source when responding to a reinvite with 491.
When we receive a SIP reinvite, it is possible that we may not be able to process the
reinvite immediately since we have also sent a reinvite out ourselves. The problem is
that whoever sent us the reinvite may have also sent a reinvite out to another party,
and that reinvite may have succeeded.
As a result, even though we are not going to accept the reinvite we just received, it
is important for us to not have problems if we suddenly start receiving RTP from a new
source. The fix for this is to grab the media source information from the SDP of the
reinvite that we receive. This information is passed to the RTP layer so that it will
know about the alternate source for media.
Review: https://reviewboard.asterisk.org/r/252
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@197618 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r197467 | file | 2009-05-28 10:47:45 -0300 (Thu, 28 May 2009) | 15 lines
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/branches/1.6.1@197470 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r196416 | dvossel | 2009-05-22 16:09:45 -0500 (Fri, 22 May 2009) | 19 lines
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/branches/1.6.1@196453 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r194496 | mmichelson | 2009-05-14 17:20:51 -0500 (Thu, 14 May 2009) | 30 lines
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/branches/1.6.1@194507 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r193954 | mmichelson | 2009-05-12 15:28:13 -0500 (Tue, 12 May 2009) | 18 lines
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/branches/1.6.1@193961 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r193387 | dvossel | 2009-05-08 15:32:51 -0500 (Fri, 08 May 2009) | 7 lines
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/branches/1.6.1@193389 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r192933 | tilghman | 2009-05-07 11:43:56 -0500 (Thu, 07 May 2009) | 17 lines
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/branches/1.6.1@192935 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r192387 | file | 2009-05-05 11:22:47 -0300 (Tue, 05 May 2009) | 10 lines
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/branches/1.6.1@192401 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r189771 | dvossel | 2009-04-21 15:28:37 -0500 (Tue, 21 Apr 2009) | 11 lines
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/branches/1.6.1@189774 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r189350 | file | 2009-04-20 14:05:15 -0300 (Mon, 20 Apr 2009) | 10 lines
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/branches/1.6.1@189352 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r189097 | mmichelson | 2009-04-17 15:20:23 -0500 (Fri, 17 Apr 2009) | 13 lines
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/branches/1.6.1@189103 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r188947 | file | 2009-04-17 11:44:56 -0300 (Fri, 17 Apr 2009) | 22 lines
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/branches/1.6.1@188949 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r188247 | file | 2009-04-14 10:14:21 -0300 (Tue, 14 Apr 2009) | 7 lines
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. Upon further inspection
this should make the behaviour of all other uses of the outbound proxy
in the code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@188254 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r188067 | file | 2009-04-13 13:28:06 -0300 (Mon, 13 Apr 2009) | 10 lines
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/branches/1.6.1@188069 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r187488 | mmichelson | 2009-04-09 13:58:41 -0500 (Thu, 09 Apr 2009) | 24 lines
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/branches/1.6.1@187495 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r185846 | dvossel | 2009-04-01 14:03:32 -0500 (Wed, 01 Apr 2009) | 16 lines
Merged revisions 185845 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r185845 | dvossel | 2009-04-01 14:02:00 -0500 (Wed, 01 Apr 2009) | 10 lines
Fixes issue with dropped calles due to re-Invite glare and re-Invites never executing after a 491
Acknowledgement for 491 responses were never being processed because it didn't match our pending invite's seqno. Since the ACK was never processed, the 491 frame would continue to be retransmitted until eventually the call was dropped due to max retries. Now during a pending invite, if we receive another invite, we send an 491 and hold on to that glare invite's seqno in the "glareinvite" variable for that sip_pvt struct. When ACK's are received, we first check to see if it is in response to our pending invite, if not we check to see if it is in response to a glare invite. In this case, it is in response to the glare invite and must be dealt with or the call is dropped. I've changed the wait time for resending the re-Invite after receving a 491 response to comply with RFC 3261. Before this patch the scheduled re-Invite would only change a flag indicating that the re-Invite should be sent out, now it actually sends it out as well.
(closes issue #12013)
Reported by: alx
Review: http://reviewboard.digium.com/r/213/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@185848 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r184948 | file | 2009-03-30 11:37:47 -0300 (Mon, 30 Mar 2009) | 21 lines
Merged revisions 184947 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r184947 | file | 2009-03-30 11:35:47 -0300 (Mon, 30 Mar 2009) | 14 lines
Improve our handling of T38 in the initial INVITE from a device.
We now answer with matching media streams to what is requested. If an INVITE
is received with both a T38 and RTP media stream this means we answer with both.
For any outgoing calls created as a result of this inbound one no T38 is requested
in the initial INVITE. Instead if we start receiving udptl packets we trigger a
reinvite on the outbound side.
(closes issue #12437)
Reported by: marsosa
Tested by: pinga-fogo, okrief, file, afu
Review: http://reviewboard.digium.com/r/208/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@184950 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r184566 | file | 2009-03-27 10:15:26 -0300 (Fri, 27 Mar 2009) | 16 lines
Merged revisions 184565 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r184565 | file | 2009-03-27 10:06:45 -0300 (Fri, 27 Mar 2009) | 9 lines
Fix an issue where nat=yes would not always take effect for the RTP session on outgoing calls.
If calls were placed using an IP address or hostname the global nat setting was copied over
but was not set on the RTP session itself. This caused the RTP stack to not perform symmetric RTP
actions.
(closes issue #14546)
Reported by: acunningham
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@184587 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r184339 | russell | 2009-03-25 16:57:19 -0500 (Wed, 25 Mar 2009) | 35 lines
Improve performance of the ast_event cache functionality.
This code comes from svn/asterisk/team/russell/event_performance/.
Here is a summary of the changes that have been made, in order of both
invasiveness and performance impact, from smallest to largest.
1) Asterisk 1.6.1 introduces some additional logic to be able to handle
distributed device state. This functionality comes at a cost.
One relatively minor change in this patch is that the extra processing
required for distributed device state is now completely bypassed if
it's not needed.
2) One of the things that I noticed when profiling this code was that a
_lot_ of time was spent doing string comparisons. I changed the way
strings are represented in an event to include a hash value at the front.
So, before doing a string comparison, we do an integer comparison on the
hash.
3) Finally, the code that handles the event cache has been re-written.
I tried to do this in a such a way that it had minimal impact on the API.
I did have to change one API call, though - ast_event_queue_and_cache().
However, the way it works now is nicer, IMO. Each type of event that
can be cached (MWI, device state) has its own hash table and rules for
hashing and comparing objects. This by far made the biggest impact on
performance.
For additional details regarding this code and how it was tested, please see the
review request.
(closes issue #14738)
Reported by: russell
Review: http://reviewboard.digium.com/r/205/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@184342 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r184280 | file | 2009-03-25 16:22:06 -0300 (Wed, 25 Mar 2009) | 5 lines
Fix issue with a T38 reinvite being sent even if not configured to do so.
If we receive a T38 request negotiate control frame we should only attempt to do so
if the option is enabled on the dialog.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@184282 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r183117 | mmichelson | 2009-03-19 11:07:54 -0500 (Thu, 19 Mar 2009) | 20 lines
Merged revisions 183115 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183115 | mmichelson | 2009-03-19 11:04:02 -0500 (Thu, 19 Mar 2009) | 14 lines
Fix an issue where cancelled outgoing SIP calls would erroneously report the device as "in use."
A user was having an issue where if an outgoing SIP call was canceled, the SIP device
would remain in use if we had not received any response to the initial INVITE we sent out.
The SIP device would remain in use until the autocongestion timer was exhausted.
I tracked down the cause of this to be the section of code I am removing here. I asked several
people what the purpose of this code was meant to be, but no one could give me any sort of
answer as to why this was here. The person who was having this issue has been using this patch
for several months and it has stopped the problems they have had.
AST-196
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@183121 65c4cc65-6c06-0410-ace0-fbb531ad65f3
