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
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
If requested by `b2b_build_pai_from_hdr` DSM parameter,
then get the value of PAI using this parameter and pass
it further for `B2BSipReplyEvent` processing.
Use event params to pass the value.
`b2b_build_pai_from_hdr` keeps the name of header
coming in the latest reply, from which the PAI's value
is to be built.
Update the `reinviteCaller()` function's signature,
to pass headers towards `dlg->sendRequest()`.
Change-Id: Ic6e66e326f26a830c3ed06c19a6ab7be4ebe0135
Re-use previously offered SDP body, when processing
a call session with an involvement of DSM, and getting
newer SIP invite having no SDP offer.
This affects applications using the B2B `connectCollee()`
functionality and doesn't actually touch the B2B core itself.
(Which would be wrong if changed in a usual core SDP
processing, whereas original request can be empty and
an offer/answer is postponed to 200OK/ACK exchange)
(Re)invites towards DSM applications technically must
not be empty, because DSMs don't support late offering.
In order to overcome that just pretend that empty
re-INVITEs are using previous body version.
Change-Id: I252eb9f32e7dc073454a2258b176f77bf15d35c9
Introduce getters for headers in requests
and replies:
- `B2B.getHeaderRequest()`
- `B2B.getHeaderReply()`
Change-Id: I1dfc24658a9e044407f95de9507032f1b041b451
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
Core in CE is missing currently functions to accept
pending invitations, introduce them from PRO version:
- `acceptPendingInviteB2B()`
- `acceptPendingInvite()`
Additionally:
- add a helper to create fake replies `createFakeReply()`
Change-Id: Icc5be22051f68f269d4b93637f2b3b59498dbd25
Sync the `CallLeg::onB2BReconnect()` with PRO code version,
and add second part of SDP origin manipulation fix.
Change-Id: I7d7558bc88ab91d00bac72a22e1f713afd218233
Because of messy organizing of the code in the function,
it's not possible to read that and work with that.
Original ticket number: 0055878
Change-Id: I6c093ccc09015c9d4745af6b3c21365220b81386
The new parameter of the 'P-DSM-App:' header is introduced:
- ';reset-to-tag=''
It affects the processing of 18X (especially it relates to 183).
If this is set to '1', then the To-tag stored as the remote tag in
the 'dlg' object, must be updated to the latest one provided by this 183.
This fixes the case as the following one:
- A calls B (B is an owner of the callqueue)
- B starts ringing, and provides the To-tag with 180
- this in its turn, will initiate generation of own "internally"
generated To-tags in all the internal legs between Proxy <-> B2B,
which are crossed by this 180
- B responds with 486 Busy and a processing gets inside the route[ROUTE_EARLY_REJECT]
- the brand-new INVITE is generated and sent to the DSM early_dbprompt app
- A brand-new 183 is provided by the DSM app, which has another (new) To-tag
- this will mismatch in the very original leg with Proxy and B2B
and 183 will be not sent towards the caller, which makes impossible
to provide an early reject playback to it
Original ticket number: 0055878
Change-Id: I96abbe0b8427d40752967607d2fdd0e11145a06a
We have to add more SIP response codes, which will be checked against
the isDSMPlaybackFinished(). So that when the DSM playback is finished,
the call is properly released on the caller's side.
Exceptionally 487 is added, for cases like:
a call to HG, where nobody answers and the timeout triggers
a cancelation of all the legs.
Change-Id: I1f7cf81dd5966843713fc41c21ea0249174c13ab
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
B2BSipReply
We have to update the media session with the caller, if the 183 response
with the 'P-Early-Announce: force' has been received.
Change-Id: Iec67c6b6cc5284afbcfb492fc53108439a427b1d
Because of messy organizing of the code in the function,
it's not possible to read that and work with that.
Change-Id: Iab28ba34ba0cc970e3f100f8cc61bcbbdabee2bb
B2BSipReply
We have to update the media session with the caller, if the 183 response
with the 'P-Early-Announce: force' has been received.
Change-Id: Ib39dc124ef5e8934ff617d562b222bd07dfcacc1
If we get the 480 reply from the office-hours DSM application,
and there is a header 'P-DSM-App: office-hours' added, with
a parameter ';playback=finished', then it means the following:
- there was either AA or transfer involved into the call, before
the call got to the DSM office-hours
- caller remains in the hold state (so there was 200/ACK)
- the office-hours playback has been finished, and now we mustn't
forward 480 to the caller's leg, but just terminate it with BYE
Change-Id: I389c6993185008c51c61bacd8eb23ac1562871b8
Because of messy organizing of the code in the function,
it's not possible to read that and work with that.
Change-Id: I558685c46358caabe55193c1e27d9531728ea7d6
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
applications which are doing outbound calls should implement
onFailedOutboundCall if the behavior should be different than
setting stopped.
Reported by Andrei Samusenko
Donat Zenichev
Richard Fuchs
Victor Seva
Stefan Sayer
Raphael Coeffic