sr-users August 2013

sr-users@lists.kamailio.org

93 participants
177 discussions

CDR generation in Kamailio.
by Nandini madhu 12 Aug '13

12 Aug '13

Dear All, I am working on Kamailio (4.0.1) server with GUI package Siremis (4.0) of it. I was successful in get through Calls and SMS features in our VoIP phones using this kamailio sever. But i am encountering some issues related to CDR data generation into mysql database. I have activated WITH_ACCDB in kamailio cfg file. Siremis is configured to kamailio DB properly as i am getting accounting list in the siremis GUI well, but only the CDR data is not getting reflecting in GUI. But this CDR data is successfully logging into syslog (see the paragraph below), but my requirement is to get the CDR data to be reflect in my GUI. Here below is the CDR data that logged into syslog: Aug 3 17:36:25 kamailio /usr/local/sbin/kamailio[12391]: INFO: acc [acc.c:275]: acc_log_request(): ACC: transaction answered: timestamp=1375531585;method=INVITE;from_tag=170287292812;to_tag=373699520912;call_id= 6595ee13-bfec-15a7-ae-4b-00210705d550(a)192.168.2.99;code=200;reason=OK;src=;dst= Aug 3 17:36:25 kamailio /usr/local/sbin/kamailio[12393]: INFO: acc [acc.c:275]: acc_log_request(): ACC: request acknowledged: timestamp=1375531585;method=ACK;from_tag=170287292812;to_tag=373699520912;call_id= 6595ee13-bfec-15a7-ae-4b-00210705d550(a)192.168.2.99;code=200;reason=OK;src=;dst= Aug 3 17:36:29 kamailio /usr/local/sbin/kamailio[12391]: INFO: acc [acc_cdr.c:192]: write_cdr(): st=1375531585.654; et=1375531588.863; duration=3.209; src_user=102; src_domain=192.168.2.41; src_ip=192.168.2.99; dst_ouser=101; dst_user=101; dst_domain=192.168.2.77 And my kamailio.cfg script relating to CDR's is like this: /* enhanced DB accounting */ #!ifdef WITH_ACCDB modparam("acc", "db_flag", FLT_ACCDB) /* FLT_ACCDB is 2 */ modparam("acc", "db_missed_flag", FLT_ACCMISSED) /* FLT_ACCMISSED is 3 */ modparam("acc", "db_url", mysql://kamailio:kamailiorw@kamailio/kamailio) #modparam("acc", "db_extra","src_user=$fU;src_domain=$fd;src_ip=$si;""dst_ouser=$tU;dst_user= $rU;dst_domain=$rd;""duration=$DLG_lifetime") #modparam("acc", "db_extra","${cdr_extra}") modparam("acc", "db_extra","src_user=$fU;src_domain=$fd;src_ip=$si;""dst_ouser=$tU;dst_user= $rU;dst_domain=$rd") modparam("acc", "db_table_acc", "acc") #modparam("acc", "db_table_acc", "acc_$time(year)_$time(mon)") modparam("acc", "db_table_missed_calls", "missed_calls") modparam("acc", "acc_method_column", "method") modparam("acc", "acc_from_tag_column", "from_tag") modparam("acc", "acc_to_tag_column", "to_tag") modparam("acc", "acc_callid_column", "callid") modparam("acc", "acc_sip_code_column", "sip_code") modparam("acc", "acc_sip_reason_column", "sip_reason") modparam("acc", "acc_time_column", "time") modparam("acc", "db_insert_mode", 0) #!endif # -------- for siremis CDRs ----------- modparam("acc", "cdr_enable", 1) modparam("acc", "cdr_start_on_confirmed", 1) modparam("acc", "cdr_facility", "LOG_DAEMON") #modparam("acc", "cdr_extra", "c1=$dlg_var(caller);c2=$dlg_var(callee)") modparam("acc", "cdr_extra", "src_user=$fU;src_domain=$fd;src_ip=$si;""dst_ouser=$tU;dst_user=$rU;dst_domain=$rd") modparam("acc", "cdr_start_id", "st") modparam("acc", "cdr_end_id", "et") modparam("acc", "cdr_duration_id", "duration") . modparam("rtimer", "timer", "name=cdr;interval=300;mode=1;") modparam("rtimer", "exec", "timer=cdr;route=2") modparam("sqlops", "sqlcon", "ca=>mysql://kamailio:kamailiorw@localhost/kamailio") modparam("sqlops", "sqlres", "ra") . . # Populate CDRs Table of Siremis route[2] { sql_query("ca","call kamailio_cdrs()","ra"); } Can u guess where i am wrong ? how can i solve this issue ? And for your notice, in acc module document it is said like this: 'Note that CDR generation does not involve any kind of database storage (yet). In order to persist the CDRs into a database you will have to set up an exterior process (i.e., a script living outside of Kamailio) and implement the storage task yourself'. What does it mean ? of course 'cdrs' table in kamailio database is empty. Any help will greatly appreciate. Regards, Nandini.

2 1

error in tm.so after REGISTER
by Nguyen Anh Tuan 12 Aug '13

12 Aug '13

Dear all, Kamailio was crashed and I got syslog file, but I don't understand what was happened with this error? Aug 9 16:27:33 Kamailio /usr/sbin/kamailio[32414]: WARNING: tm [t_lookup.c:1559]: WARNING: script writer didn't release transaction Aug 9 16:27:33 Kamailio /usr/sbin/kamailio[32418]: NOTICE: <script>: Set NAT Transaction Flag REGISTER from sip:1008@10.84.8.55 (IP:203.160.19.30:58493) to sip:1008@10.84.8.55 in route[NATDETECT] Aug 9 16:27:33 Kamailio /usr/sbin/kamailio[32418]: INFO: <script>: Unregister user [sip:1008@10.84.8.55] Aug 9 16:27:33 Kamailio /usr/sbin/kamailio[32404]: INFO: <script>: Unregister user [sip:1008@10.84.8.55] Aug 9 16:27:34 Kamailio /usr/sbin/kamailio[32403]: NOTICE: <script>: Set NAT Transaction Flag REGISTER from sip:1004@10.84.8.55 (IP:203.187.4.6:12344) to sip:1004@10.84.8.55 in route[NATDETECT] Aug 9 16:27:34 Kamailio /usr/sbin/kamailio[32403]: INFO: <script>: Unregister user [sip:1004@10.84.8.55] Aug 9 16:27:34 Kamailio /usr/sbin/kamailio[32392]: NOTICE: <script>: Set NAT Transaction Flag REGISTER from sip:1004@10.84.8.55 (IP:203.187.4.6:12344) to sip:1004@10.84.8.55 in route[NATDETECT] Aug 9 16:27:35 Kamailio /usr/sbin/kamailio[32419]: NOTICE: <script>: Set NAT Transaction Flag REGISTER from sip:1008@10.84.8.55 (IP:203.160.19.30:58493) to sip:1008@10.84.8.55 in route[NATDETECT] Aug 9 16:27:35 Kamailio /usr/sbin/kamailio[32390]: NOTICE: <script>: Set NAT Transaction Flag REGISTER from sip:1004@10.84.8.55 (IP:203.187.4.6:12344) to sip:1004@10.84.8.55 in route[NATDETECT] Aug 9 16:27:35 Kamailio kernel: [75478.500981] kamailio[32395] general protection ip:7f9fbd41089d sp:7fffde4e5620 error:0 in tm.so[7f9fbd3d5000+8e000] Aug 9 16:27:35 Kamailio /usr/sbin/kamailio[32406]: NOTICE: <script>: Set NAT Transaction Flag REGISTER from sip:1004@10.84.8.55 (IP:203.187.4.6:17209) to sip:1004@10.84.8.55 in route[NATDETECT] Aug 9 16:27:35 Kamailio /usr/sbin/kamailio[32446]: : <core> [pass_fd.c:293]: ERROR: receive_fd: EOF on 19 Aug 9 16:27:35 Kamailio /usr/sbin/kamailio[32387]: ALERT: <core> [main.c:788]: child process 32395 exited by a signal 11 Aug 9 16:27:35 Kamailio /usr/sbin/kamailio[32387]: ALERT: <core> [main.c:791]: core was generated Aug 9 16:27:35 Kamailio /usr/sbin/kamailio[32446]: : <core> [pass_fd.c:293]: ERROR: receive_fd: EOF on 19 Aug 9 16:27:35 Kamailio /usr/sbin/kamailio[32387]: ALERT: <core> [main.c:788]: child process 32395 exited by a signal 11 Aug 9 16:27:35 Kamailio /usr/sbin/kamailio[32387]: ALERT: <core> [main.c:791]: core was generated Aug 9 16:27:35 Kamailio /usr/sbin/kamailio[32387]: INFO: <core> [main.c:803]: INFO: terminating due to SIGCHLD Aug 9 16:27:35 Kamailio kernel: [75478.963781] kamailio[32387] general protection ip:7f9fbd3ede22 sp:7fffde4e5c90 error:0 in tm.so[7f9fbd3d5000+8e000] Best Regards, Nguyen Anh Tuan Network solution engineer

2 1

releasing v3.3.5
by Daniel-Constantin Mierla 12 Aug '13

12 Aug '13

Hello, I am considering to package soon a new version out of branch 3.3. If anyone has spotted fixes that should be backported to that branch, reply here. I'm not sure yet of an exact date, but should be rather soon, being just a patch update. A new release out of branch 4.0 will be done short after this one. Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

2 4

Profile sharing using xcap
by Premchandiran 12 Aug '13

12 Aug '13

Hi All, I am looking for softphone which supports profile-sharing using xcap. Please let me know if there is any softphone available. Regards, Prem Chandiran M

1 0

Generate UUID in Kamailio Script
by Grant Bagdasarian 09 Aug '13

09 Aug '13

Hello, Is it possible to generate a UUID inside the kamailio script? Is there a module available which does this already or do I need to call something external from the script? Regards, Grant

3 8

Trouble when bridging call between UDP and TCP clients behind NAT
by Roberto Fichera 09 Aug '13

09 Aug '13

Hi All, I'm try to setup kamilio v4.0.2 under a Fedora18 64bits having a public address in order to bridge calls between UDP and TCP clients. Everything works pretty fine between UDP clients even if behind NAT. But as soon as one TCP client is being called I'm getting this below on kamailio side. Note that the port is wrong and the TCP client doesn't get aliased nor tcp port remappend or received field is set: Call-ID: 23306738-94b3-49b5-b7e8-dc1b8a8061db CSeq: 50696 REGISTER User-Agent: PJSUA v2.1-svn Linux-3.10.5.44/x86_64/glibc-2.17 Supported: outbound, path Contact: <sip:528@94.94.X.X:1117;transport=TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000be3c954f>" Expires: 300 Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Content-Length: 0 SIP/2.0 401 Unauthorized Via: SIP/2.0/TCP 94.94.X.X:56120;rport=56120;branch=z9hG4bKPj75004c2a-7ba3-4807-805c-a3ac8016e5b7;alias From: <sip:528@test.domain;hide>;tag=93cc1d8e-9ccc-4d36-8587-923ff44daf89 To: <sip:528@test.domain;hide>;tag=333a0370df4a40d5d5a0c21bb156e2a6.aab2 Call-ID: 23306738-94b3-49b5-b7e8-dc1b8a8061db CSeq: 50696 REGISTER WWW-Authenticate: Digest realm="test.domain", nonce="UgOcJlIDmvotaQR8dxYacL2fFlyotlC2" Server: kamailio (4.0.2 (x86_64/linux)) Content-Length: 0 REGISTER sip:test.domain;transport=tcp;hide SIP/2.0 Via: SIP/2.0/TCP 94.94.X.X:56120;rport;branch=z9hG4bKPja2e404d0-9812-4b7b-b86b-3f3b1a27d204;alias Max-Forwards: 70 From: <sip:528@test.domain;hide>;tag=93cc1d8e-9ccc-4d36-8587-923ff44daf89 To: <sip:528@test.domain;hide> Call-ID: 23306738-94b3-49b5-b7e8-dc1b8a8061db CSeq: 50697 REGISTER User-Agent: PJSUA v2.1-svn Linux-3.10.5.44/x86_64/glibc-2.17 Supported: outbound, path Contact: <sip:528@94.94.X.X:1117;transport=TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000be3c954f>" Expires: 300 Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Authorization: Digest username="528(a)test.domain", realm="test.domain", nonce="UgOcJlIDmvotaQR8dxYacL2fFlyotlC2", uri="sip:test.domain;transport=tcp;hide", response="d6e93d582744a3cf12cc48989f66872e" Content-Length: 0 SIP/2.0 200 OK Via: SIP/2.0/TCP 94.94.X.X:56120;rport=56120;branch=z9hG4bKPja2e404d0-9812-4b7b-b86b-3f3b1a27d204;alias From: <sip:528@test.domain;hide>;tag=93cc1d8e-9ccc-4d36-8587-923ff44daf89 To: <sip:528@test.domain;hide>;tag=333a0370df4a40d5d5a0c21bb156e2a6.d863 Call-ID: 23306738-94b3-49b5-b7e8-dc1b8a8061db CSeq: 50697 REGISTER Contact: <sip:528@94.94.X.X:1117;transport=TCP;ob>;expires=300;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000be3c954f>";reg-id=1 Server: kamailio (4.0.2 (x86_64/linux)) Content-Length: 0 Thus, kamailio trigger this error: Aug 9 09:20:47 proxy /usr/sbin/kamailio[3553]: ERROR: <core> [tcp_main.c:4247]: handle_tcpconn_ev(): connect 94.94.X.X:1117 failed >From the client side (pjsua client) the log looks: REGISTER sip:test.domain;transport=tcp;hide SIP/2.0 Via: SIP/2.0/TCP 192.168.2.90:56120;rport;branch=z9hG4bKPj75004c2a-7ba3-4807-805c-a3ac8016e5b7;alias Max-Forwards: 70 From: <sip:528@test.domain;hide>;tag=93cc1d8e-9ccc-4d36-8587-923ff44daf89 To: <sip:528@test.domain;hide> Call-ID: 23306738-94b3-49b5-b7e8-dc1b8a8061db CSeq: 50696 REGISTER User-Agent: PJSUA v2.1-svn Linux-3.10.5.44/x86_64/glibc-2.17 Supported: outbound, path Contact: <sip:528@192.168.2.90:5060;transport=TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000be3c954f>" Expires: 300 Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Content-Length: 0 --end msg-- SIP/2.0 401 Unauthorized Via: SIP/2.0/TCP 192.168.2.90:56120;rport=56120;branch=z9hG4bKPj75004c2a-7ba3-4807-805c-a3ac8016e5b7;alias From: <sip:528@test.domain;hide>;tag=93cc1d8e-9ccc-4d36-8587-923ff44daf89 To: <sip:528@test.domain;hide>;tag=333a0370df4a40d5d5a0c21bb156e2a6.aab2 Call-ID: 23306738-94b3-49b5-b7e8-dc1b8a8061db CSeq: 50696 REGISTER WWW-Authenticate: Digest realm="test.domain", nonce="UgOcJlIDmvotaQR8dxYacL2fFlyotlC2" Server: kamailio (4.0.2 (x86_64/linux)) Content-Length: 0 --end msg-- REGISTER sip:test.domain;transport=tcp;hide SIP/2.0 Via: SIP/2.0/TCP 192.168.2.90:56120;rport;branch=z9hG4bKPja2e404d0-9812-4b7b-b86b-3f3b1a27d204;alias Max-Forwards: 70 From: <sip:528@test.domain;hide>;tag=93cc1d8e-9ccc-4d36-8587-923ff44daf89 To: <sip:528@test.domain;hide> Call-ID: 23306738-94b3-49b5-b7e8-dc1b8a8061db CSeq: 50697 REGISTER User-Agent: PJSUA v2.1-svn Linux-3.10.5.44/x86_64/glibc-2.17 Supported: outbound, path Contact: <sip:528@192.168.2.90:5060;transport=TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000be3c954f>" Expires: 300 Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Authorization: Digest username="528(a)test.domain", realm="test.domain", nonce="UgOcJlIDmvotaQR8dxYacL2fFlyotlC2", uri="sip:test.domain;transport=tcp;hide", response="d6e93d582744a3cf12cc48989f66872e" Content-Length: 0 --end msg-- SIP/2.0 200 OK Via: SIP/2.0/TCP 192.168.2.90:56120;rport=56120;branch=z9hG4bKPja2e404d0-9812-4b7b-b86b-3f3b1a27d204;alias From: <sip:528@test.domain;hide>;tag=93cc1d8e-9ccc-4d36-8587-923ff44daf89 To: <sip:528@test.domain;hide>;tag=333a0370df4a40d5d5a0c21bb156e2a6.d863 Call-ID: 23306738-94b3-49b5-b7e8-dc1b8a8061db CSeq: 50697 REGISTER Contact: <sip:528@192.168.2.90:5060;transport=TCP;ob>;expires=300;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000be3c954f>";reg-id=1 Server: kamailio (4.0.2 (x86_64/linux)) Content-Length: 0 --end msg-- REGISTER sip:test.domain;transport=tcp;hide SIP/2.0 Via: SIP/2.0/TCP 192.168.2.90:56120;rport;branch=z9hG4bKPj3f8c138b-df5e-40a1-8482-fa792c362291;alias Max-Forwards: 70 From: <sip:528@test.domain;hide>;tag=2256e1a1-bad1-4f02-a9ff-45ff349f2c52 To: <sip:528@test.domain;hide> Call-ID: 23306738-94b3-49b5-b7e8-dc1b8a8061db CSeq: 50698 REGISTER User-Agent: PJSUA v2.1-svn Linux-3.10.5.44/x86_64/glibc-2.17 Supported: outbound, path Contact: <sip:528@192.168.2.90:5060;transport=TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000be3c954f>" Expires: 300 Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Content-Length: 0 --end msg-- SIP/2.0 401 Unauthorized Via: SIP/2.0/TCP 192.168.2.90:56120;rport=56120;branch=z9hG4bKPj3f8c138b-df5e-40a1-8482-fa792c362291;alias From: <sip:528@test.domain;hide>;tag=2256e1a1-bad1-4f02-a9ff-45ff349f2c52 To: <sip:528@test.domain;hide>;tag=333a0370df4a40d5d5a0c21bb156e2a6.15dd Call-ID: 23306738-94b3-49b5-b7e8-dc1b8a8061db CSeq: 50698 REGISTER WWW-Authenticate: Digest realm="test.domain", nonce="UgOdTVIDnCHViWa5LC/JUVsF0HRn4wA5" Server: kamailio (4.0.2 (x86_64/linux)) Content-Length: 0 --end msg-- REGISTER sip:test.domain;transport=tcp;hide SIP/2.0 Via: SIP/2.0/TCP 192.168.2.90:56120;rport;branch=z9hG4bKPj9539d611-09a9-4cac-bd29-bfe68132c058;alias Max-Forwards: 70 From: <sip:528@test.domain;hide>;tag=2256e1a1-bad1-4f02-a9ff-45ff349f2c52 To: <sip:528@test.domain;hide> Call-ID: 23306738-94b3-49b5-b7e8-dc1b8a8061db CSeq: 50699 REGISTER User-Agent: PJSUA v2.1-svn Linux-3.10.5.44/x86_64/glibc-2.17 Supported: outbound, path Contact: <sip:528@192.168.2.90:5060;transport=TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000be3c954f>" Expires: 300 Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Authorization: Digest username="528(a)test.domain", realm="test.domain", nonce="UgOdTVIDnCHViWa5LC/JUVsF0HRn4wA5", uri="sip:test.domain;transport=tcp;hide", response="3d2ed2fc1da090f592424cfa5804943e" Content-Length: 0 --end msg-- SIP/2.0 200 OK Via: SIP/2.0/TCP 192.168.2.90:56120;rport=56120;branch=z9hG4bKPj9539d611-09a9-4cac-bd29-bfe68132c058;alias From: <sip:528@test.domain;hide>;tag=2256e1a1-bad1-4f02-a9ff-45ff349f2c52 To: <sip:528@test.domain;hide>;tag=333a0370df4a40d5d5a0c21bb156e2a6.cf79 Call-ID: 23306738-94b3-49b5-b7e8-dc1b8a8061db CSeq: 50699 REGISTER Contact: <sip:528@192.168.2.90:5060;transport=TCP;ob>;expires=300;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000be3c954f>";reg-id=1 Server: kamailio (4.0.2 (x86_64/linux)) Content-Length: 0 Does anyone can show me how solve this problem? Thanks in advance, Roberto Fichera.

2 2

Kamailio+RTProxy failover active calls
by Ivan Baques Garcia 08 Aug '13

08 Aug '13

Hi, Is possible to failover active calls between different RTPProxys with Kamailio without dropping active calls and not loosing audio? Best regards,

2 1

Kamailio RTProxy failover active calls
by Ivan Baques Garcia 08 Aug '13

08 Aug '13

Hi, Is possible to failover active calls between different RTPProxy with Kamailio without dropping active calls and not loosing audio? Best regards,

3 2

rtpproxy patch for XMLRPC notifications
by Juha Heinanen 07 Aug '13

07 Aug '13

Carsten Bock wrote: currently mediaproxy-ng only does timeout notifications only towards a SEMS-SBC, not towards Kamailio. :-( what role does mediaproxy-ng play in sems sbc installation? is mediaproxy-ng used because sems does not support RTP/SAVPF or are there some other use cases as well? -- juha

2 1

(Kamailio/RTPproyx) Public -> LAN -> Asterisk (1, 2, .., n)
by Alexandr Usov 07 Aug '13

07 Aug '13

I have Kamailio on OpenSUSE with static real Public IP (WAN), for ex. 1.1.1.1. I have LAN IP 2.2.2.2. Asterisk as KVM virtual machine with LAN IP 2.2.2.101 and default GW not the SuSe (2.2.2.2), but 2.2.2.1 pfsense LAN with PUB IP 1.1.1.2) I am configured Registration of UA on Kamailio DB, and on Asterisk side create a static peers with Kamailio LAN ip (host=2.2.2.2). RTP Proxy question. /usr/sbin/rtpproxy -u daemon -l 1.1.1.1 -s udp:127.0.0.1 12221 .... kamailio.cfg ... # RTPProxy control route[NATMANAGE] { #!ifdef WITH_NAT if (is_request()) { if(has_totag()) { if(check_route_param("nat=yes")) { setbflag(FLB_NATB); } } } if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) return; rtpproxy_manage(); if (is_request()) { if (!has_totag()) { add_rr_param(";nat=yes"); } } if (is_reply()) { if(isbflagset(FLB_NATB)) { fix_nated_contact(); } } #!endif return; } Testing call: Whe User 1-100 calling User 1-101, on Asterisk side I see: -- Called SIP/1-100(a)sip1.somedomain.com.ua -- SIP/sip1.somedomain.com.ua-000004cf is ringing -- SIP/sip1.somedomain.com.ua-000004cf answered SIP/1-101-000004ce > 0x15bc370 -- Probation passed - setting RTP source address to 1.1.1.1:50868 > 0x7f2b6044bd10 -- Probation passed - setting RTP source address to 1.1.1.1:35082 Got RTP packet from 1.1.1.1:50868 (type 00, seq 027109, ts 000160, len 000160) Sent RTP packet to 1.1.1.1:35082 (type 00, seq 037469, ts 000160, len 000160) Got RTP packet from 1.1.1.1:50868 (type 00, seq 027110, ts 000320, len 000160) Sent RTP packet to 1.1.1.1:35082 (type 00, seq 037470, ts 000320, len 000160) Got RTP packet from 1.1.1.1:50868 (type 00, seq 027111, ts 000480, len 000160) Sent RTP packet to 1.1.1.1:35082 (type 00, seq 037471, ts 000480, len 000160) Got RTP packet from 1.1.1.1:50868 (type 00, seq 027112, ts 000640, len 000160) Sent RTP packet to 1.1.1.1:35082 (type 00, seq 037472, ts 000640, len 000160) Voice transfers OK. But why not Kamailio LAN ip I receiving on the Asterisk side with the same LAN? And Kamailio log grep: skynet:~ # tail -f /var/log/messages | grep rtpproxy 2013-08-05T19:18:17.508760+03:00 skynet kamailio[25462]: 3(25481) DEBUG: rtpproxy [rtpproxy_funcs.c:148]: check_content_type(): type <application/sdp> found valid 2013-08-05T19:18:17.508875+03:00 skynet kamailio[25462]: 3(25481) DEBUG: rtpproxy [rtpproxy.c:2624]: force_rtp_proxy(): proxy reply: 63566 1.1.1.1 2013-08-05T19:18:17.530765+03:00 skynet kamailio[25462]: 6(25484) DEBUG: rtpproxy [rtpproxy_funcs.c:148]: check_content_type(): type <application/sdp> found valid 2013-08-05T19:18:17.530876+03:00 skynet kamailio[25462]: 6(25484) DEBUG: rtpproxy [rtpproxy.c:2624]: force_rtp_proxy(): proxy reply: 41958 1.1.1.1 2013-08-05T19:18:18.625815+03:00 skynet kamailio[25462]: 4(25482) DEBUG: rtpproxy [rtpproxy_funcs.c:148]: check_content_type(): type <application/sdp> found valid 2013-08-05T19:18:18.627131+03:00 skynet kamailio[25462]: 4(25482) DEBUG: rtpproxy [rtpproxy.c:2624]: force_rtp_proxy(): proxy reply: 39876 1.1.1.1 2013-08-05T19:18:18.632649+03:00 skynet kamailio[25462]: a=nortpproxy:yes 2013-08-05T19:18:18.648075+03:00 skynet kamailio[25462]: 6(25484) DEBUG: rtpproxy [rtpproxy_funcs.c:148]: check_content_type(): type <application/sdp> found valid 2013-08-05T19:18:18.649615+03:00 skynet kamailio[25462]: 6(25484) DEBUG: rtpproxy [rtpproxy.c:2624]: force_rtp_proxy(): proxy reply: 43500 1.1.1.1 2013-08-05T19:18:18.653948+03:00 skynet kamailio[25462]: a=nortpproxy:yes 2013-08-05T19:18:18.688603+03:00 skynet kamailio[25462]: 4(25482) DEBUG: rtpproxy [rtpproxy_funcs.c:148]: check_content_type(): type <application/sdp> found valid 2013-08-05T19:18:18.689762+03:00 skynet kamailio[25462]: 4(25482) DEBUG: rtpproxy [rtpproxy.c:2624]: force_rtp_proxy(): proxy reply: 63566 1.1.1.1 2013-08-05T19:18:18.701062+03:00 skynet kamailio[25462]: 6(25484) DEBUG: rtpproxy [rtpproxy_funcs.c:148]: check_content_type(): type <application/sdp> found valid 2013-08-05T19:18:18.701405+03:00 skynet kamailio[25462]: 6(25484) DEBUG: rtpproxy [rtpproxy.c:2624]: force_rtp_proxy(): proxy reply: 43500 1.1.1.1 2013-08-05T19:18:18.705506+03:00 skynet kamailio[25462]: a=nortpproxy:yes My goal is using Asterisk boxes behind Kamailio with the same LAN or even OpeVPN Lan2Lan, with Public IP on Kamailio WAN for users registration and RTP routing. So is strange to my, why RTPproxy not rewrite source of RTP traffic from PUBLIC Kamailio IP to LAN Kamailio IP when user A calls B via Asterisk?

3 19

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users August 2013