This was causing identification that should have been
made private to be public.
(closes issue AST-814)
reported by Patrick Anderson
Patches:
chan_sip.c.diff uploaded by Patrick Anderson (license 5430)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@355268 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In ASTERISK-18924, SIP INFO DTMF handlingw as changed to account for both
lowercase alphatbetic DTMF events, as well as uppercase alphabetic DTMF
events. When this occurred, the comparison of the character buffer containing
the event code was changed such that the buffer was first compared again '0'
and '9' to determine if it was numeric. Unfortunately, since the first
character in the buffer will typically be '1' in the case of non-numeric
event codes (10-16), this caused those codes to be converted to a DTMF event
of '1'. This patch fixes that, and cleans up handling of both
application/dtmf-relay and application/dtmf content types.
Review: https://reviewboard.asterisk.org/r/1722/
(closes issue ASTERISK-19290)
Reported by: Ira Emus
Tested by: mjordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@354542 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1. Set lastms to 0 when clearing instead of ""
2. Don't set ipaddr or port to the string "(null)" when they are empty
3. Add missing required fields, set default for lastms to 0, and modify
the length of the ipaddr field to 45 in the Postgresql realtime.sql
file.
(closes issue ASTERISK-19172)
Review: https://reviewboard.asterisk.org/r/1703/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@354348 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After R340970 Asterisk was still polling the RTCP file descriptor after RTCP is
shut down and removed. If the descriptor happened to have data ready when the
removal occured then Asterisk would go into an infinite loop trying to read
data that it can never actually access. This change disables the audio RTCP
file descriptor for the duration of the T.38 transaction.
(closes issue ASTERISK-18951)
Reported-by: Kristijan Vrban
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@353915 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A previous patch I committed from ASTERISK-16930 unexpectedly changed some output for
the AMI action "sippeers" which this patch changes back. Also, this aligns the output
for the cli command "sip show peers" and fixes another issue that patch introduced by
using ast_sockaddr_stringify calls multiple times without immediately using the pointer.
I also went ahead and did a little janitorial work to clean up whitespace in
_sip_show_peers.
(issue ASTERISK-16930)
(closes issue ASTERISK-19281)
Reported by: Patrick El Youssef
Patches:
ASTERISK-19281.diff uploaded by Walter Doekes (license 5674)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@353769 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are a number of cleaner looking wrappers for ast_sockaddr_stringify_fmt
available which are slightly more readable than using a direct call to
ast_sockaddr_stringify_fmt. This patch switches a number of those calls in
chan_sip to use those wrappers and is generally harmless.
(Closes issue ASTERISK-16930)
Reported by: Michael L. Young
Patches:
chan_sip-broken-registration-1.8.diff uploaded by Michael L. Young (license 5026)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@353720 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk's dnsmgr currently takes a pointer to an ast_sockaddr and updates it
anytime an address resolves to something different. There are a couple of
issues with this. First, the ast_sockaddr is usually the address of an
ast_sockaddr inside a refcounted struct and we never bump the refcount of those
structs when using dnsmgr. This makes it possible that a refresh could happen
after the destructor for that object is called (despite ast_dnsmgr_release
being called in that destructor). Second, the module using dnsmgr cannot be
aware of an address changing without polling for it in the code. If an action
needs to be taken on address update (like re-linking a SIP peer in the
peers_by_ip table), then polling for this change negates many of the benefits
of having dnsmgr in the first place.
This patch adds a function to the dnsmgr API that calls an update callback
instead of blindly updating the address itself. It also moves calls to
ast_dnsmgr_release outside of the destructor functions and into cleanup
functions that are called when we no longer need the objects and increments the
refcount of the objects using dnsmgr since those objects are stored on the
ast_dnsmgr_entry struct. A helper function for returning the proper default SIP
port (non-tls vs tls) is also added and used.
This patch also incorporates changes from a patch posted by Timo Teräs to
ASTERISK-19106 for related dnsmgr issues.
(closes issue ASTERISK-19106)
Review: https://reviewboard.asterisk.org/r/1691/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@353371 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* fix: use %u instead of %d when dealing with CSeq numbers - to remove possibility of -ve numbers.
* fix: change all uses of seqno and friends (ocseq icseq) from 'int' or 'unsigned int' to uint32_t.
Summary of CSeq numbers.
An initial CSeq number must be less than 2^31
A CSeq number can increase in value up to 2^32-1
An incrementing CSeq number must not wrap around to 0.
Tested with Asterisk 1.8.8.2 with Grandstream phones.
alecdavis (license 585)
Tested by: alecdavis
Review: https://reviewboard.asterisk.org/r/1699/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@353320 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously, if an m-line in an SDP offer or answer had a port number of zero,
that line was skipped, and resulted in an 'Unsupported SDP media type...'
warning message. This was misleading, as the media type was not unsupported,
but was ignored because the m-line indicated that the media stream had been
rejected (in an answer) or was not going to be used (in an offer).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@353260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a BLF subscription exists for long enough, using %d may print negative version numbers.
Unlikely, as 2^32 at 1 update per second is ~137 years, or half that before the versions number started going negative.
Tested with Asterisk 1.8.8.2 with Grandstream phones.
alecdavis (license 585)
Tested by: alecdavis
Review: https://reviewboard.asterisk.org/r/1694/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@352862 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For whatever reason, we don't have a single function for copying data like this
from SIP peers to the SIP pvt. This patch adds the copying of amaflags to the
sip_pvt, but it would probably be worth discussing this function along with
the others that essentially just copy some amount of data from a peer to a
private.
(Closes issue ASTERISK-19029)
Reported by: Matt Lehner
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@352755 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The invalid value used when notifycid was enabled was benign. As far as
the code was concerned -1 and 1 are equivalent.
(closes issue ASTERISK-19232)
Reported by: Eike Kuiper
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@352090 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a blind transfer were initiated using a REFER without a prior
reINVITE to place the call on hold, AND if Asterisk were sending
RTCP reports, then there was a reference for the RTP instance
of the transferer.
This fixes the issue by merging two similar but slightly conflicting
sections of code into a single area. It also adds a stop_media_flows()
call in the case that the transferer's UA never sends a BYE to us
like it is supposed to.
(issue ASTERISK-19192)
Review: https://reviewboard.asterisk.org/r/1681/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@352014 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fix corner cases in get_calleridname() parsing and ensure that the
output buffer is nul terminated.
* Make get_calleridname() truncate the name it parses if the given buffer
is too small rather than abandoning the parse and not returning anything
for the name. Adjusted get_calleridname_test() unit test to handle the
truncation change.
* Fix get_in_brackets_test() unit test to check the results of
get_in_brackets() correctly.
* Fix parse_name_andor_addr() to not return the address of a local buffer.
This function is currently not used.
* Fix potential NULL pointer dereference in sip_sendtext().
* No need to memset(calleridname) in check_user_full() or tmp_name in
get_name_and_number() because get_calleridname() ensures that it is nul
terminated.
* Reply with an accurate response if get_msg_text() fails in
receive_message(). This is academic in v1.8 because get_msg_text() can
never fail.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@351618 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch prevents the domain string from getting mangled during the initreqprep
step by moving the initialization to before its immediate use. It also documents
this pitfall for the ast_sockaddr_stringify functions.
(issue ASTERISK-19057)
Reported by: Yuri
Review: https://reviewboard.asterisk.org/r/1678/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@351559 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a Contact or a Record-Route header had a quoted string with an
item in angle brackets, then we would mis-parse it. For instance,
"Bob <1234>" <1234@example.org>
would be misparsed as having the URI "1234"
The fix for this is to use parsing functions from reqresp_parser.h
since they are heavily tested and are awesome.
(issue ASTERISK-18990)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@351284 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When an inital INVITE occurs that contains image media, a channel
is not yet associated with the SIP dialog. The file descriptor
associated with the udptl session needs to be set in
initialize_udptl or in sip_new to account for this scenario.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@351233 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds some missing locking to the function
send_provisional_keepalive_full(). This function is called from the scheduler,
which is processed in the SIP monitor thread. The associated channel (or pbx)
thread will also be using the same sip_pvt and ast_channel so locking must be
used. The sip_pvt_lock_full() function is used to ensure proper locking order
in a safe manner.
In passing, document a suspected reference counting error in this function.
The "fix" is left commented out because when the "fix" is present, crashes
occur. My theory is that fixing it is exposing a reference counting error
elsewhere, but I don't know where. (Or my analysis of this being a problem
could have been completely wrong in the first place). Leave the comment in
the code for so that someone may investigate it again in the future.
Also add a bit of doxygen to transmit_provisional_response().
(closes issue ASTERISK-18979)
Review: https://reviewboard.asterisk.org/r/1648
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@351182 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When handling a non-2xx final response on an INVITE transaction, we have to
keep the transaction around after we send an ACK in case we receive a
retransmission of the response so we can re-transmit the ACK, but also tear
down the ast_channel as soon as we transmit the ACK. Before this patch, we
could fail at both of these things. Calling sip_alreadygone/needdestroy
prevented us from keeping the transaction up and retransmitting the ACK, and
queueing CONGESTION was not sufficient to cause the channel to be torn down
when originating calls via the CLI, for example.
This patch queues a hangup with CONGESTION instead of just queueing CONGESTION
for these responses and removes the sip_alreadygone and sip_needdestroy calls
from handle_response_invite on non-2xx responses. It relies on the hangup
calling sip_scheddestroy.
For more information, see section 17.1.1.1 of RFC 3261.
(closes issue ASTERISK-17717)
Review: https://reviewboard.asterisk.org/r/1672/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@351130 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk is the UAS (incoming call, endpoint is re-inviting) the SIP session timer expires after half the time the sip endpoint indicates in the Session-expires header in proc_session_timer(). The session timer was being stopped totally and being handled as an error case instead of running again until the second expiry. This patch treats the half-time expiry as a non-error case and continues the timer until the true expiry.
(closes issue ASTERISK-18996)
Reported by: Thomas Arimont
Tested by: Thomas Arimont
Patches: session_timer_fix.diff by Terry Wilson (License #5357)
based on session_timer.patch by Thomas Arimont (License #5525)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@351080 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, the udptl struct was allocated and initialized when a
dialog was associated with a peer that supported T.38, when a new SIP
channel was allocated, or what an INVITE request was received. This resulted
in any dialog associated with a peer that supported T.38 having udptl support
assigned to it, including the UDP ports needed for communication. This
occurred even in non-INVITE dialogs that would never send image media.
This patch creates and initializes the udptl structure only when the SDP
for a dialog specifies that image media is supported, or when Asterisk
indicates through the appropriate control frame that a dialog is to support
T.38.
(closes issue ASTERISK-16698)
Reported by: under
Tested by: Stefan Schmidt
Patches: udptl_20120113.diff uploaded by mjordan (License #6283)
(closes issue ASTERISK-16794)
Reported by: Elazar Broad
Tested by: Stefan Schmidt
review: https://reviewboard.asterisk.org/r/1668/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@351027 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When someone does Set(CALLERPRES()=unavailable) (or
Set(CALLERID(pres)=unavailable)) when sendrpid=no, the From header shows
"Anonymous" <anonymous@anonymous.invalid>. When sendrpid=yes/pai, the From
header will still display the callerid info, even though we supply an rpid
header with the anonymous info. It seems like we shouldn't leak that info in
any case. Skimming http://tools.ietf.org/html/draft-ietf-sip-privacy-04 seems
to indicate that one shouldn't send identifying info in the From in this case.
This patch anonymizes the From header as well even when sendrpid=yes/pai.
(closes issue ASTERISK-16538)
Review: https://reviewboard.asterisk.org/r/1649/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@349968 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Chan_sip gives a dialog reference to the extension state callback and
assumes that when ast_extension_state_del() returns, the callback cannot
happen anymore. Chan_sip then reduces the dialog reference count
associated with the callback. Recent changes (ASTERISK-17760) have
resulted in the potential for the callback to happen after
ast_extension_state_del() has returned. For chan_sip, this could be very
bad because the dialog pointer could have already been destroyed.
* Added ast_extension_state_add_destroy() so chan_sip can account for the
sip_pvt reference given to the extension state callback when the extension
state callback is deleted.
* Fix pbx.c awkward statecbs handling in ast_extension_state_add_destroy()
and handle_statechange() now that the struct ast_state_cb has a destructor
to call.
* Ensure that ast_extension_state_add_destroy() will never return -1 or 0
for a successful registration.
* Fixed pbx.c statecbs_cmp() to compare the correct information. The
passed in value to compare is a change_cb function pointer not an object
pointer.
* Make pbx.c ast_merge_contexts_and_delete() not perform callbacks with
AST_EXTENSION_REMOVED with locks held. Chan_sip is notorious for
deadlocking when those locks are held during the callback.
* Removed unused lock declaration for the pbx.c store_hints list.
(closes issue ASTERISK-18844)
Reported by: rmudgett
Review: https://reviewboard.asterisk.org/r/1635/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@348940 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When tcpenable=no, sending to transport=tcp hosts was still allowed.
Resolving the source address wasn't possible and yielded the string
"(null)" in SIP messages. Fixed that and a couple of not-so-correct
log messages.
(closes issue ASTERISK-18837)
Reported by: Andreas Topp
Review: https://reviewboard.asterisk.org/r/1585
Reviewed by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@347166 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch resolves the issue where MWI subscriptions are orphaned
by subsequent SIP SUBSCRIBE messages. When a peer is removed, either
by pruning realtime SIP peers or by unloading / loading chan_sip, the
MWI subscriptions that were orphaned would still be on the event engine
list of valid subscriptions but have a pointer to a peer that no longer
was valid. When an MWI event would occur, this would cause a seg fault.
(closes issue ASTERISK-18663)
Reported by: Ross Beer
Tested by: Ross Beer, Matt Jordan
Patches:
blf_mwi_diff_12_06_11.txt uploaded by Matt Jordan (license 6283)
Review: https://reviewboard.asterisk.org/r/1610/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@347058 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The code that allowed admins to create users with domain-only uri's had
stopped to work in 1.8 because of the reqresp parser rewrites. This is
fixed now: if you have a [mydomain.com] sip user, you can register with
useraddr sip:mydomain.com. Note that in that case -- if you're using
domain ACLs (a configured domain list) -- mydomain.com must be in the
allow list as well.
Reviewboard r1606 shows a list of registration combinations and which
SIP response codes are returned.
Review: https://reviewboard.asterisk.org/r/1533/
Reviewed by: Terry Wilson
(closes issue ASTERISK-18389)
(closes issue ASTERISK-18741)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@346899 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Cleaning up chan_sip/tcptls file descriptor closing.
This patch attempts to eliminate various possible instances of undefined behavior caused
by invoking close/fclose in situations where fclose may have already been issued on a
tcptls_session_instance and/or closing file descriptors that don't have a valid index
for fd (-1). Thanks for more than a little help from wdoekes.
(closes issue ASTERISK-18700)
Reported by: Erik Wallin
(issue ASTERISK-18345)
Reported by: Stephane Cazelas
(issue ASTERISK-18342)
Reported by: Stephane Chazelas
Review: https://reviewboard.asterisk.org/r/1576/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@346564 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r116240, get_msg_text() got an extra parameter to fix the unwanted
addition of trailing newlines to SIP MESSAGE bodies. This caused all
linefeeds to be trimmed, which isn't right either. This is a stop-gap;
the right fix is to return the original SIP request body.
Review: https://reviewboard.asterisk.org/r/1586
Reviewed by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@346147 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It is possible to enumerate SIP usernames when the general and user/peer
nat settings differ in whether to respond to the port a request is sent
from or the port listed for responses in the Via header. In 1.4 and 1.6.2,
this would mean if one setting was nat=yes or nat=route and the other was
either nat=no or nat=never. In 1.8 and 10, this would mean when one was
nat=force_rport and the other was nat=no.
In order to address this problem, it was decided to switch the default
behavior to nat=yes/force_rport as it is the most commonly used option
and to strongly discourage setting nat per-peer/user when at all possible.
For more discussion of the issue, please see:
http://lists.digium.com/pipermail/asterisk-dev/2011-November/052191.html
(closes issue ASTERISK-18862)
Review: https://reviewboard.asterisk.org/r/1591/
........
Merged revisions 345776 from http://svn.asterisk.org/svn/asterisk/branches/1.4
........
Merged revisions 345800 from http://svn.asterisk.org/svn/asterisk/branches/1.6.2
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@345828 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The recent fix for ASTERISK-17288 to get RFC3578 SIP overlap support
working correctly removed a long standing ability to do overlap dialing
using DTMF in the early media phase of a call.
See ASTERISK-18702 it has a very good description of the issue.
I started with Pavel Troller's chan_sip.diff patch on issue
ASTERISK-18702.
* Added 'dtmf' enum value to sip.conf allowoverlap config option. The new
option value causes the Incomplte application to not send anything with
chan_sip so the caller can supply more digits via DTMF.
* Renames SIP_GET_DEST_PICKUP_EXTEN_FOUND to SIP_GET_DEST_EXTEN_MATCHMORE
since that is what it really means.
* Fixed get_destination() inconsistency with the pickup extension
matching.
* Fixed initialization of PAGE3 of global_flags in reload_config().
(closes issue ASTERISK-18702)
Reported by: Pavel Troller
Review: https://reviewboard.asterisk.org/r/1517/
Review: https://reviewboard.asterisk.org/r/1582/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@345273 65c4cc65-6c06-0410-ace0-fbb531ad65f3
