This patch fixes some invalid enum conversion warnings caught by clang. In
particular:
* chan_sip: Several functions mixed usage of the st_refresher_param
enum and st_refresher enum. This patch corrects the functions to use the
right enum.
* chan_pjsip: Fixed mixed usage of ast_sip_session_t38state and ast_t38_state.
* strings: Fixed incorrect usage of AO2 flags with strings container.
* res_stasis: Change a return enumeration to stasis_app_user_event_res.
Review: https://reviewboard.asterisk.org/r/4535
ASTERISK-24917
Reported by: dkdegroot
patches:
rb4535.patch submitted by dkdegroot (License 6600)
........
Merged revisions 433746 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 433747 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433748 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Incoming PJSIP call legs that have not been answered yet send unnecessary
"180 Ringing" or "183 Progress" messages every time a connected line
update happens. If the outgoing channel is also PJSIP then the incoming
channel will always send a "180 Ringing" or "183 Progress" message when
the outgoing channel sends the INVITE.
Consequences of these unnecessary messages:
* The caller can start hearing ringback before the far end even gets the
call.
* Many phones tend to grab the first connected line information and refuse
to update the display if it changes. The first information is not likely
to be correct if the call goes to an endpoint not under the control of the
first Asterisk box.
When connected line first went into Asterisk in v1.8, chan_sip received an
undocumented option "rpid_immediate" that defaults to disabled. When
enabled, the option immediately passes connected line update information
to the caller in "180 Ringing" or "183 Progress" messages as described
above.
* Added "rpid_immediate" option to prevent unnecessary "180 Ringing" or
"183 Progress" messages. The default is "no" to disable sending the
unnecessary messages.
ASTERISK-24781 #close
Reported by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/4473/
........
Merged revisions 433338 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433339 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The res_pjsip modules were manually checking both name and number
presentation values when there is a function that determines the combined
presentation for a party ID struct. The function takes into account if
the name or number components are valid while the manual code rarely
checked if the data was even valid.
* Made use ast_party_id_presentation() rather than manually checking party
ID presentation values.
* Ensure that set_id_from_pai() and set_id_from_rpid() will not return
presentation values other than what is pulled out of the SIP headers. It
is best if the code doesn't assume that AST_PRES_ALLOWED and
AST_PRES_USER_NUMBER_UNSCREENED are zero.
* Fixed copy paste error in add_privacy_params() dealing with RPID
privacy.
* Pulled the id->number.valid test from add_privacy_header() and
add_privacy_params() up into the parent function add_id_headers() to skip
adding PAI/RPID headers earlier.
* Made update_connected_line_information() not send out connected line
updates if the connected line number is invalid. Lower level code would
not add the party ID information and thus the sent message would be
unnecessary.
* Eliminated RAII_VAR usage in send_direct_media_request().
Review: https://reviewboard.asterisk.org/r/4472/
........
Merged revisions 432892 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432893 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Switch logger callid's from AO2 objects to simple integers.
This helps in two ways. Copying integers is faster than
referencing AO2 objects, so this will result in a small
reduction in logger overhead. This also erases the possibility
of an infinate loop caused by an invalid callid in
threadstorage.
ASTERISK-24833 #comment Committed callid conversion to trunk.
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4466/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432834 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The distinctive ring feature interferes with detecting Caller ID and
appears to have been broken for years. What happens is if you have a
ring-ring cadence as used in the UK you get too many DAHDI events for the
distinctive ring pattern array and Caller ID detection is aborted. I
think when Zapata/DAHDI added the ring begin event it broke distinctive
ring. More events happen than before and the code does no filtering of
which event times are recorded in the pattern array.
* Made distinctive ring only record the ringt count when the ring ends
instead of on just any DAHDI event. Distinctive ring can be ring,
ring-ring, ring-ring-ring, or different ring durations for the up to three
rings.
* Fixed the distinctive ring detection enable (chan_dahdi.conf option
usedistinctiveringdetection) to be per port instead of somewhat per port
and somewhat global. This has been broken since v1.8.
* Fixed using the default distinctive ring context when the detected
pattern does not match any configured dringX patterns. The default
context did not get set when the previous call was a matched distinctive
ring pattern and the current call is not matched. This has been broken
since v1.8.
* Made distinctive ring have no effect on Caller ID detection when it is
disabled. Caller ID detection just monitors for 10 seconds before giving
up.
* Fixed leak of struct callerid_state memory when a polarity reversal
during Caller ID detection causes the incoming call to be aborted.
DAHDI-1143
AST-1545
ASTERISK-24825 #close
Reported by: Richard Mudgett
ASTERISK-17588
Reported by: Daniel Flounders
Review: https://reviewboard.asterisk.org/r/4444/
........
Merged revisions 432530 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 432534 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432551 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk fails to start a PBX thread for a new channel - for example, when
the maxcalls setting in asterisk.conf is exceeded - we currently send a final
response, and then attempt to send a BYE request to the UA. Since that's all
sorts of wrong, this patch fixes that by setting sipalreadygone on the sip_pvt
such that we don't get stuck sending BYE requests to something that does not
want it.
Note that this patch is a slight modification of the one on ASTERISK-15434.
For clarity, it explicitly calls sipalreadygone with the calls to transmit a
final response.
ASTERISK-21845
ASTERISK-15434 #close
Reported by: Makoto Dei
Tested by: Matt Jordan
patches:
sip-pbxstart-failed.patch uploaded by Makoto Dei (License 5027)
........
Merged revisions 432320 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 432321 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432322 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When we receive an SDP as part of an offer/answer for a peer/friend has been
configured to require encryption, and that SDP offer/answer failed to provide
acceptable crypto attributes, we currently issue a WARNING that uses the phrase
"we" and "requested". In this case, both of those terms are ambiguous - the
user will probably think "we" is Asterisk (it most likely isn't) and it may
not be a "request", so much as an SDP that was received in some fashion.
This patch makes the WARNING messages slightly less bad and a bit more
accurate as well.
ASTERISK-23214 #close
Reported by: Rusty Newton
........
Merged revisions 432277 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 432278 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432279 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the monitor thread is stopped, its pthread ID is set to a specific value
(AST_PTHREADT_STOP) so that later portions of the code can determine whether
or not it is safe to manipulate the thread. Unfortunately, __sip_reliable_xmit
failed to check for that value, checking instead only for AST_PTHREAD_STOP.
Passing the invalid yet very specific value to pthread_kill causes a crash.
This patch adds a check for AST_PTHREADT_STOP in __sip_reliable_xmit such that
it doesn't attempt to poke the thread if the thread has already been stopped.
ASTERISK-24800 #close
Reported by: JoshE
........
Merged revisions 432198 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 432199 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432200 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses the following problems:
* ari/resource_channels: In ARI, we currently create a format capability
structure of SLIN and apply it to the new channel being created. This was
originally done when the PBX core was used to create the channel, as there
was a condition where a newly created channel could be created without any
formats. Unfortunately, now that the Dial API is being used, this has two
drawbacks:
(a) SLIN, while it will ensure audio will flows, can cause a lot of
needless transcodings to occur, particularly when a Local channel is
created to the dialplan. When no format capabilities are available, the
Dial API handles this better by handing all audio formats to the requsted
channels. As such, we defer to that API to provide the format
capabilities.
(b) If a channel (requester) is causing this channel to be created, we
currently don't use its format capabilities as we are passing in our own.
However, the Dial API will use the requester channel's formats if none
are passed into it, and the requester channel exists and has format
capabilities. This is the "best" scenario, as it is the most likely to
create a media path that minimizes transcoding.
Fixing this simply entails removing the providing of the format capabilities
structure to the Dial API.
* chan_pjsip: Rather than blindly picking the first format in the format
capability structure - which actually *can* be a video or text format - we
select an audio format, and only pick the first format if that fails. That
minimizes the weird scenario where we attempt to transcode between video/audio.
* res_pjsip_sdp_rtp: Applied the joint capapbilites to the format structure.
Since ast_request already limits us down to one format capability once the
format capabilities are passed along, there's no reason to squelch it here.
* channel: Fixed a comment. The reason we have to minimize our requested
format capabilities down to a single format is due to Asterisk's inability
to convey the format to be used back "up" a channel chain. Consider the
following:
PJSIP/A => L;1 <=> L;2 => PJSIP/B
g,u,a g,u,a g,u,a u
That is, we have PJSIP/A dialing a Local channel, where the Local;2 dials
PJSIP/B. PJSIP/A has native format capabilities g722,ulaw,alaw; the Local
channel has inherited those format capabilities down the line; PJSIP/B
supports only ulaw. According to these format capabilities, ulaw is
acceptable and should be selected across all the channels, and no
transcoding should occur. However, there is no way to convey this: when L;2
and PJSIP/B are put into a bridge, we will select ulaw, but that is not
conveyed to PJSIP/A and L;1. Thus, we end up with:
PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
g g X u u
Which causes g722 to be written to PJSIP/B.
Even if we can convey the 'ulaw' choice back up the chain (which through
some severe hacking in Local channels was accomplished), such that the chain
looks like:
PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
u u u u
We have no way to tell PJSIP/A's *channel driver* to Answer in the SDP back
with only 'ulaw'. This results in all the channel structures being set up
correctly, but PJSIP/A *still* sending g722 and causing the chain to fall
apart.
There's a lot of difficulty just in setting this up, as there are numerous
race conditions in the act of bridging, and no clean mechanism to pass the
selected format backwards down an established channel chain. As such, the
best that can be done at this point in time is clarifying the comment.
Review: https://reviewboard.asterisk.org/r/4434/
ASTERISK-24812 #close
Reported by: Matt Jordan
........
Merged revisions 432195 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432196 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a new feature to ARI to redirect a channel to another server,
and fixes a few bugs in PJSIP's handling of the Transfer dialplan
application/ARI redirect capability.
*New Feature*
A new operation has been added to the ARI channels resource, redirect. With
this, a channel in a Stasis application can be redirected to another endpoint
of the same underlying channel technology.
*Bug fixes*
In the process of writing this new feature, two bugs were fixed in the PJSIP
stack:
(1) The existing .transfer channel callback had the limitation that it could
only transfer channels to a SIP URI, i.e., you had to pass
'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is
still supported, it is somewhat unintuitive - particularly in a world full
of endpoints. As such, we now also support specifying the PJSIP endpoint to
transfer to.
(2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by
updating its Contact header. Alas, that resulted in the forwarding
destination set by the dialplan application/ARI resource/whatever being
rewritten with very incorrect information. Hence, we now don't bother
updating an outgoing response if it is a 302. Since this took a looong time
to find, some additional debug statements have been added to those modules
that update the Contact headers.
Review: https://reviewboard.asterisk.org/r/4316/
ASTERISK-24015 #close
Reported by: Private Name
ASTERISK-24703 #close
Reported by: Matt Jordan
........
Merged revisions 431717 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431718 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are three CLI commands to stop and restart Asterisk each.
1) core stop/restart now - Hangup all calls and stop or restart Asterisk.
New channels are prevented while the shutdown request is pending.
2) core stop/restart gracefully - Stop or restart Asterisk when there are
no calls remaining in the system. New channels are prevented while the
shutdown request is pending.
3) core stop/restart when convenient - Stop or restart Asterisk when there
are no calls in the system. New calls are not prevented while the
shutdown request is pending.
ARI has made stopping/restarting Asterisk more problematic. While a
shutdown request is pending it is desirable to continue to process ARI
HTTP requests for current calls. To handle the current calls while a
shutdown request is pending, a new committed to shutdown phase is needed
so ARI applications can deal with the calls until the system is fully
committed to shutdown.
* Added a new shutdown committed phase so ARI applications can deal with
calls until the final committed to shutdown phase is reached.
* Made refuse new HTTP requests when the system has reached the final
system shutdown phase. Starting anything while the system is actively
releasing resources and unloading modules is not a good thing.
* Split the bridging framework shutdown to not cleanup the global bridging
containers when shutting down in a hurry. This is similar to how other
modules prevent crashes on rapid system shutdown.
* Moved ast_begin_shutdown(), ast_cancel_shutdown(), and
ast_shutting_down(). You should not have to include channel.h just to
access these system functions.
ASTERISK-24752 #close
Reported by: Matthew Jordan
Review: https://reviewboard.asterisk.org/r/4399/
........
Merged revisions 431692 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431694 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a SIP device that has its registration stored in RealTime unregisters,
the entry for that device is updated with blank values, i.e., "", indicating
that it is no longer registered. Unfortunately, one of those values that is
'blanked' is the device's port. If the column type for the port is not a
string datatype (the recommended type is integer), an ODBC or database error
will be thrown. MariaDB does not coerce empty strings to a valid integer value.
This patch updates the query run from chan_sip such that it replaces the port
value with a value of '0', as opposed to a blank value. This is the value that
other database backends coerce the empty string ("") to already, and the
handling of reading a RealTime registration value from a backend already
anticipates receiving a port of '0' from the backends.
ASTERISK-24772 #close
Reported by: Richard Miller
patches:
chan_sip.diff uploaded by Richard Miller (License 5685)
........
Merged revisions 431673 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 431674 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431675 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RFC 3261 sections 8.1.1.8 and 12.1.1 dictate specific
scenarios when we are required to use SIPS URIs in Contact
headers. Asterisk's non-compliance with this could actually
cause calls to get dropped when communicating with clients
that are strict about checking the Contact header.
Both of the SIP stacks in Asterisk suffered from this issue.
This changeset corrects the behavior in chan_sip.
ASTERISK-24646 #close
Reported by Stephan Eisvogel
Review: https://reviewboard.asterisk.org/r/4346
........
Merged revisions 431423 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 431424 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431425 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When refreshing (with a small expiration) a registration that was sent to
chan_sip the nonce would be considered stale and reject the registration.
What was happening was that the initial registration's "dialog" still existed
in the dialogs container and upon refresh the dialog match algorithm would
choose that as the "dialog" instead of the newly created one. This occurred
because the algorithm did not check to see if the from tag matched if
authentication info was available after the 401. So, it ended up assuming
the original "dialog" was a match and stopped the search. The old "dialog"
of course had an old nonce, thus the stale nonce message.
This fix attempts to leave the original functionality alone except in the case
of a REGISTER. If a REGISTER is received if searches for an existing "dialog"
matching only on the callid. If the expires value is low enough it will reuse
dialog that is there, otherwise it will create a new one.
ASTERISK-24715 #close
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/4367/
........
Merged revisions 431187 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 431194 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431197 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses compilation errors on OS X. It's been a while, so
there's quite a few things.
* Fixed __attribute__ decls in route.h to be portable.
* Fixed htonll and ntohll to work when they are defined as macros.
* Replaced sem_t usage with our ast_sem wrapper.
* Added ast_sem_timedwait to our ast_sem wrapper.
* Fixed some GCC 4.9 warnings using sig*set() functions.
* Fixed some format strings for portability.
* Fixed compilation issues with res_timing_kqueue (although tests still fail
on OS X).
* Fixed menuconfig /sbin/launchd detection, which disables res_timing_kqueue
on OS X).
ASTERISK-24539 #close
Reported by: George Joseph
ASTERISK-24544 #close
Reported by: George Joseph
Review: https://reviewboard.asterisk.org/r/4327/
........
Merged revisions 431092 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431093 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the SIP registrations were migrated to using ao2 in what was then trunk,
the explicit destruction of the registrations on module reload was removed and
not replaced with an ao2 equivalent. Debugging done by Stefan Engström, the
issue reporter, on ASTERISK-24673 confirmed that the reference in the
registry_list container was being leaked.
Since the purpose of cleanup_all_regs is to prep a registration for
destruction, this function now calls an ao2_callback function callback with the
OBJ_MULTIPLE | OBJ_NODATA | OBJ_UNLINK flags used to remove the registrations.
This cleans up each registration, and also removes it from the registration
container registry_list.
Review: https://reviewboard.asterisk.org/r/4355/
ASTERISK-24640 #close
Reported by: Max Man
ASTERISK-24673 #close
Reported by: Stefan Engström
Tested by: Stefan Engström
........
Merged revisions 430864 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430866 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Calling ast_channel_bridge_peer() cannot be done while holding any channel
locks. The reported issue hit the deadlock in chan_iax2, but an audit of
the ast_channel_bridge_peer() calls found three more locations where the
same deadlock can occur.
* Made CHANNEL(peer), res_fax, and the SNMP agent not call
ast_channel_bridge_peer() with any channel locked. For CHANNEL(peer) I
had to rework the logic to not hold the channel lock.
* Made chan_iax2 no longer call ast_channel_bridge_peer(). It was done
for legacy reasons that no longer apply.
* Removed the iax.conf forcejitterbuffer option. It is now always enabled
when the jitterbuffer option is enabled. If you put a jitter buffer on a
channel it will be on the channel.
ASTERISK-24600 #close
Reported by: Jeff Collell
Review: https://reviewboard.asterisk.org/r/4342/
........
Merged revisions 430817 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430819 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Different clients react differently to being told that a blind transfer
has failed. Some will simply send a BYE and be done with it. Others will
attempt to reinvite themselves back onto the call.
In the latter case, we were creating a new channel and then leaving it to
sit forever doing nothing. With this code change, that new channel will
not be created and the dialog with the transferring channel will be cleaned
up properly.
ASTERISK-24624 #close
Reported by Zane Conkle
Review: https://reviewboard.asterisk.org/r/4339
........
Merged revisions 430714 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430715 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The 'pjsip_get_dest_info' function is used to determine if the signaling transport
of the dialog is secure or not. This function was added in PJSIP 2.3 and does not
exist in earlier versions.
This configure check allows Asterisk to build and run with older versions at the
loss of the 'secure' argument for the PJSIP CHANNEL dialplan function. Usage of
this argument will require upgrading to PJSIP 2.3.
ASTERISK-24665 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4329/
........
Merged revisions 430546 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430547 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Made the following AMI actions use list API calls for consistency:
Agents
BridgeInfo
BridgeList
BridgeTechnologyList
ConfbridgeLIst
ConfbridgeLIstRooms
CoreShowChannels
DAHDIShowChannels
DBGet
DeviceStateList
ExtensionStateList
FAXSessions
Hangup
IAXpeerlist
IAXpeers
IAXregistry
MeetmeList
MeetmeListRooms
MWIGet
ParkedCalls
Parkinglots
PJSIPShowEndpoint
PJSIPShowEndpoints
PJSIPShowRegistrationsInbound
PJSIPShowRegistrationsOutbound
PJSIPShowResourceLists
PJSIPShowSubscriptionsInbound
PJSIPShowSubscriptionsOutbound
PresenceStateList
PRIShowSpans
QueueStatus
QueueSummary
ShowDialPlan
SIPpeers
SIPpeerstatus
SIPshowregistry
SKINNYdevices
SKINNYlines
Status
VoicemailUsersList
* Incremented the AMI version to 2.7.0.
* Changed astman_send_listack() to not use the listflag parameter and
always set the value to "Start" so the start capitalization is consistent.
i.e., The FAXSessions used "Start" while the rest of the system used
"start". The corresponding complete event always used "Complete".
* Fixed ami_show_resource_lists() "PJSIPShowResourceLists" to output the
AMI ActionID for all of its list events.
* Fixed off-nominal AMI protocol error in manager_bridge_info(),
manager_parking_status_single_lot(), and
manager_parking_status_all_lots(). Use of astman_send_error() after
responding to the original AMI action request violates the action response
pattern by sending two responses.
* Fixed minor protocol error in action_getconfig() when no requested
categories are found. Each line needs to be formatted as "Header: text".
* Fixed off-nominal memory leak in manager_build_parked_call_string().
* Eliminated unnecessary use of RAII_VAR() in ami_subscription_detail().
ASTERISK-24049 #close
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/4315/
........
Merged revisions 430434 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430435 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Given the following scenario:
* Three SIP phones (A, B, C), all communicating via a proxy with Asterisk
* A call is established between A and B. B performs a SIP attended transfer of
A to C. B sets the call on hold (A is hearing MOH) and dials the extension of
C. While phone C is ringing, B transfers the call (that is, what we typically
call a 'blond transfer').
* When the transfer completes, A hears the ringing of phone C, while B is idle.
In the SIP messaging for the above scenario, a REFER request is sent to
transfer the call. When "sendrpid=yes" is set in sip.conf, Asterisk may send an
UPDATE request to phone C to update party information. This update is sent
directly to phone C, not through the intervening proxy. This has the unfortunate
side effect of providing route information, which is then set on the sip_pvt
structure for C. If someone (e.g. B) is trying to get the call back (through a
directed pickup), Asterisk will send a CANCEL request to C. However, since we
have now updated the route set, the CANCEL request will be sent directly to C
and not through the proxy. The phone ignores this CANCEL according to RFC3261
(Section 9.1).
This patch updates reqprep such that the route is not updated if an UPDATE
request is being sent while the INVITE state is INV_PROCEEDING or
INV_EARLY_MEDIA. This ensures that a subsequent CANCEL request is still sent
to the correct location.
Review: https://reviewboard.asterisk.org/r/4279
ASTERISK-24628 #close
Reported by: Karsten Wemheuer
patches:
issue.patch uploaded by Karsten Wemheuer (License 5930)
........
Merged revisions 429982 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429983 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429984 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the configuration section scheme of chan_dahdi.conf is used (keyword
dahdichan instead of channel) all setvar= options are completely ignored.
No variable defined this way appears in the created DAHDI channels.
* Move the clearing of setvar values to after the deferred processing of
dahdichan.
AST-1378 #close
Reported by: Guenther Kelleter
Patch by: Guenther Kelleter
........
Merged revisions 429825 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429829 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429830 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For the featdmf signaling mode the incoming MF Caller-ID information is
formatted as follows: *${CALLERID(ani2)}${CALLERID(ani)}#*${EXTEN}#
Rather than discarding the ani2 digits, populate the CALLERID(ani2) value
with what is received instead.
AST-1368 #close
Reported by: Denis Martinez
Patches:
extract_ani2_for_featdmf_v11.patch (license #5621) patch uploaded by Richard Mudgett
........
Merged revisions 429783 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429784 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429785 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, we were using the PJSIP dialog's secure flag
to determine if a secure transport was being used. Unfortunately,
the dialog's secure flag was only set if a SIPS URI were in use,
as required by RFC 3261 sections 12.1.1 and 12.1.2. What we're interested
in is not dialog security, but transport security. This code change
switches to a model where we use the dialog's target URI to determine
what transport would be used to communicate, and then check if that
transport is secure.
AST-1450 #close
Reported by John Bigelow
Review: https://reviewboard.asterisk.org/r/4277
........
Merged revisions 429739 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429740 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r413586 (1.8) various casts were added to silence gcc 4.10 warnings.
Those fixes included things like:
-out += sprintf(out, "%%%02X", (unsigned char) *ptr);
+out += sprintf(out, "%%%02X", (unsigned) *ptr);
That works for low ascii characters, but for the high range that yields
e.g. FFFFFFC3 when C3 is expected.
This changeset:
- fixes those casts to use the 'hh' unsigned char modifier instead
- consistently uses %02x instead of %2.2x (or other non-standard usage)
- adds a few 'h' modifiers in various places
- fixes a 'replcaes' typo
- dev/urandon typo (in 13+ patch)
Review: https://reviewboard.asterisk.org/r/4263/
ASTERISK-24619 #close
Reported by: Stefan27 (on IRC)
........
Merged revisions 429673 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429674 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 429675 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429683 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously when SRTP was enabled on a channel it was not possible
to switch to T.38 as no crypto attributes would be present.
This change makes it so it is now possible. If a T.38 re-invite
comes in SRTP is terminated since in practice you can't encrypt
a UDPTL stream. Now... if we were doing T.38 over RTP (which
does exist) then we'd have a chance but almost nobody does that so
here we are.
ASTERISK-24449 #close
Reported by: Andreas Steinmetz
patches:
udptl-ignore-srtp-v2.patch submitted by Andreas Steinmetz (license 6523)
........
Merged revisions 429632 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429633 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429634 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When direct media is enabled and a pjsip channel is answered a race would occur
between the handling of the answer and bridge setup. Sometimes the media
negotiation would take place after the native bridge was setup. This resulted
in a NULL media address, which in turn resulted in Asterisk using its address
as the remote media address when sending a reinvite. This patch makes the
chan_pjsip answer handler synchronous thus alleviating the race condition (the
bridge won't start setting things up until after it returns).
ASTERISK-24563 #close
Reported by: Steve Pitts
Review: https://reviewboard.asterisk.org/r/4257/
........
Merged revisions 429477 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429478 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Given the scenario where a PJSIP channel is in a native RTP bridge with direct
media and the channel is then hung up the code will currently re-INVITE the channel
back to Asterisk and send a BYE at the same time. Many SIP implementations dislike
this greatly.
This change makes it so that if a re-INVITE transaction is in progress the BYE
is queued to occur after the completion of the transaction (be it through normal
means or a timeout).
Review: https://reviewboard.asterisk.org/r/4248/
........
Merged revisions 429409 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429410 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When endpoints with direct_media enabled, behind a firewall (Asterisk on a
separate network) and were bridged sometimes Asterisk would send the ip
address of the firewall in the sdp to one of the phones in the reinvite
resulting in one way audio. When sending the reinvite Asterisk will retrieve
the media address from the associated rtp instance, but if frames were being
read this can be overwritten with another address (in this case the
firewall's). This patch ensures that Asterisk uses the original device
address when using direct media.
ASTERISK-24563
Reported by: Steve Pitts
Review: https://reviewboard.asterisk.org/r/4216/
........
Merged revisions 429195 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 429196 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429197 65c4cc65-6c06-0410-ace0-fbb531ad65f3
