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
This was dead code, test code introduced with Asterisk 13. This was
found while analyzing ASTERISK_28416 and ASTERISK_29185. This change
partly fixes, not closes those two issues.
Change-Id: I42d0daa37f6f334c7d86672f06f085858a3f3940
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
12 years ago, with ASTERISK_12115 the last four get/uses of socket.port
vanished. However, the struct member itself and all seven set/uses
remained as dead code.
ASTERISK-28798
Change-Id: Ib90516a49eca3d724a70191278aaf2144fb58c59
RFC 8760 added new digest-access-authentication schemes. Testing
revealed that chan_sip does not pick MD5 if several schemes are offered
by the User Agent Server (UAS). This change does not implement any of
the new schemes like SHA-256. This change makes sure, MD5 is picked so
UAS with SHA-2 enabled, like the service www.linphone.org/freesip, can
still be used. This should have worked since day one because SIP/2.0
already envisioned several schemes (see RFC 3261 and its augmented BNF
for 'algorithm' which includes 'token' as third alternative; note: if
'algorithm' was not present, MD5 is still assumed even in RFC 7616).
Change-Id: I61ca0b1f74b5ec2b5f3062c2d661cafeaf597fcd
The module description needs to be on the same line as the
AST_MODULE_INFO or it is not parsed correctly.
Change-Id: I9ba11df1415369790e8656fcb527bb2749373c21
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
This patch makes it so if the PJSIP_SEND_SESSION_REFRESH dialplan function
is called on a channel prior to answering a warning is issued and the
function returns unsuccessful.
ASTERISK-28878 #close
Change-Id: I053f767d10cf3b2b898fa9e3e7c35ff07e23c9bb
The ToHost parameter was not cleared when a peer's host value was
changed to dynamic. This causes invites to be sent to the original host.
ASTERISK-29011 #close
Change-Id: I9678d512741f71baca8f131a65b7523020b07d5c
Prior to making any modifications to the pjsip infrastructure
for ACN, I've added the tracing functions to the existing code.
This should make the final commit easier to review, but we can also
now run a "before and after" trace.
No functional changes were made with this commit.
Change-Id: Ia83a1a2687ccb96f2bc8a2a3928a5214c4be775c
When using the PSJIP_MEDIA_OFFER dialplan function it was not
overriding an endpoint's configured codecs on refresh unless
they had a shared codec between the two.
This patch makes it so whatever is set using PJSIP_MEDIA_OFFER
is used when creating the SDP for a refresh no matter what.
ASTERISK-28878 #close
Change-Id: I0f7dc86fd0fb607c308e6f98ede303c54d1eacb6
The Streams API becomes the home for the core ACN capabilities.
These include...
* Parsing and formatting of codec negotation preferences.
* Resolving pending streams and topologies with those configured
using configured preferences.
* Utility functions for creating string representations of
streams, topologies, and negotiation preferences.
For codec negotiation preferences:
* Added ast_stream_codec_prefs_parse() which takes a string
representation of codec negotiation preferences, which
may come from a pjsip endpoint for example, and populates
a ast_stream_codec_negotiation_prefs structure.
* Added ast_stream_codec_prefs_to_str() which does the reverse.
* Added many functions to parse individual parameter name
and value strings to their respectrive enum values, and the
reverse.
For streams:
* Added ast_stream_create_resolved() which takes a "live" stream
and resolves it with a configured stream and the negotiation
preferences to create a new stream.
* Added ast_stream_to_str() which create a string representation
of a stream suitable for debug or display purposes.
For topology:
* Added ast_stream_topology_create_resolved() which takes a "live"
topology and resolves it, stream by stream, with a configured
topology stream and the negotiation preferences to create a new
topology.
* Added ast_stream_topology_to_str() which create a string
representation of a topology suitable for debug or display
purposes.
* Renamed ast_format_caps_from_topology() to
ast_stream_topology_get_formats() to be more consistent with
the existing ast_stream_get_formats().
Additional changes:
* A new function ast_format_cap_append_names() appends the results
to the ast_str buffer instead of replacing buffer contents.
Change-Id: I2df77dedd0c72c52deb6e329effe057a8e06cd56
chan_sip handle_response() function, for a 400 response to an INVITE,
calls handle_response_invite() and does not generate ACK.
handle_response_invite() does not recognize 400 response and has no
default response processing for unexpected responses, thus it does not
generate ACK either.
The ACK on response repetition comes from handle_response() mechanism
"We must re-send ACKs to re-transmitted final responses".
According to code history, 400 response specific processing was
introduced with commit
"channels/chan_sip: Add improved support for 4xx error codes"
This commit added support for :
- 400/414/493 in handle_response_subscribe() handle_response_register()
and handle_response().
- 414/493 only in handle_response_invite().
This fix adds 400 response support in handle_response_invite().
ASTERISK-28957
Change-Id: Ic71a087e5398dfc7273946b9ec6f9a36960218ad
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
The change to how setvar works for various channels performed in
ASTERISK~23756 missed some required change in the dahdi channel,
where the variables are actually set while reading configuration.
This change should fix the issue.
ASTERISK-28955
Change-Id: Ibfeb7f8cbdd735346dc4028de6a265f24f9df274
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
It is possible to configure a TCP/TLS client without having a TCP/TLS
server. In that case, no error or warning was printed but the headers
Contact and Via in SIP REGISTER were "(null)".
ASTERISK-28798
Change-Id: I387ca5cb6a65f1eb675a29c5e41df8ec6c242ab2
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
Fixes the following compile error:
chan_vpb.cc:2688:26: error: catching polymorphic type
‘class std::exception’ by value
Change-Id: Ic87bc357d72427d77626735c83200fd278a7a649
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 you're for some reason out of RTP ports, chan_sip would previously
responde to an INVITE with a 403, which will fail the call.
Now, it returns a 503, allowing the device/proxy to retry the call on a
different machine.
ASTERISK-28718
Change-Id: I968dcf6c1e30ecddcce397dcda36db727c83ca90
Fixes no-audio issues when the media source is changed and
strictrtp is enabled (default).
If the peer media source changes, the SDP session version also changes.
If it is lower than the one we had stored, chan_sip would ignore it.
This changeset keeps track of the remote media origin identifier,
comparing that as well. If it changes, the session version needn't be
higher for us to accept the SDP.
Common scenario where this would've caused problems: a separate media
gateway that informs the caller about premium rates before handing off
the call to the final destination.
(An alternative fix would be to set ignoresdpversion=yes on the peer.)
ASTERISK-28686
Change-Id: I88fdbc5aeb777b583e7738c084254c482a7776ee
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
The no-entry timeout set to 999999 == 16⅔ minutes, change to INT_MAX
to match behavior of "no timeout" defined in comment.
ASTERISK-28702 #close
Change-Id: I4ea015986e061374385dba247b272f7aac60bf11
lws2sws() does not stop trying to handle header continuation lines
even after all headers have been found. This is problematic if the
first character of a SIP message body is a space or tab character, so
we update to recognize the end of the message header.
ASTERISK-28693 #close
Reported by: Frank Matano
Change-Id: Idec8fa58545cd3fd898cbe0075d76c223f8d33df
This commit adds support for
[AudioSocket](
https://wiki.asterisk.org/wiki/display/AST/AudioSocket),
a very simple bidirectional audio streaming protocol. There are both
channel and application interfaces.
A description of the protocol can be found on the above referenced
GitHub page. A short talk about the reasons and implementation can be
found on [YouTube](https://www.youtube.com/watch?v=tjduXbZZEgI), from
CommCon 2019.
ARI support has also been added via the existing "externalMedia" ARI
functionality. The UUID is specified using the arbitrary "data" field.
ASTERISK-28484 #close
Change-Id: Ie866e6c4fa13178ec76f2a6971ad3590a3a588b5
The change to add setting hangupsource to sig_pri_queue_hangup()
made in https://gerrit.asterisk.org/c/asterisk/+/12857 casued
deadlocks when a hangup request was received from the core at the
same time a hanguprequest was received from the remote end via the
D channel.
Although the PRI's channel private structure was being unlocked
before setting the hangupsource, the PRI's own lock was still being
held during the process. If channel actions were also coming from
the core, a deadlock on the PRI could result. This deadlock could
then escalate to the entire DAHDI subsystem via DAHDI's global
interface list lock, especially if someone used the PRI CLI commands.
Fix:
* We now unlock the PRI as well as the PRI's channel private
structure before setting the hangupsource, then relock both
afterwards.
ASTERISK-28605
Reported by: Dirk Wendland
Change-Id: Id74aaa5d4e3746063dbe9deed188eb65193cb9c9
chan_sip.c:3782 __sip_xmit: sip_xmit of 0x7f1478069230 (len 600) to
213.150.203.60:1492 returned -2: Interrupted system call
returned -2 implies this wasn't actually an OS error, so errno makes no
sense either. Internal error was already logged higher up, and -2
generally means that either there isn't a valid connection available, or
the pipe notification failed, and that is already correctly logged.
ASTERISK-28651 #close
Change-Id: I46eb82924beeff9dfd86fa6c7eb87d2651b950f2
Signed-off-by: Jaco Kroon <jaco@uls.co.za>
The SIP transaction state was reset when emitting an UPDATE or a re-INVITE
related to a COLP, preventing RTP packets to be emitted.
ASTERISK-28647
Change-Id: Ie7a30fa7a97f711e7ba6cc17f221a0993d48bd8b
During capabilities selection (joint capabilities of us and peer,
configured capability for this peer, or general configured
capabilities), if sip_new() does not keep framing information,
then directmedia activation will fail for any framing different
from default framing.
ASTERISK-28637
Change-Id: I99257502788653c2816fc991cac7946453082466
If the name of a peer is known and a SIP request is sent using that
peer's name, the address of the peer will change even if the request
fails the authentication challenge. This means that an endpoint can
be altered and even rendered unusuable, even if it was in a working
state previously. This can only occur when the nat option is set to the
default, or auto_force_rport.
This change checks the result of authentication first to ensure it is
successful before setting the address and the nat option.
ASTERISK-28589 #close
Change-Id: I581c5ed1da60ca89f590bd70872de2b660de02df
Upon a short PRI disconnection, libpri may maintain Q.921 layer 'up' and
may thus not send PRI_EVENT_DCHAN_DOWN / PRI_EVENT_DCHAN_UP events.
If pri_event_alarm() clears DCHAN_UP status bit upon alarm detection
and no Q.921 reconnection sequence occurs, chan_dahdi will keep
seeing span status "Down" at the end of alarm.
This patch modifies pri_event_alarm() in order to keep DCHAN_UP bit
unchanged. libpri will send a PRI_EVENT_DCHAN_DOWN event if it detects
a disconnection of Q.921 layer and this will clear DCHAN_UP if required.
ASTERISK-28615
Change-Id: Ibe27df4971fd4c82cc6850020bce4a8b2692c996
This patch fixes several issues reported by the lgtm code analysis tool:
https://lgtm.com/projects/g/asterisk/asterisk
Not all reported issues were addressed in this patch. This patch mostly fixes
confirmed reported errors, potential problematic code points, and a few other
"low hanging" warnings or recommendations found in core supported modules.
These include, but are not limited to the following:
* innapropriate stack allocation in loops
* buffer overflows
* variable declaration "hiding" another variable declaration
* comparisons results that are always the same
* ambiguously signed bit-field members
* missing header guards
Change-Id: Id4a881686605d26c94ab5409bc70fcc21efacc25
