10 Commits (8130c22bc14e5a7cb7982220b6b9bb02753e7ba7)

Author	SHA1	Message	Date
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	a29e09fc90	MT#62253 log: AmBasicSipDialog: add call-id based logging ... Introduce usage of `ILOG_DLG()` Change-Id: I0b3702ac779074c8cbb21a58f33beb01f128eea1	1 year ago
Daniel Grotti	f56366737c	MT#58584 Do not add outbound_proxy in Route if exist ... When outbound PRACK is challanged, SEMS is regenerating the PRACK to proxy duplicating the proxy socket in the Route header, with the result of: Route: <sip:127.0.0.1:5062;lr>, <sip:127.0.0.1:5062;lr=on;ftag=xyz;leg_b=1;did=f85.d281>, <sip:127.0.0.1;r2=on;lr=on;ftag=xyz;ngcplb=yes>, <sip:192.168.178.104;r2=on;lr=on;ftag=xyz;ngcplb=yes> the duplicate "127.0.0.1:5062" is causing routing issue on proxy, cause loose_route() function removes only the first element. Then proxy sends PRACK to itself. To avoid that, we make sure is SEMS to do not add the 'outbound_socket' value in the Route header if that value already exist in the first position. Change-Id: Id310144d8e77a99111e199358462496c9dd0495c	3 years ago
Donat Zenichev	51f57d7ce2	MT#58584 Add more logging to `core::AmBasicSipDialog::sendRequest()` ... Add more logging to the `core::AmBasicSipDialog::sendRequest()`. No functional changes. Change-Id: I3837164393e9dbb6dc592acd3e494ec228bcbcd6	3 years 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
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