Wenpeng Song authored 8 months ago and Yalu Zhang committed 8 months ago

cherry-pick the following changes from devel
- When SIP response 408/503/500 is received for SIP Register requests
  to all server addresses, the failover retry will be scheduled
  with certain time interval.
- If number of continuous failed retries reached 'failover_max_retries',
  the SIP registraion will be given up. By default, the number is '-1',
  i.e. unlimited.
- 'failover_interval1' is used between normal failover retries, which
  is 10 seconds by default.
- 'failover_interval2' is used once after every 3 continuous retries,
  which is 60 seconds by default.

More timer (T1,T2,T4,TD/TB) configuration added from asterisk to pjsip.

Priority after this changes:
* retry_after (if received, as above diagram)
* failover_max_retries (if have non-zero values, -1 as infinitive)
* retry_interval (if set, default 1 if not set)
* above diagram base on RFC

Wenpeng Song authored 8 months ago and Yalu Zhang committed 8 months ago

According to asterisk doc:

* prefer: \< pending | configured \>\
  pending - The codec list in the received SDP answer.\
  configured - The codec list from the endpoint.
* operation : \< union | intersect | only_preferred | only_nonpreferred \>\
  `union` - Merge the lists with the preferred codecs first.\
  intersect - Only common codecs with the preferred codecs first.\
  only_preferred - Use only the preferred codecs.\
  only_nonpreferred - Use only the non-preferred codecs.
* keep : \< all | first \> - all - After the operation, keep all codecs.\
  first - After the operation, keep only the first codec.

But in current Asterisk implementation, the `remote_first` which we currently used for incoming
preference has been interrupted wrongly with option "`union`"(merge).

This leading to the issue that unsupported codec could also got an valid joint cap during
ast_sip_session_create_joint_call_cap even if there has no common codec(local codec will be
used), but then failure in the later stage which given the `500 SDP negotiation failed`
response and hangup.

After this correction, unsupported codec will not receiving an valid joint cap during ast_sip_session_create_joint_call_cap if there has no common codec, then a `488 Not Acceptable
Here` response will be send as expected.

This also improve the behavior when an incoming call has no common codec at all: INVITE-
100(Trying)-488(Not Acceptable Here)-ACK, will not have 180(Ringing) in this case.

Grzegorz Sluja authored 9 months ago and Yalu Zhang committed 9 months ago

According to RFC6228 Chapter 4, when UAC sends an initial dialog initiation request
and is willing to receive 199 responses, it must insert '199' option-tag' in the
Supported header field.

Grzegorz Sluja authored 9 months ago and Yalu Zhang committed 9 months ago

Before this change, the next registration happens 10 (defined by REREGISTER_BUFFER_TIME) seconds
before expiration.

Michael Gustavsson authored 9 months ago and Yalu Zhang committed 9 months ago

This makes maxptime attribute in SDP within an outgoing INVITE have a value of 20 instead of 150.

This reverts merge request !172

Wenpeng Song authored 1 year ago and Grzegorz Sluja committed 10 months ago

There is a remaining channel when ref>2 or Asterisk may crash when ref<2 in ast_hangup().

Wenpeng Song authored 1 year ago and Grzegorz Sluja committed 10 months ago

Crash due to a race condition between this ref correction
https://dev.iopsys.eu/voice/asterisk/-/blob/devel/channels/chan_pjsip.c#L2088-2095
and the unref under chan_voicemngr_attended_call_transfer
https://dev.iopsys.eu/voice/asterisk-chan-voicemngr/-/blob/devel/src/channels/chan_voicemngr.c?ref_type=heads#L5646-5651.
When the correction happened and finished before the unref during the transfer, which leading
the result of ref=1 after the unref, then the crash happened during hangup the channel, add an
extra correction for ref<2 could resolve this issue.

Yalu Zhang authored 1 year ago and Grzegorz Sluja committed 10 months ago

Asterisk can crash if two FXS ports on the same device act as transferor and
transfer target when asterisk.tel_options.hold_target_before_refer='yes',
which is the default config. The issues happens after a couple of calls.

The solution is to revert d38e42d8 about
reference count decreasing.
Some validation check is also added to chan_pjsip_hangup().

TODO: After this commit, there will be issues if
asterisk.tel_options.hold_target_before_refer='no'.
- Remaining pjsip channels after a couple of attended transfers in the above
  scenario
- Transferor might not be able to call transfer target because the maximum
  sessions per line exceed the specified number
These issues will be solved in a new commit.

George Yang authored 1 year ago and Yalu Zhang committed 1 year ago

The pjsip channel was not released after call transfer with setting hold_target_before_refer='no'
before the fix.

This is to avoid memory corruption issue that happens when more than one thread calls ubus_free() which frees the global buffer which is defined in libubus.

Wenpeng Song authored 1 year ago and Yalu Zhang committed 1 year ago

When SIP un-registration request got an 200 OK with expiration value which is not 0 (due to the
server setting and network), it is treated as registration success based on the non zero expiration value. This made the other procedures following and it went into an uncontrollable
stage, i.e. unstoppable loop of the un-registration requests until crash.

Solution
Retrieve the requested expiration if possible, and check it together with the received expiration
in response to identify if the 200 OK is to register or unregister.

This "merge" merges the proper history of Asterisk 20.3.0 by reverting
an accidentally squashed merge and doing a proper merge commit after.
Thus, there is no change to the actual code.

Grzegorz Sluja authored 1 year ago and Andreas Gnau committed 1 year ago

This commit is identical to commit 3c8116c8 (Upgrading asterisk to
the version 20.3.0, 2023-10-03) with the difference that it retains
proper history and attribution.

Signed-off-by: Andreas Gnau <andreas.gnau@iopsys.eu>

This reverts commit 3c8116c8. It has
been a merge that has been acidentally squashed into one commit with the
consequence that all history has been lost. The next commit will be a
proper merge commit rectifying this.

Grzegorz Sluja authored 1 year ago and Yalu Zhang committed 1 year ago

There was no audio for 3-way conference when sRTP is used.
For 2-way calls frame->seqno is taken from DSP and is used by asterisk for the sequence number
in RTP headers. However for 3-way conference the sequence number is generated by asterisk and
it has to be greater than the previous value, otherwise libsrtp refuses to forward 'too old'
RTP packets.

George Joseph authored 1 year ago and Wenpeng Song committed 1 year ago

Commit f66f77fa last year prevents the res_pjsip_exten_state and
res_pjsip_mwi modules from unloading due to possible pjproject
asserts if the modules are reloaded. A side effect of the
implementation is that the taskprocessors these modules use aren't
being released. When asterisk is doing a graceful shutdown, it
waits AST_TASKPROCESSOR_SHUTDOWN_MAX_WAIT seconds for all
taskprocessors to stop but since those 2 modules don't release
theirs, the shutdown hangs for that amount of time.

This change allows the modules to be unloaded and their resources to
be released when ast_shutdown_final is true.

Resolves: #379

Wenpeng Song authored 1 year ago and Yalu Zhang committed 1 year ago

This hook function is supposed to return PJ_SUCCESS in order to let a SIP request be
transmitted.

This reverts commit 0f97e870.

Wenpeng Song authored 1 year ago and Yalu Zhang committed 1 year ago

The purpose is to avoid crash during closing.
Also enhance the pointer validation check in sipaddress_on_outgoing_inv_request().

Lukasz Kotasa authored 1 year ago and Yalu Zhang committed 1 year ago

The ast_sip_dialog_get_session function returns the session with reference count
increased. This was not taken into account and was causing sessions to remain
around when they should not be.

Wenpeng Song authored 1 year ago and Yalu Zhang committed 1 year ago

Session invitation is not ready (NULL) on "session_on_tx_request" (before sending the request)
when the function for setting SIPIPAdress is called in the current version.
Call the function under "session_inv_on_tsx_state_changed" (just after the request be sent) 
instead.

Grzegorz Sluja authored 1 year ago and Yalu Zhang committed 1 year ago

Our commits to the previous version have been rebased.

In ast_sip_session_terminate(), reset both active and pending media to prevent
non-freed resources after a call. Otherwise RTP/RTCP ports won't be closed after
the call in some call scenarios, e.g. a non-answered incoming call. In that case,
there are no active media sessions before the swapping.