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: https://origsvn.digium.com/svn/asterisk/trunk@195798 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@195589 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@194496 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@193954 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@193387 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@192933 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@192634 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The local struct ast_party_connected_line connected_caller variable
was uninitialized when the copy function was called.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@192590 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@192387 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_tls_read_conf() is a new api call for handling SSL/TLS options across all conf files. Before this change, SSL/TLS options were not consistent. http.conf and manager.conf required the 'ssl' prefix while sip.conf used options with the 'tls' prefix. While the options had different names in different conf files, they all did the exact same thing. Now, instead of mixing 'ssl' or 'tls' prefixes to do the same thing depending on what conf file you're in, all SSL/TLS options use the 'tls' prefix. For example. 'sslenable' in http.conf and manager.conf is now 'tlsenable' which matches what already existed in sip.conf. Since this has the potential to break backwards compatibility, previous options containing the 'ssl' prefix still work, but they are no longer documented in the sample.conf files. The change is noted in the CHANGES file though.
Review: http://reviewboard.digium.com/r/237/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@191028 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adds option to specify a private key .pem file when configuring TLS or SSL in AMI, HTTP, and SIP. Before this, the certificate file was used for both the public and private key. It is possible for this file to hold both, but most configurations allow for a separate private key file to be specified. Clarified in .conf files how these options are to be used. The current conf files do not explain how the private key is handled at all, so without knowledge of Asterisk's TLS implementation, it would be hard to know for sure what was going on or how to set it up.
Review: http://reviewboard.digium.com/r/234/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190545 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If transport in sip.conf is switched from UDP to TCP, Asterisk segfaults right after issuing a sip reload. The problem is the socket type is changed to TCP but the fd may still be present for UDP. Later, when the TCP session should be created or set using an existing one, it isn't because the old file descriptor is still present. Now every time transport is changed during a sip.conf reload, the file descriptor is set to -1, signifying it must be created or found.
(closes issue #14727)
Reported by: pj
Tested by: dvossel
Review: http://reviewboard.digium.com/r/229/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@189771 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This issue crept up because of a reference count issue on non-UDP based dialogs.
The dialog reference count was increased when transmitting a packet reliably but never
decreased. This caused the dialog structure to hang around despite being unlinked from
the dialogs container.
(closes issue #14919)
Reported by: vrban
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@189350 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If one attempts to use the attended transfer button on a SIP phone
to transfer an unbridged call (such as a call to an IVR) but hangs
up while the target of the transfer is still ringing, we need to not
crash.
The problem was that ast_hangup was called from outside the channel
thread.
AST-211
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@189097 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r188946 | file | 2009-04-17 11:41:25 -0300 (Fri, 17 Apr 2009) | 15 lines
Fix a bug where a value used to create the channel name was bogus.
This commit fixes the scenario where an incoming call is authenticated
using a peer entry. Previously the channel name was created using either
the username setting from the sip.conf entry or the IP address that the
call came from. Now the channel name will be created using the peer name
itself. This commit will not change the way the channel name is generated
for users or friends.
(closes issue #14256)
Reported by: Nick_Lewis
Patches:
chan_sip.c-chname.patch uploaded by Nick (license 657)
Tested by: Nick_Lewis, file
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@188947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
What I've done here is simply break up how a state NOTIFY is built. Originally both the XML and sip header information were built within the same function. While this does work, it does not allow for the creation of multipart/related message bodies that can contain multiple XML entries with only one sip header. Now a separate function builds the XML for each notify. This patch also makes maintaining and modifying state notifications in the future much less of a pain.
Review: http://reviewboard.digium.com/r/224/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@188742 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Per discussion with oej on IRC we need the actual IP address, not the
outbound proxy IP address, in the sa field. This change matches the already
existing code for all other uses of the outbound proxy setting.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@188247 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Copy the outbound proxy IP address into the SIP dialog structure as the IP address we will
be sending to. This has to be done because the logic that determines what local IP address to use
in the SIP messages is not aware of an outbound proxy being in place. It only knows what IP address
we are sending to.
(closes issue #12006)
Reported by: mnicholson
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@188067 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This allows for you to change the From header for outgoing MWI
NOTIFY requests. Prior to this, the best you could do was to
set a callerid in the general section of sip.conf. The problem
was that this was used for all outbound requests, not just
MWI NOTIFY requests.
AST-201
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187560 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r187484 | mmichelson | 2009-04-09 13:51:20 -0500 (Thu, 09 Apr 2009) | 18 lines
Handle a SIP race condition (reinvite before an ACK) properly.
RFC 5047 explains the proper course of action to take if a
reINVITE is received before the ACK from a previous invite
transaction. What we are to do is to treat the reINVITE as
if it were both an ACK and a reINVITE and process it normally.
Later, when we receive the ACK we had been expecting, we will
ignore it since its CSeq is less than the current iseqno of
the sip_pvt representing this dialog.
(closes issue #13849)
Reported by: klaus3000
Patches:
13849_v2.patch uploaded by mmichelson (license 60)
Tested by: mmichelson, klaus3000
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187488 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This was accomplished using a set of options and the setoption channel callback.
The core calls into the channel driver using these options and the channel driver
either returns success or failure.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187360 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While browsing chan_sip the other day, I noticed this dangerous code in
dialog_needdestroy(). This function is an ao2_callback. It is absolutely
_not_ okay to unlock the container from within this function. It's also not
clear why it was useful. Given that it could cause memory corruption, I have
removed it.
There was also a TODO comment left describing a potential implementation of
an improvement to the needdestroy handling. I'm not convinced that what was
described is the best choice here, so I have briefly described the way that
this function is used today that could be improved.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@186928 65c4cc65-6c06-0410-ace0-fbb531ad65f3
a dialplan variable.
This adds a dialplan variable (SIP_CODEC_OUTBOUND) which controls
the codec offered for an outgoing SIP call. This is much like the
SIP_CODEC dialplan variable and has the same restrictions. The codec
set must be one that is configured for the call.
(closes issue #13243)
Reported by: samdell3
Patches:
13243.diff uploaded by file (license 11)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@186624 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The channel drivers which have been most heavily tested with these enhancements are
chan_sip and chan_misdn. Further work is being done to add Q.SIG support and will be
introduced in a later commit. chan_skinny has code added to it here, but according
to user pj, the support on chan_skinny is not working as of now. This will be fixed in
a later commit.
A special thanks goes out to bugtracker user gareth for getting the ball rolling and
providing the initial support for this work. Without his initial work on this, this would
not have been nearly as painless as it was.
This functionality has been tested by Digium's product quality department, as well as a
customer site running thousands of calls every day. In addition, many many many many bugtracker
users have tested this, too.
(closes issue #8824)
Reported by: gareth
Review: http://reviewboard.digium.com/r/201
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@186525 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This API call now waits for a special frame from the underlying channel driver to
indicate success or failure. This allows the return value to truly convey whether
the transfer worked or not. In the case of the Transfer() dialplan application this
means the value of the TRANSFERSTATUS dialplan variable is actually true.
(closes issue #12713)
Reported by: davidw
Tested by: file
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@186382 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
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r185845 | dvossel | 2009-04-01 14:02:00 -0500 (Wed, 01 Apr 2009) | 10 lines
Fixes issue with dropped calles due to re-Invite glare and re-Invites never executing after a 491
Acknowledgement for 491 responses were never being processed because it didn't match our pending invite's seqno. Since the ACK was never processed, the 491 frame would continue to be retransmitted until eventually the call was dropped due to max retries. Now during a pending invite, if we receive another invite, we send an 491 and hold on to that glare invite's seqno in the "glareinvite" variable for that sip_pvt struct. When ACK's are received, we first check to see if it is in response to our pending invite, if not we check to see if it is in response to a glare invite. In this case, it is in response to the glare invite and must be dealt with or the call is dropped. I've changed the wait time for resending the re-Invite after receving a 491 response to comply with RFC 3261. Before this patch the scheduled re-Invite would only change a flag indicating that the re-Invite should be sent out, now it actually sends it out as well.
(closes issue #12013)
Reported by: alx
Review: http://reviewboard.digium.com/r/213/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@185846 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r184947 | file | 2009-03-30 11:35:47 -0300 (Mon, 30 Mar 2009) | 14 lines
Improve our handling of T38 in the initial INVITE from a device.
We now answer with matching media streams to what is requested. If an INVITE
is received with both a T38 and RTP media stream this means we answer with both.
For any outgoing calls created as a result of this inbound one no T38 is requested
in the initial INVITE. Instead if we start receiving udptl packets we trigger a
reinvite on the outbound side.
(closes issue #12437)
Reported by: marsosa
Tested by: pinga-fogo, okrief, file, afu
Review: http://reviewboard.digium.com/r/208/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@184948 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r184565 | file | 2009-03-27 10:06:45 -0300 (Fri, 27 Mar 2009) | 9 lines
Fix an issue where nat=yes would not always take effect for the RTP session on outgoing calls.
If calls were placed using an IP address or hostname the global nat setting was copied over
but was not set on the RTP session itself. This caused the RTP stack to not perform symmetric RTP
actions.
(closes issue #14546)
Reported by: acunningham
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@184566 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This code comes from svn/asterisk/team/russell/event_performance/.
Here is a summary of the changes that have been made, in order of both
invasiveness and performance impact, from smallest to largest.
1) Asterisk 1.6.1 introduces some additional logic to be able to handle
distributed device state. This functionality comes at a cost.
One relatively minor change in this patch is that the extra processing
required for distributed device state is now completely bypassed if
it's not needed.
2) One of the things that I noticed when profiling this code was that a
_lot_ of time was spent doing string comparisons. I changed the way
strings are represented in an event to include a hash value at the front.
So, before doing a string comparison, we do an integer comparison on the
hash.
3) Finally, the code that handles the event cache has been re-written.
I tried to do this in a such a way that it had minimal impact on the API.
I did have to change one API call, though - ast_event_queue_and_cache().
However, the way it works now is nicer, IMO. Each type of event that
can be cached (MWI, device state) has its own hash table and rules for
hashing and comparing objects. This by far made the biggest impact on
performance.
For additional details regarding this code and how it was tested, please see the
review request.
(closes issue #14738)
Reported by: russell
Review: http://reviewboard.digium.com/r/205/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@184339 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If we receive a T38 request negotiate control frame we should only attempt to do so
if the option is enabled on the dialog.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@184280 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183115 | mmichelson | 2009-03-19 11:04:02 -0500 (Thu, 19 Mar 2009) | 14 lines
Fix an issue where cancelled outgoing SIP calls would erroneously report the device as "in use."
A user was having an issue where if an outgoing SIP call was canceled, the SIP device
would remain in use if we had not received any response to the initial INVITE we sent out.
The SIP device would remain in use until the autocongestion timer was exhausted.
I tracked down the cause of this to be the section of code I am removing here. I asked several
people what the purpose of this code was meant to be, but no one could give me any sort of
answer as to why this was here. The person who was having this issue has been using this patch
for several months and it has stopped the problems they have had.
AST-196
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183117 65c4cc65-6c06-0410-ace0-fbb531ad65f3
