The previous patch for ASTERISK-27216 made it so you wouldn't get any
position or periodic announcements unless you had announce-to-first-user
enabled. The announce-to-first-user feature was added by ASTERISK_21782
as a result of the patch which introduced the redundant announcements that
ASTERISK-27216 removes.
* By noting that the makeannouncement variable is used to suppresses the
first user announcement, we set its initial value to the
announce-to-first-user enable setting.
ASTERISK-27216
Change-Id: Ieaeb7dbea8ae7073086b775fbafe0625b000b10a
Somewhere along the way we lost the ability to debug individual
source files. For modules, this wasn't a big deal but all the
source files in ./main are in the one "core" module so debugging
individual core capabilities was almost impossible.
* Added a test to DEBUG_ATLEAST that also checks __FILE__ instead
of just module name. Any source file will work even if it's in
a module subdirectory.
Change-Id: Icc0af41837f3b1679dec7af21fa32cd1f7469f6e
This change adds 'video_sfu' as a requested bridge type when
creating a bridge. By specifying this a mixing type bridge is
created that exchanges video in an SFU fashion.
Change-Id: I2ada47cf5f3fc176518b647c0b4aa39d55339606
The pjsip_publishc_init() call was referenced with a misplaced
parentheses. As a result, outbound publication messages went out with an
expiration of 1 second.
ASTERISK-27298
Change-Id: I93622eabc8ee83e7a22e98c107f921284c605a08
The "res_pjsip: Filter out non SIP(S) requests" commit moved the
filtering of messages to pjproject's PJSIP_MOD_PRIORITY_TRANSPORT_LAYER
in order to filter out incoming bad uri schemes as early as possible.
Since the change affected outgoing messages as well and the TRANSPORT
layer is the last to be run on outgoing messages, we were overwriting
the setting of external_signaling_address (which is set earlier by
res_pjsip_nat) with an internal address.
* pjsip_message_filter now registers itself as a pjproject module
twice. Once in the TSX layer for the outgoing messages (as it was
originally), then a second time in the TRANSPORT layer for the
incoming messages to catch the invalid uri schemes.
ASTERISK-27295
Reported by: Sean Bright
Change-Id: I2c90190c43370f8a9d1c4693a19fd65840689c8c
The bridge_p2p_rtp_write() has potential reentrancy problems.
* Accessing the bridged RTP members must be done with the instance1 lock
held. The DTMF and asymmetric codec checks must be split to be done with
the correct RTP instance struct locked. i.e., They must be done when
working on the appropriate side of the point to point bridge.
* Forcing the RTP mark bit was referencing the wrong side of the point to
point bridge. The set mark bit is used everywhere else to set the mark
bit when sending not receiving.
The patches for ASTERISK_26745 and ASTERISK_27158 did not take into
account that not everything carried by RTP uses a codec. The telephony
DTMF events are not exchanged with a codec. As a result when
RFC2833/RFC4733 sent digits you would crash if "core set debug 1" is
enabled, the DTMF digits would always get passed to the core even though
the local native RTP bridge is active, and the DTMF digits would go out
using the wrong SSRC id.
* Add protection for non-format payload types like DTMF when updating the
lastrxformat and lasttxformat. Also protect against non-format payload
types when checking for asymmetric codecs.
ASTERISK-27292
Change-Id: I6344ab7de21e26f84503c4d1fca1a41579364186
This could have been fixed by subtracting 1 from the final value of
'len' but the way the packet was being constructed was confusing so I
took the opportunity to (I think) make it more clear.
We were sending 1 extra byte at the end of the SDES RTCP packet which
caused Chrome to complain (in its debug log):
Too little data (1 byte) remaining in buffer to parse
RTCP header (4 bytes).
We now send the correct number of bytes.
Change-Id: I9dcf087cdaf97da0374ae0acb7d379746a71e81b
If using a legitimate certificate from a trusted certificate authority,
you don't need to provide CA file.
Change-Id: I8623973b4209b44889243716d7880274caed8a6d
For some scenarios when an outgoing call was made only a subset of the
configured codecs were offered. If the codecs being offered happened to
not have a codec supported by the phone then the call would fail.
For instance Alice and Bob both are configured in Asterisk for g722 and ulaw(
allow=!all,g722,ulaw). Alice's endpoint however only supports g722 while Bob's
only supports ulaw. When Alice calls Bob, Alice negotiates g722 fine with
Asterisk. But when Asterisk sends the outgoing offer to Bob it only contains
g722 and not both g722 and ulaw, so the call ends.
This patch makes it so all the audio codecs configured on the endpoint always
get sent, and not just a subset. However priority is given to those codecs that
are compatible with the "other side".
ASTERISK-27259 #close
Change-Id: Iffabc373bd94cd1dc700925dcfe406e12918c696
This patch reverts the change by patch 2263 from old reviewboard.
Note that reverting that 2263-patch still preserves the behaviour that
the commit log of the 2263-patch claimed to add. The reason for this is:
The function wait_for_answer is only called from try_calling which
in turn is only called from the main for loop in queue_exec, and
earlier in that loop we already check the things that's removed by
this patch. There's no need to check those things twice each loop
iteration, and I think the proper place to check it is before each
ringing cycle. By checking it in wait_for_answer, you allow the issue
explained in the jira - that the head caller hears announcements while
the agents' sip phones are actively ringing.
Reported-by: Stefan Engström
Tested-by: Stefan Engström
ASTERISK-27216 #close
Change-Id: Ic4290dc75256f9743900c6762ee1bb915f672db0
Discovered while experimenting with Cyber Mega Phone 2K Ultimate Dynamic
Edition after accepting the audio request but declining the video one.
Change-Id: Iaa86d41fccfbc1b559a30ccf740d78a3b5f8a98c
When pruning a request to change the topology of a channel be
more intelligent about the resulting topology that is actually
used for SDP renegotiation.
In a case where a stream has not already been negotiated we
don't need to renegotiate and offer a declined stream. This can
occur if something in Asterisk (such as ConfBridge) requests
to add video to a PJSIP channel that has no video codecs configured.
In this case since the stream did not already exist we can safely
remove the stream from the requested topology, resulting in no
renegotiation occurring.
In a case where a renegotiation is requested with a codec that is
not supported we can reuse the formats of the existing stream if
it exists to ensure that the stream continues to flow, instead of
removing it.
Change-Id: I636540798d55922377318fe619c510fb6ed125fb
During a reinvite, if a remote endpoint error occurs and it returns a 500 the
session would end. This patch makes it so the session is not terminated, but
continues as it was.
The reason for this is because some endpoints may send non session terminating
"server errors" like a failed codec negotiation. So in this case instead of
ending the call it can hopefully continue. In the case of a real server error
the session is already "doomed", will be known soon enough and appropriately
ended by Asterisk later.
Change-Id: Ifeedae86b8cb44b92d52c79046522ec5f0aff1d5
When an INVITE came in with both audio and video streams but there
were no audio codecs defined for the endpoint, we weren't declining
the audio stream. Since it's usually the first/transport stream,
when the video stream was processed and tried to use the transport,
it was empty and caused a crash. We now decline the the stream if
there are no matching codecs so when the video stream is processed,
it's now the first/transport stream and processes normally.
Change-Id: Ic854eda54c95031e66b076ecfae3041d34daa692
Assertions in the v15+ AST-2017-008 patches found that we were not
handling the case if the incoming SDP did not specify the required SSRC
attributes for bundled to work.
* Be strict on matching SSRC for bundled instances including the parent
instance. If the SSRC doesn't match then discard the packet. Bundled has
to tell us in the SDP signaling what SSRC to expect. Otherwise, we will
not know how to find the bundled instance structure.
Change-Id: I152830bbff71c662408909042068fada39e617f9
Some endpoints do not like a stream being reused for a new
media stream. The frame/jitterbuffer can rely on underlying
attributes of the media stream in order to order the packets.
When a new stream takes its place without any notice the
buffer can get confused and the media ends up getting dropped.
This change uses the SSRC change to determine that a new source
is reusing an existing stream and then bridge_softmix renegotiates
each participant such that they see a new media stream. This
causes the frame/jitterbuffer to start fresh and work as expected.
ASTERISK-27277
Change-Id: I30ccbdba16ca073d7f31e0e59ab778c153afae07
There was an issue reported where an SDP received on a 183 Session
Progress message caused a crash because the pending streams had
already been processed when the OK was received. In that case the
pending topology was legitimately NULL. There was an assert for an
incorrect number of streams in the topology but not one for
topology being NULL. In any case, if you're not in dev-mode the
asserts don't do anything and since the scenario is legit, the
asserts weren't appropriate anyway.
* Changed several asserts to warning or debug messages and return
codes as appropriate.
ASTERISK-27264
Reported by: Daniel Heckl
Change-Id: I58daaa9d2938fa980857ab3ec41925ab5ff9c848
In PostgreSQL 9.1 the backslash are string literals and not the escape
of characters.
In previous issue ASTERISK_26057 was fixed the use of escape LIKE but the
support for old version of Postgresql than 9.1 was dropped. The sentence
before make was "ESCAPE '\'" but in version before than 9.1 need it to be
as follow "ESCAPE '\\'".
ASTERISK-27283
Change-Id: I96d9ee1ed7693ab17503cb36a9cd72847165f949
