6 Commits (df7a2397f6c0b25e5fe32fb439b657708bef7a2e)

Author	SHA1	Message	Date
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
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	4 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