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
Previously we reached across the channel bridge to get the other party's SIP dialog
structure in order to trigger an outgoing reinvite. This is extremely dangerous to do
and only works if bridged to another SIP channel. This patch changes this to use the
T38 control frame method of requesting a switchover. This change also causes the SIP
channel driver to propogate back whether the switchover worked or not instead of blindly
accepting the incoming T38 reinvite.
Review: http://reviewboard.digium.com/r/200/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183108 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The code responsible for sending the T38 reinvite did not check if an INVITE was
already being handled. This caused things to get confused and the call to fail.
The code now defers sending the T38 reinvite until the current INVITE is done being
handled.
(issue AST-191)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@182022 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r181768 | mmichelson | 2009-03-12 13:29:48 -0500 (Thu, 12 Mar 2009) | 22 lines
Properly send a 487 on an INVITE we have not responded to if we receive a BYE.
If we receive an INVITE from an endpoint and then later receive a BYE from that
same endpoint before we have sent a final response for the INVITE, then we need
to respond to the INVITE with a 487.
There was logic in the code prior to this commit which seemed to exist solely to
handle this situation, but there was one condition in an if statement which
was incorrect. The only way we would send a 487 was if the sip_pvt had no owner
channel. This made no sense since we created the owner channel when we received
the INVITE, meaning that the majority of the time we would never send the 487.
The 487 being sent should not rely on whether we have created a channel. Its
delivery should be dependent on the current state of the initial INVITE transaction.
With this commit, that logic is now correctly in place.
(closes issue #14149)
Reported by: legranjl
Patches:
14149.patch uploaded by mmichelson (license 60)
Tested by: legranjl
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@181769 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r181328 | file | 2009-03-11 14:22:52 -0300 (Wed, 11 Mar 2009) | 14 lines
Fix issue where an attended transfer could not be completed under a rare scenario.
When completing an attended transfer chan_sip does a check to make sure the extension
in the URI portion of the Refer-To header is a local valid extension. We don't actually
need to check this since we know for sure the other channel is already up and talking to
the extension. Some devices do not put the extension in the Refer-To header either, which
can cause the extension check to fail. We now no longer do this check if it is an attended
transfer.
(closes issue #14628)
Reported by: sverre
Patches:
14628.diff uploaded by file (license 11)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@181345 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r181295 | file | 2009-03-11 13:36:50 -0300 (Wed, 11 Mar 2009) | 9 lines
Fix a problem with inband DTMF detection on outgoing SIP calls when dtmfmode=auto.
When dtmfmode was set to auto the inband DTMF detector was not setup
on outgoing SIP calls. This caused inband DTMF detection to fail.
The inband DTMF detector is now setup for both dtmfmode inband and auto.
(closes issue #13713)
Reported by: makoto
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@181296 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The main problem here was that cstdlib was undefining free thereby causing the
proper debug macros to not be used. ast_h323.cxx has been changed to call
ast_free instead to avoid the issue.
A few other issues were addressed:
- There were a few instances of functions improperly passing ast_free instead
of ast_free_ptr.
- Some clean up was done to avoid the debug macros intentionally being redefined.
(copied below from Kevin's commit, appreciate the help)
- disable astmm.h from doing anything when STANDALONE is defined, which is used
by the tools in the utils/ directory that use parts of Asterisk header files in
hackish ways; also ensure that utils/extconf.c and utils/conf2ael.c are
compiled with STANDALONE defined.
(closes issue #13593)
Reported by: pj
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@181135 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously, chan_sip had both sip_peer and sip_user objects in memory. A
patch went in to remove sip_user to simplify the code, since everything
could be done with just sip_peer. This patch resolves some regressions
found that were introduced by those changes.
This code comes from svn/asterisk/team/group/sip-object-matching/.
Here is a list of the changes that have been made:
1) When doing a match by name with the find_peer() function, make it much
easier to specify which objects should be matched by having a parameter
that specifies exactly which object types should be considered. Also,
update find_by_name() to handle this parameter. Finally, update all
code to use the new option values.
2) When looking up an object for an outbound request by name, consider
peers only. (create_addr())
3) Only match peers on an incoming registration request.
4) When doing authentication (except for SUBSCRIBE), look up users
by name, instead of all objects by name.
5) When doing authentication (except for SUBSCRIBE), after looking for
a user by name, look for a peer by IP address, instead of all objects
by IP address.
6) When handling the SIP qualify CLI command or manager action, look for
a peer by name, instead of any object by name.
7) When handling the SIP unregister CLI command, look for a peer by name,
instead of any object by name.
9) In sip_do_debug_peer(), search for a peer by name, instead of any object
by name.
9) When handling the SIPPEER() dialplan function, search for a peer by name,
instead of any object by name.
10) In the following session timer related functions, st_get_se(),
st_get_refresher(), and st_get_mode(), when looking for an object for a
given sip_pvt using pvt->peername, look for a peer by name, instead of any
object by name.
11) Fix build_peer() to properly handle the case where separate type=peer and
type=user entries were specified in sip.conf.
(closes issue #14505)
Reported by: lmadsen
Review: http://reviewboard.digium.com/r/172/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@180261 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the subscription context for a call pickup subscription differs
from the context of the call pickup target, there's not an easy way
to divine what context should be used for the pickup. The way to work
around this is to use PICKUPMARK as the context for the pickup.
This has been documented in the sip.conf.sample file
(ABE-1708)
closes issue #14567
submitted by: alecdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@180155 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously, only the "data" field of the sip_pkt created during __sip_reliable_xmit
was freed when XMIT_ERROR was returned by __sip_xmit. When retrans_pkt was called,
this inevitably resulted in the reading and writing of freed memory.
XMIT_ERROR is a condition meaning that we don't want to attempt resending the packet
at all. The proper action to take is to remove the scheduler entry we just created,
free the packet's data as well as the packet itself, and unlink it from the list of
packets on the sip_pvt structure.
(closes issue #14455)
Reported by: Nick_Lewis
Patches:
14455.patch uploaded by mmichelson (license 60)
Tested by: Nick_Lewis
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@179219 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r178205 | file | 2009-02-24 11:16:07 -0400 (Tue, 24 Feb 2009) | 9 lines
Skip check for extension when subscribing for MWI.
Since the remote side is not actually subscribing to a specific extension when
subscribing for MWI just skip the check to see if the extension exists. They can't use it
to specify the mailbox either since we require configuration of that in sip.conf
(closes issue #14531)
Reported by: festr
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@178213 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The previous implementation of T38 faxdetect resulted in both sides of the
call jumping to a fax extension when both sides had 't38pt_udptl=yes' and
'faxdetect=yes' in sip.conf and a 'fax' extension in the current context.
This revision will jump to a 'fax' extension on incoming calls only.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176869 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is required to create a UDPTL structure in create_addr_from_peer() to handle the
scenario where 't38pt_udptl=yes' is not defined in the [general] section of sip.conf but
is defined the peer's context. I tested this patch by enabling t38pt_udptl in the
[general] section on one system and only enabling t38pt_udptl in a peer's context on
the system sending a fax. Without the patch, the sending system will fail to initiate
T38 negotiation with the warning message, "No way to add SDP without an UDPTL structure".
When this patch is applied the sending side will successfully initiate T38 negotiation.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176705 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r176426 | tilghman | 2009-02-16 18:49:22 -0600 (Mon, 16 Feb 2009) | 10 lines
After a 'sip reload', qualifies for realtime peers weren't immediately
restarted, instead waiting until the next registration. We're now
caching the qualify across a reload/restart and starting the qualify
immediately upon loading the peer.
(closes issue #14196)
Reported by: pdf
Patches:
20090120__bug14196_1.4.diff.txt uploaded by pdf (license 663)
Tested by: pdf
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176459 65c4cc65-6c06-0410-ace0-fbb531ad65f3
