We are passing here null pointer (so `this->dlg->getCallid()`)
which isn't good.
Just use a default `WARN()` instead.
Fixes:
*** CID 549008: Null pointer dereferences (FORWARD_NULL)
/apps/sbc/CallLeg.cpp: 193 in CallLeg::CallLeg(const CallLeg*, AmSipDialog *, AmSipSubscription *)()
187
188 // enable OA for the purpose of hold request detection
189 if (dlg) {
190 dlg->setOAEnabled(true);
191 dlg->setOAForceSDP(false);
192 }
>>> CID 549008: Null pointer dereferences (FORWARD_NULL)
>>> Passing null pointer "this->dlg->getCallid()" to "c_str", which dereferences it.
[Note: The source code implementation of the function has been overridden by a builtin model.]
193 else ILOG_DLG(L_WARN, "can't enable OA!\n");
194
195 // code below taken from createCalleeSession
196
197 const AmSipDialog* caller_dlg = caller->dlg;
198
Change-Id: If1f62386c9a2d3f6df4a12a2b157802b8a0677fa
These are all instances of an object being put into a container just
before it goes out of scope. Use move semantics to avoid copying.
Change-Id: I9c40a56c4a67df2b8e244d51f068b50ec286f5bf
Warned-by: Coverity
Make the way we get call-id when calling ILOG_DLG()
file specific, which allows to define locally
(within a target file) how to get the call-id value.
Change-Id: I4af87edf9d1ea52d9678b3354bc797cf1f5f0b54
Use smart pointers instead of handling with new/delete.
Fixes:
Resource leak (RESOURCE_LEAK)
leaked_storage: Variable rev going out of scope leaks the storage it points to.
Change-Id: I33dfe6c4a74a01774093dc500248c3ed613b5710
Introduce `ILOG_DLG()` call-id logging based on `dlg`.
This commit only introduces a usage of it for
CallLeg and SBCCallLeg classes.
Later commits will spread this usage over all
AmB2BSession based classes.
Change-Id: I18ad8ba5129cb8912f401bb089ad82dbf9909a18
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
Consider RecvonlyStream and None (sendrecv) hold types
as NonHold methods.
Fixes:
16: 52:44 CallLeg.cpp: In member function 'CallLeg::holdMethod CallLeg::updateHoldMethod(const AmSdp&)':
16: 52:44 CallLeg.cpp:1421:10: warning: enumeration value 'None' not handled in switch [-Wswitch]
16: 52:44 1421 | switch (hold_method)
16: 52:44 | ^
Change-Id: I2021dd7152ad258e03c28c56cb3b0c7a5e363266
Now `RecvonlyStream` is excluded from those
considered as SDP medias putting other side on hold
(with MoH). Hence no need to take it into account.
Change-Id: Ia04e7808898e0d5e4ac99b71a51e9c0126a0dc11
Rework this function so, that it has all
required for it handling in itself, and doesn't
depend on pre-calls of other things before.
Defined exact purpose of it:
- return `holdMethod` based on SDP
- update `hold_type_requested` class member
It uses `isHoldRequest()` to set the `holdMethod`
but doesn't take into account true/false returned
from it, hence uses this function only as a setter.
Change-Id: Ia89eb20294a2a2533b5fb1e6f5d6d95cbb6179dc
Don't consider (global) session level sendrecv
state, in case of media section absence, as
the `InactiveStream`.
Keep it consistent with a logic for media sections:
sendrecv - means active RTP stream on this leg,
hence no MoH to be provided.
Change-Id: I82f359823f69e7fc12835db1054d63621e7d1dad
Previously introduced by 175b00d72b79561d7
the `Recvonly` hold type had started to put
a call on MoH hold.
This was done so, to fulfill momentary demands
of call scenario which is in fact wrong and
should not be supported:
- A puts on sendonly hold B
- B puts vice-versa A on inactive hold
- now two-way MoH stream both sides
- B resumes his stream with recvonly (meanwhile
only sendrecv considered as the only possible
type to put off hold)
This commits keeps support of stream types
detection as it was, hence `RecvonlyStream` is
still supported. But not anymore considered as
a type which can trigger MoH, in other words
it doesn't put on hold.
This approach makes SEMS in sync with MoH
implementation in rtpengine, whereas only
sendonly and inactive states are allowed to trigger
MoH.
Change-Id: Icf5aa082092cd8f79e43d30339ae8f98a25a7381
Add handling of the `ZeroedHold` and also handle the default action
in the switch inside `CallLeg::updateLocalSdp()`.
This eliminates the warning:
CallLeg.cpp: In member function 'virtual void CallLeg::updateLocalSdp(AmSdp&)':
CallLeg.cpp:2019:15: warning: enumeration value 'NonHold' not handled in switch [-Wswitch]
2019 | switch(hold_method_requested)
| ^
CallLeg.cpp:2019:15: warning: enumeration value 'ZeroedHold' not handled in switch [-Wswitch]
Change-Id: If0eebda2182b44aa591eb9aedd43481c94788b13
SDP session origin id and version are limited by it's size
to 64 bits (8 bytes), that is because we are using `unsigned long long`
type for both id and version. Hence the maximum value it can hold
is two sixty-forth power, so equals: 18,446,744,073,709,551,615
In case one intentionally sets it to something like:
"o=- 18446744073709551615 18446744073709551615 IN IP4 192.168.0.1"
SEMS gets overwhelmed with that conversion inside the code make
it just to a string literal 'F'.
To overcome it, just use __uint128 (which is of 128bits size)
for the session origin id and version.
Change-Id: I2ad9659aa81dad79969749053dc3fd0d69e2cbd2
Use `unsigned long long` for SDP session id and version
instead of unsigned int.
Refactor all usage of them accordingly.
Additionally intrdouce new utils functions for conversion:
- `ulonglong2str()` - converts `unsigned long long` to `string`
- `str2ull()` - converts `string` to `unsigned long long`
Change-Id: I4210349a5442d4173b14227497f4a01d68cad7a4
Save SDP origin after a call leg is held.
Successive reinvites in the session version must be incremented
based on hold/resume reinvite and not based on the original SDP origin.
Change-Id: I771778dbc26f329561fd928ec70e17ab644b19be
Increment the sessV each time,
when creating new hold request.
Instead of blindly using `established_body` AmMimeBody,
properly treat the sessV, and keep it updated.
`updateLocalSdp()` stores updated body then as `CallLeg::non_hold_sdp`
Which will be later on used to resume held.
During resume keep sessV incremented, because each time new
SDP offer is sent out, sessV has to be updated.
Change-Id: Ifaa6ead0a36f9fe77e032e64547a490d856c44d6
- remove `hm` type, which used to be a crutch
- only use the `holdMethod` type for hold method detection
(so instead of `hm` used)
- move `holdMethod` from .cpp to .h
- make `CallLeg::hold` to a `enum holdAction` data type
(so this enum can be reused)
- make `CallLeg::hold_method_requested` to a `enum holdType` data type
(so this enum can be reused)
- move the `isHoldRequest()` helper to class methods instead of being static
- rename `hold_method_requested` to `hold_type_requested` to have less
confusion in naming (with `enum holdMethod` for example)
Change-Id: Ib40a9e1c40419d6ffd444b59f92958c893c7f268
This commit affects cases when the on-hold is requested,
and the MoH emulation on the SEMS is additionally used.
Currently regardless the method used by the one who sets the call
on-hold, the answer will be always 'a=sendrecv', which leads to
a premature termination of the call at the RTPEngine
(because RTPEngine takes the 'a=sendrecv' into account and
terminates the call due to no seeing the audio)
We need to make sure, that an originator of the on-hold, is being
answered:
- with the 'a=recvonly', if an originator requests the 'a=sendonly'
method of the on-hold to be used.
- with the 'a=inactive', if an originator requests the 'a=inactive'
method of the on-hold to be used.
And after the on-hold is restored (by 'a=sendrecv'),
make sure to send the SDP answer with the 'a=sendrecv' as well.
Change-Id: I50df81be16a75d9e813484012938e2a94ec422e1
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
Make the `isHoldRequest()` safer in terms of operating
on a given `AmSdp &sdp`, we still don't change anything in
the body, but just checking if the request is a hold one.
Change-Id: I82fa3da1a11c686050dc482106735139b800ff2d
Do not take into account `send_491_on_pending_session_leg`
when processing pending updates for call-pick call scenario.
This is required to let the A side (so caller) be updated,
which in a cascading manner later triggers 200OK sending
towards the call pick-up'er, and further media updates
via re-invite.
`send_491_on_pending_session_leg` is used to prevent
overlapping updates towards the same other leg.
In this situation however, two updates towards the caller
is a proper way to finish the call-pickup, so the media update.
A new header for interaction between SBC<->B2B introduced:
`P-Force-491`, which takes either of values '1' or '0'.
If set to '0' the `send_491_on_pending_session_leg` will always
be ignored by SBC, and hence re-invite will reach the target,
regardless if there has been anyone shortly before.
Change-Id: Iee7d2c6ef38e568e7c57a89358b22be0b1cb0438
We need to take care of cases, when one leg has pending
transaction(s), and an opposite leg triggers media re-negotiations,
which assumes we have to update the first leg as well (the one which
has a pending transaction).
Perviously we used to only support sending a fake 200OK to the one,
who triggered a media attributes re-negotiation, and scheduling
an update for the opposite leg for a later time (as soon as its done
with its own transaction(s) ).
For now we can optionally decide whether:
- to send 200OK to the one who triggers re-INVITE
- to send 491 Pending to the one who triggers re-INVITE
Using the approach with 491, gives a solution to the problem,
when a fake 200OK is sent to the remote side, and ACK after a while
is not matched to any of the existing local transactions.
This can happen in case, we have sent a fake 200OK, but SBC triggers
one more transaction towards the same side (over already existing one).
This behavior leads to a failure when trying to match coming ACK to the fake 200OK.
By default, enabled behavior - generate fake 200OK.
Optionally it's now possible to enable 491 Pending response,
by setting sems.conf option:
- send_491_on_pending_session_leg = 'yes'
Change-Id: I17f41833651eb006666315c1f9a7cfd4c0441f8a
Sync the `CallLeg::onB2BReconnect()` with PRO code version,
and add second part of SDP origin manipulation fix.
Change-Id: I7d7558bc88ab91d00bac72a22e1f713afd218233
During refreshing of the media for the call leg in the
`CallLeg::adjustOffer()`, when the resume is required,
but the `on_hold` wasn't set before (so is false),
then additionally check, whether the SDP body
(media sessions of `MT_AUDIO` type) has state like:
- sendonly
- recvonly
- inactive
This will properly fix the attributes (like: `a=sendonly`)
in the re-INVITE, which is supposed to resume the session.
Change-Id: I1c45b7db55d2a5174f3fd96f3fcd0201b48345f2
This fixes the warning:
CallLeg.cpp: In member function 'void CallLeg::adjustOffer(AmSdp&)':
CallLeg.cpp:1670:7: warning: 'hm' may be used uninitialized in this function [-Wmaybe-uninitialized]
1670 | if (hm != RecvonlyStream)
| ^~
Change-Id: I7479d1107cb36b733441a3a0ec130658a6786e50
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
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
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
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
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
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
- 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
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
Donat Zenichev
Richard Fuchs
Marco Capetta
Victor Seva