| Age | Commit message (Collapse) | Author |
|---|
|
Added missing account to AMI event of sip show peers
ASTERISK-26176 #close
Change-Id: Ieb6c2c80a838a1b59c82103eba4c63ba238dc482
|
|
If in sip.conf (general section) set option register_retry_403=no,
the command "sip show settings" return value:
Outbound reg. retry 403:0
If in sip.conf (general section) set option register_retry_403=yes,
the command "sip show settings" return value:
Outbound reg. retry 403:-1
* In static char "sip show settings" for "Outbound.reg. retry 403"
option use AST_CLI_YESNO
ASTERISK-26476 #close
Change-Id: I3c14272f05f1067bd2aeaa8b3ef9cf8fcb12dcf9
|
|
ASTERISK_REGISTER_FILE no longer has any purpose so this commit removes
all traces of it.
Previously exported symbols removed:
* __ast_register_file
* __ast_unregister_file
* ast_complete_source_filename
This also removes the mtx_prof static variable that was declared when
MTX_PROFILE was enabled. This variable was only used in lock.c so it
is now initialized in that file only.
ASTERISK-26480 #close
Change-Id: I1074af07d71f9e159c48ef36631aa432c86f9966
|
|
|
|
Previously, the settings videosupport=always and videosupport=yes behaved
identically and unconditionally caused a video offer to be sent in the SDP on
an outgoing call. This was a regression introduced with commit
5a1d90e1fbfc4b48927aad55311f3b38efbf1f54 in Asterisk 1.6.1.
This commit restores correct behavior: videosupport=always causes a video offer
to be sent unconditionally, while videosupport=yes will only offer video on an
outbound channel if the incoming channel it is bridged to also supports video.
That way, the device receiving the outgoing call can display the correct user
interface elements for audio or video and will not unnecessarily show a blank
video window on an audio-only call.
ASTERISK-17470 #close
Change-Id: I782f4409d436114dbc97061c3570c0cd24f7c3ae
|
|
In the SIP channel driver chan_sip, auto_comedia was expected to be used in
tandem with auto_force_rport. Or stated differently: Only when auto_force_rport
was chosen (the default), auto_comedia worked. This change allows auto_comedia
to be set independently of the state of (auto_)force_rport. For example,
nat=force_rport,auto_comedia is useful for IPv4/IPv6 Dual Stack deployments
when IPv6 clients are behind a Firewall.
ASTERISK-26457 #close
Change-Id: Ib29d66c6dbb61648e371e01fc36c6978ddae5bc2
|
|
In the SIP channel driver chan_sip, the default is "auto_force_rport". When no
NAT was detected, for example in case of IPv6, Asterisk uses the IP address
from the headers within the SIP-REGISTER for subsequent SIP signaling. When
the remote party specifies support for Symmetric Response (RFC 3581) via the
parameter "rport", Asterisk should not extract the port from the SIP headers
but reuse the port of the transport. This did not happen because of a typo.
ASTERISK-26438 #close
Change-Id: If6e7891848aaf96666dee5305695f7c6667cd5a6
|
|
|
|
For the channel driver chan_sip, you specify externhost=example.com in sip.conf
when your Asterisk is behind a NAT and your IP address is assigned dynamically.
Or stated differently: You do not have a static IP address to use "externaddr"
directly. This NAT support is quite handy but just about IPv4. Previously,
Asterisk resolved "externhost" to any IP version. When the first DNS answer
resolved to an IPv6, Asterisk sent an IPv6 in SIP/SDP for origin (o=) and
connection (c=). This happened in outgoing SIP-REGISTER and while answering
SIP-INVITE. If the remote peer is IPv4-only, it might not handle o=/c= with an
IPv6. This change makes sure, no IPv6 is resolved anymore for "externhost".
ASTERISK-18232 #close
Reported by: Jacek Kowalski
Tested by: Alexander Traud
patches:
changes.patch submitted by Alessandro Crespi
Change-Id: If68eedbeff65bd1c1d8a9ed921c02ba464b32dac
|
|
Users upgrading from asterisk 13.5 to a later version and who use
realtime with peers that have mailboxes were experiencing runaway
situations that manifested as a continuous stream of taskprocessor
congestion errors, memory leaks and an unresponsive chan_sip.
A related issue was that setting rtcachefriends=no NEVER worked in
asterisk 13 (since the move to stasis). In 13.5 and earlier, when a
peer tried to register, all of the stasis threads would block and
chan_sip would again become unresponsive. After 13.5, the runaway
would happen.
There were a number of causes...
* mwi_event_cb was (indirectly) calling build_peer even though calls to
mwi_event_cb are often caused by build_peer.
* In an effort to prevent chan_sip from being unloaded while messages
were still in flight, destroy_mailboxes was calling
stasis_unsubscribe_and_join but in some cases waited forever for the
final message.
* add_peer_mailboxes wasn't properly marking the existing mailboxes
on a peer as "keep" so build_peer would always delete them all.
* add_peer_mwi_subs was unsubscribing existing mailbox subscriptions
then just creating them again.
All of this was causing a flood of subscribes and unsubscribes on
multiple threads all for the same peer and mailbox.
Fixes...
* add_peer_mailboxes now marks mailboxes correctly and build_peer only
deletes the ones that really are no longer needed by the peer.
* add_peer_mwi_subs now only adds subscriptions marked as "new" instead
of unsubscribing and resubscribing everything. It also adds the peer
object's address to the mailbox instead of its name to the subscription
userdata so mwi_event_cb doesn't have to call build_peer.
With these changes, with rtcachefriends=yes (the most common setting),
there are no leaks, locks, loops or crashes at shutdown.
rtcachefriends=no still causes leaks but at least it doesn't lock, loop
or crash. Since making rtcachefriends=no work wasnt in scope for this
issue, further work will have to be deferred to a separate patch.
Side fixes...
* The ast_lock_track structure had a member named "thread" which gdb
doesn't like since it conflicts with it's "thread" command. That
member was renamed to "thread_id".
ASTERISK-25468 #close
Change-Id: I07519ef7f092629e1e844f855abd279d6475cdd0
|
|
|
|
Change-Id I1cd33453c77c56c8e1394cd60a6f17bb61c1d957 Enable Session-Timers for
SIP over TCP (and TLS) also disables SIP retransmits in chan_sip for non-UDP
connections, allowing the TCP layer to handle the retransmits. Unfortunately,
this caused sessions to be terminated with a retransmit timeout becasue it
stopped at the point of the first retrans call.
This patch waits for the 64*T1 timer to expire instead.
ASTERISK-19968
Change-Id: I844f26801aada10bc94e9bebe6e151f0a8443204
|
|
Previously, the Contact was stored only on initial INVITE and on any
18X and 200. That meant that after re-INVITEs from *us* the Contact
could get updated, but after re-INVITEs from the *peer*, it did not.
This changeset fixes this inconsistency, properly allowing target
refreshes through re-INVITES (RFC3261, 12.2).
If your strictrtp setting allows it, this change allows you to switch
the source IP of a connected/calling device mid-call with a simple
re-INVITE from the new IP.
ASTERISK-26358 #close
Change-Id: Ibb8512054ab27c8c3d2514022568fde943bf2435
|
|
In some scenarios dialog_initialize_rtp can be called multiple times on
the same dialog. This can cause RTP instances to be leaked along with
multiple file descriptors for each instance.
This change makes it so the existing RTP instances are destroyed and
not overwritten, stopping the memory leak.
ASTERISK-26272 #close
patches:
ASTERISK-26272-13.patch submitted by Corey Farrell (license 5909)
Change-Id: Id529de1184c68f2f4d254ab41a1f458dafdb5f73
|
|
Following the Encrypt-all-the-things paradigm:
The user enters his SIP-URI and password. Thanks to DNS-NAPTR, the phone
determines SIP-over-TLS as preferred transport. In SIP/SDP, the phone starts
the call with a crypto attribute, but not as RTP/sAVP but the RTP/AVP profile
(sRTP is preferred aka optional; not mandatory). If the VoIP server does not
support sRTP and TLS, the phone shows an open padlock icon.
This paradigm is supported by several VoIP/SIP clients on default. Some
implementations even cannot be changed to RTP/sAVP. Therefore here, this
change allows Preferred sRTP for ingress. For egress, please, create a dial
plan which starts with RTP/SAVP, and when rejected tries again with RTP/AVP.
ASTERISK-20234 #close
Reported by: tootai
Tested by: tootai, Alexander Traud
patches:
srtp_patches.diff submitted by Matt Jordan
Change-Id: I42cb779df3a9c7b3dd03a629fb3a296aa4ceb0fd
|
|
Certain SNOM phones send so-called "optional crypto" in their SDP body.
Regular SRTP setup looks like this:
m=audio 64620 RTP/SAVP 8 0 9 99 3 18 4 101
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:...
SNOM-style "optional crypto" looks like this:
m=audio 61438 RTP/AVP 8 0 9 99 3 18 4 101
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:...
A crypto line is supplied, but the m-line does not have SAVP.
When res_srtp.so is *not* loaded, then chan_sip.so treats the optional
crypto as regular RTP, but when res_srtp.so *is* loaded, it refuses the
incoming call with the following message:
WARNING: process_sdp: Failed to receive SDP offer/answer with
required SRTP crypto attributes for audio
For platforms that want to start providing SRTP this presents a
compatibility problem.
This changeset lets chan_sip handle the SDP as if no crypto-line was
supplied: i.e. accept the call as regular RTP, just like it did before
res_srtp was loaded.
Now you'll get this informative warning instead:
WARNING: Ignoring crypto attribute in SDP because RTP transport is
insecure
ASTERISK-23989 #close
Reported by: Olle Johansson
Change-Id: I91a15ae05a0296e398d6b65f53bb11afde1d80e2
|
|
Historically, Asterisk has always specified annexb=no for the g729 format.
However, when using res_pjsip no format attribute was specified. This patch
makes it so the SDP now contains a format attribute line with annexb=no.
Note, that this means only g729a is negotiated. Even for pass through support.
According to rfc7261 the type of annex used (a or b) is dependent upon the
answerer. However, Asterisk being a back to back user agent makes this tricky
to support at this time, thus we only allow annex 'a' for now.
ASTERISK-26228 #close
patches:
res_format_attr_g729.c submitted by Jason Parker (license 4993)
Change-Id: I76bc20cc0a01af01536e9915afef319c269c22d0
|
|
This updates func_channel.c and main/message.c to use a generic xpointer
include instead of including info from each channel driver. Now the
name attribute of info is CHANNEL or CHANNEL_EXAMPLES to be included in
documentation for func_channel. Setting the name attribute of info to
MessageToInfo or MessageFromInfo causes it to be included in the
MessageSend application and AMI action.
Change-Id: I89fd8276a3250824241a618009714267d3a8d1ea
|
|
Packets are read regulary, when there is no data in buffer fr->frametype
is AST_FRAME_NULL. There was no check of frametype and lastrtprx always
updated and, therefore, rtptimeout did not work at all.
ASTERISK-25270 #close
Change-Id: If3b5ca0dbb822582a86eb7d01dcae4e83448c41d
|
|
|
|
Asterisk defaults to timers=accept/refresher=uas. In that scenario, only in that
scenario, Sessions-Timers (RFC 4028) had no effect via TCP. This change enables
Session-Timers for SIP over TCP (and for SIP over TLS).
However with longer international calls via TCP, the SIP channel might break,
because all hops on the Internet route must stay online (have not a single power
outage, for example). Therefore with Session-Timers enabled (which are enabled
at default), you might see dropped calls. Consequently even with this change,
you might be better-off going for session-timers=refuse in your sip.conf.
ASTERISK-19968 #close
Change-Id: I1cd33453c77c56c8e1394cd60a6f17bb61c1d957
|
|
|
|
|
|
sip_show_channels locks the dialogs container first then locks each
sip_pvt so it can spit out the details. The rest of sip dialog
processing locks the sip_pvt first then locks the dialogs container
if it needs to. Both lock in the order they need but deadlocks can
result. To fix, sip_show_channels and sip_show_channelstats have
been converted to use an iterator rather than ao2_callback. This way
the container is locked only while getting the next entry and is
unlocked when the callback is called.
ASTERISK-23013 #close
Change-Id: Id9980419909e811f89484950ed46ef117b9eb990
|
|
ASTERISK-26190 #close
Change-Id: I11326d80edd656524a51a19450e586c583aa0a0b
|
|
The sip_read() has the potential to deadlock if an incoming fax happens
during the Playback or similar application.
* Fixed the potential deadlock by not calling ast_async_goto() with the
channel lock held.
* Made always eat the fax detection frame whether there is a fax extension
or not.
ASTERISK-26216
Reported by: Richard Mudgett
Change-Id: I6d3f5cccd4b77c3aa6ffc1a54c0f6bde61c9278e
|
|
Cleanup the peer reference when stasis_subscription_final_message is
true. Also free peer_name even if peer exists, after reload a new
peer_name will be allocated.
ASTERISK-26193 #close
Change-Id: If7ecd52facdc5c227f701c760841e3f6ca53cc69
|
|
* get_sip_pvt_from_replaces leaks sip_pvt_ptr on any error.
* build_peer leaks peer on failure to allocate the endpoint.
This patch fixes get_sip_pvt by using an RAII_VAR, build_peer is fixed
with an unref in the appropriate place.
ASTERISK-26184 #close
Change-Id: I728b424648ad041409f7d90880f4c28b3ce2ca12
|
|
Some T.38 implementations may send another re-invite after the initial
one which adds additional negotiation details (such as the max bitrate).
Currently this will fail when passthrough is being done in chan_sip as we
do nothing if T.38 is already active.
Other handlers of T.38 inside of Asterisk (such as res_fax) handle this
scenario so this change adds support for it to chan_sip and res_pjsip_t38.
If a request to negotiate is received while T.38 is already enabled a
new re-INVITE is sent and negotiation is done again.
ASTERISK-26179 #close
Change-Id: I0298494d3da6df3219bbfa4be9aa04015043145c
|
|
This change removes hardcoded SDP parsing and generation for
Siren7 and Siren14 from chan_sip and moves it to format attribute
modules so it can also be used by chan_pjsip.
With this the fmtp lines for both are added with the bitrate
information.
ASTERISK-26021
Change-Id: Ibb004eda37a14c0a35ef0613f6237977fc800037
|
|
|
|
|
|
A change to glibc 2.22 changed the order of the sockadddr_storage
members which caused the places where we do an initialization of
ast_sockaddr with '{ { 0, 0, } }' to fail compilation. Those
initializers (which we shouldn't have been using anyway) have been
replaced with memsets.
Change-Id: Idd1b3b320903d8771bfe221f0b015685de628fa4
|
|
|
|
POSIX defines signal.h. sys/signal.h should not be used as it is
c-library internal header which may or may not exist. Notably with
musl it generates warning of being incorrect.
Change-Id: Ia56b0aa1d84b5c590114867b1b384a624f39a6fc
|
|
This saves around 100 bytes when G.711, G.722, G.729, and GSM are advertised in
SDP. This reduces the chance to hit the MTU bearer of 1300 bytes for SIP over
UDP, if many codecs are allowed in Asterisk. This new feature is enabled
together with the optional feature compactheaders=yes via the file sip.conf.
ASTERISK-25578 #close
Change-Id: I16491b1937862de26f84fa0ffe679a6bab925044
|
|
Currently chan_sip can give weird messages if the contacts don't
fit in the From: or To: headers. This fix changes the from,to and
invite variables to use ast_str, allocates and deallocates them and
resizes them if needed.
ASTERISK-26069 #close
Change-Id: I1b68fcbddca6f6cc7d7a92fe1cb0d5430282b2b3
|
|
ASTERISK-20527 #close
Change-Id: I659cf7f00836a09d09d146ad226a40477d731239
|
|
When chan_sip does a re-INVITE to refresh a session and authentication
is required, the INVITE with the Authorization header containes a
second Session-Expires header without the ";refersher=" parameter.
This is causing some proxies to return a 400. Also, when Asterisk is
the uas and the refresher, it is including the Session-Expires and
Min-SE headers in OPTIONS messages which is not allowed per RFC4028.
This patch (based on the reporter's) Checks to see if a Session-Expires
header is already in the message before adding another one. It also
checks that the method is INVITE or UPDATE.
ASTERISK-26030 #close
Change-Id: I58a7b07bab5a3177748d8a7034fb8ad8e11ce1d9
|
|
|
|
The unload process currently tells each TCP/TLS to terminate but
does not wait for them to do so. This introduces a race condition
where the container holding the threads may be destroyed before
the threads are able to remove themselves from it. When they
finally do the container is invalid and can't be used causing a
crash.
A previous change existed which waited a bit to wait for any
stranglers to finish. This change extends this and waits longer.
ASTERISK-25961 #close
Change-Id: Idc6262b670ca49ede32061159e323b7b63c6f3c6
|
|
Since Stasis has been introduced, an attempt to send AMI messages by an
autocreated peer caused a crash, and all events from autocreated peers were
semi-inadvertently disabled altogether in 0b83761. This change restores the
disabled functionality.
ASTERISK-25950
Change-Id: Iecc350f23db603fadb2f302064643ebe9664e974
|
|
If rtupdate=no do not verify sipregs/peers table has updatable fields.
ASTERISK-25934 #close
Change-Id: Iaa2c53037b93daccc7e7333c40d61861847b856d
|
|
This eliminates some casts that I made a note saying v10 and above
would no longer need them.
Better late than never :)
Change-Id: I346cdb3032b6478ceb40eb6fe732978b54035572
|
|
Asterisk 13.7.0 included a fix for ASTERISK-24543, not to send all those
codecs, which the caller did not request/support. That fix was not complete
because on the second Session Timer all codecs were sent again. Some VoIP/SIP
clients interpreted that complete codec-list as a change in the SIP session.
Because of that, Asterisk did not send the RTP audio via NAT anymore which
created a non-audio scenario after the second Session Timer fired.
ASTERISK-24543 #close
Change-Id: I1881827816ab7fd47eb4287a95961179b34a0b66
|
|
check_via() already skips leading blanks where the sent-by address (with the
optional port) should be placed.
Since RFC 3261 allows for blanks between the port ant the Via parameters:
> https://tools.ietf.org/html/rfc3261#section-20.42
(actually it allows a lot of blanks more ;-)). I just switched from
ast_skip_blanks() to ast_strip() on the local copy of the string.
ASTERISK-21301 #close
Change-Id: Ie5b8fe5a07067b7c0dc9bcdd1707e99b23b02b06
|
|
|
|
This patch is part of a series to resolve deadlocks in chan_sip.c.
Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event. If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen. The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event. Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.
ASTERISK-25023 #close
Change-Id: I96d429c57a48861fd8bde63dd93db4e92dc3adb6
|
|
This patch is part of a series to resolve deadlocks in chan_sip.c.
Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event. If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen. The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event. Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.
ASTERISK-25023
Change-Id: I2e40de89efc8ae6e8850771d089ca44bc604b508
|
|
This patch is part of a series to resolve deadlocks in chan_sip.c.
Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event. If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen. The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event. Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.
ASTERISK-25023
Change-Id: If595e4456cd059d7171880c7f354e844c21b5f5f
|
