Add missing initialisers and fix order.
In some cases the member was actually unused and could just be removed.
Change-Id: I0f0c927eb8271c35dcfd371f225847f62bea2812
Warned-by: Coverity
Ignore SDP repeated in 183 and 200OK messages
in the late offer/answer, but only for the
`OA_OfferSent` OA state.
Change-Id: I136ad02182685d0158e2c7c4eee53833cd8e00f4
When OA generates own SDP body (e.g. case with
accepted invite in DSP), save it as established_body
for this leg, in order to be able to re-invite
this leg later.
It can happen there is still no SDP seen from the
callee side (other side), and in case we want to
send established re-invite towards this leg,
this will fail, since no SDP body seen yet.
Change-Id: Ifd9f0fb70d27deac871de4eed1648f7c152813f3
When replying with 200OK generated by SEMS to INVITE requests,
which have no SDP body included, just answer with empty 200OK.
This sets the `OAState` of the call leg to `OA_None`.
Change-Id: Ic28e80d670ba4ce98be6abac9d17689688f99f71
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
Backport from the upstream to add support for body content type
application/csta+xml in INVITE and INFO requests/responses.
Upstream commit: 6f67d15c3857c1f8ed5b33615b7f5ff0e12d3a92
Change-Id: I085eda4a10e73139bd4dce4d75def82bf6da1e8d
This fixes that:
AmOfferAnswer.cpp: In member function 'int AmOfferAnswer::onReplyOut(AmSipReply&)':
log.h:143:30: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 4 has type 'unsigned int' [-Wformat=]
143 | _LOG(L_DBG, error_category " " fmt, ##args)
log.h:121:45: note: in definition of macro '_LOG'
121 | int n_ = snprintf(msg_, sizeof(msg_), fmt, ##args); \
| ^~~
log.h:166:29: note: in expansion of macro 'CAT_DBG'
166 | #define DBG(fmt, args...) CAT_DBG(ERROR_CATEGORY_DGENERAL, fmt, ##args)
| ^~~~~~~
AmOfferAnswer.cpp:367:9: note: in expansion of macro 'DBG'
367 | DBG("Forcing no OA state update (no SDP changes, same session version: was <%llu>, now is <%llu>).\n",
| ^~~
AmOfferAnswer.cpp:367:88: note: format string is defined here
367 | DBG("Forcing no OA state update (no SDP changes, same session version: was <%llu>, now is <%llu>).\n",
| ~~~^
| |
| long long unsigned int
| %u
In file included from AmArg.h:43,
from AmSipMsg.h:3,
from AmOfferAnswer.h:32,
from AmOfferAnswer.cpp:29:
log.h:143:30: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 5 has type 'unsigned int' [-Wformat=]
143 | _LOG(L_DBG, error_category " " fmt, ##args)
log.h:121:45: note: in definition of macro '_LOG'
121 | int n_ = snprintf(msg_, sizeof(msg_), fmt, ##args); \
| ^~~
log.h:166:29: note: in expansion of macro 'CAT_DBG'
166 | #define DBG(fmt, args...) CAT_DBG(ERROR_CATEGORY_DGENERAL, fmt, ##args)
| ^~~~~~~
AmOfferAnswer.cpp:367:9: note: in expansion of macro 'DBG'
367 | DBG("Forcing no OA state update (no SDP changes, same session version: was <%llu>, now is <%llu>).\n",
| ^~~
AmOfferAnswer.cpp:367:103: note: format string is defined here
367 | DBG("Forcing no OA state update (no SDP changes, same session version: was <%llu>, now is <%llu>).\n",
| ~~~^
| |
| long long unsigned int
| %u
Change-Id: I15c6e37756a55ea5c917b123030b30e0ddc55724
We don't have to change the SDP OA state, in case
the 183 response has exactly the same SDP content
(same SDP session version) as we already have seen
before in previous 183 message.
Change-Id: Ica008104c31e979cdcb352cefea39db4d1ff3c56
We have to improve AmOfferAnswer functions in terms of adding
more logging, to let the debug of the OA be more clear.
Also in parallel the refactoring is done in scope of AmOfferAnswer
in order to make reading more convenient.
Change-Id: If7353f1285057760dd5fbeada984a5ef96af9854
Re-use existing local sdp, in case there is a sequential 183 coming,
but it has no SDP.
This will fix the cases, when:
- first 183 has been sent, and provided to the system the SDP
- second/third etc. 183 is coming, but has no SDP body
To not confuse the recipient (end subscriber) of these 183,
the media description in the scenario with 183 having no SDP body,
mustn't be changed (session id, media and attributes).
Previously the behavior was to generate local SDP with
a new session id and add sems-b2b into the media processing by that
(new media port, codecs and other attributes).
However, this change doesn't have an influence on very first 183
sent with no SDP body, because there was essentially no local SDP
saved before. So in this situation behavior is not changed.
Change-Id: I53dd57ae8a4739d5356d94fff45fb290896fd777
Because of messy organizing of the code in the function,
it's not possible to read that and work with that.
Change-Id: I4a56000a6f33051f9267048dcb620fb1a4eba7c6
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
Richard Fuchs
Donat Zenichev
Marco Capetta
Jozef Kenyeres
Victor Seva