Dear Kamailians,
I just opened a merge request for a new module called RTP Media Server
I understand that integrating an RTP/Media endpoint directly in Kamailio
may seems strange at first.
Let me share my thoughts ...
By combining Kamailio, oRTP and mediastreamer2
this module is providing some very good foundation to support RTP endpoint
and various media processing features.
This seems like a great idea for various use cases like IoT, IVR or other
specific needs.
Kamailio is still handling everything related to SIP/SDP (the module is
adding some SDP parsing, they could be integrated in the core if this seems
fit).
By doing integration with a library we can benefit from the scripting
engine and probably KEMI.
This does not means that everyone should run this module on a Kamailio
sever acting as a load balancer, of course CPU intensive operations like
resampling and encoding may be taking place on the server.
oRTP is providing RTP endpoints compliant with (RFC 3550)
MediaStreamer2, even if written in C is quite a high level library, because
it is implementing a framework for audio processing using graphs of
filters, filters can be to do various things.
Similar to playing with lego blocks :)
- Support for most free and some non free codecs can be added easily.
- Work to bridge calls is already in progress in the module.
- Mobile phone support ARM CPU and other embedded scenario should be
supported
Mediastream2 is creating one thread per call "msticker", this can work
smoothly in Kamailio even if it is forking processes.
Shared memory allocation is supported using wrapper around malloc/free used
by the libraries.
This project was started last year, I exposed the idea at
KamailioWorld2017, the feedbacks I god where not all positives :)
But we did speak about it again at ClueCon2018 and I was encouraged to
complete the work and propose a MR.
The module is not working and was tested with several softphones.
I think it is time to submit it ... before considering adding more features
or investing more time in it.
Julien
Example config using the features already implemented
event_route[rms:start] {
xnotice("[rms:start] play ...\n");
rms_play("/tmp/reference_8000.wav", "rms:after_play");
};
event_route[rms:after_play] {
xnotice("[rms:after_play] play done...\n");
rms_hangup();
};
route {
if (t_precheck_trans()) {
t_check_trans();
exit;
}
t_check_trans();
if (is_method("INVITE") && !has_totag()) {
if (!rms_answer()) {
t_reply("503", "server error");
}
}
if (is_method("BYE")){
rms_media_stop();
}
}
### Description
I am looking at how to properly handle a problem with duplicate ACC
This is when `TMCB_ON_FAILURE` and `TMCB_RESPONSE_OUT` are both called, they are not using the same version of the message.
`TMCB_ON_FAILURE` is using the cloned version
`TMCB_RESPONSE_OUT` is using the original version
They are not sharing the message flags and 2 ACC events are generated.
Since this is very sensitive, I want to make sure I can trace the real root cause.
Not sure if this is a regression ...
#### Reproduction
Any failed call
#### Debugging Data
```
0(4603) NOTICE: acc [acc_logic.c:686]: tmcb_func(): acc callback called for t(0x7f768b6dac08) event type 2, reply code 404 reqmsg[0x7f768b6dc840] rplmsg[0x7f76d096dee8]
0(4603) ERROR: acc [acc_logic.c:697]: tmcb_func(): [TMCB_RESPONSE_IN][0x7f768b6dc840][0x7f76d096dee8]
// reply route execution
0(4603) ERROR: <core> [core/sip_msg_clone.c:504]: sip_msg_shm_clone(): sip_msg_shm_clone[0x7f768b6dc840]>>[0x7f768b6de738]
0(4603) NOTICE: acc [acc_logic.c:686]: tmcb_func(): acc callback called for t(0x7f768b6dac08) event type 128, reply code 404 reqmsg[0x7f768b6de738] rplmsg[0x7f76d096dee8]
0(4603) ERROR: acc [acc_logic.c:694]: tmcb_func(): [TMCB_ON_FAILURE] run on_missed [0x7f768b6de738][0x7f76d096dee8] // working with the cloned message
0(4603) ERROR: <core> [core/flags.c:59]: isflagset(): isflagset[0x7f768b6de738]
0(4603) ERROR: acc_json [acc_json_mod.c:189]: acc_json_send_request(): missed call flag [7] for this transaction [on]
// failure route execution, we are working with the cloned message
0(4603) NOTICE: <script>: [FAILURE]
0(4603) ERROR: <core> [core/flags.c:46]: setflag(): setflag[0x7f768b6de738]
// failure
0(4603) NOTICE: acc [acc_logic.c:686]: tmcb_func(): acc callback called for t(0x7f768b6dac08) event type 512, reply code 404 reqmsg[0x7f768b6dc840] rplmsg[0x7f76d096dee8]
0(4603) ERROR: acc [acc_logic.c:689]: tmcb_func(): [TMCB_RESPONSE_OUT][0x7f768b6dc840][0x7f76d096dee8] // working with the original message
0(4603) ERROR: <core> [core/flags.c:59]: isflagset(): isflagset[0x7f768b6dc840]
0(4603) ERROR: acc_json [acc_json_mod.c:189]: acc_json_send_request(): missed call flag [7] for this transaction [on]
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1673
on missed / failed calls issue #1673
#### Pre-Submission Checklist
<!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply -->
<!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above-->
<!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list -->
- [x] Commit message has the format required by CONTRIBUTING guide
- [x] Commits are split per component (core, individual modules, libs, utils, ...)
- [x] Each component has a single commit (if not, squash them into one commit)
- [x] No commits to README files for modules (changes must be done to docbook files
in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change
- [x] Small bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds new functionality)
- [x] Breaking change (not tested with all scenarios, review could confirm that this is not introducing regressions)
#### Checklist:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that apply -->
- [ ] PR should be backported to stable branches
- [x] Tested changes locally
- [x] Related to issue #1673
#### Description
problem with confusion when using flags (integer value vs bit position value)
proposed solution is using the flags helpers functions `isflagset`, etc. where possible.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/1674
-- Commit Summary --
* acc: generating duplicates
-- File Changes --
M src/modules/acc/acc.c (8)
M src/modules/acc/acc_logic.c (5)
M src/modules/acc_diameter/acc_diameter_mod.c (4)
M src/modules/acc_json/acc_json_mod.c (4)
M src/modules/acc_radius/acc_radius_mod.c (4)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/1674.patchhttps://github.com/kamailio/kamailio/pull/1674.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/1674