sr-users August 2013

sr-users@lists.kamailio.org

93 participants
176 discussions

by Nguyen Anh Tuan

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

10 years, 11 months

releasing v3.3.5

by Daniel-Constantin Mierla

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

10 years, 11 months

Profile sharing using xcap

by Premchandiran

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

10 years, 11 months

Generate UUID in Kamailio Script

by Grant Bagdasarian

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

10 years, 11 months

Trouble when bridging call between UDP and TCP clients behind NAT

by Roberto Fichera

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.

10 years, 11 months

Kamailio+RTProxy failover active calls

by Ivan Baques Garcia

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

10 years, 11 months

Kamailio RTProxy failover active calls

by Ivan Baques Garcia

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

10 years, 11 months

rtpproxy patch for XMLRPC notifications

by Juha Heinanen

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

10 years, 11 months

(Kamailio/RTPproyx) Public -> LAN -> Asterisk (1, 2, .., n)

by Alexandr Usov

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?

10 years, 11 months

Workings of the kamailio dispatcher module

by Grant Bagdasarian

Hello, Consider the following Kamailio script: route { .... route(DISPATCH); route(RELAY); } route[DISPATCH] { ds_select_domain("1", "8"); return; } Dispatcher Table SetID Destination 1 192.168.1.10 1 192.168.1.11 Algorithm 8 uses the first destination, but if it's not available, it uses the next one. Does the ds_select_domain function send the SIP request to the first destination or is it the responsibility of the RELAY route to do this? I believe it's the latter, according to the documentation. Assuming the above (message is relayed in the RELAY route). When Kamailio can't reach the first destination, how does it internally handle the failover? Because once the SIP request has been relayed to the host, the script doesn't have any instructions anymore.

10 years, 11 months

Jump to page:

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