Hi Daniel,
This is a sketch of how I would force the execution of the acc/cdr dialog callbacks for dialogues created from the database. This solution needs more testing and I don't expect it to be accepted as is.
I think that the run_create_callbacks was omitted because at a later step, the callbacks would need to access the initial request (params->req) that originated the dialog. Looking in the generated CDRs one can also spot that certain values are left blank most probably because of the params->req message is missing.
How would you solve this problem? Is there a way to populate/ mock the request with values inside the dialog_vars table? Would you add all variables of interest inside that table or inside the dialog table?
Thank you,
Lucian
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/1036
-- Commit Summary --
* Fix for no cdr after Kamailio 5.0 restart
-- File Changes --
M src/modules/acc/acc_cdr.c (8)
M src/modules/dialog/dlg_db_handler.c (11)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/1036.patchhttps://github.com/kamailio/kamailio/pull/1036.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/1036
Hello guys!
I need to connect a SIP server to a GSM operator MSC so that users can call a short number on their phones and access an IVR.
My SIP server does not talk SIP-T (isup embedded on sip) but the MSC requires SIP-T
Is it possible to create a kamailio configuration file that translates SIP to SIP-T back and forth so that I can have that SIP-T support?
Regards,
Martin
### Description
We are running a Kamailio on a mirror port for capturing traffic. This works as long as the packets are not fragmented. If they are fragmented, the packet is not seen inside Kamailio.
On the regular SIP servers, those fragmented packets are successfully reassembled and processed.
I guess this is an issue for @adubovikov.
#### Reproduction
Setup a Kamailio with sipcapture in mirror mode. These are the config parameters we use:
```
modparam("sipcapture", "capture_on", 1)
modparam("sipcapture", "raw_moni_capture_on", 1)
modparam("sipcapture", "raw_socket_listen", "10.0.0.1:5060")
modparam("sipcapture", "raw_interface", "eth1")
modparam("sipcapture", "raw_sock_children", 6)
modparam("sipcapture", "promiscious_on", 1)
modparam("sipcapture", "raw_moni_bpf_on", 1)
modparam("sipcapture", "db_url", "mysql://root:XXXXX@127.0.0.1/sipcapture")
```
And this is what our route says:
```
request_route {
if ($sp == 5060 || $Rp == 5060) {
xlog("L_INFO", "Request received from $si:$sp to $Ri:$Rp :\n$mb\n");
exit;
}
}
```
Now if you craft really big INVITEs (e.g. with a snom phone turning on encryption and long SDP and stuff), the first INVITE without Auth will still show up because it is below 1500 bytes, the second one will exceed 1500 bytes and won't appear in Kamailio.
#### Debugging Data
In tcpdump I can see the the missing packet:
```
17:07:33.568718 IP 82.116.x.y.11223 > 217.10.79.9.5060: SIP: INVITE sip:0163xxxxxxx@sipgate.de;user=phone SIP/2.0
17:07:33.572659 IP 217.10.79.9.5060 > 82.116.x.y.11223: SIP: SIP/2.0 407 Proxy Authentication Required
17:07:33.951787 IP 82.116.x.y.11223 > 217.10.79.9.5060: SIP: ACK sip:0163xxxxxxx@sipgate.de;user=phone SIP/2.0
17:07:33.980561 IP 82.116.x.y.11223 > 217.10.79.9.5060: SIP: INVITE sip:0163xxxxxxx@sipgate.de;user=phone SIP/2.0
17:07:33.980566 IP 82.116.x.y > 217.10.79.9: ip-proto-17
17:07:33.995269 IP 217.10.79.9.5060 > 82.116.x.y.11223: SIP: SIP/2.0 100 trying -- your call is important to us
```
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.0.0 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled with gcc 4.9.2
```
* **Operating System**:
```
Linux hostname 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07) x86_64 GNU/Linux
```
--
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/1049