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
JABBER_RECEIVE (along with JabberSend) makes Asterisk interact with users over
XMPP to process calls.
SendText can be used instead of JabberSend in the context of XMPP based voice
channels (chan_gtalk and chan_jingle).
(closes issue #12569)
Reported by: eech55
Tested by: phsultan, asannucci, lmadsen, jtodd, maxgo
Review: https://reviewboard.asterisk.org/r/88/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@220457 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r219519 | dvossel | 2009-09-18 18:19:50 -0500 (Fri, 18 Sep 2009) | 9 lines
iax2 frame double free
The iax frame's retrans sched id was written over right
before iax2_frame_free was called. In iax2_frame_free that
retrans id is used to delete the sched item. By writing over
the retrans field before the sched item could be deleted, it was
possible for a retransmit to occur on a freed frame.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@219520 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r219450 | dvossel | 2009-09-18 11:19:15 -0500 (Fri, 18 Sep 2009) | 14 lines
via-header branches not updated correctly on INVITE
INVITE requests must always contain a new unique branch id. When
a new branch id is created for an INVITE, the dialog's invite_branch
variable must be updated so CANCEL requests use the correct branch id.
(closes issue #15262)
Reported by: maniax
Patches:
asterisk-1.6.1.0-sip-branch.patch uploaded by tweety (license 608)
invite_new_branch_trunk.diff uploaded by dvossel (license 671)
Tested by: maniax, dvossel
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@219451 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r219303 | dvossel | 2009-09-17 16:29:37 -0500 (Thu, 17 Sep 2009) | 21 lines
INVITE w/Replaces deadlock fix
This patch cleans up the locking logic in chan_sip.c's
handle_invite_replaces() function as well as making use
of ast_do_masquerade() rather than forcing the masquerade
on an ast_read(). The code had several redundant unlocks
that would result in 'freed more times than we've locked!'
errors. I cleaned these up as well as moving all the unlock
logic to the end of the function. This patch should also
resolve the issue people were having with the replacecall
channel never being unlocked with one legged calls.
(closes issue #15151)
Reported by: irroot
Patches:
invite_w_replaces_1.4.diff uploaded by dvossel (license 671)
Tested by: irroot, dvossel
Review: https://reviewboard.asterisk.org/r/371/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@219304 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This way, we don't always write a null byte into
byte 1 of the buffer
(closes issue #15905)
Reported by: ebroad
Patches:
freadfix.patch uploaded by ebroad (license 878)
Tested by: ebroad
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@218933 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This was preventing responses from being properly processed because the packet was not being found
causing handle_response to return prematurely.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@218918 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Remove thread_spawned in handle_init_event since it was never used
* Always check handle_init_event in case a channel is destroyed
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@218583 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r218401 | jpeeler | 2009-09-14 16:47:11 -0500 (Mon, 14 Sep 2009) | 11 lines
Fix handling of DAHDI_EVENT_REMOVED event to prevent crash in do_monitor.
After talking to rmudgett about some of his recent iflist locking changes, it
was determined that the only place that would destroy a channel without being
explicitly to do so was in handle_init_event. The loop to walk the interface
list has been modified to wait to destroy the channel until the dahdi_pvt of
the channel to be destroyed is no longer needed.
(closes issue #15378)
Reported by: samy
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@218430 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the course of this, I also found that the results of ast_gethostbyname
were being used incorrectly in both chan_iax2 and chan_sip, so both have
been fixed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@217916 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fixed walking the iflist so it is always done with the iflock locked.
* Simplified iflist walking routines.
* Created chan_dahdi iflist insertion and extraction routines.
* Fixed duplicate_pseudo() malloc fail handling.
* Fixed infinite loop in action_dahdishowchannels() when showing a single channel.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@217912 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r217806 | dvossel | 2009-09-10 16:06:07 -0500 (Thu, 10 Sep 2009) | 22 lines
IAX2 encryption regression
The IAX2 Call Token security patch inadvertently broke the use of
encryption due to the reorganization of code in the socket_process()
function. When encryption is used, an incoming full frame must first
be decrypted before the information elements can be parsed. The
security release mistakenly moved IE parsing before decryption in
order to process the new Call Token IE. To resolve this, decryption
of full frames is once again done before looking into the frame. This
involves searching for an existing callno, checking the pvt to see if
encryption is turned on, and decrypting the packet before the internal
fields of the full frame are accessed.
(closes issue #15834)
Reported by: karesmakro
Patches:
iax2_encryption_fix_1.4.diff uploaded by dvossel (license 671)
Tested by: dvossel, karesmakro
Review: https://reviewboard.asterisk.org/r/355/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@217807 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes the problem that would occur if an analog phone was picked up while
the caller id was being sent. The caller id before sent the whole spill even
after pickup and is now corrected.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@217744 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Related to #12713
Patch by oej
A big thank you to file for finally fixing the transfer() dialplan application.
I've been waiting for years for this. Great work!
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@217482 65c4cc65-6c06-0410-ace0-fbb531ad65f3
parse_uri was not being given the correct scheme's, as
a result, uri parsing did not parse the username correctly.
One of the side effects of this is an empty caller id.
(closes issue #15839)
Reported by: ebroad
Patches:
blank_cidv2.patch uploaded by ebroad (license 878)
parse_uri_fix.diff uploaded by dvossel (license 671)
Tested by: ebroad, dvossel
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@216993 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Remove unused string in sip_registry -- "random"
- Someone added a function in the middle of all forward declarations... Weird. Moved it out of that
section.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@216905 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Add variable for number of known media streams instead of hardcoding in definition of sip_pvt
- Rename "text" to "codecs" - beacuse it's what it is
- Add documentation for future developers so that we make sure that we define new sdp media types
for SRTP-variants
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@216883 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r216430 | oej | 2009-09-04 15:45:48 +0200 (Fre, 04 Sep 2009) | 27 lines
Make apps send PROGRESS control frame for early media and fix too early media issue in SIP
The issue at hand is that some legacy (dying) PBX systems send empty media frames on PRI
links *before* any call progress. The SIP channel receives these frames and by default
signals 183 Session progress and starts sending media. This will cause phones to
play silence and ignore the later 180 ringing message. A bad user experience.
The fix is twofold:
- We discovered that asterisk apps that support early media ("noanswer") did not send
any PROGRESS frame to indicate early media. Fixed.
- We introduce a setting in chan_sip so that users can disable any relay of media frames
before the outbound channel actually indicates any sort of call progress.
In 1.4, 1.6.0 and 1.6.1, this will be disabled for backward compatibility. In later versions
of Asterisk, this will be enabled. We don't assume that it will change your Asterisk
phone experience - only for the better.
We encourage third-party application developers to make sure that if they have applications
that wants to send early media, add a PROGRESS control frame transmission to make sure that
all channel drivers actually will start sending early media. This has not been the default
in Asterisk previous to this patch, so if you got inspiration from our code, you need to
update accordingly. Sorry for the trouble and thanks for your support.
This code has been running for a few months in a large scale installation (over 250
servers with PRI and/or BRI links to old PBX systems).
That's no proof that this is an excellent patch, but, well, it's tested :-)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@216438 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There was a problem in the function responsible for doing peer matching by
IP address and port number such that during the second pass for checking for
a peer configured with insecure=port, it would end up treating every peer as
if it had been configured that way. These changes fix the logic in the peer
IP and port comparison callback to handle insecure=port checking properly.
This problem was introduced when SIP peers were converted to astobj2. Many
thanks to dvossel for noticing this while working on another peer matching
issue.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@216368 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added detection of DTMF tone energy levels on FXO channels in chan_dahdi
monitoring loop so DTMF CID can be detected without the need of a polarity
change precursor.
(closes issue #9096)
Reported by: fleed
Patches:
9096-chan_dahdi-trunk.diff uploaded by dbailey (license 819)
Tested by: cyberplant, sum, maturs
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@216094 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r215682 | twilson | 2009-09-02 16:41:22 -0500 (Wed, 02 Sep 2009) | 18 lines
Re-send non-100 provisional responses to prevent cancellation
From section 13.3.1.1 of RFC 3261:
If the UAS desires an extended period of time to answer the INVITE,
it will need to ask for an "extension" in order to prevent proxies
from canceling the transaction. A proxy has the option of canceling
a transaction when there is a gap of 3 minutes between responses in a
transaction. To prevent cancellation, the UAS MUST send a non-100
provisional response at every minute, to handle the possibility of
lost provisional responses.
(closes issue #11157)
Reported by: rjain
Tested by: twilson
Review: https://reviewboard.asterisk.org/r/315/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@215758 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are several instances where a port is parsed
from a uri or some other source and converted to
an int value using atoi(), if for some reason the
port string is empty, then a standard port is used.
This logic is used over and over, so I created a function
to handle it in a safer way using sscanf().
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@215681 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If we had this from the start, debugging the 'parking not using configured parkinglot'
bug would have been easier.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@215665 65c4cc65-6c06-0410-ace0-fbb531ad65f3
made analog_set_linear_mode return back the mode that was being overwritten
so it could be restored later.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@215608 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Now, the scheme passed to parse_uri can either be a
single scheme, or a list of schemes ',' delimited.
This gets rid of the whole problem of having to create
two buffers and calling parse_uri twice to check for
separate schemes.
Review: https://reviewboard.asterisk.org/r/343/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@215522 65c4cc65-6c06-0410-ace0-fbb531ad65f3
keep-alive events are used by Sipura/Linksys for NAT keepalive.
There currently don't appear to be any problems with NAT, but
everytime a keep-alive event is received, Asterisk responds with a
"489 Bad event". This error may indicate to a user that NAT
problems exist just because this even is not supported. Now,
rather than respond with an error, the packet is consumed and
a "200 ok" is sent just to indicate we received the packet.
(issue #15084)
Patches:
chan_sip.keepalive.v1.diff uploaded by IgorG (license 20)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@215466 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Thank oej for pointing out the fact that sip_new did not copy parkinglot from the peer
into the newly created channel.
(closes issue #15538)
Reported by: gracedman
Patches:
2009090100_sipnewparkinglot-161.diff.txt uploaded by mvanbaak (license 7)
With mod by me to also fix callparking as well (this uploaded patch only fixed retrieving a parked call)
Tested by: gracedman, mvanbaak
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@215462 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Allows characters that are otherwise used as delimiters to be used within
certain fields (like the secret).
(closes issue #15008, closes issue #15672)
Reported by: tilghman
Patches:
20090818__issue15008.diff.txt uploaded by tilghman (license 14)
Tested by: lmadsen, tilghman
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@213098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Add Connected Line Presentation (COLP) support to chan_dahdi/libpri as an
addition to issue 8824. This is the chan_dahdi/sig_pri portion. COLP
support is now available for any switch for which libpri supports COLP
(currently ETSI PTP, ETSI PTMP, and Q.SIG) with this patch.
(closes issue #14068)
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/340/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@213007 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r212498 | jpeeler | 2009-08-17 11:34:56 -0500 (Mon, 17 Aug 2009) | 12 lines
Fix segfault when reloading chan_misdn.
If more ports were specified than configured in misdn.conf a reload would crash
asterisk. The problem was the unconfigured port was using data from the
previously configured port. When the data for an unconfigured port was freed a
crash would result from the double free.
(closes issue #12113)
Reported by: agupta
Patches:
bug12113.patch uploaded by jpeeler (license 325)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@212506 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* confirmanswer option now respected
* check and set waiting for dialtone timer
* unneeded needcallerid flag removed from analog_subchannel
* ss_astchan does not need to be a void pointer
* swap_channels callback updated to trunk
* analog_hangup now resets channel to default law
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@212287 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ETSI 300-196 implies that a facility return result without arguments does
not have the operation-value. This fact implies for ETSI that you can
only use the invoke-id to match requests with responses.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@212199 65c4cc65-6c06-0410-ace0-fbb531ad65f3
dahdi_read relies on the dahdi_pvt copy of ringt which was not getting set
in sig_analog. This patch adds a callback to do so.
(closes issue #15288)
Reported by: alecdavis
Patches:
chan_dahdi.ringtimeout.diff.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@211908 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change uses separate values for the acceptable minimum expiry provided by the 423 error and the expiry value stored in the configuration file. Previously, the value pulled from the configuration file would be overwritten.
(closes issue #14366)
Reported by: Nick_Lewis
Patches:
sip-expiry-fix1.diff uploaded by mnicholson (license 96)
chan_sip.c-reqexpiry.patch uploaded by Nick (license 657)
Tested by: mnicholson
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@211876 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes a crash reported in #asterisk-dev where chan_mgcp unexpectedly
allocated an RTP instance from res_rtp_multicast, since by not specifying an
engine, you get the first one in the list of engines.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@211732 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Created the dahdi_sig_pri_lib_handles() function and
SIG_PRI_LIB_HANDLE_CASES macro to simplify testing for which signaling
styles are handled by sig_pri.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@211675 65c4cc65-6c06-0410-ace0-fbb531ad65f3
like we have in chan_sip
(closes issue #15499)
Reported by: arifzaman
Patches:
2009072600-skinnymanagerevents.diff.txt uploaded by mvanbaak (license 7)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@211475 65c4cc65-6c06-0410-ace0-fbb531ad65f3
You cannot cast the struct dahdi_pvt.sig_pvt pointer to a specific
signaling private pointer without first checking that it is in fact
pointing to the correct signaling private structure.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@211197 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Discussion of this subject has yielded that it is not actually acceptable to change
T.38 parameters after the initial reinvite but declining is harsh and can cause the
fax to fail when it may be possible to allow it to continue. This patch changes things
so that additional T.38 reinvites are accepted but parameter changes ignored. This gives
the fax a fighting chance.
(closes issue #15610)
Reported by: huangtx2009
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@210817 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r210575 | rmudgett | 2009-08-05 14:18:56 -0500 (Wed, 05 Aug 2009) | 14 lines
Dialplan starts execution before the channel setup is complete.
* Issue 15655: For the case where dialing is complete for an incoming
call, dahdi_new() was asked to start the PBX and then the code set more
channel variables. If the dialplan hungup before these channel variables
got set, asterisk would likely crash.
* Fixed potential for overlap incoming call to erroneously set channel
variables as global dialplan variables if the ast_channel structure failed
to get allocated.
* Added missing set of CALLINGSUBADDR in the dialing is complete case.
(closes issue #15655)
Reported by: alecdavis
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@210640 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It is clear from multiple mailing list, forum, wiki and other sorts of posts
that users don't really understand the effects that the 'canreinvite' config
option actually has, and that in some cases they think that setting it to 'no'
will actually cause various other features (T.38, MOH, etc.) to not work properly,
when in fact this is not the case. This patch changes the proper name of the
option to what it should have been from the beginning ('directmedia'), but
preserves backwards compatibility for existing configurations.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@210190 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Moved SUPPORT_USERUSER to sig_pri.c
* Fix PRI_DEADLOCK_AVOIDANCE parameter.
* Whitespace changes.
* Added missing unlock in pri_dchannel():PRI_EVENT_RING case.
* Balanced curly braces.
* ast_debug/ast_log changes from chan_dahdi.
* sig_pri_indicate() should default to return -1 if the indication is not
handled.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@210154 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r209759 | kpfleming | 2009-07-31 19:52:00 -0500 (Fri, 31 Jul 2009) | 7 lines
Minor changes inspired by testing with latest GCC.
The latest GCC (what will become 4.5.x) has a few new warnings, that in these
cases found some either downright buggy code, or at least seriously poorly
designed code that could be improved.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@209760 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The previous effort here was to store what a peer is capable of receiving by parsing REGISTER
requests from the peer and keeping that information for as long as the registration was active.
The problem with this is that there are a great number of SIP devices which give no indication
of the methods allowed in their REGISTER requests, and it is unreasonable to try to guess what
the device may or may not support. In addition, some SIP devices have been found to claim support
for a specific method, but their handling the method is less than ideal, or they are actually
lying.
With this patch, we now determine what methods a device supports by parsing the Allow header we
receive from them, and we do this with each new dialog. In addition, a configuration option has
been added so that an administrator can essentially blacklist certain methods from being used
with certain peers if the admin knows that support for a specific method is dodgy or nonexistent.
ABE-1822
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@209673 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r208746 | jpeeler | 2009-07-25 01:19:50 -0500 (Sat, 25 Jul 2009) | 7 lines
Fix compiling under dev-mode with gcc 4.4.0.
Mostly trivial changes, but I did not know of any other way to fix the
"dereferencing type-punned pointer will break strict-aliasing rules" error
without creating a tmp variable in chan_skinny.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208749 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r208587 | mmichelson | 2009-07-24 13:26:50 -0500 (Fri, 24 Jul 2009) | 10 lines
Only send a BYE when hanging up a channel that is up.
For cases where Asterisk sends an INVITE and receives a non 2XX final
response, Asterisk would follow the INVITE transaction by immediately
sending a BYE, which was unnecessary.
(closes issue #14575)
Reported by: chris-mac
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208588 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The udptl-updates branch that was merged yesterday failed to properly send back
T.38 SDP responses with the correct error correction mode, if the incoming SDP
from the other end caused us to change error correction modes. This patch
corrects that situation.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208548 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Over the past couple of months, a number of issues with Asterisk
negotiating (and successfully completing) T.38 sessions with various
endpoints have been found. This patch attempts to address many of
them, primarily focused around ensuring that the endpoints'
MaxDatagram size is honored, and in addition by ensuring that T.38
session parameter negotiation is performed correctly according to the
ITU T.38 Recommendation.
The major changes here are:
1) T.38 applications in Asterisk (app_fax) only generate/receive IFP
packets, they do not ever work with UDPTL packets. As a result of
this, they cannot be allowed to generate packets that would overflow
the other endpoints' MaxDatagram size after the UDPTL stack adds any
error correction information. With this patch, the application is told
the maximum *IFP* size it can generate, based on a calculation using
the far end MaxDatagram size and the active error correction mode on
the T.38 session. The same is true for sending *our* MaxDatagram size
to the remote endpoint; it is computed from the value that the
application says it can accept (for a single IFP packet) combined with
the active error correction mode.
2) All treatment of T.38 session parameters as 'capabilities' in
chan_sip has been removed; these parameters are not at all like
audio/video stream capabilities. There are strict rules to follow for
computing an answer to a T.38 offer, and chan_sip now follows those
rules, using the desired parameters from the application (or channel)
that wants to accept the T.38 negotiation.
3) chan_sip now stores and forwards ast_control_t38_parameters
structures for tracking 'our' and 'their' T.38 session parameters;
this greatly simplifies negotiation, especially for pass-through
calls.
4) Since T.38 negotiation without specifying parameters or receiving
the final negotiated parameters is not very worthwhile, the
AST_CONTROL_T38 control frame has been removed. A note has been added
to UPGRADE.txt about this removal, since any out-of-tree applications
that use it will no longer function properly until they are upgraded
to use AST_CONTROL_T38_PARAMETERS.
Review: https://reviewboard.asterisk.org/r/310/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r208386 | mmichelson | 2009-07-23 14:24:21 -0500 (Thu, 23 Jul 2009) | 17 lines
Fix a problem where a 491 response could be sent out of dialog.
This generalizes the fix for issue 13849. The initial fix corrected the
problem that Asterisk would reply with a 491 if a reinvite were received
from an endpoint and we had not yet received an ACK from that endpoint
for the initial INVITE it had sent us. This expansion also allows Asterisk
to appropriately handle an INVITE with authorization credentials if Asterisk
had not received an ACK from the previous transaction in which Asterisk had
responded to an unauthorized INVITE with a 407.
(closes issue #14239)
Reported by: klaus3000
Patches:
14239.patch uploaded by mmichelson (license 60)
Tested by: klaus3000
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208388 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The wrong logic was being used in chan_dahdi to convert a sig_pri_chan
to the proper libpri channel number. The most significant bit must only
be set only when trunk groups are being used.
(closes issue #15452)
Reported by: alecdavis
Patches:
bug15452.patch uploaded by jpeeler (license 325)
Tested by: alecdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208267 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Pointed out by Matt F.
Also in the case of not using a signaling module, set the law back to the
default as well.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208155 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r207827 | jpeeler | 2009-07-21 15:16:55 -0500 (Tue, 21 Jul 2009) | 9 lines
Wait for wink before dialing when using E&M wink signaling
There was already code for other signaling types in dahdi_handle_event to
handle dialing if a dial operation dial string was present. Simply add
SIG_EMWINK to the list.
(closes issue #14434)
Reported by: araasch
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@207854 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r207647 | kpfleming | 2009-07-21 08:04:44 -0500 (Tue, 21 Jul 2009) | 12 lines
Ensure that user-provided CFLAGS and LDFLAGS are honored.
This commit changes the build system so that user-provided flags (in ASTCFLAGS
and ASTLDFLAGS) are supplied to the compiler/linker *after* all flags provided
by the build system itself, so that the user can effectively override the
build system's flags if desired. In addition, ASTCFLAGS and ASTLDFLAGS can now
be provided *either* in the environment before running 'make', or as variable
assignments on the 'make' command line. As a result, the use of COPTS and LDOPTS
is no longer necessary, so they are no longer documented, but are still supported
so as not to break existing build systems that supply them when building Asterisk.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@207680 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The registration string can contain an expanded user portion of the
form user@domain. This expanded user portion was stored in
reg->username and parsed each time there is a registration refresh.
Now, the domain portion of the user is parsed and stored separately
in the regdomain field.
(closes issue #14331)
Reported by: Nick_Lewis
Patches:
chan_sip.c.domainparse3.patch uploaded by Nick (license 657)
Tested by: Nick_Lewis, dvossel
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@207484 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r207423 | mmichelson | 2009-07-20 14:39:59 -0500 (Mon, 20 Jul 2009) | 33 lines
Answer video SDP offers properly when videosupport is not enabled.
Copied from Review board:
In issue 12434, the reporter describes a situation in which audio and video
is offered on the call, but because videosupport is disabled in sip.conf,
Asterisk gives no response at all to the video offer. According to RFC 3264,
all media offers should have a corresponding answer. For offers we do not
intend to actually reply to with meaningful values, we should still reply
with the port for the media stream set to 0.
In this patch, we take note of what types of media have been offered and
save the information on the sip_pvt. The SDP in the response will take into
account whether media was offered. If we are not otherwise going to answer
a media offer, we will insert an appropriate m= line with the port set to 0.
It is important to note that this patch is pretty much a bandage being
applied to a broken bone. The patch *only* helps for situations where video
is offered but videosupport is disabled and when udptl_pt is disabled but
T.38 is offered. Asterisk is not guaranteed to respond to every media offer.
Notable cases are when multiple streams of the same type are offered.
The 2 media stream limit is still present with this patch, too.
In trunk and the 1.6.X branches, things will be a bit different since Asterisk
also supports text in SDPs as well.
(closes issue #12434)
Reported by: mnnojd
Review: https://reviewboard.asterisk.org/r/311
Review: https://reviewboard.asterisk.org/r/313
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@207424 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/be/branches/C.2-...
..........
r207316 | rmudgett | 2009-07-17 23:05:05 -0500 (Fri, 17 Jul 2009) | 20 lines
Fixed incoming calls being matched to MSNs without type-of-number prefix added.
For an incoming ISDN call the dialed.number is incorrectly matched against
the configured MSNs in misdn.conf. The numbers passed to the dialplan
include the configured prefix for the dialed.number_type, whereas the
check against the configured MSNs (to decide if the call is accepted at
all), is executed without the configured prefix.
e.g., dialed.number = 241168020, TON = national, configured national
prefix is "0". (This is the TON which is used by ISDN providers in the
Netherlands.)
In chan_misdn.c:cb_events() in case EVENT_SETUP the call to
misdn_cfg_is_msn_valid() uses the unnormalized number 241168020, but 57
lines later the call to read_config() adds the prefix, and the
dialed.number is now 0241168020, which is then used in the dialplan.
misdn_cfg_is_msn_valid() must use the normalized number, too.
JIRA ABE-1912
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@207318 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Sig_analog handles allocating the sub channel for callwaiting, so no longer try
to do it in chan_dahdi. Modified analog_alloc_sub to only mark the sub as
allocated upon success of the alloc_sub callback, which was responsible for the
segfault. Also, the callwaiting and callwaitingcallerid options were being
unconditionally set to true. Now, the options are properly set from
chan_dahdi.conf.
(closes issue #15508)
Reported by: elguero
Tested by: elguero
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@206998 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r206938 | dvossel | 2009-07-17 11:05:06 -0500 (Fri, 17 Jul 2009) | 14 lines
SIP incorrect From: header information when callpres is prohib
Some ITSP make use of the "Anonymous" display name to detect a
requirement to withhold caller id across the PSTN. This does
not work if the display name is "Unknown".
(closes issue #14465)
Reported by: Nick_Lewis
Patches:
chan_sip.c-callerpres.patch uploaded by Nick (license 657)
chan_sip.c-callerpres_trunk.patch uploaded by dvossel (license 671)
Tested by: Nick_Lewis, dvossel
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@206939 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This readds the proper setting of the flag and is really a continuation of
r205731. The flag was being set properly in sig_analog, but use of the
newly added set_dialing callback allowed for some simplification in
chan_dahdi.
(closes issue #15486)
Reported by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@206767 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r206706 | rmudgett | 2009-07-15 15:44:55 -0500 (Wed, 15 Jul 2009) | 26 lines
Merged revision 206700 from
https://origsvn.digium.com/svn/asterisk/be/branches/C.2-...
..........
Fixed chan_misdn crash because mISDNuser library is not thread safe.
With Asterisk the mISDNuser library is driven by two threads concurrently:
1. channels/misdn/isdn_lib.c::manager_event_handler()
2. channels/misdn/isdn_lib.c::misdn_lib_isdn_event_catcher()
Calls into the library are done concurrently and recursively from
isdn_lib.c.
Both threads can fiddle with the master/child layer3_proc_t lists. One
thread may traverse the list when the other interrupts it and then removes
the list element which the first thread was currently handling. This is
exactly what caused the crash. About 60 calls were needed to a Gigaset
CX475 before it occurred once.
This patch adds locking when calling into the mISDNuser library.
This also fixes some cb_log calls with wrong port parameter.
JIRA ABE-1913
Patches: misdn-locking.patch (Modified with mostly cosmetic changes)
..........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@206707 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A domain only sip uri <sip:123.123.123.123> would return
123.123.123.123 as callid num. Now, if the username is
missing from a uri, the callerid num field is left empty.
(closes issue #15476)
Reported by: viraptor
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@206702 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The main purpose of this commit is to restore missing functionality present in
the ss_thread before all the sig related work was done. Two of the biggest
missing things were distinctive ring detection and cid handling for V23.
fxsoffhookstate and associated mwi variables have been moved inside sig_analog
as they were not being set properly as well.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@206566 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r206487 | rmudgett | 2009-07-14 11:44:47 -0500 (Tue, 14 Jul 2009) | 28 lines
Fixes several call transfer issues with chan_misdn.
* issue #14355 - Crash if attempt to transfer a call to an application.
Masquerade the other pair of the four asterisk channels involved in the
two calls. The held call already must be a bridged call (not an
applicaton) or it would have been rejected.
* issue #14692 - Held calls are not automatically cleared after transfer.
Allow the core to initate disconnect of held calls to the ISDN port. This
also fixes a similar case where the party on hold hangs up before being
transferred or taken off hold.
* JIRA ABE-1903 - Orphaned held calls left in music-on-hold.
Do not simply block passing the hangup event on held calls to asterisk
core.
* Fixed to allow held calls to be transferred to ringing calls.
Previously, held calls could only be transferred to connected calls.
* Eliminated unused call states to simplify hangup code.
* Eliminated most uses of "holded" because it is not a word.
(closes issue #14355)
(closes issue #14692)
Reported by: sodom
Patches:
misdn_xfer_v14_r205839.patch uploaded by rmudgett (license 664)
Tested by: rmudgett
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@206489 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r206385 | russell | 2009-07-14 09:48:00 -0500 (Tue, 14 Jul 2009) | 13 lines
Merged revisions 206384 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r206384 | russell | 2009-07-14 09:45:47 -0500 (Tue, 14 Jul 2009) | 6 lines
Ensure apathetic replies are sent out on the proper socket.
chan_iax2 supports multiple address bindings. The send_apathetic_reply()
function did not attempt to send its response on the same socket that the
incoming message came in on.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@206386 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If callbackextension is defined for a peer it successfully causes
a registration to occur, but the registration ignores the
outboundproxy settings for the peer. This patch allows the
peer to be passed to obproxy_get() in transmit_register().
(closes issue #14344)
Reported by: Nick_Lewis
Patches:
callbackextension_peer_trunk.diff uploaded by dvossel (license 671)
Tested by: dvossel
Review: https://reviewboard.asterisk.org/r/294/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205985 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r205804 | dvossel | 2009-07-10 11:23:59 -0500 (Fri, 10 Jul 2009) | 31 lines
SIP registration auth loop caused by stale nonce
If an endpoint sends two registration requests in a very short
period of time with the same nonce, both receive 401 responses
from Asterisk, each with a different nonce (the second 401
containing the current nonce and the first one being stale).
If the endpoint responds to the first 401, it does not match
the current nonce so Asterisk sends a third 401 with a newly
generated nonce (which updates the current nonce)... Now if
the endpoint responds to the second 401, it does not match the
current nonce either and Asterisk sends a fourth 401 with a
newly generated nonce... This loop goes on and on.
There appears to be a simple fix for this. If the nonce from
the request does not match our nonce, but is a good response
to a previous nonce, instead of sending a 401 with a newly
generated nonce, use the current one instead. This breaks
the loop as the nonce is not updated until a response is
received. Additional logic has been added to make sure no
nonce can be responded to twice though.
(closes issue #15102)
Reported by: Jamuel
Patches:
patch-bug_0015102 uploaded by Jamuel (license 809)
nonce_sip.diff uploaded by dvossel (license 671)
Tested by: Jamuel
Review: https://reviewboard.asterisk.org/r/289/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205840 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r205775 | mmichelson | 2009-07-10 10:51:36 -0500 (Fri, 10 Jul 2009) | 10 lines
Ensure that outbound NOTIFY requests are properly routed through stateful proxies.
With this change, we make note of Record-Route headers present in any SUBSCRIBE
request that we receive so that our outbound NOTIFY requests will have the proper
Route headers in them.
(closes issue #14725)
Reported by: ibc
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205776 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Recent changes in T.38 negotiation in Asterisk caused these applications to
not respond when the other endpoint initiated a switchover to T.38; this
resulted in the T.38 switchover failing, and the FAX attempt to be made
using an audio connection, instead of T.38 (which would usually cause the
FAX to fail completely).
This patch corrects this problem, and the applications will now correctly
respond to the T.38 switchover request. In addition, the response will include
the appopriate T.38 session parameters based on what the other end offered
and what our end is capable of.
(closes issue #14849)
Reported by: afosorio
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205696 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also go back and wrap all of the places that use the specific reverse charge
APIs with preprocessor conditionals.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204919 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r204834 | rmudgett | 2009-07-02 16:59:43 -0500 (Thu, 02 Jul 2009) | 10 lines
Removed confusing warning message "Got Busy in Connected State"
If an incoming mISDN call is answered with the Answer application and a
subsequent Dial gets a busy endpoint then it is valid for that already
connected channel to get the busy indication. Asterisk will play the busy
tones until the dialplan plays something else or hangs up the call.
(closes issue #11974)
Reported by: fvdb
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204835 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is a continuation of revision 885 to LibPRI (Capture and expose the Reverse
Charging Indication IE on ISDN PRI) which added the ability to get/set Reverse
Charging Indication in LibPRI. This patch adds the ability to specify RCI on
the outbound leg of a PRI call from within Asterisk, by prefixing the dialed
number with a capital 'C' like:
...,Dial(DAHDI/g1/C4445556666)
And to read it off an inbound channel:
exten => s,1,Set(RCI=${CHANNEL(reversecharge)})
Thanks again to rmudgett for the thorough review.
(closes issue #13760)
Reported by: mrgabu
Review: https://reviewboard.asterisk.org/r/303/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204749 65c4cc65-6c06-0410-ace0-fbb531ad65f3
First of all, the code was unnecessary. The goal was to lock a channel
which was already locked. Second, the assumption of the deadlock avoidance
loop was that the sip_pvt was already locked and we were trying to get the
channel lock. The problem is that the sip_pvt was unlocked a few lines above.
Basically, I'm removing 5 lines of no-op.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204530 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r204300 | mmichelson | 2009-06-29 17:45:34 -0500 (Mon, 29 Jun 2009) | 9 lines
Add error message so that it is clear why a SIP peer was not processed when
a DNS lookup fails on a host or outboundproxy.
(closes issue #13432)
Reported by: p_lindheimer
Patches:
outboundproxy.patch uploaded by p (license 558)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204301 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r204243 | mmichelson | 2009-06-29 16:23:43 -0500 (Mon, 29 Jun 2009) | 22 lines
Fix a problem where chan_sip would ignore "old" but valid responses.
chan_sip has had a problem for quite a long time that would manifest when
Asterisk would send multiple SIP responses on the same dialog before receiving
a response. The problem occurred because chan_sip only kept track of the highest
outgoing sequence number used on the dialog. If Asterisk sent two requests out,
and a response arrived for the first request sent, then Asterisk would ignore
the response. The result was that Asterisk would continue retransmitting the
requests and ignoring the responses until the maximum number of retransmissions
had been reached.
The fix here is to rearrange the code a bit so that instead of simply comparing
the sequence number of the response to our latest outgoing sequence number, we
walk our list of outstanding packets and determine if there is a match. If there is,
we continue. If not, then we ignore the response.
In doing this, I found a few completely useless variables that I have now removed.
(closes issue #11231)
Reported by: flefoll
Review: https://reviewboard.asterisk.org/r/298
........
r204246 | mmichelson | 2009-06-29 16:37:05 -0500 (Mon, 29 Jun 2009) | 3 lines
Fix build oops.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204247 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r203908 | rmudgett | 2009-06-26 19:55:12 -0500 (Fri, 26 Jun 2009) | 16 lines
The ISDN CPE side should not exclusively pick B channels normally.
Before this patch, Asterisk unconditionally picked B channels exclusively
on the CPE side and normally allowed alternative B channels on the network
side. Now Asterisk does the opposite.
Reasons for the CPE side to normally not pick B channels exclusively:
* For CPE point-to-multipoint mode (i.e. phone side), the CPE side does
not have enough information to exclusively pick B channels. (There may be
other devices on the line.)
* Q.931 gives preference to the network side picking B channels.
* Some telcos require the CPE side to not pick B channels exclusively.
(closes issue #14383)
Reported by: mbrancaleoni
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203909 65c4cc65-6c06-0410-ace0-fbb531ad65f3
after a polarity reversal.
Previously on a polarity switch event chan_dahdi would set the channel
immediately as answered. This would cause problems if a polarity reversal
occurred when the line was picked up as the dial would not have yet occurred.
Now if the polarity reversal occurs before delay has elapsed after coming off
hook or an answer, it is ignored. Also, some refactoring was done in
_handle_event.
(closes issue #13917)
Reported by: alecdavis
Patches:
chan_dahdi.bug13917.feb09.diff2.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
CEL is the new system for logging channel events. This was inspired after
facing many problems trying to represent what is possible to happen to a call
in Asterisk using CDR records. For more information on CEL, see the built in
HTML or PDF documentation generated from the files in doc/tex/.
Many thanks to Steve Murphy (murf) and Brian Degenhardt (bmd) for their hard
work developing this code. Also, thanks to Matt Nicholson (mnicholson) and
Sean Bright (seanbright) for their assistance in the final push to get this
code ready for Asterisk trunk.
Review: https://reviewboard.asterisk.org/r/239/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203638 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This merge splits the PRI/BRI signaling logic out of chan_dahdi.c into
sig_pri.c. Functionality in theory should not change (mostly). A few trivial
changes were made in sig_analog with verbose messages and commenting.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203304 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Moved SETCADENCE ioctl call to before call into new analog signal module
to insure that it gets set.
(closes issue #15381)
Reported by: alecdavis
Patches:
fix15381.diff uploaded by dbailey (license 819)
Tested by: dbailey
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203126 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r203115 | russell | 2009-06-25 11:02:16 -0500 (Thu, 25 Jun 2009) | 11 lines
Resolve a crash related to a T.38 reinvite race condition.
This change resolves a crash observed locally during some T.38 testing.
A call was set up using a call file, and when the T.38 reinvite came in,
the channel state was still AST_STATE_DOWN. The reason is explained by
a comment in the code that previously lived in the handling of
AST_STATE_RINGING. This change modifies the logic to handle the same
race condition for any channel state that is not UP.
(closes ABE-1895)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203116 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r203036 | rmudgett | 2009-06-24 16:01:43 -0500 (Wed, 24 Jun 2009) | 8 lines
Improved chan_dahdi.conf pritimer error checking.
Valid format is: pritimer=timer_name,timer_value
* Fixed segfault if the ',' is missing.
* Completely check the range returned by pri_timer2idx() to prevent
possible access outside array bounds.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203037 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the outgoing_colp parameter is set to not send COLP information, then
it does not make sense to send redirecting or transfer messages announcing
new COLP information that is blocked. The service provider may supply the
listed number for that line when it passes the messages to the next hop.
Why tell the switch that these events happened when the information is
otherwise suppressed?
Also blocked the number of previous redirects that may have occurred to
calls going out the port when outgoing_colp is 2.
Follow on to JIRA ABE-1853.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@202755 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r202341 | mmichelson | 2009-06-22 09:42:55 -0500 (Mon, 22 Jun 2009) | 26 lines
Fix a situation in which Asterisk would not stop retransmitting 487s.
If a CANCEL were received by Asterisk, we would send a 487 in response
to the original INVITE and a 200 OK for the CANCEL. If there were a network
hiccup which caused the 200 OK and the 487 to be lost, then the UA communicating
with Asterisk may try to retransmit its CANCEL. Asterisk's response to this used
to be to try sending another 487 to the canceled INVITE and another 200 OK to the
CANCEL.
The problem here is that the originally-sent 487 was sent "reliably" meaning that
it will be retransmitted until it is received properly. So when we receive the second
CANCEL it is likely that the first batch of 487s we sent is still going strong and
reaches the UA. The result was that the second set of 487s would be retransmitted
constantly until the maximum number of retries had been reached.
The fix for this is that if we receive a second CANCEL for an INVITE, then we cancel
the retransmission of the first set of 487s and start a second set. This causes the
dialog to be terminated reasonably.
(closes issue #14584)
Reported by: klaus3000
Patches:
14584_v2.patch uploaded by mmichelson (license 60)
Tested by: klaus3000
........
r202342 | mmichelson | 2009-06-22 09:44:58 -0500 (Mon, 22 Jun 2009) | 3 lines
Remove an extra debug line left from previous commit.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@202343 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r202336 | mmichelson | 2009-06-22 09:34:05 -0500 (Mon, 22 Jun 2009) | 25 lines
Fix a possible infinite loop in SDP parsing during glare situation.
There was a while loop in get_ip_and_port_from_sdp which was controlled
by a call to get_sdp_iterate. The loop would exit either if what we were
searching for was found or if the return was NULL. The problem is that
get_sdp_iterate never returns NULL. This means that if what we were searching
for was not present, the loop would run infinitely. This modification of the
loop fixes the problem.
(closes issue #15213)
Reported by: schmidts
(closes issue #15349)
Reported by: samy
(closes issue #14464)
Reported by: pj
(closes issue #15345)
Reported by: aragon
Patches:
sip_inf_loop.patch uploaded by mmichelson (license 60)
Tested by: aragon
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@202337 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a transport type was specified, but no extension, parsing of the extension would return whatever was after the transport rather than defaulting to 's'.
(closes issue #15111)
Reported by: ffs
Patches:
chan_sip.c_register-parser.patch uploaded by ffs (license 730)
Tested by: ffs, dvossel
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@201570 65c4cc65-6c06-0410-ace0-fbb531ad65f3
chan_sip has an option to save the sysname on rtupdate. This patch copies that same logic to chan_iax.
(closes issue #14837)
Reported by: barthpbx
Patches:
iax2-rtsavesysname.patch uploaded by barthpbx (license 744)
rt_iax.diff uploaded by dvossel (license 671)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@201534 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A recent change to our SDP version comparison made audio not function
on some calls. This was because of a test wherein we were trying to
see if an unsigned value was less than 0. This is a dumb comparison
and arguably the compiler should have warned about it. Alas, though,
it slipped past. Now it's fixed by changing the variable to be a
signed type.
Found by several developers. Tested by mnicholson and dbrooks.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@201462 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r201380 | dbrooks | 2009-06-17 13:45:50 -0500 (Wed, 17 Jun 2009) | 9 lines
Checks for NULL sip_pvt pointer in chan_sip.c->acf_channel_read()
Zombie channels could be passed, and chan_sip.c wasn't checking for it.
Could crash Asterisk. Now checking for NULL pointer.
(closes issue #15330)
Reported by: okrief
Tested by: dbrooks
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@201381 65c4cc65-6c06-0410-ace0-fbb531ad65f3
During a sip reload, the list of sip_registry objects are
supposed to be traversed, unlinked, and destroyed, but
destruction never takes place due to a ref counting error.
This causes a memory leak when registry items are removed
from sip.conf and reloaded. While the registries are removed
from the global list, they are not removed from the scheduler.
Because of this, SIP register attempts continue to be sent
out for the item even though it may no longer be in the .conf.
(closes issue #15295)
Reported by: amorsen
Review: https://reviewboard.asterisk.org/r/282/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@201344 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Some applications (notably app_fax) do not need digit detection nor FAX tone
detection while they are running, and if Asterisk is using software DSPs to provide
the detection, this consumes extra CPU cycles that could be better spent on the
actual application. This patch allows applications to query and control the state
of digit and tone detection on a channel, and modifies app_fax to disable them
while the FAX operations are occurring (and re-enable digit detection afterwards).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@201139 65c4cc65-6c06-0410-ace0-fbb531ad65f3
What this patch addresses:
1. ast_sip_ouraddrfor() by default binds to the UDP address/port
reguardless if the sip->pvt is of type UDP or not. Now when no
remapping is required, ast_sip_ouraddrfor() checks the sip_pvt's
transport type, attempting to set the address and port to the
correct TCP/TLS bindings if necessary.
2. It is not necessary to send the port number in the Contact
header unless the port is non-standard for the transport type.
This patch fixes this and removes the todo note.
3. In sip_alloc(), the default dialog built always uses transport
type UDP. Now sip_alloc() looks at the sip_request (if present)
and determines what transport type to use by default.
4. When changing the transport type of a sip_socket, the file
descriptor must be set to -1 and in some cases the tcptls_session's
ref count must be decremented and set to NULL. I've encountered
several issues associated with this process and have created a function,
set_socket_transport(), to handle the setting of the socket type.
(closes issue #13865)
Reported by: st
Patches:
dont_add_port_if_tls.patch uploaded by Kristijan (license 753)
13865.patch uploaded by mmichelson (license 60)
tls_port_v5.patch uploaded by vrban (license 756)
transport_issues.diff uploaded by dvossel (license 671)
Tested by: mmichelson, Kristijan, vrban, jmacz, dvossel
Review: https://reviewboard.asterisk.org/r/278/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@200946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit changes the 'incoming SDP version' check logic a bit more; when
'ignoresdpversion' is *not* set for a peer, if we initiate a re-INVITE to
switch to T.38, we'll always accept the peer's SDP response, even if they
don't properly increment the SDP version number as they should. If this situation
occurs, a warning message will be generated suggesting that the peer's
configuration be changed to include the 'ignoresdpversion' configuration option
(although ideally they'd fix their SIP implementation to be RFC compliant).
AST-221
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@200689 65c4cc65-6c06-0410-ace0-fbb531ad65f3
These modules all contained variables that are module-global but not system-global,
but were not marked 'static'.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@200587 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Using the 'pahole' tool, it is now quite easy to see where structure fields
could be organized differently to keep the compiler from having to add
padding to satisfy alignment requirements. These changes reduced the sizes of
sip_pvt and sip_peer by a few bytes each (on 64-bit platforms), and also fixed
a spelling error in a field name.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@200584 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Jeff Peeler
Tzafrir Cohen
Kevin P. Fleming
David Vossel
Richard Mudgett
Tilghman Lesher
Matthew Nicholson
Olle Johansson
Terry Wilson
Philippe Sultan
Russell Bryant
Mark Michelson
Joshua Colp
Moises Silva
Doug Bailey
Michiel van Baak
Sean Bright
David Brooks
Jason Parker
Matthew Fredrickson