8 Commits (master)

Author	SHA1	Message	Date
Donat Zenichev	8e1a41a9ec	MT#59962 core: introduce new RTP transport model ... 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	5 months ago
Richard Fuchs	8083dcd92f	MT#62181 use shared_ptr for msg_logger ... Use shared_ptr for reference counting instead of hand-rolling it. Change-Id: I147dd6df4e302a2400b184aa88775cf635a57506	10 months ago
Donat Zenichev	ede52ab0b3	MT#61912 OA: save the established body when it's generated ... When OA generates own SDP body (e.g. case with accepted invite in DSP), save it as established_body for this leg, in order to be able to re-invite this leg later. It can happen there is still no SDP seen from the callee side (other side), and in case we want to send established re-invite towards this leg, this will fail, since no SDP body seen yet. Change-Id: Ifd9f0fb70d27deac871de4eed1648f7c152813f3	1 year ago
Daniel Grotti	cdcbbb7866	MT#57562 sems (CE): Add Allow header in 200 OK when empty ... This is a partial rework of b67428d. The patch was always saving the Allow header from the initial INVITE and replacing the Allow header in the 200 OK with that. This fixed an issue with AA, where Allow header in the 200 OK, generated by the AA, was empty. But it causes an issue in case of normal calls between A and B. In general we want to keep the Allow header in the 200 OK, if exist. Instead, we want to add the Allow header in the 200 OK response in case the 200 OK does not contain the Allow header. In this case we won't set the original Allow from the INVITE but instead we will set a default Allow header (SIP_REPLY_DEFAULT_ALLOW) containing all the major SIP method. Change-Id: I6bf5a2cc7e0228f7b99d28963d16c14c463be695	3 years ago
Donat Zenichev	aec816dad7	MT#56321 Add 'Allow:' header to the 200OK, if present in the request ... We have to take care of keeping the actual 'Allow:' header in the request, if the incoming request has had it. One of the use cases for that is for example the INVITE coming to the AA, when we must respond with the 200OK, but there is no 'Allow:' header inside the 200OK. Certain systems can be confused by that, even though the RFCs are not forcing us to do so. Which can even lead to an impossibility to use a normal call clearing with the BYE method, from behalf of the caller. Change-Id: I9bafb89e4aa5e53077450068f847c07a497b43f1	3 years ago
Victor Seva	2bf464e5cb	Imported Upstream version 1.6.0~20150612~a2d214df36	11 years ago
Victor Seva	be6b7d527c	Imported Upstream version 1.6.0~20140819~0b6d12	12 years ago
Victor Seva	df9992620d	Imported Upstream version 1.6.0~20140516~eaa616	12 years ago