The allowed methods advertised by chan_sip did not previously note the MESSAGE
request. Even in Asterisk 1.8, we do accept in-dialog MESSAGE requests; we
should advertise that we support MESSAGE requests.
ASTERISK-23504 #close
ASTERISK-23504 #comment Reported by: Martin Kontsek
ASTERISK-23504 #comment Patch sip.h_patch.diff uploaded by Martin Kontsek (license 6587)
Review: https://reviewboard.asterisk.org/r/3396/
........
Merged revisions 411372 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@411373 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior too this patch, the P-Asserted-Identity header would include anonymous
caller id information which seems to go against the point of the
P-Asserted-Identity header. Now the real caller ID information will be
included in this header. Also, no privacy header would be included.
This patch adds 'Privacy: id' to outgoing SIP messages that include the
P-Asserted-Identity header.
(closes issue AST-1301)
........
Merged revisions 411189 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@411190 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If update_provisional_keepalive() is called while
send_provisional_keepalive_full() is waiting on the PVT lock, then
pvt->provisional_keepalive_sched_id will be changed to a new sched_id
value by update_provisional_keepalive(), but that new sched_id then may
be overwritten with -1 by send_provisional_keepalive_full(), killing
the pvt's reference to a schedule and "leaking" the reference.
(closes issue ASTERISK-22079)
Review: https://reviewboard.asterisk.org/r/3368/
Reported by: Jamuel Starkey, Matteo, Leif Madsen, Steve Davies
Patches:
provisional_keepalive_fix.diff uploaded by Steve Davies (license 5012)
........
Merged revisions 411088 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@411089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change allows chan_sip to avoid creation of the channel and
consumption of associated file descriptors altogether if the inbound
request is going to be rejected anyway.
(closes issue ASTERISK-23373)
Reported by: Corey Farrell
Patches:
chan_sip-earlier-st-1.8.patch uploaded by Corey Farrell (license 5909)
chan_sip-earlier-st-11.patch uploaded by Corey Farrell (license 5909)
........
Merged revisions 410308 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@410311 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a static realtime peer with qualify=yes is loaded, Asterisk will fail to
send an OPTIONS request due to the lastms being equal to 0. This results in
the peer being unable to receive calls from Asterisk because the status is
permanently UNKNOWN.
This patch allows an OPTIONS request to be sent during module load by
ignoring the lastms value on startup only.
Review: https://reviewboard.asterisk.org/r/3294/
(closes issue ASTERISK-17523)
Reported by: Maciej Krajewski
Tested by: wushumasters
patches:
realtime_fix_11.7.0.txt uploaded by Trevor Peirce (license 6112)
........
Merged revisions 410105 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@410106 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Fixed too early RTP setup with phone, that cause no ringback tone on caller side
- Handle call transfer cancel only in STATE_CALL case (related to ASTERISK-23073)
(Reported by: Németh Tamás, niurkin sil)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@409761 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fix crash in ast_channel_hangupcause_set() because p->owner not checked
before calling. Regression introduced by the fix for ASTERISK-22621.
(closes issue ASTERISK-23135)
Reported by: OK
(issue ASTERISK-23323)
Reported by: Walter Doekes
........
Merged revisions 409156 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@409157 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Updated the code to check to see if MOH is playing on the transferor and if
so then start it on the channel that replaces it during a masquerade.
Example scenario of the problem:
Alice calls Bob and then Bob begins the attended transfer process into a queue.
Upon going on hold Alice hears music and so does Bob once he is in the queue.
Bob then transfers Alice into the queue and then music for Alice stops even
though she should be hearing it since has now replaced Bob in the queue.
The problem that was occurring is that once the channel was masqueraded the app
(queues, confbridge, etc...) had no way of knowing that the channel had just
been swapped out thus it did not start music for the present channel.
Credit to Olle Johansson for pointing me in the right direction on this issue.
(closes issue ASTERISK-19499)
Reported by: Timo Teräs
Review: https://reviewboard.asterisk.org/r/3226/
........
Merged revisions 408642 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@408643 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a DAHDI device is removed at run-time it sends the event
DAHDI_EVENT_REMOVED on each channel. This is intended to signal the
userspace program to close the respective file handle, as the driver of
the device will need all of them closed to properly clean-up.
This event has long since been handled in chan_dahdi (chan_zap at the
time). However the event that is sent on a D-Channel of a "PRI" (ISDN)
span simply gets ignored.
This commit adds handling for closing the file descriptor (and shutting
down the span, while we're at it).
It also adds a CLI command 'pri destroy span <N>' to destroy the span
and its DAHDI channels.
Backported from trunk/12.
Review: https://reviewboard.asterisk.org/r/726/
........
Merged revisions 394552 394567 from http://svn.asterisk.org/svn/asterisk/trunk
........
Merged revisions 407817 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@407818 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Establishing an IAX2 call between Asterisk v1.4 and v1.8 (or later)
results in an unexpected call disconnect. The problem happens because
newer values in the enum ast_control_frame_type are not consistent between
the branch versions of Asterisk.
For example:
1) v1.4 calls v1.8 (or later) using IAX2
2) v1.8 answers and sends a connected line update control frame. (on v1.8
AST_CONTROL_CONNECTED_LINE = 22)
3) v1.4 receives the control frame as an end-of-q (on v1.4
AST_CONTROL_END_OF_Q = 22)
4) v1.4 disconnects the call once the receive queue becomes empty.
Several things are done by this patch to fix the problem and attempt to
prevent it from happening again in the future:
* Added a warning at the definition of enum ast_control_frame_type about
how to add new control frame values.
* Made block sending and receiving control frames that have no reason to
go over the wire.
* Extended the connectedline iax.conf parameter to also include the
redirecting information updates.
* Updated the connectedline iax.conf parameter documentation to include a
notice that the parameter must be "no" when the peer is an Asterisk v1.4
instance.
(closes issue AST-1302)
Review: https://reviewboard.asterisk.org/r/3174/
........
Merged revisions 407678 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@407727 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change allows chan_sip to decline individual image streams over
unsupported transports in the SDP of the 200 response. Previously,
an image stream offer with RTP/AVP as the transport would cause
chan_sip to respond with a 488.
(closes issue ASTERISK-22988)
Reported by: adomjan
Original patch by: adomjan
........
Merged revisions 406170 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@406171 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This restricts direct usage of global oseq so that all accesses are
locked and threads are not racing to get oseq values that they did not
claim.
This also fixes a build error in res_pktccops under dev mode.
(closes issue ASTERISK-23100)
Reported by: adomjan
Patch by: adomjan
........
Merged revisions 406037 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@406038 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fixes typos of "transfered" instead of "transferred" in various code. Fixes incorrect gosub param help text for app_queue.
Fixes Asterisk man pages containing unquoted minus signs. Adds note about the "textsupport" option in sip.conf.sample.
(issue ASTERISK-23061)
(issue ASTERISK-23028)
(issue ASTERISK-23046)
(issue ASTERISK-23027)
(closes issue ASTERISK-23061)
(closes issue ASTERISK-23028)
(closes issue ASTERISK-23046)
(closes issue ASTERISK-23027)
Reported by: Eugene, Jeremy Laine, Denis Pantsyrev
Patches:
transferred.patch uploaded by Jeremy Laine (license 6561)
hyphen.patch uploaded by Jeremy Laine (license 6561)
sip.conf.sample.patch uploaded by Eugene (license 6360)
........
Merged revisions 405791 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@405792 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In ASTERISK-12117, an improvement to insure consistant local from tags
on outbound registrations resulted in an undesirable behavior - caused
by leftover unexpired sip_pvt dialogs (with the previous cseq number),
resulting in many uncessary REGISTER requests. Instead of significant
rework of transmit_register(), this change deletes the dialogs after a
200 OK response indiciating a successful registration, keeping the old
dialogs from interfering with normal operation.
(closes issue ASTERISK-22946)
Reported by: Stephan Eisvogel
Review: https://reviewboard.asterisk.org/r/3109/
........
Merged revisions 405433 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@405434 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When performing a SIP transfer to a Park extension, if the Park fails, chan_sip
will currently not hang up either the transferer or the transfer target. This
results in the channels being orphaned with no thread to service frames,
resulting in stuck channels.
This patch immediately hangs up the two channels if a Park fails.
(closes issue ASTERISK-22834)
Reported by: rsw686
Tested by: rsw686
(closes issue ASTERISK-23047)
Reported by: Tommy Thompson
Tested by: Tommy Thomspon
Review: https://reviewboard.asterisk.org/r/3107
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@405380 65c4cc65-6c06-0410-ace0-fbb531ad65f3
dahdi show channels output slices the callerid (which is dnid copied over on
PRI channels). If the channel naming structures look like:
'DAHDI/i1/1408409XXXX-6'
then the output slices 1408409XXXX down to 1408409XXX. This patch just opens
it up to 15 chars so you can see the whole thing.
(closes issue ASTERISK-22918)
Reported by: outtolunc
Patches:
svn_chan_dahdi.c.format12_15.diff.txt uploaded by outtolunc (license 5198)
........
Merged revisions 404784 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@404785 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk will sometimes core dump during caller id read on analog
channels due to a negative return value from the read() in
my_get_callerid that slips through as a negative length argument to
callerid_feed() if the errno returned by DAHDI is ELAST. This change
ensures that the negative return is treated properly even when it is
ELAST.
(closes issue ASTERISK-22746)
Reported by: Michael Walton
Patches:
chan_dahdi_cid_crash_fix.r401410.patch uploaded by Michael Walton (License 6502)
........
Merged revisions 402708 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@402709 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For outbound register requests the tag on the From line was
updated every 20 seconds prior to a successful registration
and also once for each registration renewal. That behavior
can possibly cause the registration to be denied because of
the different tag, and is not aligned with the intention of
RFC 3261 8.1.3.5 "... request constitutes a new transaction
and SHOULD have the same value of the Call-ID, To, and From
of the previous request...". This updates chan_sip to have
a field to keep the local tag in the registration structure
and use that tag for registration requests where the callid
is also unchanged.
(closes issue ASTERISK-12117)
Reported by: Pawel Pierscionek
Review: https://reviewboard.asterisk.org/r/2988/
........
Merged revisions 402604 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@402605 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The presentation indicator in a callerid (e.g. set by dialplan function
Set(CALLERID(name-pres)= ...)) is not checked when SIP Dialog Info Notifies
are generated during extension monitoring. Added a check to make sure the
name and/or number presentations on the callee (remote identity) are set to
allow. If they are restricted then "anonymous" is used instead.
(closes issue AST-1175)
Reported by: Thomas Arimont
Review: https://reviewboard.asterisk.org/r/2976/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@402450 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This corrects one-way audio between Asterisk and Chrome/jssip as a
result of Asterisk inserting the incorrect RTCP port into RTCP SRFLX
ICE candidates. This also exposes an ICE component enumeration to
extract further details from candidates.
(closes issue ASTERISK-21383)
Reported by: Shaun Clark
Review: https://reviewboard.asterisk.org/r/2967/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@402345 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While looking at ASTERISK-22236, Walter Doekes pointed out that when running
"sip show peers", the setting being displayed can be confusing. The display of
"N" used to mean NAT (i.e. yes). The NAT setting has gone through many
different changes resulting in the display of different characters to try and
convey what the current setting is for 'Forcerport' (A for Auto and Forcerport
is currently on, a for Auto but Forcerport is off, Y for yes, and N for no).
During the initial code review to try and clarify these settings (especially
since "N" no longer meant what it used to mean in prior versions of Asterisk),
Mark Michelson suggested using the full space available to display the settings
which helped to make the settings very clear. That was a great suggestion.
Therefore, this patch does the following:
* The column for 'Forcerport' now will show: Auto (Yes), Auto (No), Yes, or No.
* A column for the 'Comedia' setting has been added. It too will display the
setting in a non-cryptic way: Auto (Yes), Auto (No), Yes, or No.
* UPGRADE.txt has been updated to document this change.
(closes issue ASTERISK-22728)
Reported by: Walter Doekes
Tested by: Michael L. Young
Patches:
asterisk-forcerport-display-clarification_v3.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2941
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@402111 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adapts the behaviour of avpf to only impact the format of outgoing calls. For
inbound calls, both AVP and AVPF calls will be accepted regardless of the value
of avpf in the configuration.
(closes issue ASTERISK-22005)
Reported by: Torrey Searle
Patches:
optional_avpf_trunk.patch uploaded by tsearle (license 5334)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@401884 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also covers ast_app_parse_timelen-fail-zero-length.patch, but the patch was
replaced with one of my own.
(issue ASTERISK-22467)
Reported by: Corey Farrell
Patches:
chan_dahdi-cleanup_push.patch uploaded by coreyfarrell (license 5909)
clicompat-r2.patch uploaded by coreyfarrell (license 5909)
codecs-ilbc-doCPLC.patch uploaded by coreyfarrell (license 5909)
data-cleanup-test-registration.patch uploaded by coreyfarrell (license 5909)
main-asterisk-kill-listener.patch uploaded by coreyfarrell (license 5909)
........
Merged revisions 401704 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@401705 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If preferred codecs included any non-audio format the code would
mistakenly add the audio format, even if it was not a joint capability
with the remote side.
(closes issue ASTERISK-21131)
Reported by: nbougues
Patches:
patch_unsupported_codec_1.8.patch uploaded by nbougues (license 6470)
........
Merged revisions 401497 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@401498 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Transferring an analog call using flashhooks generated an unable to get
index WARNING message when the transfer is completed.
* Removed unnecessary analog subchannel shell games when transferring a
call using flashhooks.
Thanks to Tzafrir Cohen for mentioning this in a comment on issue
ASTERISK-22720.
........
Merged revisions 401378 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@401379 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When trying to determine if a peer is behind NAT, we should not be using the
ports when comparing addresses.
This patch removes the port from being checked and just useds the addresses
now.
(closes issue ASTERISK-22729)
Reported by: Michael L. Young
Tested by: Michael L. Young
Patches:
asterisk-remove-using-port-for-nat-check.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2927/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@401182 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A condition was added in a commit to fix ASTERISK-21374, that, if the
SIP_PAGE3_NAT_AUTO_RPORT flag was set, to then copy a peer's SIP_NAT_FORCE_RPORT
flag to the dialog. This condition should not have been there since it assumed
that if Asterisk is in an environment where NAT is involved, that the auto_* nat
settings or force_rport setting would be on in the global settings. If the nat
setting in the global setting is set to 'nat=no' and then turned on for peers
(which is not quite the recommended way, although it is allowed) this flag is
never copied to the dialog resulting in problems like, REGISTER replies going
to the wrong port.
This patch removes this conditional check and will now always use the peer's
flag which by this point in the code the checks on whether the peer is behind
NAT or not (if using auto_force_rport) have already been run.
(closes issue ASTERISK-22236)
Reported by: Filip Frank
Tested by: Michael L. Young
Patches:
asterisk-2236-always-set-rport.diff uploaded
by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2919/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@401167 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a 200 OK for an initial INVITE is received, we were doing
the right thing by ACKing and sending an immediate BYE. However,
we also were doing the wrong thing and queuing an answer frame,
thus causing the call to be answered. This would cause the call
to be hung up by the channel thread, thus resulting in a second
BYE being sent out.
In this fix, I also have set the hangupcause to be correct since
the initial BYE being sent by Asterisk had an unknown hangup
cause. I have changed to using "Bearer capabilty not available"
since the call was hung up due to an SDP offer/answer error.
(closes issue ASTERISK-22621)
reported by Kinsey Moore
........
Merged revisions 400970 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@400971 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Remember the swgain setting from CLI "dahdi set swgain" command so the
CLI "dahdi show channel" output will reflect the current setting.
* Updated CLI "dahdi set hwgain" and "dahdi set swgain" documentation.
(issue ASTERISK-22429)
Reported by: Jaco Kroon
Patches:
jira_asterisk_22429_v1.8_v2.patch (license #5621) patch uploaded by rmudgett
........
Merged revisions 400907 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@400909 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Bumping the SDP version number can cause interoperability problems
since receivers of the responses will expect that a 200 SDP will
be identical to a previous 183 SDP.
(closes issue ASTERISK-21204)
reported by NITESH BANSAL
Patches:
dont-increment-session-version-in-2xx-after-183.patch uploaded by NITESH BANSAL (License #6418)
........
Merged revisions 400906 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@400908 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The member reg in the peercnt structure is an unsigned char and peercnt_modify()
is expecting an unsigned char argument which gets assigned to peercnt->reg.
This patch fixes that by casting the integer argument being passed to
peercnt_modify to unsigned char.
........
Merged revisions 400314 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@400315 65c4cc65-6c06-0410-ace0-fbb531ad65f3
