When optimistic SRTP was on it was possible for us to still
set up a call without an audio stream if an offer was received
with required SRTP.
This change makes it so this scenario will now fail with a 488
response.
ASTERISK-26575
Change-Id: I7d14187037681f48879bd20319ac79d0877318f3
The res_pjsip_sdp_rtp module did not restrict the number of
formats added to a media stream in the SDP to the defined
limit. If allow=all was used with additional loaded codecs this
could result in the next media stream being overwritten some.
This change restricts the module to limit it to the defined
maximum and also increases the maximum in our bundled pjproject.
ASTERISK-26541 #close
Change-Id: I0dc5f59d3891246cafa2f3df5ec406f088559ee8
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
When channel format changes occurred as a result of an RTP
re-negotiation the bridge was not informed this had happened.
As a result the bridge technology was not re-evaluated and the
channel may have been in a bridge technology that was incompatible
with its formats. The bridge is now unbridged and the technology
re-evaluated when this occurs.
The chan_pjsip module also allowed asymmetric codecs for sending
and receiving. This did not work with all devices and caused one
way audio problems. The default has been changed to NOT do this
but to match the sending codec to the receiving codec. For users
who want asymmetric codecs an option has been added, asymmetric_rtp_codec,
which will return chan_pjsip to the previous behavior.
The codecs returned by the chan_pjsip module when queried by
the bridge_native_rtp module were also not reflective of the
actual negotiated codecs. The nativeformats are now returned as
they reflect the actual negotiated codecs.
ASTERISK-26423 #close
Change-Id: I6ec88c6e3912f52c334f1a26983ccb8f267020dc
When an explicit media_address is provided the address family
in the SDP needs to be set to reflect it.
ASTERISK-26309
Change-Id: Ib9350cc91c120eb2f96f0623d3907d12af67eb79
This change adds support for dual stack automatically. No
configuration is required and the IP address and version
in the SIP messages and SDP will be automatically changed
based on the transport over which the message is being
sent. RTP usage has also been changed to listen on both
IPv4 and IPv6 simultaneously to allow media to flow, and
to allow ICE support on both simultaneously. This also
allows failover between IPv6 and IPv4 to work as expected.
ASTERISK-26309 #close
Change-Id: I235a421d8f9a326606d861b449fa6fe3a030572d
This patch add config to pjsip by endpoint.
;preferred_codec_only=yes
; Respond to a SIP invite with the single most preferred codec
; rather than advertising all joint codec capabilities. This
; limits the other side's codec choice to exactly what we prefer.
ASTERISK-26317 #close
Reported by: AaronAn
Tested by: AaronAn
Change-Id: Iad04dc55055403bbf5ec050997aee2dadc4f0762
Attempting to load a transport from realtime was forcing asterisk into an
infinite recursion loop. The first thing transport_apply did was to do a
sorcery retrieve by id for an existing transport of the same name. For files,
this just returns the previous object from res_sorcery_config's internal
container, if any. For realtime, the res_sourcery_realtime driver looks in the
database and finds the existing row but now it has to rehydrate it into a
sorcery object which means calling... transport_apply. And so it goes.
The main issue with loading from realtime (apart from the loop) was that
transport stores structures and pointers directly in the ast_sip_transport
structure instead of the separate ast_transport_state structure. This patch
separates those items into the ast_sip_transport_state structure. The pattern
is roughly the same as res_pjsip_outbound_registration.
Although all current usages of ast_sip_transport and ast_sip_transport_state
were modified to use the new ast_sip_get_transport_state API, the original
items are left in ast_sip_transport and kept updated to maintain ABI
compatability for third-party modules. They are marked as deprecated and
noted that they're now in ast_sip_transport_state.
ASTERISK-25606 #close
Reported-by: Martin Moučka
Change-Id: Ic7a836ea8e786e8def51fe3f8cce855ea54f5f19
On a system with multiple ip addresses in the same subnet, if a
transport is bound to a specific ip address and endpoint/media_address
is set, the SIP/SDP will have the correct address in all fields but
the rtp stream MAY still originate from one of the other ip addresses,
most probably the "primary" ip address. This happens because
res_pjsip_sdp_rtp/create_rtp always calls ast_instance_new with
the "all" ip address (0.0.0.0 or ::).
The new option causes res_pjsip_sdp_rtp/create_rtp to call
ast_rtp_instance_new with the endpoint's media_address (if specified)
instead of the "all" address. This causes the packets to originate from
the specified address.
ASTERISK-25632
ASTERISK-25637
Reported-by: Olivier Krief
Reported-by: Dan Journo
Change-Id: I3dfaa079e54ba7fb7c4fd1f5f7bd9509bbf8bd88
In SIP/SDP, Opus has two channels always (see RFC 7587 section 7). The actual
amount of channels is negotiated in-band. Therefore now, the Opus codec and its
attribute rtpmap are registered with two channels.
ASTERISK-24779 #close
Reported by: PowerPBX
Tested by: Alexander Traud
patches:
asterisk-24779.patch submitted by Sean Bright (license #5060)
Change-Id: Ic7ac13cafa1d3450b4fa4987350924b42cbb657b
The keepalive support in res_pjsip_sdp_rtp currently assumes
that a stream will only be negotiated once. This is false.
If the stream is replaced and later added back it can be
negotiated again causing multiple keepalive scheduled items
to exist. This change explicitly deletes the existing
keepalive scheduled item before adding the new one.
The res_pjsip_sdp_rtp module also does not stop RTP
keepalives or timeout timer if the stream has been
replaced. This change adds a callback to the session media
interface to allow a media stream to be stopped without
the resources being destroyed. This allows the scheduled
items and RTP to be stopped when the stream no longer
exists.
ASTERISK-25356 #close
Change-Id: Ibe6a7cc0927c87326fd5f1c0d4ad889dbfbea1de
If the ast_strndup() call fails to allocate a copy of the
transport string for parsing, fail gracefully.
ASTERISK-25323
Reported by: Scott Griepentrog
Change-Id: Ia4b905ce6d03da53fea526224455c1044b1a5a28
Modules commonly used the pj_gethostip function for retrieving the
IP address of the host. This function does not cache the result and may
result in a DNS lookup occurring, or additional work. If the DNS
server is unreachable or network issues arise this can cause the
pj_gethostip function to block for a period of time.
This change adds an ast_sip_get_host_ip and ast_sip_get_host_ip_string
function which does the same thing but caches the host IP address at
module load time. This results in no additional work being done each
time the local host IP address is needed.
ASTERISK-25342 #close
Change-Id: I3205deb679b01fa5ac05a94b623bfd620a2abe1e
When sending an RTP keepalive, we need to be sure we're not dealing with
a NULL RTP instance. There had been a NULL check, but the commit that
added the rtp_timeout and rtp_hold_timeout options removed the NULL
check.
Change-Id: I2d7dcd5022697cfc6bf3d9e19245419078e79b64
This change adds support for the 'rtp_timeout' and 'rtp_timeout_hold'
endpoint options. These allow the channel to be hung up if RTP
is not received from the remote endpoint for a specified number of
seconds.
ASTERISK-25259 #close
Change-Id: I3f39daaa7da2596b5022737b77799d16204175b9
This adds an "rtp_keepalive" option for PJSIP endpoints. Similar to the
chan_sip option, this specifies an interval, in seconds, at which we
will send RTP comfort noise frames. This can be useful for keeping RTP
sessions alive as well as keeping NAT associations alive during lulls.
ASTERISK-25242 #close
Reported by Mark Michelson
Change-Id: I3b9903d99e35fe5d0b53ecc46df82c750776bc8d
Some phones send g.726 audio packed for AAL2, which differs from what is
recommended by RFC 3351. If Asterisk receives audio formatted as such when
negotiating g.726 then it sounds a bit distorted. Added an option to
res_pjsip_endpoint that allows g.726 negotiated audio to be treated as g.726
AAL2 packed.
ASTERISK-25158 #close
Reported by: Steve Pitts
Change-Id: Ie7e21f75493d7fe53e75e12c971e72f5afa33615
Git does not support the ability to replace a token with a version
string during check-in. While it does have support for replacing a
token on clone, this is somewhat sub-optimal: the token is replaced
with the object hash, which is not particularly easy for human
consumption. What's more, in practice, the source file version was often
not terribly useful. Generally, when triaging bugs, the overall version
of Asterisk is far more useful than an individual SVN version of a file. As a
result, this patch removes Asterisk's support for showing source file
versions.
Specifically, it does the following:
* Rename ASTERISK_FILE_VERSION macro to ASTERISK_REGISTER_FILE, and
remove passing the version in with the macro. Other facilities
than 'core show file version' make use of the file names, such as
setting a debug level only on a specific file. As such, the act of
registering source files with the Asterisk core still has use. The
macro rename now reflects the new macro purpose.
* main/asterisk:
- Refactor the file_version structure to reflect that it no longer
tracks a version field.
- Remove the "core show file version" CLI command. Without the file
version, it is no longer useful.
- Remove the ast_file_version_find function. The file version is no
longer tracked.
- Rename ast_register_file_version/ast_unregister_file_version to
ast_register_file/ast_unregister_file, respectively.
* main/manager: Remove value from the Version key of the ModuleCheck
Action. The actual key itself has not been removed, as doing so would
absolutely constitute a backwards incompatible change. However, since
the file version is no longer tracked, there is no need to attempt to
include it in the Version key.
* UPGRADE: Add notes for:
- Modification to the ModuleCheck AMI Action
- Removal of the "core show file version" CLI command
Change-Id: I6cf0ff280e1668bf4957dc21f32a5ff43444a40e
With this patch, chan_pjsip/res_pjsip now sets the native formats to the
codecs negotiated by a call.
* The changes in chan_pjsip.c and res_pjsip_sdp_rtp.c set the native
formats to include all the negotiated audio codecs instead of only the
initial preferred audio codec and later the currently received audio
codec.
* The audio frame handling in channel.c:ast_read() is more streamlined and
will automatically adjust to changes in received frame formats. The new
policy is to remove translation and pass the new frame format to the
receiver except if the translation was to a signed linear format. A more
long winded version is commented in ast_read() along with some caveats.
* The audio frame handling in channel.c:ast_write() is more streamlined
and will automatically adjust any needed translation to changes in the
frame formats sent. Frame formats sent can change for many reasons such
as a recording is being played back or the bridged peer changed the format
it sends. Since it is a normal expectation that sent formats can change,
the codec mismatch warning message is demoted to a debug message.
* Removed the short circuit check in
channel.c:ast_channel_make_compatible_helper(). Two party bridges need to
make channels compatible with each other. However, transfers and moving
channels among bridges can result in otherwise compatible channels having
sub-optimal translation paths if the make compatible check is short
circuited. A result of forcing the reevaluation of channel compatibility
is that the asterisk.conf:transcode_via_slin and codecs.conf:genericplc
options take effect consistently now. It is unfortunate that these two
options are enabled by default and negate some of the benefits to the
changes in channel.c:ast_read() by forcing translation through signed
linear on a two party bridge.
* Improved the softmix bridge technology to better control the translation
of frames to the bridge. All of the incoming translation is now normally
handled by ast_read() instead of splitting any translation steps between
ast_read() and the slin factory. If any frame comes in with an unexpected
format then the translation path in ast_read() is updated for the next
frame and the slin factory handles the current frame translation.
This is the final patch in a series of patches aimed at improving
translation path choices. The other patches are on the following reviews:
https://reviewboard.asterisk.org/r/4600/https://reviewboard.asterisk.org/r/4605/
ASTERISK-24841 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4609/
........
Merged revisions 434671 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds support for automatically detecting the type of DTMF that a
PJSIP endpoint supports. When the 'dtmf_mode' endpoint option is set to 'auto',
the channel created for an endpoint will attempt to determine if RFC 4733
DTMF is supported. If so, it will use that DTMF type. If not, the DTMF type
for the channel will be set to inband.
Review: https://reviewboard.asterisk.org/r/4438
ASTERISK-24706 #close
Reported by: yaron nahum
patches:
yaron_patch_3_Feb.diff submitted by yaron nahum (License 6676)
........
Merged revisions 434637 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434638 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Valgrind found a memory leak and invalid access.
* Fix invalid access by sscanf() being fed a non-nul terminated string of
digits in res/res_pjsip_sdp_rtp.c:get_codecs().
* Fix memory leak in main/sorcery.c:sorcery_object_field_destructor().
* Fix potential NULL pointer dereference in
main/xmldoc.c:xmldoc_get_syntax_config_option().
Review: https://reviewboard.asterisk.org/r/4513/
........
Merged revisions 433199 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433200 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Valgrind found some memory leaks associated with ast_sockaddr_resolve().
Most of the leaks had already been fixed by earlier memory leak hunt
patches. This patch performs an audit of ast_sockaddr_resolve() and found
one more.
* Fix ast_sockaddr_resolve() memory leak in
apps/app_externalivr.c:app_exec().
* Made main/netsock2.c:ast_sockaddr_resolve() always set the addrs
parameter for safety so the pointer will never be uninitialized on return.
The same goes for res/res_pjsip_acl.c:extract_contact_addr().
* Made functions that call ast_sockaddr_resolve() with RAII_VAR()
controlling the addrs variable use ast_free instead of ast_free_ptr to
provide better MALLOC_DEBUG information.
Review: https://reviewboard.asterisk.org/r/4509/
........
Merged revisions 433056 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 433057 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433058 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Unfortunately, while initial testing with ConfBridge did not reproduce the
audio problem alluded to in the comment in res_pjsip_sdp_rtp, further testing
did show that bridge_softmix and/or ConfBridge has a severe problem bridging
two or more participants at different sampling rates. Sometimes, it even picks
odd sampling rates that cause hideous audio problems.
This patch backs out the offending portion of the code until the issues in
the affected bridging modules can be more properly analyzed.
ASTERISK-24841
........
Merged revisions 432423 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432425 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses the following problems:
* ari/resource_channels: In ARI, we currently create a format capability
structure of SLIN and apply it to the new channel being created. This was
originally done when the PBX core was used to create the channel, as there
was a condition where a newly created channel could be created without any
formats. Unfortunately, now that the Dial API is being used, this has two
drawbacks:
(a) SLIN, while it will ensure audio will flows, can cause a lot of
needless transcodings to occur, particularly when a Local channel is
created to the dialplan. When no format capabilities are available, the
Dial API handles this better by handing all audio formats to the requsted
channels. As such, we defer to that API to provide the format
capabilities.
(b) If a channel (requester) is causing this channel to be created, we
currently don't use its format capabilities as we are passing in our own.
However, the Dial API will use the requester channel's formats if none
are passed into it, and the requester channel exists and has format
capabilities. This is the "best" scenario, as it is the most likely to
create a media path that minimizes transcoding.
Fixing this simply entails removing the providing of the format capabilities
structure to the Dial API.
* chan_pjsip: Rather than blindly picking the first format in the format
capability structure - which actually *can* be a video or text format - we
select an audio format, and only pick the first format if that fails. That
minimizes the weird scenario where we attempt to transcode between video/audio.
* res_pjsip_sdp_rtp: Applied the joint capapbilites to the format structure.
Since ast_request already limits us down to one format capability once the
format capabilities are passed along, there's no reason to squelch it here.
* channel: Fixed a comment. The reason we have to minimize our requested
format capabilities down to a single format is due to Asterisk's inability
to convey the format to be used back "up" a channel chain. Consider the
following:
PJSIP/A => L;1 <=> L;2 => PJSIP/B
g,u,a g,u,a g,u,a u
That is, we have PJSIP/A dialing a Local channel, where the Local;2 dials
PJSIP/B. PJSIP/A has native format capabilities g722,ulaw,alaw; the Local
channel has inherited those format capabilities down the line; PJSIP/B
supports only ulaw. According to these format capabilities, ulaw is
acceptable and should be selected across all the channels, and no
transcoding should occur. However, there is no way to convey this: when L;2
and PJSIP/B are put into a bridge, we will select ulaw, but that is not
conveyed to PJSIP/A and L;1. Thus, we end up with:
PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
g g X u u
Which causes g722 to be written to PJSIP/B.
Even if we can convey the 'ulaw' choice back up the chain (which through
some severe hacking in Local channels was accomplished), such that the chain
looks like:
PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
u u u u
We have no way to tell PJSIP/A's *channel driver* to Answer in the SDP back
with only 'ulaw'. This results in all the channel structures being set up
correctly, but PJSIP/A *still* sending g722 and causing the chain to fall
apart.
There's a lot of difficulty just in setting this up, as there are numerous
race conditions in the act of bridging, and no clean mechanism to pass the
selected format backwards down an established channel chain. As such, the
best that can be done at this point in time is clarifying the comment.
Review: https://reviewboard.asterisk.org/r/4434/
ASTERISK-24812 #close
Reported by: Matt Jordan
........
Merged revisions 432195 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432196 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Analyzing a one-off crash on a busy system showed that processing a REFER
request had a NULL session channel pointer. The only way I can think of
that could cause this is if an outgoing BYE transaction overlapped the
incoming REFER transaction in a collision. Asterisk sends a BYE while the
phone sends a REFER to complete an attended transfer.
* Made check the session channel pointer before processing an incoming
REFER request in res_pjsip_refer.
* Fixed similar crash potential for res_pjsip supplement incoming request
processing for res_pjsip_sdp_rtp INFO, res_pjsip_caller_id INVITE/UPDATE,
res_pjsip_messaging MESSAGE, and res_pjsip_send_to_voicemail REFER
messages.
* Made res_pjsip_messaging respond to a message body too large with a 413
instead of ignoring it.
ASTERISK-24700 #close
Reported by: Zane Conkle
Review: https://reviewboard.asterisk.org/r/4417/
........
Merged revisions 431898 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431899 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When an SDP is created for an outgoing request/response, the ICE candidates
obtained from the RTP instance are currently leaked. This causes the ao2
container that holds the candidates to never properly be reclaimed when the
RTP instance is destroyed.
This patch properly decrements the ICE candidates' container if it is
successfully obtained.
ASTERISK-24769 #close
Reported by: Matt Jordan
........
Merged revisions 431600 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431601 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change fixes two issues:
1. During a swap operation bridging added the new channel before having the swap channel
leave. This was not handled in bridge_native_rtp and could result in a channel not getting
reinvited back to Asterisk. After this change the swap channel will leave first and the
new channel will then join.
2. If a re-invite was received after a session had been established any upstream elements
(such as bridge_native_rtp) were not notified that they may want to re-evaluate things.
After this change an UPDATE_RTP_PEER control frame is queued when this situation occurs
and upstream can react.
AST-1524 #close
Review: https://reviewboard.asterisk.org/r/4378/
........
Merged revisions 431157 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A native rtp bridge was being chosen (it shouldn't have been) when using two
pjsip channels with incompatible DTMF modes. This patch sets the rtp instance
property, AST_RTP_PROPERTY_DTMF, for the appropriate DTMF mode(s) for pjsip.
It was not being set before, meaning all DTMF modes for pjsip were being treated
as compatible, thus native bridging would be chosen as the bridge type when it
shouldn't have been.
ASTERISK-24459 #close
Reported by: Yaniv Simhi
Review: https://reviewboard.asterisk.org/r/4265/
........
Merged revisions 429763 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429764 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
This patch for r425924 introduced a bug, wherein sending an INVITE request
with no SDP would cause Asterisk to not send an SDP Offer in the 200
OK. The current structure of res_pjsip_sdp_rtp is a bit hard to deal with
to fix this, as create_outgoing_sdp has no knowledge of whether or not it is
creating an SDP as a new Offer or an Answer. This is something of an oversight
in the callback definition, as the caller of it does have this information.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425945 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The usage of the local override_prefs variable in create_outgoing_sdp_stream
was previously to track an override format preference set by PJSIP_MEDIA_OFFER.
Now, however, that function simply sets the joint capabilities structure,
session->req_caps. During the media format rework, the override_prefs was
instead used to check if there were any formats in session->req_caps.
However, this usage isn't useful in create_outgoing_sdp_stream.
session->req_caps contains the negotiated formats for *all* streams, not just
the current one being created. Thus, so long as any stream of any type has
provided a format, override_prefs will be non-zero. Hence, its usage in
checking whether or not we should look at the formats on the endpoint or
the joint capabilities is generally useless.
There's only two things useful to check:
(1) Does the endpoint have a format for the media type?
(2) Did we negotiate a format for the media type?
If either of those is a 'no', then we must kill the media stream.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425924 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When an inbound SDP offer is received, Asterisk currently makes a few
incorrection assumptions:
(1) If the offer contains more than a single audio/video stream, Asterisk will
reject the entire stream with a 488. This is an overly strict response;
generally, Asterisk should accept the media streams that it can accept and
decline the others.
(2) If the offer contains a declined media stream, Asterisk will attempt to
process it anyway. This can result in attempting to match format
capabilities on a declined media stream, leading to a 488. Asterisk should
simply ignore declined media streams.
(3) Asterisk will currently attempt to handle offers with AVPF with
use_avpf=No/AVP with use_avpf=Yes. This mismatch results in invalid SDP
answers being sent in response. If there is a mismatch between the media
type being offered and the configuration, Asterisk must reject the offer
with a 488.
This patch does the following:
* Asterisk will accept SDP offers with at least one media stream that it can
use. Some WARNING messages have been dropped to NOTICEs as a result.
* Asterisk will not accept an offer with a media type that doesn't match its
configuration.
* Asterisk will ignore declined media streams properly.
#SIPit31
Review: https://reviewboard.asterisk.org/r/4063/
ASTERISK-24122 #close
Reported by: James Van Vleet
ASTERISK-24381 #close
Reported by: Matt Jordan
........
Merged revisions 425868 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 425879 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425881 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Outgoing PJSIP calls can result in non-negotiated formats listed in the
channel's native formats if video formats are listed in the endpoint's
configuration. The resulting call could then use a non-negotiated format
resulting in one way audio.
* Simplified the update of session->req_caps in set_caps(). Why do
something in five steps when only one is needed?
AFS-162 #close
Review: https://reviewboard.asterisk.org/r/4000/
........
Merged revisions 423561 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Joshua Colp
zuul
Corey Farrell
Aaron An
Alexander Traud
Alexei Gradinari
George Joseph
Matt Jordan
Scott Griepentrog
Richard Mudgett
Mark Michelson
Kevin Harwell
Rodrigo Ramírez Norambuena
Kinsey Moore