Age | Commit message (Collapse) | Author |
|
|
|
If a read error occurs, we immediately attempt a reconnect without any
delay. Instead, let's sleep and backoff up to 60 seconds before we try
again.
ASTERISK-24712 #close
Reported by: Matthias Urlichs
Change-Id: I6fe10ef4734837727437beab715e336777f13f48
|
|
|
|
|
|
|
|
chan_sip sets the hangup cause code to AST_CAUSE_REQUESTED_CHAN_UNAVAIL
(44) when a channel is hung up due to an RTP timeout. So do the same
when it happens with PJSIP for parity.
Change-Id: I3546ebbde6460c22a27c9da1bf321711b5961ab8
|
|
|
|
|
|
|
|
|
|
Updated the AMI version for the following reason (see CHANGES for more details):
The 'PJSIPShowEndpoint' command's response event of 'IdentifyDetail' now
contains a new optional parameter, 'MatchHeader'.
Change-Id: Ie206913ef1dcfa6a2ebe3282da2387e52d6f05b9
|
|
After configuring Asterisk with '--with-pjproject-bundled' the configure/build
process attempts to download pjproject from its download site. Currently, a
timeout of 10 seconds is used that will stop the download process if pjproject
has not been fully downloaded in that time. For some systems this was not enough
time and the process was timing out too early.
This patch raises the download timeout value to '60'. Also, this patch fixes
another bug where the DOWNLOAD_TIMEOUT variable was not being properly exported
due to a naming error. DOWNLOAD_MAX_TIMEOUT is now properly renamed to
DOWNLOAD_TIMEOUT.
ASTERISK-26814 #close
Change-Id: Ia56e4e8a3d39db76bc8a1852b2cf07ec10b39842
|
|
The documentation for JABBER_STATUS (and the deprecated JabberStatus
app) indicate that a return value of 7 indicates that the specified
buddy was not in the roster. It also indicates that you can specify a
"bare" JID (one without a resource). Unfortunately the actual behavior
does not match the documented behavior.
Assuming that our roster includes the buddy online and available
"valid@example.org/Valid" and does *not* include the buddy
"invalid@example.org", the JABBER_STATUS() function returns the
following before this patch:
+------------------------------+------------+--------------------------+
| Buddy | Status | Result |
+------------------------------+------------+--------------------------+
| valid@example.org | Online | 7 (Not in roster) |
| valid@example.org/Valid | Online | 1 (Online) |
| valid@example.org/Invalid | N/A | 7 (Not in roster) |
| invalid@example.org | N/A | Error logged, no return |
| invalid@example.org/Valid | N/A | Error logged, no return |
+------------------------------+------------+--------------------------+
And after this patch:
+------------------------------+------------+--------------------------+
| Buddy | Status | Result |
+------------------------------+------------+--------------------------+
| valid@example.org | Online | 1 (Online) |
| valid@example.org/Valid | Online | 1 (Online) |
| valid@example.org/Invalid | N/A | 6 (Offline) |
| invalid@example.org | N/A | 7 (Not in roster) |
| invalid@example.org/Valid | N/A | 7 (Not in roster) |
+------------------------------+------------+--------------------------+
This brings the behavior in line with the documentation.
ASTERISK-23510 #close
Reported by: Anthony Critelli
Change-Id: I9c3241035363ef4a6bdc21fabfd8ffcd9ec657bf
|
|
If any errors occur during the TLS connection setup, we currently dump a
fairly generic error message. So instead we try to pull in something
useful from OpenSSL to report instead.
ASTERISK-24712
Reported by: Matthias Urlichs
Change-Id: I288500991a9681f447d92913b11fedaf426087f4
|
|
The only remaining reference to the endpoint is in the endpoints
container, and because it is unlinked in ast_endpoint_shutdown, we don't
have to explicitly cleanup the endpoint ourselves.
Change-Id: I912a2692e52d3e2ed445b32d8ae3f9004bc2f2e8
|
|
SSL_connect returns non-zero for both success and some error conditions
so simply negating is inadequate.
Change-Id: Ifbf882896e598703b6c615407fa456d3199f95b1
|
|
If we never establish a connection to our Jabber server, iksemel never sets up
its internal transport pointer, so attempting to send a message dereferences a
NULL pointer and causes a crash.
ASTERISK-21855 #close
Reported by: Jeremy Kister
Change-Id: I204a568894e4a53ab929783ecc594a000f04d79c
|
|
ASTERISK-25622 #close
Reported by: Sean Darcy
Change-Id: I8472cb7bfb58d411a3cfbd482da98cae2d94d1e9
|
|
|
|
|
|
Dynamic payload types were statically defined in Asterisk. This unfortunately
limited the number of dynamic payloads that could be registered. With this patch
dynamic payload type numbers are now assigned dynamically and per RTP instance.
However, in order to limit any issues where some clients expect the old
statically defined value this patch makes it so the value Asterisk used to pre-
designate is used for the dynamic assignment if available.
An option, "rtp_use_dynamic", has also been added (can be set in asterisk.conf)
that turns the new dynamic behavior on or off. When off it reverts back to using
statically defined payload values. This option defaults to "yes" in Asterisk 15.
ASTERISK-26515 #close
patches:
ASTERISK-26515.diff submitted by jcolp (license 5000
Change-Id: I7653465c5ebeaf968f1a1cc8f3f4f5c4321da7fc
|
|
|
|
bridge""
|
|
from queue"
|
|
The CDR code previously did not allow the user field to be set
from the 'h' extension in the dialplan. This change removes that
limitation and allows it to be set.
ASTERISK-26818
Change-Id: I0fed8a79b5e408bac4e30542b8f33a61c5ed9aa6
|
|
|
|
Support for RFC3578 overlap dialling (i.e. 484 Response to partially matched
destinations) as currently provided by chan_sip is missing from res_pjsip.
This patch adds a new endpoint attribute (allow_overlap) [defaults to yes]
which when set to yes enables 484 responses to partial destination
matches rather than the current 404.
ASTERISK-26864
Change-Id: Iea444da3ee7c7d4f1fde1d01d138a3d7b0fe40f6
|
|
|
|
|
|
Rather than hard-coding UDP, allow consumers of the HEP API to specify
which protocol is in use. Update the PJSIP provider to pass in the
current protocol type.
ASTERISK-26850 #close
Change-Id: I54bbb0a001cfe4c6a87ad4b6f2014af233349978
|
|
This reverts commit 163e9e53dc7d84dd42721e733b7706c8147bdd27.
Change-Id: Ief28479c77a298879dfe2c56be7ee92dc465da4b
|
|
We aren't validating that the URI we just parsed is a SIP/SIPS one before
trying to access the user, host, and port members of a possibly uninitialized
structure.
Also update the MessageSend documentation to indicate what 'from' formats are
accepted.
ASTERISK-26484 #close
Reported by: Vinod Dharashive
Change-Id: I476b5cc5f18a7713d0ee945374f2a1c164857d30
|
|
ASTERISK-26776 #close
Change-Id: I884b6f4e8233a355d0be687ec78d41bc0e4d3fd2
|
|
Some codecs - codec_speex specifically - take voice frames and return
other types of frames, like CNG. If we subsequently treat those as
voice frames, we'll run into trouble when destroying the frame because
of the requirement that each voice frame have an associated format.
ASTERISK-26880 #close
Reported by: Kirsty Tyerman
Change-Id: I43f8450c48fb276ad8b99db8512be82949c1ca7c
|
|
|
|
Fixed a bug in function "ast_audiohook_write_frame" that checked the
variable other_factory_samples and only flushed the factories, so they
would be in sync, when other_factory_samples > 0. When there is not any
rtp incoming the variable other_factory_samples will be 0, and although
the result of "our_factory_ms - other_factory_ms" may be very large,
this led to the record file not syncing.
ASTERISK-26875 #close
Reported-by: Aaron An
Tested-by: Aaron An
Change-Id: Ia4d890fb8fc1636a7188502bab35f555685aea22
|
|
|
|
POSIX does not require getprotobyname() to be thread safe and some
implementations use static memory which causes issues when multiple
threads are used.
Further, our usage of it today is just to ultimately get IPPROTO_TCP
for calls to setsockopt(). So instead we just use IPPROTO_TCP directly.
Change-Id: I2e14e58674808f7ce99b2f5e900d0f90d0d8da48
|
|
We are currently passing in the capacity of the read buffer instead of the
number of bytes that we actually read off the wire.
Change-Id: I60465049727d955c7f9a5e529e6f2aaff04cda36
|
|
|
|
|
|
stopped."
|
|
|
|
|
|
|
|
transport"
|
|
Queue member will get stuck in pending_members if queue calls a device
that is different from the one observed for state changes.
This patch removes members from pending_members as a result of channel stasis
events such as blind or attended transfers and hangup.
ASTERISK-26862 #close
Change-Id: I8bf6df487b9bb35726c08049ff25cdad5e357727
|
|
* Added CHANNEL(callid) to retrieve the call identifier log tag associated
with the channel. Dialplan now has access to the call log search key
associated with the channel so it can be saved in case there is a problem
with the call.
ASTERISK-26878
Change-Id: I2c97ebd928b6f3c5bc80c5729e4d3c07f453049f
|
|
The queue_stasis_data structure contains various mutable fields that require
appropriate locking. Specifically, the 'dying,' 'member_uniqueid,' and
'caller_uniqueid' fields need to be locked when read from or written to.
Change-Id: I246b7dbff8447acc957a1299f6ad0ebd0fd39088
|
|
ASTERISK-26846 #close
Change-Id: I541a1602ff55ab73684e9f8002edb9e0e745d639
|