sr-users September 2012

sr-users@lists.kamailio.org

78 participants
139 discussions

Re: [SR-Users] RTPProxy with kamailio : How to get calls count?
by Alex Balashov 13 Sep '12

13 Sep '12

You can't get it from rtpproxy. You'd really have to use something like the dialog or htable modules to keep call state and get that from Kamailio. -- Alex -- Sent from my Samsung mobile, and thus lacking in the refinement one might expect from a proper keyboard. Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Web: http://www.evaristesys.com/Mino Haluz <mino.haluz(a)gmail.com> wrote:Hi, I'm doing the performance test with kamailio + RTPProxy, but I would like to get the real calls count that the rtpproxy is serving. I don't want to use value that I get from sipp. So is there any management tool for rtpproxy, or should I get it somewhere in kamailio config ? Thanks, Mino _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

2 1

RTPProxy with kamailio : How to get calls count?
by Mino Haluz 13 Sep '12

13 Sep '12

Hi, I'm doing the performance test with kamailio + RTPProxy, but I would like to get the real calls count that the rtpproxy is serving. I don't want to use value that I get from sipp. So is there any management tool for rtpproxy, or should I get it somewhere in kamailio config ? Thanks, Mino

1 0

script stops processing when relaying e2e ack?
by Andrew Mortensen 12 Sep '12

12 Sep '12

Hi all. I'm working on a custom module and would like to be able to send UPDATEs to the call legs after the script forwards the e2e ACK from the caller. I had hoped to export a function to call in my ACK handling route after the script forwards the ACK. However, the script stops processing after calling t_relay in my ACK handling route. I tracked this back to the fact that t_relay_to invokes forward_request when handling e2e ACKs, and returns the return code of forward_request to the script. Since forward_request returns 0 on success, the t_relay call in the script returns 0, which stops script processing. Is this intentional? My module currently hooks the TMCB_E2EACK_IN, and I can UPDATE the caller here, but the callee seems to be ignoring the UPDATE if it's received prior to the ACK. Thanks for any advice you can offer. andrew

1 0

Kamailio 3.2, NAT, rtpproxy bridging between interfaces
by Russell McConnachie 12 Sep '12

12 Sep '12

Hello, I'm having some issues getting media bridging working in kamailio and rtpproxy. I've attempted to attach as much relevant information as possible. Thanks in advance for taking a look; I'm completely stuck right now. Actual results:No audio is being passed through the rtpproxy from caller "A" to caller "B" even though both media server and UAC are sending media to the rtpproxy. Expected results:Audio that is sent to rtpproxy is bridged/proxied across from caller "A" to caller "B" and vice-versa. ------------------------------------------------------------------------------- Signaling trace: ------------------------------------------------------------------------------- 08:34:57.543224 IP (tos 0x0, ttl 49, id 3237, offset 0, flags [none], proto: UDP (17), length: 1456) x.x.x.199.31280 > x.x.x.102.sip: SIP, length: 1428 INVITE sip:9991@r18.test-bwks.local:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.2.250:51620;branch=z9hG4bK1158b9f850c008ff7.6835b1eb6e3bffee5 Route: <sip:x.x.x.102:5060;lr> Max-Forwards: 70 From: "99999999" <sip:99999999@r18.test-bwks.local:5060>;tag=1cf0b02fab To: "9991" <sip:9991@r18.test-bwks.local:5060> Call-ID: b2af8b83e20b0740 CSeq: 29663 INVITE Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK, SUBSCRIBE, INFO Allow-Events: talk, hold, conference, LocalModeStatus Contact: "99999999" <sip:99999999@192.168.2.250:51620;transport=udp;srcadr=192.168.2.250:5060>;+sip.instance="<urn:uuid:00000000-0000-1000-8000-00085D2DF3BB>" Supported: gruu, path, timer, 100rel, replaces User-Agent: Aastra 57i/2.6.0.1007 Content-Type: application/sdp Content-Length: 619 v=0 o=MxSIP 0 0 IN IP4 192.168.2.250 s=SIP Call c=IN IP4 192.168.2.250 t=0 0 m=audio 51720 RTP/AVP 0 18 106 107 113 110 111 112 98 97 115 96 9 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=rtpmap:106 BV16/8000 a=rtpmap:107 BV32/16000 a=rtpmap:113 L16/16000 a=rtpmap:110 PCMU/16000 a=rtpmap:111 PCMA/16000 a=rtpmap:112 L16/8000 a=rtpmap:98 G726-16/8000 a=rtpmap:97 G726-24/8000 a=rtpmap:115 G726-32/8000 a=rtpmap:96 G726-40/8000 a=rtpmap:9 G722/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=silenceSupp:on - - - - a=fmtp:18 annexb=yes a=fmtp:101 0-15 a=ptime:30 a=sendrecv 08:34:57.545766 IP (tos 0x10, ttl 64, id 58136, offset 0, flags [none], proto: UDP (17), length: 439) x.x.x.102.sip > x.x.x.199.31280: SIP, length: 411 SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 192.168.2.250:51620;branch=z9hG4bK1158b9f850c008ff7.6835b1eb6e3bffee5;rport=31280;received=x.x.x.199 From: "99999999" <sip:99999999@r18.test-bwks.local:5060>;tag=1cf0b02fab To: "9991" <sip:9991@r18.test-bwks.local:5060> Call-ID: b2af8b83e20b0740 CSeq: 29663 INVITE Server: kamailio (3.2.4 (x86_64/linux)) Content-Length: 0 08:34:57.547619 IP (tos 0x10, ttl 64, id 47936, offset 0, flags [+], proto: UDP (17), length: 1500) 10.0.0.38.sip > 10.0.0.29.sip: SIP, length: 1472 INVITE sip:9991@10.0.0.29 SIP/2.0 Record-Route: <sip:10.0.0.38;r2=on;lr=on;nat=yes> Record-Route: <sip:x.x.x.102;r2=on;lr=on;nat=yes> Via: SIP/2.0/UDP 10.0.0.38;branch=z9hG4bK4ed5.ec1e41a.0 Via: SIP/2.0/UDP 192.168.2.250:51620;rport=31280;received=x.x.x.199;branch=z9hG4bK1158b9f850c008ff7.6835b1eb6e3bffee5 Max-Forwards: 69 From: "99999999" <sip:99999999@r18.test-bwks.local:5060>;tag=1cf0b02fab To: "9991" <sip:9991@r18.test-bwks.local:5060> Call-ID: b2af8b83e20b0740 CSeq: 29663 INVITE Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK, SUBSCRIBE, INFO Allow-Events: talk, hold, conference, LocalModeStatus Contact: "99999999" <sip:99999999@x.x.x.199:31280;transport=udp;srcadr=192.168.2.250:5060>;+sip.instance="<urn:uuid:00000000-0000-1000-8000-00085D2DF3BB>" Supported: gruu, path, timer, 100rel, replaces User-Agent: Aastra 57i/2.6.0.1007 Content-Type: application/sdp Content-Length: 629 v=0 o=MxSIP 0 0 IN IP4 10.0.0.38 s=SIP Call c=IN IP4 10.0.0.38 t=0 0 m=audio 29682 RTP/AVP 0 18 106 107 113 110 111 112 98 97 115 96 9 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=rtpmap:106 BV16/8000 a=rtpmap:107 BV32/16000 a=rtpmap:113 L16/16000 a=rtpmap:110 PCMU/16000 a=rtpmap:111 PCMA/16000 a=rtpmap:112 L16/8000 a=rtpmap:98 G726-16/8000 a=rtpmap:97 G726-24/8000 a=rtpmap:115 G726-32/8000 a=rtpmap:96 G726-40/8000 a=rtpmap:9 G722/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event 08:34:57.551126 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 409) 10.0.0.29.55620 > 10.0.0.38.sip: SIP, length: 381 SIP/2.0 100 Trying Via:SIP/2.0/UDP 10.0.0.38;branch=z9hG4bK4ed5.ec1e41a.0,SIP/2.0/UDP 192.168.2.250:51620;received=x.x.x.199;branch=z9hG4bK1158b9f850c008ff7.6835b1eb6e3bffee5;rport=31280 From:"99999999"<sip:99999999@r18.test-bwks.local:5060>;tag=1cf0b02fab To:"9991"<sip:9991@r18.test-bwks.local:5060> Call-ID:b2af8b83e20b0740 CSeq:29663 INVITE Content-Length:0 08:34:57.561084 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 723) 10.0.0.29.55620 > 10.0.0.38.sip: SIP, length: 695 SIP/2.0 180 Ringing Via:SIP/2.0/UDP 10.0.0.38;branch=z9hG4bK4ed5.ec1e41a.0,SIP/2.0/UDP 192.168.2.250:51620;received=x.x.x.199;branch=z9hG4bK1158b9f850c008ff7.6835b1eb6e3bffee5;rport=31280 From:"99999999"<sip:99999999@r18.test-bwks.local:5060>;tag=1cf0b02fab To:"9991"<sip:9991@r18.test-bwks.local:5060>;tag=1693866893-1347366897367 Call-ID:b2af8b83e20b0740 CSeq:29663 INVITE Supported: Contact:<sip:10.0.0.29:5060> Record-Route:<sip:10.0.0.38;r2=on;lr=on;nat=yes>,<sip:x.x.x.102;r2=on;lr=on;nat=yes> P-Asserted-Identity:"Auto Attendant"<sip:9991@10.0.0.29;user=phone> Privacy:none Allow:ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE Content-Length:0 08:34:57.562404 IP (tos 0x10, ttl 64, id 58137, offset 0, flags [none], proto: UDP (17), length: 672) x.x.x.102.sip > x.x.x.199.31280: SIP, length: 644 SIP/2.0 180 Ringing Via:SIP/2.0/UDP 192.168.2.250:51620;received=x.x.x.199;branch=z9hG4bK1158b9f850c008ff7.6835b1eb6e3bffee5;rport=31280 From:"99999999"<sip:99999999@r18.test-bwks.local:5060>;tag=1cf0b02fab To:"9991"<sip:9991@r18.test-bwks.local:5060>;tag=1693866893-1347366897367 Call-ID:b2af8b83e20b0740 CSeq:29663 INVITE Supported: Contact:<sip:10.0.0.29:5060> Record-Route:<sip:10.0.0.38;r2=on;lr=on;nat=yes>,<sip:x.x.x.102;r2=on;lr=on;nat=yes> P-Asserted-Identity:"Auto Attendant"<sip:9991@10.0.0.29;user=phone> Privacy:none Allow:ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE Content-Length:0 08:34:57.609771 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 953) 10.0.0.29.55620 > 10.0.0.38.sip: SIP, length: 925 SIP/2.0 200 OK Via:SIP/2.0/UDP 10.0.0.38;branch=z9hG4bK4ed5.ec1e41a.0,SIP/2.0/UDP 192.168.2.250:51620;received=x.x.x.199;branch=z9hG4bK1158b9f850c008ff7.6835b1eb6e3bffee5;rport=31280 From:"99999999"<sip:99999999@r18.test-bwks.local:5060>;tag=1cf0b02fab To:"9991"<sip:9991@r18.test-bwks.local:5060>;tag=1693866893-1347366897367 Call-ID:b2af8b83e20b0740 CSeq:29663 INVITE Supported: Contact:<sip:10.0.0.29:5060> Record-Route:<sip:10.0.0.38;r2=on;lr=on;nat=yes>,<sip:x.x.x.102;r2=on;lr=on;nat=yes> P-Asserted-Identity:"Auto Attendant"<sip:9991@10.0.0.29;user=phone> Privacy:none Allow:ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE Accept:application/media_control+xml,application/sdp,multipart/mixed Content-Type:application/sdp Content-Length:133 v=0 o=BroadWorks 196 1 IN IP4 10.0.0.24 s=- c=IN IP4 10.0.0.24 t=0 0 m=audio 10498 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=ptime:20 08:34:57.612047 IP (tos 0x10, ttl 64, id 58138, offset 0, flags [none], proto: UDP (17), length: 930) x.x.x.102.sip > x.x.x.199.31280: SIP, length: 902 SIP/2.0 200 OK Via:SIP/2.0/UDP 192.168.2.250:51620;received=x.x.x.199;branch=z9hG4bK1158b9f850c008ff7.6835b1eb6e3bffee5;rport=31280 From:"99999999"<sip:99999999@r18.test-bwks.local:5060>;tag=1cf0b02fab To:"9991"<sip:9991@r18.test-bwks.local:5060>;tag=1693866893-1347366897367 Call-ID:b2af8b83e20b0740 CSeq:29663 INVITE Supported: Contact:<sip:10.0.0.29:5060> Record-Route:<sip:10.0.0.38;r2=on;lr=on;nat=yes>,<sip:x.x.x.102;r2=on;lr=on;nat=yes> P-Asserted-Identity:"Auto Attendant"<sip:9991@10.0.0.29;user=phone> Privacy:none Allow:ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE Accept:application/media_control+xml,application/sdp,multipart/mixed Content-Type:application/sdp Content-Length:161 v=0 o=BroadWorks 196 1 IN IP4 x.x.x.102 s=- c=IN IP4 x.x.x.102 t=0 0 m=audio 29774 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=ptime:20 a=sdpmangled:yes 08:34:57.844645 IP (tos 0x0, ttl 49, id 3239, offset 0, flags [none], proto: UDP (17), length: 506) x.x.x.199.31280 > x.x.x.102.sip: SIP, length: 478 ACK sip:10.0.0.29:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.2.250:51620;branch=z9hG4bK15c3c5e900b3f6d36.26b037b92d0bba7c9 Route: <sip:x.x.x.102;r2=on;lr=on;nat=yes>, <sip:10.0.0.38;r2=on;lr=on;nat=yes> Max-Forwards: 70 From: "99999999" <sip:99999999@r18.test-bwks.local:5060>;tag=1cf0b02fab To: "9991" <sip:9991@r18.test-bwks.local:5060>;tag=1693866893-1347366897367 Call-ID: b2af8b83e20b0740 CSeq: 29663 ACK User-Agent: Aastra 57i/2.6.0.1007 Content-Length: 0 08:34:57.845182 IP (tos 0x10, ttl 64, id 47937, offset 0, flags [none], proto: UDP (17), length: 509) 10.0.0.38.sip > 10.0.0.29.sip: SIP, length: 481 ACK sip:10.0.0.29:5060 SIP/2.0 Via: SIP/2.0/UDP 10.0.0.38;branch=z9hG4bKcydzigwkX Via: SIP/2.0/UDP 192.168.2.250:51620;rport=31280;received=x.x.x.199;branch=z9hG4bK15c3c5e900b3f6d36.26b037b92d0bba7c9 Max-Forwards: 69 From: "99999999" <sip:99999999@r18.test-bwks.local:5060>;tag=1cf0b02fab To: "9991" <sip:9991@r18.test-bwks.local:5060>;tag=1693866893-1347366897367 Call-ID: b2af8b83e20b0740 CSeq: 29663 ACK User-Agent: Aastra 57i/2.6.0.1007 Content-Length: 0 ------------------------------------------------------------------------------- The call session is up at this point. CPE Router, Source NAT IP x.x.x.199, Internal Network: 192.168.2.0/24 192.168.2.250 is an Aastra 6757i IP Phone, behind the x.x.x.102 is the external interface on our SIP proxy allowing traffic on: Inbound: port 5060/udp Inbound: range 16384 - 32768/udp 10.0.0.38 is the internal interface facing our BroadWorks lab cluster 10.0.0.29 is the internal interface of our BroadWorks Application Server 10.0.0.24 is the internal interface of our BroadWorks Media Server RTP Proxy has been spawned with the following command line arguments: /usr/bin/rtpproxy -p /var/run/rtpproxy.pid -u rtpproxy \ -u root \ -s udp:localhost:7722 \ -l x.x.x.102/10.0.0.38 \ -d DBUG LOG_LOCAL5 \ -m 16384 -M 32768 We've changed the /etc/kamailio/kamailio.cfg and added the #!define's at the top of the configuration file: #!define WITH_NAT #!define WITH_DEBUG In the route[NATMANAGE] { } block we've added a few additional lines to handle the setup of the rtpproxy_manage() function which handles the rtpproxy_offer(), rtpproxy_answer() and unforce_rtp_proxy() convientenly in one function. The logic we've got in place currently is: if ((src_ip =~ "10\.0\.0\.*") && (dst_ip =~ "10\.0\.0\.*")) { xlog("L_INFO", "Media session for ($ci) with source address ($si): Internal > External: SDP contact/origin will be x.x.x.102"); rtpproxy_manage("FAIEOC", "x.x.x.102"); } else if (!(src_ip =~ "10\.0\.0\.*") && (dst_ip == x.x.x.102)) { xlog("L_INFO", "Media session for ($ci) with source address ($si): External > Internal: SDP contact/origin will be 10.0.0.38"); rtpproxy_manage("FAEIOC", "10.0.0.38"); } else { xlog("L_INFO", "!!! Uncaught condition for media session for ($ci) with source address ($si) !!!"); } This rtpproxy log is not from the call above, but the same source #, destination # were used: Sep 11 08:50:27 sip-proxy1 rtpproxy[3101]: INFO:handle_command: new session 84bf2a7cb9d4ab24, tag dcfa6a860e;1 requested, type strong Sep 11 08:50:27 sip-proxy1 rtpproxy[3101]: INFO:handle_command: new session on a port 28282 created, tag dcfa6a860e;1 Sep 11 08:50:27 sip-proxy1 rtpproxy[3101]: INFO:handle_command: pre-filling caller's address with 192.168.2.250:51720 Sep 11 08:50:27 sip-proxy1 rtpproxy[3101]: INFO:handle_command: lookup on ports 28282/22500, session timer restarted Sep 11 08:50:27 sip-proxy1 rtpproxy[3101]: INFO:handle_command: pre-filling callee's address with 10.0.0.24:10502 ... Call is currently active and then hung-up ... Sep 11 08:51:28 sip-proxy1 rtpproxy[3101]: INFO:process_rtp: session timeout Sep 11 08:51:28 sip-proxy1 rtpproxy[3101]: INFO:remove_session: RTP stats: 0 in from callee, 0 in from caller, 0 relayed, 0 dropped Sep 11 08:51:28 sip-proxy1 rtpproxy[3101]: INFO:remove_session: RTCP stats: 0 in from callee, 0 in from caller, 0 relayed, 0 dropped Sep 11 08:51:28 sip-proxy1 rtpproxy[3101]: INFO:remove_session: session on ports 28282/22500 is cleaned up Example of the RTP: 08:53:13.555834 IP (tos 0x0, ttl 48, id 510, offset 0, flags [none], proto: UDP (17), length: 200) x.x.x.199.32052 > x.x.x.102.16552: UDP, length 172 x.x.x.199:32052 > x.x.x.102:16552 Why is this packet not being forwarded to the media proxy (rtpproxy) to 10.0.0.24 (specified in the 200 OK from the BroadWorks Application Server) 08:53:13.562206 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 200) 10.0.0.24.10504 > 10.0.0.38.17968: UDP, length 172 10.0.0.24:10504 > 10.0.0.38:17968 Why is this packet not being forwarded from rtpproxy to the UAC at x.x.x.199? ------------------------------------------------------------------------------- System details: ------------------------------------------------------------------------------- OS: CentOS 5.8 x86-64, Hypervisor is qemu-kvm Memory: 2GB Disk: 40G VCPU: 1 /etc/sysctl.conf: # Controls IP packet forwarding net.ipv4.ip_forward = 1 ------------------------------------------------------------------------------- Current software versions: ------------------------------------------------------------------------------- [root@sip-proxy1 kamailio]# rpm -qa | grep -E 'kamailio|rtpproxy' | xargs rpm -qi Name : rtpproxy Relocations: (not relocatable) Version : 1.2.1 Vendor: Fedora Project Release : 2.el5 Build Date: Sun 19 Sep 2010 08:12:23 AM EDT Install Date: Mon 10 Sep 2012 09:23:28 PM EDT Build Host: x86-10.phx2.fedoraproject.org Group : Applications/Internet Source RPM: rtpproxy-1.2.1-2.el5.src.rpm Size : 105682 License: BSD Signature : DSA/SHA1, Mon 20 Sep 2010 12:40:46 PM EDT, Key ID 119cc036217521f6 Packager : Fedora Project URL : http://www.rtpproxy.org Summary : A symmetric RTP proxy Description : This is symmetric RTP proxy designed to be used in conjunction with the SIP Express Router (SER) or any other SIP proxy capable of rewriting SDP bodies in SIP messages that it processes. Name : kamailio Relocations: (not relocatable) Version : 3.2.4 Vendor: kamailio.org Release : 1.1 Build Date: Fri 03 Aug 2012 05:14:14 AM EDT Install Date: Tue 11 Sep 2012 08:22:32 AM EDT Build Host: build08 Group : Productivity/Telephony/SIP/Servers Source RPM: kamailio-3.2.4-1.1.src.rpm Size : 10200784 License: GPL Signature : DSA/SHA1, Fri 03 Aug 2012 05:14:38 AM EDT, Key ID c9a75909941fdbdd Packager : Daniel-Constantin Mierla <miconda(a)gmail.com> URL : http://kamailio.org/ Summary : Kamailio, very fast, reliable and flexible SIP Server Description : Kamailio is a very fast, reliable and flexible SIP (RFC3261) proxy server. Written entirely in C, kamailio can handle thousands calls per second even on low-budget hardware. A C Shell like scripting language provides full control over the server's behaviour. It's modular architecture allows only required functionality to be loaded. Among available features: IPv4, IPv6, digest authentication, accounting, CPL scripts, instant messaging, MySQL and UNIXODBC support, SIMPLE presence agent, radius authentication, record routing, SMS gateway, ENUM, UDP, TCP, TLS and SCTP, transaction and dialog module, OSP module, statistics support, registrar and user location, SNMP, SIMPLE Presence and Perl programming interface. Name : kamailio-cpl Relocations: (not relocatable) Version : 3.2.4 Vendor: kamailio.org Release : 1.1 Build Date: Fri 03 Aug 2012 05:14:14 AM EDT Install Date: Tue 11 Sep 2012 08:22:33 AM EDT Build Host: build08 Group : Productivity/Telephony/SIP/Servers Source RPM: kamailio-3.2.4-1.1.src.rpm Size : 296947 License: GPL Signature : DSA/SHA1, Fri 03 Aug 2012 05:14:38 AM EDT, Key ID c9a75909941fdbdd Packager : Daniel-Constantin Mierla <miconda(a)gmail.com> URL : http://kamailio.org/ Summary : CPL module (CPL interpreter engine) for Kamailio Description : The kamailio-cpl package provides a CPL interpreter engine for Kamailio

2 1

Max-Forwards: and loops. Testing purpose.
by Anton Kvashenkin 12 Sep '12

12 Sep '12

Hi, List. I'm using sipsak to fire some predefined sip message with Max-Forwards: header equal 0 to test mf_process_maxfwd_header function. I'm doing this exclusively for learning purpose. As far as we know, this exported function from maxfwd module services only for adding Max-Forwards header, decrement or detect Max-Forwards: 0 header to prevent loops. So, my question guys, how can I create this loop in my lab, with two proxies for example? What message should I craft?

2 1

using kamailio with clients in a nat environment
by David Thomson 12 Sep '12

12 Sep '12

hi, I was wondering if in clients in a nat environment need to be in the dmz or need to have ports forwarded for kamailio to be used to connect the clients? I have setup kamailio with the nat settings but am still only getting one way audio. chances are it has not been setup correctly but just checking. If i try to connect the two clients from the same network i can get zrtp and 2 way communication working correctly. if one of the clients is on a different network the call initiates and answers but zrtp and 2way audio does not work. kamailio 3.3 running on ec2 ttyl,Dave

2 4

Re: [SR-Users] Jurisdictional (inter vs intra calling) LCR on Kamailio
by Alex Balashov 11 Sep '12

11 Sep '12

William, This is a business-layer function that is far outside the scope of what built-in Kamailio modules can do. In fact, even the 'lcr' module is something of a misnomer: it does not do LCR in a truly financialised sense, to say nothing of jurisdictionally specific regulatory awareness. It's just a basic weighted routing table. The appropriate place to find such functionality, unless you want to write it yourself, is in a variety of ITSP-oriented commercial platforms built on top of Kamailio. They exist precisely to fill these gaps and bring the somewhat general capabilities of Kamailio into an applied dimension that is useful in specific business and product contexts. Many members of this list represent software or consulting companies that offer such solutions. However, as it is a noncommercial list, I'll refrain from plugging them directly. You may want to ask the question on Kamailio-Business. You can also email me privately and I would be happy to give you some unbiased pointers about the commercial ecosystem. -- Alex -- Sent from my Samsung mobile, and thus lacking in the refinement one might expect from a proper keyboard. Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Web: http://www.evaristesys.com/William Fulton <wfulton(a)thirdhatch.com> wrote:I can’t find any information anywhere on how to get jurisdictional lcr configured. I have intra and interstate rates for each carrier rate deck and don’t know how to let the system know when one is appropriate versus the other. Can someone point me to a tutorial or some documentation on this? Thanks so much! William

1 0

Jurisdictional (inter vs intra calling) LCR on Kamailio
by William Fulton 11 Sep '12

11 Sep '12

I can't find any information anywhere on how to get jurisdictional lcr configured. I have intra and interstate rates for each carrier rate deck and don't know how to let the system know when one is appropriate versus the other. Can someone point me to a tutorial or some documentation on this? Thanks so much! William

1 0

rls notify delay
by Juha Heinanen 11 Sep '12

11 Sep '12

one rls thing that stilll wonders me is the about 2-5 sec delay that occurs when backend notifies have been received and notify to subscriber ua is sent: Sep 11 17:27:41 siika /usr/sbin/sip-proxy[4495]: INFO: Routing PUBLISH <sip:foo@test.fi> to presence server Sep 11 17:27:41 siika /usr/sbin/pres-serv[19270]: INFO: Handling PUBLISH <sip:foo@test.fi> Sep 11 17:27:41 siika /usr/sbin/pres-serv[19270]: INFO: Routing locally generated NOTIFY <sip:rls@127.0.0.1:5082;transport=tcp> to <sip:jh@test.fi> from <sip:foo@test.fi> Sep 11 17:27:41 siika /usr/sbin/pres-serv[19270]: INFO: presence [notify.c:1575]: NOTIFY sip:jh@test.fi via sip:rls@127.0.0.1:5082;transport=tcp on behalf of sip:foo@test.fi for event presence Sep 11 17:27:41 siika /usr/sbin/pres-serv[19271]: INFO: Handling in-dialog NOTIFY <sip:rls@127.0.0.1:5082;transport=tcp> from <sip:foo@test.fi> to <sip:jh@test.fi> Sep 11 17:27:46 siika /usr/sbin/pres-serv[19265]: INFO: Routing locally generated NOTIFY <sip:cyvrphbz@192.98.103.1:60122;alias=192.98.103.1~47419~2;transport=tcp> to <sip:jh@test.fi> from <sip:jh-buddies@test.fi> Sep 11 17:27:46 siika /usr/sbin/sip-proxy[4482]: INFO: Routing in-dialog NOTIFY <sip:cyvrphbz@192.98.103.1:60122;transport=tcp> from <sip:jh-buddies@test.fi> to <sip:192.98.103.1:47419;transport=tcp> this does not depend on the pua patch nor which db_mode i have in rls module. -- juha

2 2

rls does not generally work
by Juha Heinanen 11 Sep '12

11 Sep '12

it turned out that presence rls module does not work unless pua module is configured to use database mode and database is postgre. the issue is serious, since besides not working, it makes presence/rls server not to accept any new requests. since there is no easy cure, should i go and write a warning in rls readme file so that others don't stumble on this? -- juha

2 6

← Newer
1
...
7
8
9
10
11
12
13
14
Older →

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 September 2012