| Age | Commit message (Collapse) | Author |
|---|
|
From reviewboard:
Digium has a commercial customer who has made extensive use of the connected party and
redirecting information present in later versions of Asterisk Business Edition and which
is to be in the upcoming 1.8 release. Through their use of the feature, new problems and solutions
have come about. This patch adds several enhancements to maximize usage of the connected party
and redirecting information functionality.
First, Asterisk trunk already had connected line interception macros. These macros allow you to
manipulate connected line information before it was sent out to its target. This patch adds the
same feature except for redirecting information instead.
Second, the ast_callerid and ast_party_id structures have been enhanced to provide a "tag." This
tag can be set with func_callerid, func_connectedline, func_redirecting, and in the case of DAHDI,
mISDN, and SIP channels, can be set in a configuration file. The idea behind the callerid tag is
that it can be set to whatever value the administrator likes. Later, when running connected line
and redirecting macros, the admin can read the tag off the appropriate structure to determine what
action to take. You can think of this sort of like a channel variable, except that instead of having
the variable associated with a channel, the variable is associated with a specific identity within
Asterisk.
Third, app_dial has two new options, s and u. The s option lets a dialplan writer force a specific
caller ID tag to be placed on the outgoing channel. The u option allows the dialplan writer to force
a specific calling presentation value on the outgoing channel.
Fourth, there is a new control frame subclass called AST_CONTROL_READ_ACTION added. This was added
to correct a very specific situation. In the case of SIP semi-attended (blond) transfers, the party
being transferred would not have the opportunity to run a connected line interception macro to
possibly alter the transfer target's connected line information. The issue here was that during a
blond transfer, the SIP transfer code has no bridged channel on which to queue the connected line
update. The way this was corrected was to add this new control frame subclass. Now, we queue an
AST_CONTROL_READ_ACTION frame on the channel on which the connected line interception macro should
be run. When ast_read is called to read the frame, ast_read responds by calling a callback function
associated with the specific read action the control frame describes. In this case, the action taken
is to run the connected line interception macro on the transferee's channel.
Review: https://reviewboard.asterisk.org/r/652/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This change basically reverts the change reviewed in
https://reviewboard.asterisk.org/r/374/ and instead limits the
updating of the RTP synchronization source to only those times when we
detect that the other side of the conversation has changed the ssrc.
The problem is that SRCUPDATE control frames are sent many times where
we don't want a new ssrc, including whenever Asterisk has to send DTMF
in a normal bridge. This is also not the first time that this mistake
has been made. The initial implementation of the ast_rtp_new_source
function also changed the ssrc--and then it was removed because of
this same issue. Then, we put it back in again to fix a different
issue. This patch attempts to only change the ssrc when we see that
the other side of the conversation has changed the ssrc.
It also renames some functions to make their purpose more clear.
Review: https://reviewboard.asterisk.org/r/540/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@252089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue #16543)
Reported by: crjw
Patches:
rtp_sin_family.patch uploaded by crjw (license 963)
Tested by: crjw, qwell
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@241098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
In the process of swapping ULAW to a place in the extended codec space, we
found several unhandled cases, where a 32-bit integer was still being used to
handle a codec field. Most of these have been fixed with this commit, although
there is at least one case (codec_dahdi) which depends upon outside headers to
be altered before a conversion can be made.
(Fixes AST-278, SWP-459)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@231850 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Reviewboard: https://reviewboard.asterisk.org/r/416/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@227580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r221776 | tilghman | 2009-10-01 18:53:12 -0500 (Thu, 01 Oct 2009) | 2 lines
Fix a bunch of off-by-one errors
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@221777 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Thanks, Josh.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@221278 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r221086 | twilson | 2009-09-30 09:49:11 -0500 (Wed, 30 Sep 2009) | 25 lines
Change the SSRC by default when our media stream changes
Be default, change SSRC when doing an audio stream changes Asterisk doesn't
honor marker bit when reinvited to already-bridged RTP streams,resulting in
far-end stack discarding packets with "old" timestamps that areactually part of
a new stream. This patch sends AST_CONTROL_SRCUPDATE whenever there is a
reinvite, unless the 'constantssrc' is set to true in sip.conf.
The original issue reported to Digium support detailed the following situation:
ITSP <-> Asterisk 1.4.26.2 <-> SIP-based Application Server Call comes in
fromITSP, Asterisk dials the app server which sends a re-invite back
toAsterisk--not to negotiate to send media directly to the ITSP, but to
indicatethat it's changing the stream it's sending to Asterisk. The app
servergenerates a new SSRC, sequence numbers, timestamps, and sets the marker
bit on the new stream. Asterisk passes through the teimstamp of the new stream,
butdoes not reset the SSRC, sequence numbers, or set the marker bit.
When the timestamp on the new stream is older than the timestamp on the
originalstream, the ITSP (which doesn't know there has been any change) discards
the newframes because it thinks they are too old. This patch addresses this by
changing the SSRC on a stream update unless constantssrc=true is set in
sip.conf.
Review: https://reviewboard.asterisk.org/r/374/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@221266 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@220920 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
code.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@212390 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@212161 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Over the past couple of months, a number of issues with Asterisk
negotiating (and successfully completing) T.38 sessions with various
endpoints have been found. This patch attempts to address many of
them, primarily focused around ensuring that the endpoints'
MaxDatagram size is honored, and in addition by ensuring that T.38
session parameter negotiation is performed correctly according to the
ITU T.38 Recommendation.
The major changes here are:
1) T.38 applications in Asterisk (app_fax) only generate/receive IFP
packets, they do not ever work with UDPTL packets. As a result of
this, they cannot be allowed to generate packets that would overflow
the other endpoints' MaxDatagram size after the UDPTL stack adds any
error correction information. With this patch, the application is told
the maximum *IFP* size it can generate, based on a calculation using
the far end MaxDatagram size and the active error correction mode on
the T.38 session. The same is true for sending *our* MaxDatagram size
to the remote endpoint; it is computed from the value that the
application says it can accept (for a single IFP packet) combined with
the active error correction mode.
2) All treatment of T.38 session parameters as 'capabilities' in
chan_sip has been removed; these parameters are not at all like
audio/video stream capabilities. There are strict rules to follow for
computing an answer to a T.38 offer, and chan_sip now follows those
rules, using the desired parameters from the application (or channel)
that wants to accept the T.38 negotiation.
3) chan_sip now stores and forwards ast_control_t38_parameters
structures for tracking 'our' and 'their' T.38 session parameters;
this greatly simplifies negotiation, especially for pass-through
calls.
4) Since T.38 negotiation without specifying parameters or receiving
the final negotiated parameters is not very worthwhile, the
AST_CONTROL_T38 control frame has been removed. A note has been added
to UPGRADE.txt about this removal, since any out-of-tree applications
that use it will no longer function properly until they are upgraded
to use AST_CONTROL_T38_PARAMETERS.
Review: https://reviewboard.asterisk.org/r/310/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
application and channel.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203699 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
for specific formats to be transcoded for an RTP instance.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@201902 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This contains the interface by which we can let an rtp instance know
that it might start receiving audio from a new source. This is similar
in nature to revision 197588 of Asterisk 1.4.
Review: https://reviewboard.asterisk.org/r/276
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@201583 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
unmodified to a function that may modify it.
(closes issue #15243)
Reported by: pj
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@198762 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@197338 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r195095 | file | 2009-05-18 10:53:39 -0300 (Mon, 18 May 2009) | 5 lines
Fix a bug where the codecs of the called party leg were not properly sent back to the caller call leg when reinvited.
(closes issue #13569)
Reported by: bkw918
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@195096 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(issue #14981)
Reported by: snuffy
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190989 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The code will now only change the address and port. It will not overwrite any other values.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187773 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187772 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187108 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
as errors when they are not.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187036 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(issue #14827)
Reported by: pj
Patches:
14827.diff uploaded by file (license 11)
Tested by: pj
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@186563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This API provides a generic way for multiple RTP stacks to be
integrated into Asterisk. Right now there is only one present, res_rtp_asterisk,
which is the existing Asterisk RTP stack. Functionality wise this commit
performs the same as previously. API documentation can be viewed in the
rtp_engine.h header file.
Review: http://reviewboard.digium.com/r/209/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@186078 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
