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.0@197469 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.0@196454 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.0@194504 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.0@193960 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.0@193449 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.0@192934 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.0@192397 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.0@189773 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.0@189101 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.0@188948 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. 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/branches/1.6.0@188248 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.0@188068 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A note to all of you. Don't block revisions in a branch if you actually
meant to merge them. Two very old revisions somehow didn't get merged into
1.6.0 and this change was dependent on those two old revisions. What should have
taken 2 minutes has now wasted about 30 minutes of my time :(
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@187555 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r141810 | mmichelson | 2008-09-08 16:18:49 -0500 (Mon, 08 Sep 2008) | 22 lines
Merged revisions 141809 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r141809 | mmichelson | 2008-09-08 16:10:10 -0500 (Mon, 08 Sep 2008) | 14 lines
Fix pedantic mode of chan_sip to only check the
remote tag of an endpoint once a dialog has
been confirmed. Up until that point, it is possible
and legal for the far-end to send provisional
responses with a different To: tag each time. With
this patch applied, these provisional messages
will not cause a matching problem.
(closes issue #11536)
Reported by: ibc
Patches:
11536v2.patch uploaded by putnopvut (license 60)
........
................
r141868 | mmichelson | 2008-09-08 17:14:40 -0500 (Mon, 08 Sep 2008) | 4 lines
Um, apparently I didn't actually finish merging before committing.
Bad bad bad
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@187554 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A bad merge from trunk to 1.6.0 meant freeing memory that
should not be freed. In trunk, pkt->data is an ast_str, but
in 1.6.0, it is allocated in the same chunk of memory as the
sip_pkt. This only affects 1.6.0.
(closes issue #14819)
Reported by: cwolff09
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@186517 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.0@185847 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.0@184949 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.0@184580 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.0@184281 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.0@183118 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r183108 | file | 2009-03-19 12:37:23 -0300 (Thu, 19 Mar 2009) | 11 lines
Improve our triggering of a T38 switchover internally when triggered by a received reinvite.
Previously we reached across the channel bridge to get the other party's SIP dialog
structure in order to trigger an outgoing reinvite. This is extremely dangerous to do
and only works if bridged to another SIP channel. This patch changes this to use the
T38 control frame method of requesting a switchover. This change also causes the SIP
channel driver to propogate back whether the switchover worked or not instead of blindly
accepting the incoming T38 reinvite.
Review: http://reviewboard.digium.com/r/200/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@183109 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r182022 | file | 2009-03-13 14:25:09 -0300 (Fri, 13 Mar 2009) | 7 lines
Fix an issue with requesting a T38 reinvite before the call is answered.
The code responsible for sending the T38 reinvite did not check if an INVITE was
already being handled. This caused things to get confused and the call to fail.
The code now defers sending the T38 reinvite until the current INVITE is done being
handled.
(issue AST-191)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@182036 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r181769 | mmichelson | 2009-03-12 13:30:58 -0500 (Thu, 12 Mar 2009) | 28 lines
Merged revisions 181768 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r181768 | mmichelson | 2009-03-12 13:29:48 -0500 (Thu, 12 Mar 2009) | 22 lines
Properly send a 487 on an INVITE we have not responded to if we receive a BYE.
If we receive an INVITE from an endpoint and then later receive a BYE from that
same endpoint before we have sent a final response for the INVITE, then we need
to respond to the INVITE with a 487.
There was logic in the code prior to this commit which seemed to exist solely to
handle this situation, but there was one condition in an if statement which
was incorrect. The only way we would send a 487 was if the sip_pvt had no owner
channel. This made no sense since we created the owner channel when we received
the INVITE, meaning that the majority of the time we would never send the 487.
The 487 being sent should not rely on whether we have created a channel. Its
delivery should be dependent on the current state of the initial INVITE transaction.
With this commit, that logic is now correctly in place.
(closes issue #14149)
Reported by: legranjl
Patches:
14149.patch uploaded by mmichelson (license 60)
Tested by: legranjl
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@181770 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r181345 | file | 2009-03-11 14:26:40 -0300 (Wed, 11 Mar 2009) | 21 lines
Merged revisions 181328 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r181328 | file | 2009-03-11 14:22:52 -0300 (Wed, 11 Mar 2009) | 14 lines
Fix issue where an attended transfer could not be completed under a rare scenario.
When completing an attended transfer chan_sip does a check to make sure the extension
in the URI portion of the Refer-To header is a local valid extension. We don't actually
need to check this since we know for sure the other channel is already up and talking to
the extension. Some devices do not put the extension in the Refer-To header either, which
can cause the extension check to fail. We now no longer do this check if it is an attended
transfer.
(closes issue #14628)
Reported by: sverre
Patches:
14628.diff uploaded by file (license 11)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@181352 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r181296 | file | 2009-03-11 13:40:48 -0300 (Wed, 11 Mar 2009) | 16 lines
Merged revisions 181295 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r181295 | file | 2009-03-11 13:36:50 -0300 (Wed, 11 Mar 2009) | 9 lines
Fix a problem with inband DTMF detection on outgoing SIP calls when dtmfmode=auto.
When dtmfmode was set to auto the inband DTMF detector was not setup
on outgoing SIP calls. This caused inband DTMF detection to fail.
The inband DTMF detector is now setup for both dtmfmode inband and auto.
(closes issue #13713)
Reported by: makoto
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@181297 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r181135 | jpeeler | 2009-03-10 23:06:44 -0500 (Tue, 10 Mar 2009) | 20 lines
Fix malloc debug macros to work properly with h323.
The main problem here was that cstdlib was undefining free thereby causing the
proper debug macros to not be used. ast_h323.cxx has been changed to call
ast_free instead to avoid the issue.
A few other issues were addressed:
- There were a few instances of functions improperly passing ast_free instead
of ast_free_ptr.
- Some clean up was done to avoid the debug macros intentionally being redefined.
(copied below from Kevin's commit, appreciate the help)
- disable astmm.h from doing anything when STANDALONE is defined, which is used
by the tools in the utils/ directory that use parts of Asterisk header files in
hackish ways; also ensure that utils/extconf.c and utils/conf2ael.c are
compiled with STANDALONE defined.
(closes issue #13593)
Reported by: pj
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@181137 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r151464 | mmichelson | 2008-10-21 18:54:41 -0500 (Tue, 21 Oct 2008) | 11 lines
Make the sip_standard_port function more granular by allowing separate
type and port arguments. This is necessary because when building our From
and Contact headers, we need to be absolutely sure that we are placing our
source port there and not the peer's source port.
(closes issue #12761)
Reported by: asbestoshead
Patches:
patch-chan-sip-contact-port.txt uploaded by asbestoshead (license 455)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@179473 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r179219 | mmichelson | 2009-03-01 15:45:08 -0600 (Sun, 01 Mar 2009) | 18 lines
Properly free memory and remove scheduler entries when a transmission failure occurs.
Previously, only the "data" field of the sip_pkt created during __sip_reliable_xmit
was freed when XMIT_FAILURE was returned by __sip_xmit. When retrans_pkt was called,
this inevitably resulted in the reading and writing of freed memory.
XMIT_FAILURE is a condition meaning that we don't want to attempt resending the packet
at all. The proper action to take is to remove the scheduler entry we just created,
free the packet's data as well as the packet itself, and unlink it from the list of
packets on the sip_pvt structure.
(closes issue #14455)
Reported by: Nick_Lewis
Patches:
14455.patch uploaded by mmichelson (license 60)
Tested by: Nick_Lewis
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@179220 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r178213 | file | 2009-02-24 11:18:38 -0400 (Tue, 24 Feb 2009) | 16 lines
Merged revisions 178205 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r178205 | file | 2009-02-24 11:16:07 -0400 (Tue, 24 Feb 2009) | 9 lines
Skip check for extension when subscribing for MWI.
Since the remote side is not actually subscribing to a specific extension when
subscribing for MWI just skip the check to see if the extension exists. They can't use it
to specify the mailbox either since we require configuration of that in sip.conf
(closes issue #14531)
Reported by: festr
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@178224 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r176705 | dhubbard | 2009-02-17 15:59:38 -0600 (Tue, 17 Feb 2009) | 11 lines
create a UDPTL structure in create_addr_from_peer() if it does not already exist for T38
This is required to create a UDPTL structure in create_addr_from_peer() to handle the
scenario where 't38pt_udptl=yes' is not defined in the [general] section of sip.conf but
is defined the peer's context. I tested this patch by enabling t38pt_udptl in the
[general] section on one system and only enabling t38pt_udptl in a peer's context on
the system sending a fax. Without the patch, the sending system will fail to initiate
T38 negotiation with the warning message, "No way to add SDP without an UDPTL structure".
When this patch is applied the sending side will successfully initiate T38 negotiation.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@176709 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r176459 | tilghman | 2009-02-16 19:58:39 -0600 (Mon, 16 Feb 2009) | 17 lines
Merged revisions 176426 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r176426 | tilghman | 2009-02-16 18:49:22 -0600 (Mon, 16 Feb 2009) | 10 lines
After a 'sip reload', qualifies for realtime peers weren't immediately
restarted, instead waiting until the next registration. We're now
caching the qualify across a reload/restart and starting the qualify
immediately upon loading the peer.
(closes issue #14196)
Reported by: pdf
Patches:
20090120__bug14196_1.4.diff.txt uploaded by pdf (license 663)
Tested by: pdf
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@176460 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r176030 | file | 2009-02-16 11:36:19 -0400 (Mon, 16 Feb 2009) | 16 lines
Merged revisions 176029 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r176029 | file | 2009-02-16 11:33:53 -0400 (Mon, 16 Feb 2009) | 9 lines
Don't have the Via header stored as a stringfield as it can change often during the lifetime of a dialog.
This issue crept up with subscriptions on the AA50. When an outgoing NOTIFY is sent a new branch value
is created and the Via header is changed to reflect it. Since this was a stringfield a new spot in the
pool was used for the value while the old was left untouched/unused. If the current pool was full a new
pool was created. This would cause memory usage to increase steadily.
(issue #AA50-2332)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@176031 65c4cc65-6c06-0410-ace0-fbb531ad65f3
