12 Commits (0bd7fa65b892b35b0e3f6ea5fffcfe08b7cdf75e)

Author	SHA1	Message	Date
Donat Zenichev	0bd7fa65b8	MT#56321 Refactor: core::CallLeg::onSipRequest() ... For better reading of the code, refactor this function. Original ticket's number: 56719 Change-Id: Ie19d008562dc7a13eb982809f23fd6553245f07c	3 years ago
Donat Zenichev	b79fc7a089	MT#56321 Implement 'recvonly' beginning on-hold ... Improvement of the way we detect, whether or not the received SDP offer is the on-hold request. Now we do not take into account the 'recvonly' cases, when the offer arrives with that (only 'inactive', 'sendonly' or "zeroed" on-hold). From now on we also want to consider 'recvonly' as the completely equal on-hold request, which expects that the end recipient of that will return us the 'sendonly' (or worst case 'sendrecv'). Original ticket number: 0055934 Change-Id: Ice3b767c4aef2c6e3e96199219ad0d0e04e93ecf	3 years ago
Donat Zenichev	b34b85fe62	MT#56321 DSM: Introduce helper functions related to DSM processing ... We have to optimize our code: - substitute all repeating (DSM related) code with a helper static functions - remove all excessive stuff, which plays no role Change-Id: I27170509d84a634dc4a9a865ea8395e4e8cc2f3d	3 years ago
Donat Zenichev	020cd18448	MT#56321 core: introduce 'global_defs.h' header ... Introduce a new header file "global_defs.h" in order to use that for global definitions or macroses, which are not particularly related to the SIP headers. Such as DSM applications names. This will simplify handling and decrease hardcoding all around the project. With this commit additionally: - stop hardcoding values related to DSM applications specific names - move all the DSM definitions into the global_defs.h or defs.h Change-Id: I389f632434f0ae1e62540e8df584fdc5e1e07e39	3 years ago
Donat Zenichev	8195d1378d	MT#56321 AmB2BSession::onB2BEvent - add DSM 'early-dbprompt' processing ... We need to add the 'early-dbprompt' DSM application into the processing of the 480 replies, which have 'P-DSM-App: <app-name>;playback=finished' parameter set. Change-Id: I3e561f510d8e56ca7d0cece714c0330f3bfa9ecd	3 years ago
Donat Zenichev	14ad7f85f6	MT#56321 Use the P-DSM-App instead of the P-Early-Announce ... 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	3 years ago
Donat Zenichev	91cd45fe7b	MT#56321 Treat 183 as 200OK (other leg), when early media forced ... 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	3 years ago
Donat Zenichev	d5eaa1c5a2	MT#56321 call_transfer: add support of 183 in failed transfers ... 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	3 years ago
Marco Capetta	d4d1fc7bb8	MT#55831 Handle BYE after 180 with to_tag ... - customer has a scenario when 180 has to_tag and call terminated by caller with BYE but calle did not get any call termination signalling. - a bit more special for such cases BYE handling added. (real ticket number: TT#73957) Change-Id: I9ebbf4f3a504d3587550e55aec926438199be5e9	3 years ago
Marco Capetta	d45dcf1ecf	MT#55831 Fix issue if an UPDATE is received after 183 ... 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	3 years ago
Victor Seva	2bf464e5cb	Imported Upstream version 1.6.0~20150612~a2d214df36	11 years ago
Victor Seva	df9992620d	Imported Upstream version 1.6.0~20140516~eaa616	12 years ago