Age | Commit message (Collapse) | Author |
|
The fix for the issue is broken up into three parts.
This is part one which refactors the transport state monitor code to allow
more modules to be able to monitor transports.
* Pull the management of PJPROJECT's transport state callback code from
res_pjsip_transport_management.c into res_pjsip. Now other modules can
dynamically add and remove themselves from transport monitoring without
worrying about breaking PJPROJECT's callback chain.
* Add the ability for other modules to get a callback whenever a specific
transport is shutdown.
ASTERISK-27147
Change-Id: I7d9a31371eb1487c9b7050cf82a9af5180a57912
|
|
* Use monitored instead of the misleading keepalive name.
Change-Id: I9e5bcbb4ab2b82d49bcd0f06dfe85d15e0b552b6
|
|
ASTERISK-26375 #close
Change-Id: I46496af5cae41413e76d44d2068a7431279f09dc
|
|
* In unload_module(), reordered destroying things to minimize the window
that the global transports container could be used by other threads on
shutdown. When shutting down you need to stop things in the opposite
order of creation.
* Put the global transports container into an AO2_GLOBAL_OBJ_STATIC to
eliminate the crash potential by other threads using the container on
shutdown.
* Made struct monitored_transport.sip_received not use
ast_atomic_fetchadd_int() since it is used as a boolean value that is only
set TRUE. It was previously incremented for every received SIP message
and could theoretically overflow.
* In monitored_transport_state_callback(), allocated the monitored
transport object without a lock since the lock was unused.
* In keepalive_global_loaded(), removed releasing the transports container
if the keepalive_thread could not be started. I set it up to be tried
again if the user reloads the configuration.
Change-Id: I8d12d16ef564290fa6d25a32334bb5ce8fdf87ff
|
|
At shutdown it is possible for modules to be unloaded that wouldn't
normally be unloaded. This allows the environment to be cleaned up.
The res_pjsip_transport_management module did not have the unload
logic in it to clean itself up causing the res_pjsip module to not
get unloaded. As a result the res_pjsip monitor thread kept going
processing traffic and timers when it shouldn't.
Change-Id: Ic8cadee131e3b2c436a81d3ae8bb5775999ae00a
|
|
The scheduler thread that kills idle TCP connections was not registering
with PJProject properly and causing assertions if PJProject was built in
debug mode.
This change registers the thread with PJProject the first time that the
scheduler callback executes.
AST-2016-005
Change-Id: I5f7a37e2c80726a99afe9dc2a4a69bdedf661283
|
|
"Idle" here means that someone connects to us and does not send a SIP
request. PJProject will not automatically time out such connections, so
it's up to Asterisk to do it instead.
When we receive an incoming TCP connection, we will start a timer
(equivalent to transaction timer D) waiting to receive an incoming
request. If we do not receive a request in that timeframe, then we will
shut down the TCP connection.
ASTERISK-25796 #close
Reported by George Joseph
AST-2016-005
Change-Id: I7b0d303e5d140d0ccaf2f7af562071e3d1130ac6
|
|
ASTERISK-25796
Reported by George Joseph
AST-2016-005
Change-Id: Id322a05f927392293570599730050bc677d99433
|