When we send an ACK for a 2xx response to an INVITE, we are supposed
to use the learned route set. However, when we receive a non-2xx final
response to an INVITE, we are supposed to send the ACK to the same place
we initially sent the INVITE.
We had been doing this up until the changes went in that would build a route
set from provisional responses. That introduced a regression where we would
use the learned route set under all circumstances.
With this change, we now will set the destination of our ACK based on the
invitestate. If it is INV_COMPLETED then that means that we have received
a non-2xx final response (INV_TERMINATED indicates a 2xx response was received).
If it is INV_CANCELLED, then that means the call is being canceled, which
means that we should be ACKing a 487 response.
The other change introduced here is setting the invitestate to INV_CONFIRMED
when we send an ACK *after* the reqprep instead of before. This way, we can
tell in reqprep more easily what the invitestate is prior to sending the ACK.
(closes issue ASTERISK-19389)
reported by Karsten Wemheuer
patches:
ASTERISK-19389v2.patch uploaded by Mark Michelson (license #5049)
(with some slight modifications prior to commit)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@356475 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The "sip show peers" command uses a fix sized array to sort the current peers
in the peers ao2_container. The size of the array is based on the current
number of peers in the container. However, once the size of the array is
determined, the number of peers in the container can change, as the peers
container is not locked. This could cause a buffer overrun when populating
the array, if peers were added to the container after the array was created.
Additionally, a memory leak of the allocated array would occur if a user
caused the _show_peers method to return CLI_SHOWUSAGE.
We now create a snapshot of the current peers using an ao2_callback with the
OBJ_MULTIPLE flag. This size of the array is set to the number of peers
that the iterator will iterate over; hence, if peers are added or removed
from the peers container it will not affect the execution of the "sip show
peers" command.
Review: https://reviewboard.asterisk.org/r/1738/
(closes issue ASTERISK-19231)
(closes issue ASTERISK-19361)
Reported by: Thomas Arimont, Jamuel Starkey
Tested by: Thomas Arimont, Jamuel Starkey
Patches: sip_show_peers_2012_02_16.diff uploaded by mjordan (license 6283)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@356214 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes two main issues:
1. Asterisk would send a CANCEL to the route created by the provisional response
instead of using the same destination it did in the initial INVITE.
2. If a new route set arrives in a 200 OK than was in the 1XX response (perfectly
possible if our outbound INVITE gets forked), then the route set in the 200 OK
needs to overwrite the route set in the 1XX response.
(closes issue ASTERISK-19358)
Reported by: Karsten Wemheuer
Tested by: Karsten Wemheuer
patches:
ASTERISK-19358.patch uploaded by Mark Michelson (license 5049)
ASTERISK-19358.patch uploaded by Stefan Schmidt (license 6034)
Review: https://reviewboard.asterisk.org/r/1749
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@355732 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
