If non-magic pickup (no "pickup-" in callid) is used, chan_sip locks the
channel it wants to pick up, and a bit further down, it locks the
channel list when allocating a new channel.
That causes a deadlock when another part of the code traverses over the
channel list, locking all the channels one by one.
This changeset fixes it by releasing the locks before calling sip_new
and reacquiring them afterwards. Unfortunately this involves doing the
checks we already did again (because the channel may have changed).
While trying to avoid duplicate code, I did some refactoring for
readability:
- if refer_locked == 1, we guarantee there is a locked channel
- magic_callid holds a cached version of !ast_strlen_zero(pickup.exten)
This is for branch 11 only. It appears that the changed code in 13 does
not lock the components like it does in 11 and below. Reproducing the
deadlock on 13 has thusfar failed.
ASTERISK-25213 #close
Change-Id: Ie1d15bec7d634035f48892e1ed6227411d7de2c1
If a client sends and INVITE which is 401 rejected, then subsequently
sends a new INVITE with the auth info and uses a different fromtag
from the first INVITE, Asterisk will accept the new INVITE as part of
the original dialog - match_req_to_dialog() specifically ignores the
fromtag. However it does not update the stored dialog with the new
fromtag.
This results in Asterisk being unable to match future packets that are
part of this dialog (such as the ACK to the OK or the OK to the BYE),
and the call is dropped.
This problem was originally found when using an NEC-i SV8100-GE (NEC SIP
Card).
* After a successful match of a packet to the dialog, if the packet is
not a SIP_RESPONSE, authentication is present and the fromtags are
different, the stored fromtag is updated with the one from the recent
INVITE.
ASTERISK-25154 #close
Reported by: Damian Ivereigh
Tested by: Damian Ivereigh
Change-Id: I5c16cf3b409e5ef9f2b2fe974b6bd2a45a6aa17e
When a BYE with an Also header is successfully processed, and the sender
of the BYE is bridged with another channel, chan_sip will unlock the
owner of the dialog on which the BYE was received, call ast_async_goto()
on the bridged channel, and then re-lock the owner. The reason for this
locking behavior is that ast_async_goto() can result in a masquerade,
which requires that the involved channels are unlocked.
The problem here is that this causes a locking inversion since the
dialog's lock is held when re-locking the owner channel after the async
goto. The lock order is supposed to be channel and then sip_pvt.
The fix proposed is simple. In addition to unlocking the owner channel
before the ast_async_goto() call, also unlock the sip_pvt. Then relock
both after ast_async_goto() returns, being sure to lock the channel and
then the sip_pvt.
ASTERISK-25139 #close
Reported by Gregory Massel
Change-Id: I72c4fc295ec8573bee599e8e9213c5350a3cd224
Although ast_context_find, ast_context_find_or_create and
ast_context_destroy perform locking of the contexts table,
any context pointer can become invalid at any time that the
contexts table is unlocked. This change adds locking around
all complete operations involving these functions.
Places where ast_context_find was followed by ast_context_destroy
have been replaced with calls ast_context_destroy_by_name.
ASTERISK-25094 #close
Reported by: Corey Farrell
Change-Id: I1866b6787730c9c4f3f836b6133ffe9c820734fa
When udpbindaddr is set to the IPv6 bind all address of '::', Asterisk will
attempt to handle both IPv4 and IPv6 addresses, although the information will
be stored in a struct with an AF_INET6 address type. However, the current
NAT handling code won't handle the IPv4 mapped IPv6 addresses correctly.
This patch adds an additional check for the mapped address case, allowing
the NAT code to handle clients even when the address is IPv6.
Review: https://reviewboard.asterisk.org/r/4563/
ASTERISK-18032 #close
Reported by: Christoph Timm
patches:
nat_with_ipv6.diff submitted by Valentin Vidić (License 6697)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@434288 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Clang will flag errors when a char pointer is set to '\0', as opposed to a
value that the char pointer points to. This patch fixes this warning
in a variety of locations.
Review: https://reviewboard.asterisk.org/r/4551
ASTERISK-24917
Reported by: dkdegroot
patches:
rb4551.patch submitted by dkdegroot (License 6600)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@434187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
These are fixes for compilation under gcc 5.0...
chan_sip.c: In parse_request needed to make 'lim' unsigned.
inline_api.h: Needed to add a check for '__GNUC_STDC_INLINE__' to detect C99
inline semantics (same as clang).
ccss.c: In ast_cc_set_parm, needed to fix weird comparison.
dsp.c: Needed to work around a possible compiler bug. It was throwing
an array-bounds error but neither
sgriepentrog, rmudgett nor I could figure out why.
manager.c: In action_atxfer, needed to correct an array allocation.
This patch will go to 11, 13, trunk.
Review: https://reviewboard.asterisk.org/r/4581/
Reported-by: Jeffrey Ollie
Tested-by: George Joseph
ASTERISK-24932 #close
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@434113 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes some invalid enum conversion warnings caught by clang. In
particular, several functions in chan_sip mixed usage of the st_refresher_param
enum and st_refresher enum. This patch corrects that.
ASTERISK-24917
Reported by: dkdegroot
patches:
rb4535.patch submitted by dkdegroot (License 6600)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@433746 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a realtime peer is built it can cause a locking inversion when the
just built peer is poked. If the CLI command "sip show channels" is
periodically executed then a deadlock can happen because of the locking
inversion.
* Push the peer poke off onto the scheduler thread to avoid the locking
inversion of the just built realtime peer.
AST-1540
ASTERISK-24838 #close
Reported by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/4454/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@432526 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk fails to start a PBX thread for a new channel - for example, when
the maxcalls setting in asterisk.conf is exceeded - we currently send a final
response, and then attempt to send a BYE request to the UA. Since that's all
sorts of wrong, this patch fixes that by setting sipalreadygone on the sip_pvt
such that we don't get stuck sending BYE requests to something that does not
want it.
Note that this patch is a slight modification of the one on ASTERISK-15434.
For clarity, it explicitly calls sipalreadygone with the calls to transmit a
final response.
ASTERISK-21845
ASTERISK-15434 #close
Reported by: Makoto Dei
Tested by: Matt Jordan
patches:
sip-pbxstart-failed.patch uploaded by Makoto Dei (License 5027)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@432320 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When we receive an SDP as part of an offer/answer for a peer/friend has been
configured to require encryption, and that SDP offer/answer failed to provide
acceptable crypto attributes, we currently issue a WARNING that uses the phrase
"we" and "requested". In this case, both of those terms are ambiguous - the
user will probably think "we" is Asterisk (it most likely isn't) and it may
not be a "request", so much as an SDP that was received in some fashion.
This patch makes the WARNING messages slightly less bad and a bit more
accurate as well.
ASTERISK-23214 #close
Reported by: Rusty Newton
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@432277 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the monitor thread is stopped, its pthread ID is set to a specific value
(AST_PTHREADT_STOP) so that later portions of the code can determine whether
or not it is safe to manipulate the thread. Unfortunately, __sip_reliable_xmit
failed to check for that value, checking instead only for AST_PTHREAD_STOP.
Passing the invalid yet very specific value to pthread_kill causes a crash.
This patch adds a check for AST_PTHREADT_STOP in __sip_reliable_xmit such that
it doesn't attempt to poke the thread if the thread has already been stopped.
ASTERISK-24800 #close
Reported by: JoshE
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@432198 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a SIP device that has its registration stored in RealTime unregisters,
the entry for that device is updated with blank values, i.e., "", indicating
that it is no longer registered. Unfortunately, one of those values that is
'blanked' is the device's port. If the column type for the port is not a
string datatype (the recommended type is integer), an ODBC or database error
will be thrown. MariaDB does not coerce empty strings to a valid integer value.
This patch updates the query run from chan_sip such that it replaces the port
value with a value of '0', as opposed to a blank value. This is the value that
other database backends coerce the empty string ("") to already, and the
handling of reading a RealTime registration value from a backend already
anticipates receiving a port of '0' from the backends.
ASTERISK-24772 #close
Reported by: Richard Miller
patches:
chan_sip.diff uploaded by Richard Miller (License 5685)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@431673 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Consider a scenario where Alice and Bob have an established dialog with each
other external to Asterisk. Bob decides to perform an attended transfer of
Alice to Asterisk. In this case, Alice will send an INVITE with Replaces
to Asterisk, where the Replaces specifies Bob's dialog with Asterisk. In this
particular scenario, Asterisk will complete the transfer, but - since Bob's
channel has had Alice masqueraded into it and is now a Zombie - a BYE
request will not be sent.
This patch fixes that issue by adding a new flag to chan_sip that tracks
whether or not we have an INVITE with Replaces. If we do, the flag is used
on the sip_pvt to ensure that a BYE request is sent, even if the channel has
been masqueraded away.
Review: https://reviewboard.asterisk.org/r/4362/
ASTERISK-22436 #close
Reported by: Eelco Brolman
Tested by: Jeremiah Gowdy, Kristian Høgh
patches:
asterisk-11-hangup-replaced-3.diff uploaded by Jeremiah Gowdy (License 6358)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@431620 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RFC 3261 sections 8.1.1.8 and 12.1.1 dictate specific
scenarios when we are required to use SIPS URIs in Contact
headers. Asterisk's non-compliance with this could actually
cause calls to get dropped when communicating with clients
that are strict about checking the Contact header.
Both of the SIP stacks in Asterisk suffered from this issue.
This changeset corrects the behavior in chan_sip.
ASTERISK-24646 #close
Reported by Stephan Eisvogel
Review: https://reviewboard.asterisk.org/r/4346
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@431423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When refreshing (with a small expiration) a registration that was sent to
chan_sip the nonce would be considered stale and reject the registration.
What was happening was that the initial registration's "dialog" still existed
in the dialogs container and upon refresh the dialog match algorithm would
choose that as the "dialog" instead of the newly created one. This occurred
because the algorithm did not check to see if the from tag matched if
authentication info was available after the 401. So, it ended up assuming
the original "dialog" was a match and stopped the search. The old "dialog"
of course had an old nonce, thus the stale nonce message.
This fix attempts to leave the original functionality alone except in the case
of a REGISTER. If a REGISTER is received if searches for an existing "dialog"
matching only on the callid. If the expires value is low enough it will reuse
dialog that is there, otherwise it will create a new one.
ASTERISK-24715 #close
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/4367/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@431187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
All the other configuration options are case insensitive, so this one
should be too.
ASTERISK-24355 #close
Reported by: HZMI8gkCvPpom0tM
patches:
ast.patch uploaded by HZMI8gkCvPpom0tM (License 6658)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@430993 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Given the following scenario:
* Three SIP phones (A, B, C), all communicating via a proxy with Asterisk
* A call is established between A and B. B performs a SIP attended transfer of
A to C. B sets the call on hold (A is hearing MOH) and dials the extension of
C. While phone C is ringing, B transfers the call (that is, what we typically
call a 'blond transfer').
* When the transfer completes, A hears the ringing of phone C, while B is idle.
In the SIP messaging for the above scenario, a REFER request is sent to
transfer the call. When "sendrpid=yes" is set in sip.conf, Asterisk may send an
UPDATE request to phone C to update party information. This update is sent
directly to phone C, not through the intervening proxy. This has the unfortunate
side effect of providing route information, which is then set on the sip_pvt
structure for C. If someone (e.g. B) is trying to get the call back (through a
directed pickup), Asterisk will send a CANCEL request to C. However, since we
have now updated the route set, the CANCEL request will be sent directly to C
and not through the proxy. The phone ignores this CANCEL according to RFC3261
(Section 9.1).
This patch updates reqprep such that the route is not updated if an UPDATE
request is being sent while the INVITE state is INV_PROCEEDING or
INV_EARLY_MEDIA. This ensures that a subsequent CANCEL request is still sent
to the correct location.
Review: https://reviewboard.asterisk.org/r/4279
ASTERISK-24628 #close
Reported by: Karsten Wemheuer
patches:
issue.patch uploaded by Karsten Wemheuer (License 5930)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@429982 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r413586 (1.8) various casts were added to silence gcc 4.10 warnings.
Those fixes included things like:
-out += sprintf(out, "%%%02X", (unsigned char) *ptr);
+out += sprintf(out, "%%%02X", (unsigned) *ptr);
That works for low ascii characters, but for the high range that yields
e.g. FFFFFFC3 when C3 is expected.
This changeset:
- fixes those casts to use the 'hh' unsigned char modifier instead
- consistently uses %02x instead of %2.2x (or other non-standard usage)
- adds a few 'h' modifiers in various places
- fixes a 'replcaes' typo
- dev/urandon typo (in 13+ patch)
Review: https://reviewboard.asterisk.org/r/4263/
ASTERISK-24619 #close
Reported by: Stefan27 (on IRC)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@429673 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously when SRTP was enabled on a channel it was not possible
to switch to T.38 as no crypto attributes would be present.
This change makes it so it is now possible. If a T.38 re-invite
comes in SRTP is terminated since in practice you can't encrypt
a UDPTL stream. Now... if we were doing T.38 over RTP (which
does exist) then we'd have a chance but almost nobody does that so
here we are.
ASTERISK-24449 #close
Reported by: Andreas Steinmetz
patches:
udptl-ignore-srtp-v2.patch submitted by Andreas Steinmetz (license 6523)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@429632 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Frames with a payload length of 0 were incorrectly handled in res_http_websocket.
Provided a frame with a payload had been received prior it was possible for a double
free to occur. The realloc operation would succeed (thus freeing the payload) but be
treated as an error. When the session was then torn down the payload would be
freed again causing a crash. The read function now takes this into account.
This change also fixes assumptions made by users of res_http_websocket. There is no
guarantee that a frame received from it will be NULL terminated.
ASTERISK-24472 #close
Reported by: Badalian Vyacheslav
Review: https://reviewboard.asterisk.org/r/4220/
Review: https://reviewboard.asterisk.org/r/4219/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@429270 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If transmit_refer is called when p->refer is already allocated,
it leaks the previous allocation. Updated code to always free
previous allocation during a new allocation. Also instead of
checking if we have a previous allocation, always create a
clean record.
ASTERISK-15242 #close
Reported by: David Woolley
Review: https://reviewboard.asterisk.org/r/4160/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@428117 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The outboundproxy setting is currently ignored when sending OPTIONS requests
as a result of the qualify setting. This means that if an Asterisk server is
unable to send the packet directly to a peer, it is unable to qualify any
non-inbound registered peer (e.g. a peer SIP Trunk).
This patch grabs the outboundproxy information for a peer when a qualify
attempt is being constructed and, if it finds the information, uses it
when sending the OPTIONS request.
Review: https://reviewboard.asterisk.org/r/3948
ASTERISK-24063 #close
Reported by: Damian Ivereigh
patches:
outboundproxy-dai.patch uploaded by Damian Ivereigh (License 6632)
........
Merged revisions 425818 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@425819 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a device re-INVITEs at the same time as the dialog is hung up, and
if then the ACK to the re-INVITE never reaches Asterisk, chan_sip would
fail to destroy the dialog after a while. This resulted in (most
prominently) file handle leaks.
(Patch reindented by me.)
ASTERISK-20784 #close
ASTERISK-15879 #close
Reported by: Torrey Searle, Nitesh Bansal
Patches:
reinvite_ack_timeout.patch uploaded by Torrey Searle (License #5334)
patch_asterisk_20784.txt uploaded by Nitesh Bansal (License #6418)
Reviewboard: https://reviewboard.asterisk.org/r/4052/
(testcase can be found at r4051)
........
Merged revisions 425068 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@425069 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This code originally worked around an issue within res_rtp_asterisk itself.
The wrong socket was being used for the STUN check for RTCP, causing the
port to be the same as RTP. This was subsequently fixed and the RTCP port
provided for the ICE candidate is correct and does not need to be incremented.
ASTERISK-23997 #close
Reported by: Badalian Vyacheslav
Patches:
plus1.diff submitted by Badalian Vyacheslav (license 5249)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@421909 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a user does not provide a port in the fromdomain setting, chan_sip will set
the fromdomainport to STANDARD_SIP_PORT (5060). The fromdomainport value will
then get used unilaterally in certain places. This causes issues with TLS,
where the default port is expected to be 5061.
This patch modifies chan_sip such that fromdomainport is only used if it is
not the standard SIP port; otherwise, the port from the SIP pvt's recorded
self IP address is used.
Review: https://reviewboard.asterisk.org/r/3893/
ASTERISK-24178 #close
Reported by: Elazar Broad
patches:
fromdomainport_fix.diff uploaded by Elazar Broad (License 5835)
........
Merged revisions 421717 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@421718 65c4cc65-6c06-0410-ace0-fbb531ad65f3
sip_subscribe_mwi_destroy calls sip_destroy on the reference counted
mwi->call. This results in the fields of mwi->call being freed, but
mwi->call itself it leaked. If other code is still using mwi->call
it can cause problems. This change uses dialog_unref instead, to
balance the ref provided by sip_alloc().
ASTERISK-24087 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/3834/
........
Merged revisions 419440 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@419441 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change fixes up DTLS support in res_rtp_asterisk so it can accept and provide
a SHA-256 fingerprint, so it occurs on RTCP, and so it occurs after ICE negotiation
completes. Configuration options to chan_sip have also been added to allow behavior
to be tweaked (such as forcing the AVP type media transports in SDP).
ASTERISK-22961 #close
Reported by: Jay Jideliov
Review: https://reviewboard.asterisk.org/r/3679/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@417677 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is essentially a backport of a small portion of r397526 from
ASTERISK-21981. In that patch, pass through support and format attribute
negotiation was added for Opus. Part of that included being more tolerant to
whitespace in the fmtp line of an SDP; that part of the patch is being
applied here.
As the author of the backport pointed out, in SDP, the fmtp line is allowed to
include whitespace between attributes. RFC 3267 chapter 8.3 (from 2001)
includes an example for this. This was not removed in the updated RFC 4867 in
2007.
Review: https://reviewboard.asterisk.org/r/3658
ASTERISK-23916 #close
Reported by: Alexander Traud
patches:
sdpFMTPspace_Asterisk11.patch uploaded by Alexander Traud (License 6520)
........
Merged revisions 417587 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@417588 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a client takes a long time to process information received from Asterisk,
a write operation using fwrite may fail to write all information. This causes
the underlying file stream to be in an unknown state, such that the socket
must be disconnected. Unfortunately, there are two problems with this in
Asterisk's existing websocket code:
1. Periodically, during the read loop, Asterisk must write to the connected
websocket to respond to pings. As such, Asterisk maintains a reference to
the session during the loop. When ast_http_websocket_write fails, it may
cause the session to decrement its ref count, but this in and of itself
does not break the read loop. The read loop's write, on the other hand,
does not break the loop if it fails. This causes the socket to get in a
'stuck' state, preventing the client from reconnecting to the server.
2. More importantly, however, is that the fwrite in ast_http_websocket_write
fails with a large volume of data when the client takes awhile to process
the information. When it does fail, it fails writing only a portion of
the bytes. With some debugging, it was shown that this was failing in a
similar fashion to ASTERISK-12767. Switching this over to ast_careful_fwrite
with a long enough timeout solved the problem.
ASTERISK-23917 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3624/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@417310 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Simply establishing a TCP connection and never sending anything to the
configured HTTP port in http.conf will tie up a HTTP connection. Since
there is a maximum number of open HTTP sessions allowed at a time you can
block legitimate connections.
A similar problem exists if a HTTP request is started but never finished.
* Added http.conf session_inactivity timer option to close HTTP
connections that aren't doing anything. Defaults to 30000 ms.
* Removed the undocumented manager.conf block-sockets option. It
interferes with TCP/TLS inactivity timeouts.
* AMI and SIP TLS connections now have better authentication timeout
protection. Though I didn't remove the bizzare TLS timeout polling code
from chan_sip.
* chan_sip can now handle SSL certificate renegotiations in the middle of
a session. It couldn't do that before because the socket was non-blocking
and the SSL calls were not restarted as documented by the OpenSSL
documentation.
* Fixed an off nominal leak of the ssl struct in
handle_tcptls_connection() if the FILE stream failed to open and the SSL
certificate negotiations failed.
The patch creates a custom FILE stream handler to give the created FILE
streams inactivity timeout and timeout after a specific moment in time
capability. This approach eliminates the need for code using the FILE
stream to be redesigned to deal with the timeouts.
This patch indirectly fixes most of ASTERISK-18345 by fixing the usage of
the SSL_read/SSL_write operations.
ASTERISK-23673 #close
Reported by: Richard Mudgett
........
Merged revisions 415841 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@415854 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk started counting the session timer at INVITE while the other
end correctly started at 200. This meant that for short session-expiries
(90 seconds) combined with long ringing times (e.g. 30 seconds), asterisk
would wrongly assume that the timer was hit before the other end thought
it was time to send a session refresh. This resulted in prematurely
ended calls.
This changes the session timer to start counting first at 200 like RFC
says it should.
(Also removed a few excess NULL checks that would never hit, because if
they did, asterisk would have crashed already.)
ASTERISK-22551 #close
Reported by: i2045
Review: https://reviewboard.asterisk.org/r/3562/
........
Merged revisions 414620 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@414628 65c4cc65-6c06-0410-ace0-fbb531ad65f3
