When using a non-default sorcery wizard (in this instance realtime) for
outbound registrations and after adding in an appropriate call to
ast_sorcery_apply_config() (since it is missing) Asterisk will crash after
a stack overflow occurs due to the code infinitely recursing. The fix entails
removing the outbound registration state dependency from the outbound
registration sorcery object and instead keeping an in memory container that
can be used to lookup the state when needed.
ASTERISK-24514
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4164/
........
Merged revisions 427814 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427815 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427823 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change corrects message ordering in cases where a channel-related
message can be received after a Stasis/ARI application has received the
StasisEnd message. The StasisEnd message was being passed to
applications directly without waiting for the channel topic to empty.
As a result of this fix, other bugs were also identified and fixed:
* StasisStart messages were also being sent directly to apps and are
now routed through the stasis message bus properly
* Masquerade monitor datastores were being removed at the incorrect
time in some cases and were causing StasisEnd messages to not be sent
* General refactoring where necessary for the above
* Unsubscription on StasisEnd timing changes to prevent additional
messages from following the StasisEnd when they shouldn't
A channel sanitization function pointer was added to reduce processing
and AO2 lookups.
Review: https://reviewboard.asterisk.org/r/4163/
ASTERISK-24501 #close
Reported by: Matt Jordan
........
Merged revisions 427788 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427789 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427790 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk - in res_rtp_asterisk - only understands a single RTCP report info
block. When the RTCP information was refactored in the RTP Engine to be pushed
over the Stasis message bus, I put in the hooks into the engine to handle
multiple RTCP report info blocks, in the hope that a future RTP implementation
would be able to provide that data. Unfortunately, res_rtp_asterisk has a
tendency to "lie":
(1) It will send RTCP reports with a reception_report_count greater than 1
(which is pulled directly from the RTCP packet itself, so that part is
correct)
(2) It will only provide a single report block
When the rtp_engine goes to convert this to a JSON blob, hilarity ensues as it
looks for a report block that doesn't exist.
This patch updates the rtp_engine to be a bit more skeptical about what it is
presented with. While this could also be fixed in res_rtp_asterisk, this patch
prefers to fix it in the engine for two reasons:
(1) The engine is designed to work with multiple RTP implementation, and hence
having it be more robust is a good thing (tm)
(2) res_rtp_asterisk's handling of RTCP information is "fun". It should report
the correct reception_report_count; ideally it should also be giving us all
of the blocks - but it is *definitely* not designed to do that. Going down
that road is a non-trivial effort.
Review: https://reviewboard.asterisk.org/r/4158/
ASTERISK-24489 #close
Reported by: Gregory Malsack
Tested by: Gregory Malsack
ASTERISK-24498 #close
Reported by: Beppo Mazzucato
Tested by: Beppo Maazucato
........
Merged revisions 427762 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427763 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427771 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r227276, a while loop was turned into a for loop. Unfortunately, a portion
of the while loop was left in the code such that, when a static gateway is
encountered in the list of MGCP gateways, the next gateway would be skipped.
At best, we would simply flip past a gateway; at worst, this could lead to a
crash.
ASTERISK-24500 #close
Reported by: Xavier Hienne
patches:
chan_mgcp.patch uploaded by Xavier Hienne (License 6657)
........
Merged revisions 427613 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 427614 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427615 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427616 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When UCS2 character encoding is used, one symbol in national language can be
expanded to 4 bytes. The current buffer used for receiving message in
do_monitor_phone is 256 bytes, which is not large enough for incoming messages.
For example:
* AT+CMGR phone response prefix
'+CMGR: "REC UNREAD","+7**********",,"14/10/29,13:31:39+12"\r\n' - 60 bytes
* SMS body with UCS2 encoding (max) - 280 bytes
* AT+CMGR phone response suffix '\r\n\r\nOK\r\n' - 8 bytes
* Terminating null character - 1 byte
This results in a needed buffer size of 349 bytes. Hence, this patch opts for a
350 byte buffer.
ASTERISK-24468 #close
Reported by: Dmitriy Bubnov
patches:
chan_mobile-1_8.diff uploaded by Dmitriy Bubnov (License 6651)
chan_mobile-trunk.diff uploaded by Dmitry Bubnov (License 6651)
........
Merged revisions 427607 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 427610 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427611 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427612 65c4cc65-6c06-0410-ace0-fbb531ad65f3
An issue existed in r420577, which added multiple recipients to voicemail
emails. The patch, when looking at the intended recipients, looked ahead for
the '|' character inside a while loop which already had pulled out the
appropriate field parsing on the '|' character. This would cause it to skip
the recipients.
This patch fixes it such that it relies completely on the while loop to parse
through the e-mail fields.
Note that the original author of the patch looked at this fix and approved it.
ASTERISK-24250 #close
Reported by: abelbeck
patches:
voicemail-420577-to-comma-fix.diff uploaded by abelbeck (License 5903)
........
Merged revisions 427585 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427586 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After r425242 the fax/sip/directmedia_reinvite_t38 test started failing due to
the surviving channel not being re-INVITEd back from T.38 to audio. This patch
fixes that bug - a deeper explanation of what happened follows.
When two RTP channels are in a native bridge, the bridging layer will
investigate each via the get_rtp_info glue callback. This callback returns the
native bridge preference of the channel *at that moment in time* (that part is
key). At different points during the bridging, the native bridging layer will
inform the RTP capable channels of the status of the bridge via the update_peer
glue callback.
In a T.38 scenario with audio direct media, the sequence of events will often
look like the following:
* SIP/A and SIP/B both have audio and enter a native bridge.
* Asterisk re-INVITEs audio between SIP/A and SIP/B directly (via an
update_peer callback).
* SIP/A sends a re-INVITE to T.38, which causes Asterisk to send a re-INVITE
to T.38 to SIP/B. Assuming everyone 200 OKs the process, the UDPTL stack
receives UDPTL packets in Asterisk from both endpoints. From the perspective
of the channels, we are now in a local bridge for T.38, even though we are
technically still in a remote bridge in bridge_native_rtp. (YAY!)
* When one side hangs up, bridge_native_rtp is told to stop bridging. It then
re-evaluates the channels and asks them how they are bridged - and since
T.38 is enabled, they reply with a Local bridge (which is correct), but is
wrong because the audio portion is still technically in a remote bridge.
* Asterisk releases the surviving channel, whose audio is *not* re-INVITED
back to Asterisk as bridge_native_rtp incorrectly assumes that it was in a
local bridge.
Ironically, prior to r425242, this used to work mostly due to a fluke in the
bridging layer.
The purpose of the get_rtp_info callback shouldn't be modified: it should tell
the bridging layer what kind of bridge the channel prefers at that moment in
time. If you have T.38 enabled, that *must* be a local bridge, as the UDPTPL
stack must be in the media path. As such, this patch does not modify that
part of the code.
However, we have to tell the channels to re-evaluate themselves when they come
out of a native bridge, since we can no longer trust the get_rtp_info callbacks
when the native bridge is being stopped. Something else may have changed in the
channels, and they may now be lying to us. As such, this patch makes it so that
we unilaterally tell the channels that they are no longer bridged via the
update_peer callback. This is actually what the channels expect anyway: code in
both chan_sip and chan_pjsip's callbacks look at the T.38 state and - if they
were in T.38 - send a re-INVITE to get the audio back to Asterisk.
Review: https://reviewboard.asterisk.org/r/4157/
........
Merged revisions 427582 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427583 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427584 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Made agent able to interrupt the alerting beep playback with DTMF. Any
digit can interrupt if the call does not need to be acknowledged. Only
the first digit of the acknowledgement can interrupt if the call needs to
be acknowledged. The agent interrupting the alerting playback builds on
the ASTERISK-24447 patch because it knows what digit interrupted the
playback and needs to be able to pass that digit to the DTMF hook digit
collection code.
ASTERISK-24257 #close
Reported by: Steve Pitts
Review: https://reviewboard.asterisk.org/r/4123/
........
Merged revisions 427508 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427512 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427519 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When handling incoming messages we determine if it is associated with
a dialog. If so we use that to determine what serializer and endpoint
to use for the message. Previously this would pass the endpoint to the
endpoint lookup module to actually place the endpoint completely on the
message. For in-dialog responses, however, this did not occur as
dialog processing took over and the endpoint lookup did not occur.
This change just places the endpoint in the expected spot immediately
instead of relying on the endpoint lookup module. In-dialog responses
thus have the expected endpoint.
AST-1459 #close
Review: https://reviewboard.asterisk.org/r/4146/
........
Merged revisions 427490 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427491 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427492 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Testing has shown repeatedly that PJSIP's default behavior of switching
automatically to TCP for large messages can cause issues. The most common
issues are that devices that we are communicating with do not handle the
switch to TCP gracefully, thus causing situations such as broken calls or
broken subscriptions. Now, in order to have this behavior happen, you must
opt into it. The sample file has been updated to warn that enabling the
TCP switch behavior may cause issues for you, so use at your own risk.
........
Merged revisions 427334 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427335 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a config file is read, an unescaped semicolon signals comments which are
stripped from the value before it's stored. Escaped semicolons are then
unescaped and become part of the value. Both of these behaviors are normal
and expected. When the config is serialized either by 'dialplan save' or
AMI/UpdateConfig however, the now unescaped semicolons are written as-is.
If you actually reload the file just saved, the unescaped semicolons are
now treated as start of comments.
Since true comments are stripped on read, any semicolons in
ast_variable.value must have been escaped originally. This patch
re-escapes semicolons in ast_variable.values before they're written to
file either by 'dialplan save' or config/ast_config_text_file_save which
is called by AMI/UpdateConfig. I also fixed a few pre-existing formatting
issues nearby in pbx_config.c
Tested-by: George Joseph
ASTERISK-20127 #close
Review: https://reviewboard.asterisk.org/r/4132/
........
Merged revisions 427275 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427276 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427277 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Virtual line support establishes a relationship between messages
related to an outbound registration and a local endpoint. This is
accomplished by attaching a parameter to the Contact of the outbound
registration and looking for it on any received requests. If the
parameter exists and can be matched to an outbound registration
the configured endpoint is associated with the request.
Review: https://reviewboard.asterisk.org/r/2964/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427165 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a packet exceeds the MTU, pjproject will switch from UDP to TCP. In
some circumstances (on some networks), this can cause some issues with
messages not getting sent to the correct destination - and can also cause
connections to get dropped due to quirks in pjproject deciding to
terminate TCP connections with no messages.
While fixing the routing/messaging issues is important, having a
configuration option in Asterisk that tells pjproject to not switch over
to TCP would be useful. That way, if some glitch is discovered on some
other network/site, we can at least disable the behavior until a fix is
put into place.
AFS-197 #close
Review: https://reviewboard.asterisk.org/r/4137/
........
Merged revisions 427129 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427130 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427137 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change adds an option, moh_passthrough, that when enabled will pass
hold and unhold requests through using a SIP re-invite. When placing on
hold a re-invite with sendonly will be sent and when taking off hold a
re-invite with sendrecv will be sent. This allows remote servers to handle
the musiconhold instead of the local Asterisk instance being responsible.
Review: https://reviewboard.asterisk.org/r/4103/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427112 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the res_stasis module is unloaded, it will dispose of the apps_registry
container. This is a problem if an ARI operation is in flight that attempts
to use the registry, as the shutdown occurs in a separate thread. This patch
adds some sanity checks to the various routines that access the registry which
cause the operations to fail if the apps_registry does not exist.
Crash caught by the Asterisk Test Suite.
........
Merged revisions 426995 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 426996 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@426997 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Currently, it is possible for some subscriptions to get into a NULL state. When
this occurs and the PJSIPShowSubscriptionsInbound ami action is issued and a
device is subscribed for extension state then the associated subscription state
object can't be located. The code then attempts to dereference a NULL object.
Added a NULL check to avoid the problem.
Reported by: John Bigelow
........
Merged revisions 426779 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 426780 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@426781 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Kevin Harwell
Kinsey Moore
Matthew Jordan
Corey Farrell
Joshua Colp
Richard Mudgett
George Joseph
Mark Michelson
Tzafrir Cohen
Scott Griepentrog
Walter Doekes
Igor Goncharovskiy