Adds parsing of ANI II digits (Originating
Line Information) to PJSIP, on par with
what currently exists in chan_sip.
ASTERISK-29472
Change-Id: Ifc938a7a7d45ce33999ebf3656a542226f6d3847
When a Transfer/REFER is executed, TRANSFERSTATUSPROTOCOL variable is
0 when no protocl specific error
SIP example of failure, 3xx-6xx for the SIP error code received
This allows applications to perform actions based on the failure
reason.
ASTERISK-29252 #close
Reported-by: Dan Cropp
Change-Id: Ia6a94784b4925628af122409cdd733c9f29abfc4
There are a couple of parameters (datalen and data) that do not get set
in chan_pjsip_indicate which could cause an Invalid message to pop up
for things such as fax. This patch adds them to the frame.
Change-Id: Ia51be086a0708be905e73d1f433572c49c7e38f8
session->channel doesn't exist until chan_pjsip creates it, so intead of
setting a channel variable every new incoming call sets one and the same
global variable.
This patch moves the code to chan_pjsip so that SIPDOMAIN is set on
a newly created channel, it also removes a misleading reference to
channel->session used to fetch call pickup configuraion.
ASTERISK-29240
Change-Id: I90c9bbbed01f5d8863585631a29322ae4e046755
The fix for ASTERISK-27902 made chan_pjsip process SIP responses twice.
This resulted in extra noise in logs (for example, "is making progress"
and "is ringing" get logged twice by app_dial), as well as in noise in
signalling: one incoming 183 Session Progress results in 2 outgoing 183-s.
This change splits the response handler into 2 functions:
- one for updating HANGUPCAUSE, which is still called twice,
- another that does the rest, which is called only once as before.
ASTERISK-28016
Reported-by: Alex Hermann
ASTERISK-28549
Reported-by: Gant Liu
ASTERISK-28185
Reported-by: Julien
Change-Id: I0a1874be5bb5ed12d572d17c7f80de6e5e542940
Add channel reference count for PJSIP REFER. The call could be terminated
prior to the result of the transfer. In that scenario, when the SUBSCRIBE/NOTIFY
occurred several minutes later, it would attempt to access a session which was
no longer valid. Terminate event subscription if pjsip_xfer_initiate() or
pjsip_xfer_send_request() fails in transfer_refer().
ASTERISK-29201 #close
Reported-by: Dan Cropp
Change-Id: I3fd92fd14b4e3844d3d7b0f60fe417a4df5f2435
In some circumstances it was possible for an INVITE
session to be destroyed while we were still using it.
This occurred due to the reference on the INVITE session
being released internally as a result of its state
changing to DISCONNECTED.
This change adds a reference to the INVITE session
which is released when our own session is destroyed,
ensuring that the INVITE session remains valid for
the lifetime of our session.
ASTERISK-29022
Change-Id: I300c6d9005ff0e6efbe1132daefc7e47ca6228c9
Added to:
* bridges/bridge_softmix.c
* channels/chan_pjsip.c
* include/asterisk/res_pjsip_session.h
* main/channel.c
* res/res_pjsip_session.c
There NO functional changes in this commit.
Change-Id: I06af034d1ff3ea1feb56596fd7bd6d7939dfdcc3
A patch made a reference to the PJSIP_SC_NULL enumeration value, which
was added to pjproject 2.8 and above thus making it so Asterisk would
fail to compile with prior versions of pjproject.
This patch removes the reference, and instead initializes the value
to '0'.
ASTERISK-28886 #close
Change-Id: I68491c80da1a0154b2286c9458440141c98db9d7
When fax_gateway_framehook is called and a gateway hasn't already
been started, the framehook gets the t38 state for both the current
channel and the peer. That call trickles down to the channel
driver which determines the state. If either channel is hung up
(or in the process of being hung up), the channel driver's tech_pvt
is going to be NULL which, in the case of chan_pjsip, will cause a
segfault.
* Added a hangup check for both the channel and peer channel
before starting a fax gateway.
* Added a check for NULL tech_pvt to chan_pjsip_queryoption
so we don't attempt to reference a tech_pvt that's already
gone.
ASTERISK-28923
Reported by: Yury Kirsanov
Change-Id: I4e10e63b667bbb68c1c8623f977488f5d807897c
Some places in Asterisk did not treat the formats on a stream
as immutable when they are.
The ast_stream_get_formats function is now const to enforce this
and parts of Asterisk have been updated to take this into account.
Some violations of this were also fixed along the way.
An additional minor tweak is that streams are now allocated with
an empty format capabilities structure removing the need in various
places to check that one is present on the stream.
ASTERISK-28846
Change-Id: I32f29715330db4ff48edd6f1f359090458a9bfbe
If chan_pjsip is configured for DTMF_RFC_4733, and the core triggers a
digit begin before media, or rtp has been setup then it's possible the
outgoing channel will hear a constant DTMF tone upon answering.
This happens because when there is no media, or rtp chan_pjsip notifies
the core to initiate inband DTMF. However, upon digit end if media, and
rtp become available then chan_pjsip does not notify the core to stop
inband DTMF. Thus the tone continues playing.
This patch makes it so chan_pjsip only notifies the core to start
inband DTMF in only the required cases. Now if there is no media, or
rtp availabe upon digit begin chan_pjsip does nothing, but tells the
core it handled it.
ASTERISK-28817 #close
Change-Id: I0dbea9fff444a2595fb18c64b89653e90d2f6eb5
Do not hang up a PJSIP channel on RTP timeout if that channel is in
a direct-media bridge. Also reset the time of the last received RTP packet when
direct-media ends (wait full rtp_timeout period before checking first time after
audio came back to Asterisk).
ASTERISK-28774
Reported-by: Michael Neuhauser
Change-Id: I8b62012be7685849e8fb2b1c5dd39d35313ca2d1
If the SSRC of a received RTP packet differed from the previous SSRC
an SSRC change control frame would be queued ahead of the media
frame. In the case of audio this would result in the format of the
audio frame not being checked, and if it differed or was not allowed
then it could cause the call to drop due to failure to set up a
translation path.
The chan_pjsip module will now no longer assume the first frame
will be the audio frame and instead goes through the complete list
to find it.
ASTERISK-28759
Change-Id: I6d854cc523f343e299a615636fc65bdbd5f809ec
If chan_pjsip receives an RTP packet whose payload differs from the
channel's native format, and asymmetric_rtp_codec is disabled (the
default), Asterisk will switch the channel's native format to match
that of the incoming packet without regard to the negotiated payloads.
We now check that the received frame is in a format we have negotiated
before switching payloads which results in these packets being dropped
instead of causing the session to terminate.
ASTERISK-28139 #close
Reported by: Paul Brooks
Change-Id: Icc3b85cee1772026cee5dc1b68459bf9431c14a3
Add a new dialplan function PJSIP_MOH_PASSTHROUGH that allows
the on-hold behavior to be controlled on a per-call basis
ASTERISK-28542 #close
Change-Id: Iebe905b2ad6dbaa87ab330267147180b05a3c3a8
When fax detection occurs on an outbound PJSIP channel the
redirect operation will result in a masquerade occurring and
the underlying channel on the session changing. The code
incorrectly relocked the new channel instead of the old
channel when returning. This resulted in the new channel
being locked indefinitely. The code now always acts on the
expected channel.
ASTERISK-28538
Change-Id: I2b2e60d07e74383ae7e90d752c036c4b02d6b3a3
This change adds H.265/HEVC as a known codec and creates a cached
"h265" media format for use.
Note that RFC 7798 section 7.2 also describes additional SDP
parameters. Handling of these is not yet supported.
ASTERISK-28512
Change-Id: I26d262cc4110b4f7e99348a3ddc53bad0d2cd1f2
Previously, when a Transfer (REFER) was performed, chan_pjsip would set
the TRANSFERSTATUS to SUCCESS when the REFER was queued up. This did not
reflect a successful/unsuccessful transfer the way chan_sip did.
Added a callback module to process the refer subscription information.
Now depends on res_pjsip_pubsub so call transfer progress can be monitored
and reported
ASTERISK-26968 #close
Reported-by: Dan Cropp
Change-Id: If6c27c757c66f71e8b75e3fe49da53ebe62395dc
We have seen some rare case of segmentation fault in hangup function
and we could notice that channel pointer was NULL. Debug log shows
that there is a 200 OK answer and SIP timeout at the same time. It
looks that while the SIP session was being destroyed due to timeout
call hangup due to answer event lead to race condition and channel
is being destroyed from two different places. The check ensures we
check it not to be NULL before freeing it.
ASTERISK-25371
Change-Id: I19f6566830640625e08f7b87bfe15758ad33a778
The caller endpoint hears dead silence if a callee replies 180 (without SDP)
and the caller already received 183 (with SDP).
It happens because Asterisk sends 180 (WITH SDP) to the caller,
there are not incoming RTP packets from the callee
and Asterisk does not generate inband ringing,
so there are not any outgoing RTP packets to the caller.
This patch replaces 180 by 183 if SDP negotiation has completed,
as if the caller endpoint is configured with "inband_progress=yes".
In this case Asterisk will generate inband ringing untill Asterisk receive
incoming RTP packets from the callee.
ASTERISK-27994 #close
Change-Id: I7450b751083ec30d68d6abffe922215a15ae5a73
When the dtmf_mode on an endpoint is configured as "auto_info"
Asterisk will produce an inband DTMF tone alongside an INFO
message when sending DTMF.
ASTERISK-28371
Change-Id: I1380b82f006e110a1b83fbb50c9873edd13a5d9a
chan_sip will always ignore 183 responses that do not contain SDP
however, chan_pjsip will currently always translate it into a
183 with SDP. This new flag allows chan_pjsip to have the same
behavior as chan_sip.
ASTERISK-28322 #close
Change-Id: If81cfaa17c11b6ac703e3d71696f259d86c6be4a
New dialplan function PJSIP_PARSE_URI added to parse an URI and return
a specified part of the URI.
This is useful when need to get part of the URI instead of cutting it
using a CUT function.
For example to get 'user' part of Remote URI
${PJSIP_PARSE_URI(${CHANNEL(pjsip,remote_uri)},user)}
ASTERISK-28144 #close
Change-Id: I5d828fb87f6803b6c1152bb7b44835f027bb9d5a
This patch adds new options 'trust_connected_line' and 'send_connected_line'
to the endpoint.
The option 'trust_connected_line' is to control if connected line updates
are accepted from this endpoint.
The option 'send_connected_line' is to control if connected line updates
can be sent to this endpoint.
The default value is 'yes' for both options.
Change-Id: I16af967815efd904597ec2f033337e4333d097cd
chan_pjsip wasn't registering for "BEFORE_MEDIA" responses which meant
it was not updating HANGUPCAUSE for 4XX responses. If the remote end
sent a "180 Ringing", then a "486 Busy", the hangup cause was left at
"180 Normal Clearing".
* Removed chan_pjsip_incoming_response from the original session
supplement (which was handling only "AFTER MEDIA") and added it to a
new session supplement which accepts both "BEFORE_MEDIA" and
"AFTER_MEDIA".
* Also cleaned up some cleanup code in load module.
ASTERISK-27902
Change-Id: If9b860541887aca8ac2c9f2ed51ceb0550fb007a
Core bridging and, more specifically, bridge_softmix have been
enhanced to relay received frames of type TEXT or TEXT_DATA to all
participants in a softmix bridge. res_pjsip_messaging and
chan_pjsip have been enhanced to take advantage of this so when
res_pjsip_messaging receives an in-dialog MESSAGE message from a
user in a conference call, it's relayed to all other participants
in the call.
res_pjsip_messaging already queues TEXT frames to the channel when
it receives an in-dialog MESSAGE from an endpoint and chan_pjsip
will send an MESSAGE when it gets a TEXT frame. On a normal
point-to-point call, the frames are forwarded between the two
correctly. bridge_softmix was not though so messages weren't
getting forwarded to conference bridge participants. Even if they
were, the bridging code had no way to tell the participants who
sent the message so it would look like it came from the bridge
itself.
* The TEXT frame type doesn't allow storage of any meta data, such
as sender, on the frame so a new TEXT_DATA frame type was added that
uses the new ast_msg_data structure as its payload. A channel
driver can queue a frame of that type when it receives a message
from outside. A channel driver can use it for sending messages
by implementing the new send_text_data channel tech callback and
setting the new AST_CHAN_TP_SEND_TEXT_DATA flag in its tech
properties. If set, the bridging/channel core will use it instead
of the original send_text callback and it will get the ast_msg_data
structure. Channel drivers aren't required to implement this. Even
if a TEXT_DATA enabled driver uses it for incoming messages, an
outgoing channel driver that doesn't will still have it's send_text
callback called with only the message text just as before.
* res_pjsip_messaging now creates a TEXT_DATA frame for incoming
in-dialog messages and sets the "from" to the display name in the
"From" header, or if that's empty, the caller id name from the
channel. This allows the chat client user to set a friendly name
for the chat.
* bridge_softmix now forwards TEXT and TEXT_DATA frames to all
participants (except the sender).
* A new function "ast_sendtext_data" was added to channel which
takes an ast_msg_data structure and calls a channel's
send_text_data callback, or if that's not defined, the original
send_text callback.
* bridge_channel now calls ast_sendtext_data for TEXT_DATA frame
types and ast_sendtext for TEXT frame types.
* chan_pjsip now uses the "from" name in the ast_msg_data structure
(if it exists) to set the "From" header display name on outgoing text
messages.
Change-Id: Idacf5900bfd5f22ab8cd235aa56dfad090d18489
ast_sip_push_task_synchronous() did not necessarily execute the passed in
task under the specified serializer. If the current thread is any
registered pjsip thread then it would execute the task immediately instead
of under the specified serializer. Reentrancy issues could result if the
task does not execute with the right serializer.
The original reason ast_sip_push_task_synchronous() checked to see if the
current thread was a registered pjsip thread was because of a deadlock
with masquerades and the channel technology's fixup callback
(ASTERISK_22936). A subsequent masquerade deadlock fix (ASTERISK_24356)
involving call pickups avoided the original deadlock situation entirely.
The PJSIP channel technology's fixup callback no longer needed to call
ast_sip_push_task_synchronous().
However, there are a few places where this unexpected behavior is still
required to avoid deadlocks. The pjsip monitor thread executes callbacks
that do calls to ast_sip_push_task_synchronous() that would deadlock if
the task were actually pushed to the specified serializer. I ran into one
dealing with the pubsub subscriptions where an ao2 destructor called
ast_sip_push_task_synchronous().
* Split ast_sip_push_task_synchronous() into
ast_sip_push_task_wait_servant() and ast_sip_push_task_wait_serializer().
ast_sip_push_task_wait_servant() has the old behavior of
ast_sip_push_task_synchronous(). ast_sip_push_task_wait_serializer() has
the new behavior where the task is always executed by the specified
serializer or a picked serializer if one is not passed in. Both functions
behave the same if the current thread is not a SIP servant.
* Redirected ast_sip_push_task_synchronous() to
ast_sip_push_task_wait_servant() to preserve API for released branches.
ASTERISK_26806
Change-Id: Id040fa42c0e5972f4c8deef380921461d213b9f3
This change allows chan_pjsip to be given an AST_FRAME_RTCP
containing REMB feedback and pass it to res_rtp_asterisk.
Once res_rtp_asterisk receives the frame a REMB RTCP feedback
packet is constructed with the appropriate contents and sent
to the remote endpoint.
ASTERISK-27776
Change-Id: Ic53f821c1560d8924907ad82c4d9c0bc322b38cd
This change extends the existing AST_FRAME_RTCP frame type to be
able to contain additional RTCP message types, such as feedback
messages. The payload type is contained in the subclass which allows
knowing what is in the frame itself.
The RTCP feedback message type is now handled and REMB[1] messages
are raised with their containing information.
This also fixes a bug where all feedback messages were triggering
video updates instead of just FIR and FUR.
Finally RTCP frames are now passed up through the Asterisk core to
what is handling the channel, mapped appropriately in the case of
bridging, and written to an outgoing stream. Since RTCP frames are
on a per-stream basis this is only done on multistream capable
channels.
[1] https://tools.ietf.org/html/draft-alvestrand-rmcat-remb-03
ASTERISK-27758
ASTERISK-26366
Change-Id: I680da0ad8d5059d5e9655d896fb9d92e9da8491e
This removes references that are no longer needed due to automatic
references created by module dependencies.
In addition this removes most calls to ast_module_check as they were
checking modules which are listed as dependencies.
Change-Id: I332a6e8383d4c72c8e89d988a184ab8320c4872e
* Declare 'requires' and 'enhances' text fields on module info structure.
* Rename 'nonoptreq' to 'optional_modules'.
* Update doxygen comments.
Still need to investigate dependencies among modules I cannot compile.
Change-Id: I3ad9547a0a6442409ff4e352a6d897bef2cc04bf
Attempting to dial PJSIP/endpoint when the endpoint doesn't exist and
disable_multi_domain=no results in a misleading empty endpoint name
message. The message should say the endpoint was not found.
* Added missing endpoint not found message.
* Added more information to the empty endpoint name msgs if available.
* Eliminated RAII_VAR in request().
Change-Id: I21da85ebd62dcc32115b2ffcb5157416ebae51e4
This patch does three things associated with the initial incoming INVITE
request URI.
1) Add access to the full initial incoming INVITE request URI.
2) We were not setting DNID on incoming PJSIP channels. The DNID is the
user portion of the initial incoming INVITE Request-URI. The value is
accessed by reading CALLERID(dnid).
3) Fix CHANNEL(pjsip,target_uri) documentation.
* The initial incoming INVITE request URI is now available using
CHANNEL(pjsip,request_uri).
* Set the DNID on PJSIP channel creation so CALLERID(dnid) can return the
initial incoming INVITE request URI user portion.
* CHANNEL(pjsip,target_uri) now correctly documents that the target URI is
the contact URI.
* Refactored print_escaped_uri() out of channel_read_pjsip() to handle
pjsip_uri_print() error condition when the buffer is too small.
ASTERISK-27478
Change-Id: I512e60d1f162395c946451becb37af3333337b33
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
chan_pjsip_indicate was missing a case for the recently added
AST_CONTROL_STREAM_TOPOLOGY_CHANGED condition and was returning an
error and causing the call to be hung up instead of just ignoring
it.
ASTERISK-27260
Reported by: Daniel Heckl
Change-Id: I4fecbb00a0b8a853da85155065c1a6bddf235e80
When rtp_keepalive is on for a PJSIP endpoint dialing to another
Asterisk instance also using PJSIP, Asterisk will continue to print
warning messages about not being able to send frames of a certain
type. This suppresses that warning message.
Change-Id: I0332a05519d7bda9cacfa26d433909ff1909be67
Introduce a new property to rtp-engine to make it aware of
the desire for assymetric codecs or not. If asymmetric codecs
is not allowed, the bridge will compare read/write formats
and shut down the p2p bridge if needed
ASTERISK-26745 #close
Change-Id: I0d9c83e5356df81661e58d40a8db565833501a6f
This function is a replica of SIPDtmfMode, allowing the DTMF mode of a
PJSIP call to be modified on a per-call basis
ASTERISK-27085 #close
Change-Id: I20eef5da3e5d1d3e58b304416bc79683f87e7612
This patch creates a new configuration option called "webrtc". When enabled it
defaults and enables the following options that are needed in order for webrtc
to work in Asterisk:
rtcp-mux, use_avpf, ice_support, and use_received_transport=enabled
media_encryption=dtls
dtls_verify=fingerprint
dtls_setup=actpass
When "webrtc" is enabled, this patch also parses the "msid" media level
attribute from an SDP. It will also appropriately add it onto the outgoing
session when applicable.
Lastly, when "webrtc" is enabled h264 RTCP FIR feedback frames are now sent.
ASTERISK-27119 #close
Change-Id: I5ec02e07c5d5b9ad86a34fdf31bf2f9da9aac6fd
