| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@197824 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This makes sure that we mark a method as being unallowed if we
receive a 405 response so that we don't continue to try to
send that same type of message.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@197740 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@197701 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
1240 on load but was on reload.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@197697 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r197562 | eliel | 2009-05-28 11:21:32 -0400 (Thu, 28 May 2009) | 13 lines
Use the address we already know when reloading a peer with nat=yes.
If we already have an address for a peer, and we are reloading the sip
configuration, try to use that address to contact the peer, instead of
getting it from the Contact.
(closes issue #15194)
Reported by: ibc
Patches:
sip.patch uploaded by eliel (license 64)
Tested by: manwe
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@197621 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14833)
Reported by: contactmayankjain
Patches:
all_changes.patch uploaded by contactmayankjain (license 740)
slightly modified by me
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@197616 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r197466 | file | 2009-05-28 10:44:58 -0300 (Thu, 28 May 2009) | 8 lines
Fix a bug where the flag indicating the presence of rport would get overwritten by the nat setting.
The presence of rport is now stored as a separate flag. Once the dialog is setup and authenticated
(or it passes through unauthenticated) the proper nat flag is set.
(closes issue #13823)
Reported by: dimas
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@197467 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Previously they always set hangupcause 0, which is generally wrong. With this
change, we're setting some generic hangup causes. For 5xx errors, which indicate
some sort of problem with the remote server, we're now setting CONGESTION.
EDVX002
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@197266 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
or inaccessible configuration file.
Before this change, when chan_alsa failed to load due to a missing or
inaccessible configuration file, no message would be displayed. With this
change, when chan_alsa fails to load due to a missing or inaccessible
configuration file, a message will be displayed.
(closes issue #14760)
Reported by: Nick_Lewis
Patches:
chan_alsa.c-confload.patch uploaded by Nick (license 657)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@196988 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@196893 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
the peer.
(closes issue #15118)
Reported by: alecdavis
Patches:
chan_sip_unregister.diff2.txt uploaded by alecdavis (license 585)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@196721 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@196456 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
In sip.conf the transport option allows for the configuration of what transport types (udp, tcp, and tls) a peer will accept, but only the first type listed was used for outbound connections. This patch changes this. Now the default transport type is only used until the peer registers. When registration takes place the transport type is parsed out of the Contact header. If the Contact header's transport type is equal to one that the peer supports, the peer's default transport type for outbound connections is set to match the Contact header's type. If the Contact header's transport type is not present, then the peer's default transport type is set to match the one the peer registered with. When a peer unregisters or the registration expires, the default transport type for that peer is reset.
(closes issue #12282)
Reported by: rjain
Patches:
reg_patch_1.diff uploaded by dvossel (license 671)
Tested by: dvossel
(closes issue #14727)
Reported by: pj
Patches:
reg_patch_3.diff uploaded by dvossel (license 671)
Tested by: pj, dvossel
Review: https://reviewboard.asterisk.org/r/249/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@196416 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
invalid bindaddr was specified in gtalk.conf.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@196381 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
A new xml element was created to manage the AMI actions documentation,
using AstXML.
To register a manager action using XML documentation it is now possible
using ast_manager_register_xml().
The CLI command 'manager show command' can be used to show the parsed
documentation.
Example manager xml documentation:
<manager name="ami action name" language="en_US">
<synopsis>
AMI action synopsis.
</synopsis>
<syntax>
<xi:include xpointer="xpointer(...)" /> <-- for ActionID
<parameter name="header1" required="true">
<para>Description</para>
</parameter>
...
</syntax>
<description>
<para>AMI action description</para>
</description>
<see-also>
...
</see-also>
</manager>
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@196308 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@196268 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@196246 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
a result of the const-ify the world patch.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@196227 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@196187 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r196116 | file | 2009-05-22 10:54:17 -0300 (Fri, 22 May 2009) | 5 lines
Fix a bug where using immediate with mISDN caused a cause code of 16 to get sent back instead of 1 if the 's' extension did not exist.
(closes issue #12286)
Reported by: lmamane
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@196117 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This patch adds 'const' tags to a number of Asterisk APIs where they are appropriate (where the API already demanded that the function argument not be modified, but the compiler was not informed of that fact). The list includes:
- CLI command handlers
- CLI command handler arguments
- AGI command handlers
- AGI command handler arguments
- Dialplan application handler arguments
- Speech engine API function arguments
In addition, various file-scope and function-scope constant arrays got 'const' and/or 'static' qualifiers where they were missing.
Review: https://reviewboard.asterisk.org/r/251/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@196072 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r195991 | dvossel | 2009-05-21 14:04:56 -0500 (Thu, 21 May 2009) | 14 lines
Sign problem calculating timestamp for iax frame leads to no audio on the receiving peer.
There are rare cases in which a frame's delivery timestamp is slightly less than the iax2_pvt's offset. This causes the pvt's timestamp to be a small negative number, but since the timestamp value is unsigned it looks like a huge positive number. This patch checks for this negative case and sets the ms to zero. A similar check is already done right below this one in the 'else' statement.
(closes issue #15032)
Reported by: guillecabeza
Patches:
chan_iax2.c.patch_timestamp uploaded by guillecabeza (license 380)
Tested by: guillecabeza
(closes issue #14216)
Reported by: Andrey Sofronov
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@195995 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
When receiving a 200 OK response to an INVITE, it was possible to transmit two
connected line updates instead of a single one. Furthermore, the second did not
have the proper information present.
Now the two have been combined into a single update and the correct information
is presented.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@195798 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
SIP purists may want to look the other way...
When COLP/CONP support for SIP was committed, there was a condition under
which Asterisk may transmit a SIP UPDATE in order to communicate the change
in connected line information. The issue here is that while we could send a
SIP UPDATE message, we were not prepared to receive such an UPDATE and would
always responde with a 501 when we received an UPDATE.
The situation was a bit rough. We really want to be able to receive UPDATEs
having to do with connected line changes, but the amount of effort involved
in properly supporting RFC 3311 was staggering. This commit represents a
compromise.
First, it was decided that it is important to only send a SIP UPDATE to
an endpoint that is able to handle one. So, now we have added parsing of
the Allow header into SIP. We store the allowed methods on SIP peers so
that when we communicate with them, we already will know what we can and
cannot send to them. We will parse the peer's allowed methods when he registers
with us. If the peer is not the type to register with us, but the qualify option
is enabled, then we will use the response to the OPTIONS request we send
the peer to determine the peer's allowed methods. When the peer's registration
expires, or when qualify deems the peer to be unreachable, we clear the allowed
methods from the peer.
For an actual call, we will copy the peer's allowed methods to the sip_pvt
representing the call leg. If we are communicating with an endpoint which is
not a peer, then we will just parse the Allow header from the first message
we receive during the call and store the information in the sip_pvt.
If, during communication with a peer, we receive a 501 response, then we will
make sure to save the fact that we cannot use that method when communicating
with that peer.
Now, with all that infrastructure in place, the only actual place we use this
information currently is when attempting to send a connected line change using
an UPDATE request. If we cannot send the change immediately using an UPDATE,
we will set the SIP_NEEDREINVITE flag so that we can send a REINVITE as soon
as it is allowed.
The second part of the changes here is for Asterisk to accept UPDATE requests
that have connected line changes. Since we are not fully supporting RFC 3311,
Asterisk will NOT place the UPDATE method in Allow headers it sends. Instead,
if you are communicating with what you know to be another Asterisk box, you may
set the rpid_update parameter in sip.conf so that we will send UPDATEs to that
Asterisk box. When we send a connected line update, we set a custom header
called "X-Asterisk-rpid-update."
On the receiving end, if Asterisk receives an UPDATE that does not have the
"X-Asterisk-rpid-update" header present, then Asterisk will respond with a 501
since media-changing UPDATEs are not supported. We should never get such
UPDATEs, since as was stated earlier, Asterisk does not put UPDATE in its Allow
header. If the custom header is present in the received UPDATE, though, then we
will check the incoming request for connected line updates and queue the update
on the channel where the change occurred.
ABE-1840
ABE-1822
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@195589 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r195448 | file | 2009-05-19 11:41:45 -0300 (Tue, 19 May 2009) | 7 lines
Fix a bug where direct RTP setup would partially occur even when disabled if the calling channel was answered.
(issue #13545)
Reported by: davidw
(issue #14244)
Reported by: mbnwa
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@195449 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
parameters.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@195266 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
sent to ourself.
(closes issue #15106)
Reported by: timeshell
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@195089 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r194873 | dvossel | 2009-05-15 17:43:13 -0500 (Fri, 15 May 2009) | 17 lines
IAX2 REGAUTH loop
IAX was not sending REGREJ to terminate invalid registrations. Instead it sent another REGAUTH if the authentication challenge failed. This caused a loop of REGREQ and REGAUTH frames.
(Related to Security fix AST-2009-001)
(closes issue #14867)
Reported by: aragon
Tested by: dvossel
(closes issue #14717)
Reported by: mobeck
Patches:
regauth_loop_update_patch.diff uploaded by dvossel (license 671)
Tested by: dvossel
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@194874 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r194557 | dvossel | 2009-05-14 17:59:43 -0500 (Thu, 14 May 2009) | 10 lines
IAX2 "Ghost" Channels
There is a bug tracker issue where people are reporting "Ghost" channels in their 'iax2 show channels' output. The confusion is caused by channels being listed as "(NONE)" with format "unknown". These are not channels of coarse. They are usually just pending registration or poke requests, but it is confusing output. To help make sense of this I have added two columns to 'iax2 show channels'. One shows the first message which started the transaction, and the second shows the last message sent by either side of the call. This helps diagnose why the entry exists and why it may not go away.
(closes issue #14207)
Reported by: clive18
Review: https://reviewboard.asterisk.org/r/246/
........
r194685 | dvossel | 2009-05-15 10:40:37 -0500 (Fri, 15 May 2009) | 6 lines
Update to previous IAX2 "Ghost" Channels patch.
Fixed some comments made on reviewboard for the previous patch.
(issue #14207)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@194833 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r194484 | mmichelson | 2009-05-14 17:17:55 -0500 (Thu, 14 May 2009) | 24 lines
Fix a race condition where a reinvite could trigger a 482 response.
The loop detection/spiral detection code in chan_sip used the owner
channel's state as a criterion for determining if the incoming INVITE
is a looped request. The problem with this is that the INVITE-handling
code happens in a different thread than the thread that marks the owner
channel as being up. As a result, if a reinvite were to come in very quickly,
say from another Asterisk on the same LAN, it was possible for the reinvite
to arrive before the owner channel had been set to the up state.
This patch corrects the problem by using the invitestate of the sip_pvt
instead, since that can be guaranteed to be set correctly by the time
the reinvite arrives. Since there is a switch statement further in the
INVITE-handling code, the AST_STATE_RINGING state also checks the invitestate
of the sip_pvt in case we should actually be treating the channel as if it were
up already.
(closes issue #12215)
Reported by: jpyle
Patches:
12215_confirmed.patch uploaded by mmichelson (license 60)
Tested by: lmadsen
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@194496 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Select what to do with outgoing COLP information on this port.
0 - Send out COLP information unaltered. (default)
1 - Force COLP to restricted on all outgoing COLP information.
2 - Do not send COLP information.
outgoing_colp=0
Also fixed sending the EctInform message so it always has the
required redirectionNumber parameter when the status is active.
JIRA ABE-1853
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@194479 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
In 1.4, a SIP spiral is treated the same way as a call forward. This
works much better than what is currently in trunk and 1.6.X. The code
in trunk and 1.6.X did not create a new call to the recipient of the spiral,
instead trying to continue the same call. In addition to just being plain
wrong, this also had the side effect of only being able to spiral calls
to other SIP channels.
With this in place, as long as call forwards are honored, SIP spirals
will work properly. This means that it will work for outbound calls
made by the Queue, Dial, and Page applications. For originated calls and
spool calls, however, the spiral will not work properly until a generic
call forward mechanism is introduced into Asterisk.
(relates to issue #13630)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@193954 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@193832 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r193613 | rmudgett | 2009-05-11 14:09:00 -0500 (Mon, 11 May 2009) | 12 lines
Sent wrong message to clear a call we started if the other end has not responed yet.
In the state MISDN_CALLING (i.e. SETUP was sent but no answer has arrived yet),
it is not allowed to clear the call with RELEASE_COMPLETE. It must be
cleared with DISCONNECT. A RELEASE_COMPLETE is only allowed as an answer
to a SETUP. (See Q.931 ch. 5.3.2, 5.3.2.a, 5.3.2.b)
Patches:
chan-misdn-ccstate7.patch uploaded by customer.
JIRA ABE-1862
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@193614 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
find_peer() does not find a valid peer when using pvt->recv as the sockaddr_in argument. Because of the way TCP works, the port number in pvt->recv is not what we're looking for at all. There is currently only one place that find_peer searches for a peer using the sockaddr_in argument. If the peer is not found after using pvt->recv (works for UDP since the port number will be correct), a temp sockaddr_in struct is made using the Contact header in the sip_request. This has the correct port number in it.
Review: http://reviewboard.digium.com/r/236/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@193387 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r193262 | dvossel | 2009-05-08 09:51:09 -0500 (Fri, 08 May 2009) | 9 lines
"misdn show config" segfaults asterisk, if no MSN lists
(closes issue #14976)
Reported by: alecdavis
Patches:
misdn_config.diff.txt uploaded by alecdavis (license 585)
Tested by: alecdavis, FabienToune
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@193263 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r193050 | rmudgett | 2009-05-07 17:17:06 -0500 (Thu, 07 May 2009) | 5 lines
Give a more helpful message when an incoming call's dialed extension does not match.
Added the dialed extension and context to the chan_misdn messages warning
that the dialed number cannot be matched in the dialplan.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@193077 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14858)
Reported by: barryf
Patches:
20090507__bug14858.diff.txt uploaded by tilghman (license 14)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@192938 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r192932 | tilghman | 2009-05-07 11:29:08 -0500 (Thu, 07 May 2009) | 10 lines
Eliminate repetition of fullcontact during reconstruction.
If the fullcontact field appears in both the sippeers and the
sipregs table, then during reconstruction of the field, it will
otherwise be doubled.
(closes issue #14754)
Reported by: Alexei Gradinari
Patches:
20090506__bug14754.diff.txt uploaded by tilghman (license 14)
Tested by: lmadsen
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@192933 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This scenario crept up if chan_iax2 was loaded with no configuration file present.
It would create a timer and tell it to go at an interval but the thread that normally
acknowledges it would not be created because no configuration file was present. The timer
will now be closed if no configuration file is present.
(closes issue #15014)
Reported by: madkins
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@192808 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r192633 | file | 2009-05-06 10:30:51 -0300 (Wed, 06 May 2009) | 7 lines
Update some old logic to stop both begin and end DTMF frames from reaching the core if rfc2833 is not enabled.
(closes issue #15036)
Reported by: dimas
Patches:
v1-15036.patch uploaded by dimas (license 88)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@192634 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
The local struct ast_party_connected_line connected_caller variable
was uninitialized when the copy function was called.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@192590 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
merged into libss7/1.0 (It's still in the bug13495 branch and in libss7/trunk)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@192427 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
If an incoming call authenticated as a user or peer and t38pt_udptl was
not set to yes in general then no UDPTL session would be present and any
T38 related things would fail. This commit changes it so that if after
authenticating T38 is enabled but no UDPTL session is present one will be
created.
(issue AST-215)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@192387 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r192213 | dvossel | 2009-05-04 17:37:31 -0500 (Mon, 04 May 2009) | 11 lines
global mohinterpret setting is ignored
mohinterpret and mohsuggest global variables were not copied over during build_users and build_peers.
(closes issue #14728)
Reported by: dimas
Patches:
v1-14728.patch uploaded by dimas (license 88)
Tested by: dimas, dvossel
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@192214 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This feels like a sane change (wouldn't compile without this addition), but I'm
not intimately familiar with this code.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@191739 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r191559 | tilghman | 2009-05-01 15:00:23 -0500 (Fri, 01 May 2009) | 6 lines
SIP Response 410 maps to cause code 22 (or 23), not 1.
(closes issue #14993)
Reported by: BigJimmy
Patches:
causepatch uploaded by BigJimmy (license 371)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@191560 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15007)
Reported by: hulber
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@191494 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
DAHDI channels
Adds ability for CHANNEL() dialplan function, when used on DAHDI channels,
to temporarily change the number of buffers and/or the buffer policy, and also
to enable, disable, or switch the echo canceller between FAX/data and voice
modes.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@191411 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@191219 f38db490-d61c-443f-a65b-d21fe96a405b
|
