This is the second commit for this and documents the text stream using the configured
IP address and fixes a bug in the original patch where the UDPTL stream would also
use the different IP address.
(closes issue #14729)
Reported by: _brent_
Patches:
media_address.patch uploaded by brent (license 388)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@225089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r225032 | dvossel | 2009-10-21 09:37:04 -0500 (Wed, 21 Oct 2009) | 20 lines
IAX/SIP shrinkcallerid option
The shrinking of caller id removes '(', ' ', ')', non-trailing '.',
and '-' from the string. This means values such as 555.5555 and
test-test result in 555555 and testtest. There are instances,
such as Skype integration, where a specific value is passed via
caller id that must be preserved unmodified. This patch makes
the shrinking of caller id optional in chan_sip and chan_iax in
order to support such cases. By default this option is on to
preserve previous expected behavior.
(closes issue #15940)
Reported by: dimas
Patches:
v2-15940.patch uploaded by dimas (license 88)
15940_shrinkcallerid_trunk.c uploaded by dvossel (license 671)
Tested by: dvossel
Review: https://reviewboard.asterisk.org/r/408/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@225033 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r224330 | jpeeler | 2009-10-16 20:32:47 -0500 (Fri, 16 Oct 2009) | 13 lines
Fix stale caller id data from being reported in AMI NewChannel event
The problem here is that chan_dahdi is designed in such a way to set
certain values in the dahdi_pvt only once. One of those such values
is the configured caller id data in chan_dahdi.conf. For PRI, the
configured caller id data could be overwritten during a call. Instead
of saving the data and restoring, it was decided that for all non-analog
channels it was simply best to not set the configured caller id in the
first place and also clear it at the end of the call.
(closes issue #15883)
Reported by: jsmith
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@224331 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r224260 | rmudgett | 2009-10-16 15:25:23 -0500 (Fri, 16 Oct 2009) | 18 lines
Never released PRI channels when using Busy() or Congestion() dialplan apps.
When the Busy() or Congestion() application is used towards ISDN (an ISDN
progress is sent), the responding ISDN Disconnect or Release may contain
the ISDN cause user busy or one of the congestion causes. In chan_dahdi.c
these causes will only set the needbusy or needcongestion flags and not
activate the softhangup procedure. Unfortunately only the latter can
interrupt the endless wait loop of Busy()/Congestion().
Result: PRI channels staying in state busy for the rest of asterisk life
or until the other end times out and forces the call to clear.
(issue #14292)
Reported by: tomaso
Patches:
disc_rel_userbusy.patch uploaded by tomaso (license 564)
(This patch is unrelated to the issue.)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@224261 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Ability has been added to both manager command SIPnotify as well as console
command sip notify. Message body is stored in the "Content" variable. An
example is present in sip_notify.conf.
(closes issue #13926)
Reported by: jthurman
Patches:
sip-notify-svn189463.diff uploaded by gareth (license 208)
Tested by: gareth
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@224035 65c4cc65-6c06-0410-ace0-fbb531ad65f3
chan_sip has some code to automatically switch from T.38 mode to voice mode when
a voice frame is written to the channel while it is in T.38 mode; this was
intended to handle the situation when a FAX transmission has ended and the channel
is not yet hung up, but is causing problems at the beginning of FAX sessions as
well when there are still voice frames 'in flight' at the time the T.38 negotiation
completes. This patch removes the automatic switchover, and changes app_fax to
explicitly switch off T.38 mode when the FAX transmission process ends.
(closes issue #16025)
Reported by: jamicque
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@223652 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a pending reinvite were sent, we might not properly
send connected party info since we were checking the wrong
flag. This was a rare occurrence, but could still happen
nevertheless.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@223617 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When using callbackextension or specifing the peer name
in a registration string, the peer's specific auth settings
set by the "auth=" strings within the peer definition are not
used by the registration. Thanks to ebroad for reporting the
issue and providing the patch.
(closes issue #15955)
Reported by: ebroad
Patches:
regauthfix.patch uploaded by ebroad (license 878)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@223088 65c4cc65-6c06-0410-ace0-fbb531ad65f3
chan_sip calls pbx_exec on a pvt's owner channel while only the
pvt lock is held. Since pbx_exec calls ast_cel_report_event which
attempts to lock the channel, invalid locking order occurs. Channels
should be locked before pvt's.
(closes issue #15512)
Reported by: lmsteffan
Patches:
ast_cel_deadlock_15512.diff uploaded by dvossel (license 671)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222981 65c4cc65-6c06-0410-ace0-fbb531ad65f3
externtcpport and externtlsport need to be declared as static
variables. Thanks to russell for finding and pointing this out.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r222797 | rmudgett | 2009-10-08 11:33:06 -0500 (Thu, 08 Oct 2009) | 12 lines
Fix memory leak if chan_misdn config parameter is repeated.
Memory leak when the same config option is set more than once in an
misdn.conf section. Why must this be considered? Templates! Defining a
template with default port options and later adding to or overriding some
of them.
Patches:
memleak-misdn.patch
JIRA ABE-1998
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222799 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Channels are stored in an ao2_container. When accessing an item within
an ao2_container the proper locking order is to first lock the container,
and then the items within it.
In ast_do_masquerade both the clone and original channel must be locked
for the entire duration of the function. The problem with this is that
it attemptes to unlink and link these channels back into the ao2_container
when one of the channel's name changes. This is invalid locking order as
the process of unlinking and linking will lock the ao2_container while
the channels are locked!!! Now, both the channels in do_masquerade are
unlinked from the ao2_container and then locked for the entire function.
At the end of the function both channels are unlocked and linked back
into the container with their new names as hash values.
This new method of requiring all channels and tech pvts to be unlocked
before ast_do_masquerade() or ast_change_name() required several
changes throughout the code base.
(closes issue #15911)
Reported by: russell
Patches:
masq_deadlock_trunk.diff uploaded by dvossel (license 671)
Tested by: dvossel, atis
(closes issue #15618)
Reported by: lmsteffan
Patches:
deadlock_local_attended_transfers_trunk.diff uploaded by dvossel (license 671)
Tested by: lmsteffan, dvossel
Review: https://reviewboard.asterisk.org/r/387/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222761 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r222691 | rmudgett | 2009-10-07 16:51:24 -0500 (Wed, 07 Oct 2009) | 14 lines
chan_misdn.c:process_ast_dsp() memory leak
misdn.conf: astdtmf must be set to "yes". With "no", buffer loss does not
occur.
The translated frame "f2" when passing through ast_dsp_process() is not
freed whenever it is not used further in process_ast_dsp(). Then in the
end it is never ever freed.
Patches:
translate.patch
JIRA ABE-1993
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222692 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds support for TCP/TLS in the Contact header when using
NAT, specifically externip or externhost. The original issue was that
Asterisk sent 5060 as the port in the contact header whether TLS was
used or not. Additionally, this patch adds 2 config options to sip.conf,
specifically externtcpport and externtlsport. This allows a user to
specify different external ports for TCP and TLS other than those used
internally, this is especially useful in in a PAT/port redirection setup.
Thanks to ebroad for reporting the issue and providing the patch!
(closes issue #15880)
Reported by: ebroad
Patches:
portmap.patch uploaded by ebroad (license 878)
externtXXport_v2.patch uploaded by ebroad (license 878)
Tested by: ebroad
Review: https://reviewboard.asterisk.org/r/392/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222398 65c4cc65-6c06-0410-ace0-fbb531ad65f3
setvar).
I mistakenly reasoned that setvar would be used on all channels. Since it can
be set per channel, give each dahdi channel a copy of the variable.
(related to #15899)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222351 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The setvar line in chan_dahdi.conf is shared among all the channels, so make
sure to only free the resources only when the last channel is destroyed.
(closes issue #15899)
Reported by: tzafrir
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222298 65c4cc65-6c06-0410-ace0-fbb531ad65f3
dahdievent_to_analogevent used a simple switch statement to convert DAHDI
event numbers to "ANALOG_*" event numbers. However "digit" events
(DAHDI_EVENT_PULSEDIGIT, DAHDI_EVENT_DTMFDOWN, DAHDI_EVENT_DTMFUP)
are accompannied by the digit in the low word of the event number.
This fix makes dahdievent_to_analogevent() return the event number as-is
for such an event.
This is also required to fix#15924 (in addition to r222108).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222237 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r222152 | kpfleming | 2009-10-05 20:16:36 -0500 (Mon, 05 Oct 2009) | 20 lines
Fix ao2_iterator API to hold references to containers being iterated.
See Mantis issue for details of what prompted this change.
Additional notes:
This patch changes the ao2_iterator API in two ways: F_AO2I_DONTLOCK
has become an enum instead of a macro, with a name that fits our
naming policy; also, it is now necessary to call
ao2_iterator_destroy() on any iterator that has been
created. Currently this only releases the reference to the container
being iterated, but in the future this could also release other
resources used by the iterator, if the iterator implementation changes
to use additional resources.
(closes issue #15987)
Reported by: kpfleming
Review: https://reviewboard.asterisk.org/r/383/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222176 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Many T.38 endpoints incorrectly send the maximum IFP frame size they can accept
as the T38FaxMaxDatagram value in their SDP, when in fact this value is
supposed to be the maximum UDPTL payload size (datagram size) they can accept.
If the value they supply is small enough (a commonly supplied value is '72'),
T.38 UDPTL transmissions will likely fail completely because the UDPTL packets
will not have enough room for a primary IFP frame and the redundancy used for
error correction. If this occurs, the Asterisk UDPTL stack will emit log messages
warning that data loss may occur, and that the value may need to be overridden.
This patch extends the 't38pt_udptl' configuration option in sip.conf to allow
the administrator to override the value supplied by the remote endpoint and
supply a value that allows T.38 FAX transmissions to be successful with that
endpoint. In addition, in any SIP call where the override takes effect, a debug
message will be printed to that effect. This patch also removes the
T38FaxMaxDatagram configuration option from udptl.conf.sample, since it has not
actually had any effect for a number of releases.
In addition, this patch cleans up the T.38 documentation in sip.conf.sample
(which incorrectly documented that T.38 support was passthrough only).
(issue #15586)
Reported by: globalnetinc
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222110 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The reported bug was actually only for pulsedigit, dtmfup, and dtmfdown
handling. Also added recognition for fax events (just some verbose output) and
fixed handling for the ec_disabled_event. In order to make comparing the analog
version of events to the DAHDI events easier, the ordering has been changed to
follow that of the DAHDI events.
(closes issue #15924)
Reported by: tzafrir
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222108 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r221769 | rmudgett | 2009-10-01 18:18:28 -0500 (Thu, 01 Oct 2009) | 26 lines
Occasionally losing use of B channels in chan_misdn.
I have not been able to reproduce the problem of losing channels.
However, I have seen in the code a reentrancy problem that might give
these symptoms.
The reentrancy patch does several things:
1) Guards B channel and B channel structure allocation.
2) Makes the B channel structure find routines more precise in locating records.
3) Never leave a B channel allocated if we received cause 44.
The last item may cause temporary outgoing call problems, but they should
clear when the line becomes idle.
(closes issue #15490)
Reported by: slutec18
Patches:
issue15490_channel_alloc_reentrancy.patch uploaded by rmudgett (license 664)
Tested by: rmudgett, slutec18
(closes issue #15458)
Reported by: FabienToune
Patches:
issue15458_channel_alloc_reentrancy.patch uploaded by rmudgett (license 664)
Tested by: FabienToune, rmudgett, slutec18
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@221844 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The PRI channels can no longer change the channel name if a different B
channel is selected during call negotiation. To prevent using the channel
name to infer what B channel a call is using and to avoid name collisions,
the channel name format is changed.
The new channel naming for PRI channels is:
DAHDI/ISDN-<span>-<sequence-number>
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@221701 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r221360 | mnicholson | 2009-09-30 14:36:06 -0500 (Wed, 30 Sep 2009) | 10 lines
Fix SRV lookup and Request-URI generation in chan_sip.
This patch adds a new field "portinuri" to the sip dialog struct and the sip peer struct. That field is used during RURI generation to determine if the port should be included in the RURI. It is also used in some places to determine if an SRV lookup should occur.
(closes issue #14418)
Reported by: klaus3000
Tested by: klaus3000, mnicholson
Review: https://reviewboard.asterisk.org/r/369/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@221432 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r221086 | twilson | 2009-09-30 09:49:11 -0500 (Wed, 30 Sep 2009) | 25 lines
Change the SSRC by default when our media stream changes
Be default, change SSRC when doing an audio stream changes Asterisk doesn't
honor marker bit when reinvited to already-bridged RTP streams,resulting in
far-end stack discarding packets with "old" timestamps that areactually part of
a new stream. This patch sends AST_CONTROL_SRCUPDATE whenever there is a
reinvite, unless the 'constantssrc' is set to true in sip.conf.
The original issue reported to Digium support detailed the following situation:
ITSP <-> Asterisk 1.4.26.2 <-> SIP-based Application Server Call comes in
fromITSP, Asterisk dials the app server which sends a re-invite back
toAsterisk--not to negotiate to send media directly to the ITSP, but to
indicatethat it's changing the stream it's sending to Asterisk. The app
servergenerates a new SSRC, sequence numbers, timestamps, and sets the marker
bit on the new stream. Asterisk passes through the teimstamp of the new stream,
butdoes not reset the SSRC, sequence numbers, or set the marker bit.
When the timestamp on the new stream is older than the timestamp on the
originalstream, the ITSP (which doesn't know there has been any change) discards
the newframes because it thinks they are too old. This patch addresses this by
changing the SSRC on a stream update unless constantssrc=true is set in
sip.conf.
Review: https://reviewboard.asterisk.org/r/374/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@221266 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r220873 | tilghman | 2009-09-29 12:59:26 -0500 (Tue, 29 Sep 2009) | 9 lines
Reduce CPU usage related to building a peer merely for devicestates.
This fixes a 100% CPU problem in the SIP driver, found by profiling
the driver while the problem was occurring.
(closes issue #14309)
Reported by: pkempgen
Patches:
20090924__issue14309.diff.txt uploaded by tilghman (license 14)
Tested by: pkempgen, vrban
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@220906 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Check for remotesecret option was unintentionally always true, which therefore
caused the secret option to never be used. Thanks to dvossel for pointing out
the exact fix.
(closes issue #15943)
Reported by: tpsast
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@220718 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Kevin P. Fleming
Joshua Colp
David Vossel
Richard Mudgett
Matthew Nicholson
Jeff Peeler
Mark Michelson
Tzafrir Cohen
Tilghman Lesher
Olle Johansson
Terry Wilson