This commit introduces a new RTP transport model,
based on the AmRtpTransport abstraction, providing a more modular and
efficient approach to RTP handling compared to the legacy model.
General things:
- Introduction of new RTP receiver and transport abstractions
- The new model coexists with the legacy RTP handling
to preserve backward compatibility
Architecture overview:
- A new AmRtpTransport layer is introduced to encapsulate RTP transport logic
and decouple it from AmRtpStream and session-level code
- Transport-specific functionality is implemented via dedicated classes:
- AmRtpTransport: base abstraction responsible for RTP/RTCP packet flow,
lifecycle management, and interaction with streams
- AmRtpUdpSocket: UDP-based RTP socket implementation
- AmRtpSocketPair: manages RTP/RTCP socket pairs and their coordination
- AmRtpStream is refactored to rely on the transport interface
instead of directly managing sockets and low-level I/O
Integration details:
- SIP session and dialog logic (AmSession, AmSipDialog) is updated to work with
the new transport model
- SBC call legs and call profiles are extended to support transport selection
and lifecycle handling
- SDP processing (AmSdp) is updated to reflect transport capabilities and
address handling changes
This refactoring improves separation of concerns, reduces coupling between RTP
streaming and transport mechanics, and provides a cleaner foundation for future
RTP extensions and optimizations.
Code provenance and license:
- part of the code was written by Fokus GmbH
- part of the code was written by Sipwise GmbH
- part of the code base copyrighted by Fokus GmbH was provided by them in
the form of backports under the GPL license.
- these changes are covered by the GPL, matching the existing project license
Change-Id: I313c4abd9b54f805c1e668c019cf6fb8c4a9e46d
Don't re-exploit the connection information and port
(taken from the coming SDP offer) for creation of faked
SDP answer (200OK). This is confusing and can break things
in rtpengine monologues handling.
Better to create fake SDP answer based on already learned
local SDP port and entirely connection information.
Change-Id: Id71453022fd6c93f6743f1046588447b52c38c07
Make the AmOfferAnswer model actual and introduce
according class API updates.
Accordingly update CallLeg, SBCCallLeg and AmSipDialog.
Change-Id: Iab26f4a7577af56df68ffe693859eaac08913b7f
Move it to the dlg level, because of complex visibility.
In other words, when working on the dialog level and e.g.
generating new SDP body using `dlg.oa`, there is no way
to save it.
Moving it to the dlg level, gives a control over it on
the whole amount of inheritance levels plus dlg.
Change-Id: Iebb13e3e58f2558dc060e23270d99d690fa54572
Add a function to the AmSipDialog class interface,
to be able to check whether the OA currently expects an offer.
Use it then in the `CallLeg::updateLocalSdp(AmSdp &sdp)`
Change-Id: I1c4f4364ce13c7b03e22e0f037d19b99245a0be8
Since the P-Early-Announce has gotten deprecated, it's required
to stop using it. And instead start using the P-DSM-App header, which
now carries the same information as parameter ';early-annonce='.
Change-Id: I7f0f378143d0b6600a239084cd51935a31df3d08
B2BSipReply
We have to update the media session with the caller, if the 183 response
with the 'P-Early-Announce: force' has been received.
Change-Id: Ib39dc124ef5e8934ff617d562b222bd07dfcacc1
There is a need to add an exception processing for 183 Session Progress,
and the following in-dialog requests/responses, in case the 183
has been previously sent to the B2B with the hf
'P-Early-Announce: force'.
This adds the following behavior.
When 183 is received, and the caller has been updated with the
new media capabilities, according to those needed to embed early
media into the media session with the caller (via re-INVITE), then:
- even though the 183 is treated similarly to 200OK in terms of media
updates, do not send ACK to the leg going towards DSM,
becausethe sems-b2b giving the DSM, it's still in stage INVITE/183
- do not re-negotiate the leg going towards the DSM,
after the caller has been updated with the new media (a usual behavior)
because the sems-b2b giving the DSM still considers the dialog here
in the Early stage
- do not set the leg going towards DSM into the Connected state,
because by the fact, it's still in the Early stage, and setting of
it into the Connected state, will break processing of BYE / CANCEL.
- upon receiving the BYE from the caller (after the DSM announce is heard),
answer right away with 200OK, but do not forward BYE to the let going
towards DSM. Instead initiate the CANCEL towards it, because this leg
is technically still in the Early stage of the dialog.
Original ticket number: TT#187351
Change-Id: Id6e05202add1bcbd358eecbcd5e2cbda1a995b32
We have to add support for playing an early announce for those
failed trasnfers, which for example reach the timeout.
This means there is a need to do the following:
- send 183 from early announce DSM module
- receive 183 on the B2B leg, which was sending an INVITE to
the transfer destination
- update the caller with an actual media capabilities,
so it is able to receive the early announcement
The mechanism behind that is that:
- if Proxy in the other leg, which was used to reach the party
(to which the transfer has been done),
requests the force usage of the announcement for the caller
in the very first leg (with the caller who is on hold now)
- then the DSM functionality adds the 'P-Early-Announce: force' header in 183
to let sems-b2b in the very first leg know, that there is a need to embed
the audio from the early media into the media session with the caller.
- hence, caller gets a media re-negotiation
- and the leg with the DSM doesn't get updated, since it's still remains
in the Early stage of the dialog
All the solution is built around two important things:
- Proxy uses the P-App-Param called ';force_early_announce=1' to show to the
DSM that it needs a "forcive" early media, which must "override" the MoH
for the caller, if it's being played.
- Sems-b2b uses the header 'P-Early-Announce' to let the very original leg
with sems-b2b know, that there is a need to embed early media into
the already established media session with a caller
Original ticket number: TT#187351
Change-Id: I2cda231e877d9ba91eaa1738322b0981618c1dbf
If an SDP UPDATE is received after the 183, but before the 200,
SEMS fails when it receive the final ACK. In fact SEMS tries to
find the SDP content inside the ACK message itself.
The solution is copied from sems-pbx module where the issue
doesn't happen.
(real ticket number: TT#43503)
Change-Id: I5a432dc57c701d7eb0d5306d6005508e3310e7ba
If an INVITE has been forked and more than one branch is aimed at SEMS,
then the branch parameter of the top-via is necessary to distinguish the
different sessions.
By default, SEMS will now accept forked INVITEs.
This behavior can be switched off by setting "accept_forked_dialogs" to "no" (default=yes).
Conflicts:
core/AmSipDispatcher.cpp
In case 100rel is disabled on SEMS' side, but UAC requires it, SEMS
would reject the INVITE, drop further processing on the session, but
still keep it. If INVITE is first in session, UAC would clear the
dialog, but SEMS would still keep it.
But spotted and explained by Stefan S.
In the context of multihomed servers, the signaling interface can be selecetd by the application. By default, the signaling interface is determined automatically. The media interface can also be set manually, there is however no automatic selection. In the case it is not set by the application, the default interface (the first one defined) is used instead.
- add reliable_1xx REL100_IGNORED, where all rel100 stuff is ignored
- set B2B sessions as reliable_1xx=REL100_IGNORED
- translate RAck Cseq
- for this: adds rack_method and rack_cseq to sip request (should possibly be reworked to use some dynamic field)
- relay Rseq (if exist)
- change the way RSeq accounting is done: changed signed data type to
unsigned, at expense of adding two more vars to AmSipDialog; this
should make AmSipDialog more replication friendly.
- b/f: if 100rel is disabled and an inbound request asks support for it,
reply with 420.
The 100rel logic moved in great part to AmSipDialog; this way, it can be
hooked directly to request/reply processing routines, the ones on top of
the transactional layer (::updateStatus(..)).
This allows to:
- better control when to push the messages into the AmSession's
onSipRequest/~Reply, fixing some issues with applications that received
replies, but without sending themselves the requests
- insert needed headers, no matter which request function is used
(::invite() vs. ..sendRequest())
- B2BUA app with SIP Session Timer (SST) now can also use UPDATE
(see session_refresh_method in sst_b2b.conf)
- if re-INVITE is used, normal SDP OA (INVITE+SDP/200+SDP) is done
using last established SDP (instead of delayed SDP negotiation
and SDP ping-pong)
- SDP is compared only after o= line (no SDP ping-pong with UAs which
always increase SDP version)
- introduced outbound_proxy+force_outbound_proxy at the SIP dialog level (AmSipDialog)
- outbound_proxy+force_outbound_proxy is configurable in the sems.conf
git-svn-id: http://svn.berlios.de/svnroot/repos/sems/trunk@1818 8eb893ce-cfd4-0310-b710-fb5ebe64c474
- moved 200 ACK from sipctrl into the UA.
- [request|dialog].next_hop ("host:port") can be used to set the outbound host/port.
- 200 ACKs are passed to the UA.
git-svn-id: http://svn.berlios.de/svnroot/repos/sems/trunk@1460 8eb893ce-cfd4-0310-b710-fb5ebe64c474
some fix with CRLF on refer-to
some fix with content_type on announce_transfer
based on patch by Balint Kovacs
git-svn-id: http://svn.berlios.de/svnroot/repos/sems/trunk@1388 8eb893ce-cfd4-0310-b710-fb5ebe64c474
Donat Zenichev
Marco Capetta
Victor Seva
Stefan Sayer
Stefan Sayer
bpintea
Raphael Coeffic
bpi