sr-users October 2012

sr-users@lists.kamailio.org

87 participants
164 discussions

Wrong ACK packet sent from Cisco gw
by Nawfel Oujdi 07 Mar '13

07 Mar '13

Hello! I m facing the same strange behaviour with my AS5300 voice gateway. When the gw is connected directly to PBX everythings works well but when i put a sip proxy forwarding calls between gw and PBX all the calls hangs up after 5 sec (+or -). Looking into the trace sip i realize that gw send a wrong ACK in reply of INVITE , then sip proxy discard it and PBX hangs the call cause he never receive the ACK. ACK sip:79.125.120.12:5060;lr=on;did=ce.3716ea02 SIP/2.0 Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag="cid:Orange@cisco_gw" From: <sip:911873699@cisco_gw>;tag=65FB8-B18 Route: <sip:911111500@PBX:5060> To: <sip:911111500@sip_proxy>;tag=as7f388e3f Date: Mon, 17 Jan 2011 09:26:36 GMT Call-ID: B6F61A2E-215211E0-802BD462-C4432B89@cisco_gw To work fine , the content of Route header should be in ACK header and viceversa. I tried to compare between the sip trace of a wrong call and a good one (using other cisco gw AS5350 who works well with sip proxy in the same escenario) and i realize that the only difference is the INVITE of wrong case doesn' t send branch number in the via header. INVITE sip:911111500@sip_proxy:5060 SIP/2.0 Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag="cid:Orange@cisco_gw" From: <sip:911873699@cisco_gw>;tag=65FB8-B18 To: <sip:911111500@sip_proxy> i m using c5300-is-mz.123-26.bin ios version. Anybody understand what is happening in there?? is there any solution?? i ll send more information if it s requested. Thanks in advance. Nawfel Oujdi here is the result of ngrep: U 2011/01/13 15:14:43.791514 cisco_gw:51703 -> sip_server:5060 INVITE sip:911111500@sip_server:5060 SIP/2.0. Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag="cid:Orange@cisco_gw". From: <sip:911873699@cisco_gw>;tag=4F226C8-2DC. To: <sip:911111500@sip_server>. Date: Thu, 13 Jan 2011 14:14:43 GMT. Call-ID: 4D776A24-1E5611E0-9B81F289-1B94787@cisco_gw. Supported: timer,100rel. Min-SE: 1800. Cisco-Guid: 1295951687-508957152-2608788105-28919687. User-Agent: Cisco-SIPGateway/IOS-12.x. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO. CSeq: 101 INVITE. Max-Forwards: 6. Remote-Party-ID: <sip:911873699@cisco_gw >;party=calling;screen=yes;privacy=off. Timestamp: 1294928083. Contact: <sip:911873699@cisco_gw:5060>. Expires: 180. Allow-Events: telephone-event. Content-Type: application/sdp. Content-Length: 270. . v=0. o=CiscoSystemsSIP-GW-UserAgent 8894 2421 IN IP4 cisco_gw. s=SIP Call. c=IN IP4 cisco_gw. t=0 0. m=audio 16924 RTP/AVP 18 101. c=IN IP4 cisco_gw. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. U 2011/01/13 15:14:43.791893 sip_server:5060 -> cisco_gw:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag="cid:Orange@cisco_gw". From: <sip:911873699@cisco_gw>;tag=4F226C8-2DC. To: <sip:911111500@sip_server>. Call-ID: 4D776A24-1E5611E0-9B81F289-1B94787@cisco_gw. CSeq: 101 INVITE. Server: OpenSIPS (1.6.3-notls (i386/linux)). Content-Length: 0. . U 2011/01/13 15:14:43.791957 sip_server:5060 -> asterisk_server:5060 INVITE sip:911111500@sip_server:5060 SIP/2.0. Record-Route: <sip:sip_server;lr=on;did=015.864b8107>. Via: SIP/2.0/UDP sip_server;branch=z9hG4bK3e35.3ed9b366.0. Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag="cid:Orange@cisco_gw". From: <sip:911873699@cisco_gw>;tag=4F226C8-2DC. To: <sip:911111500@sip_server>. Date: Thu, 13 Jan 2011 14:14:43 GMT. Call-ID: 4D776A24-1E5611E0-9B81F289-1B94787@cisco_gw. Supported: timer,100rel. Min-SE: 1800. Cisco-Guid: 1295951687-508957152-2608788105-28919687. User-Agent: Cisco-SIPGateway/IOS-12.x. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO. CSeq: 101 INVITE. Max-Forwards: 5. Remote-Party-ID: <sip:911873699@cisco_gw >;party=calling;screen=yes;privacy=off. Timestamp: 1294928083. Contact: <sip:911873699@cisco_gw:5060>. Expires: 180. Allow-Events: telephone-event. Content-Type: application/sdp. Content-Length: 270. . v=0. o=CiscoSystemsSIP-GW-UserAgent 8894 2421 IN IP4 cisco_gw. s=SIP Call. c=IN IP4 cisco_gw. t=0 0. m=audio 16924 RTP/AVP 18 101. c=IN IP4 cisco_gw. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. U 2011/01/13 15:14:43.792775 asterisk_server:5060 -> sip_server:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP sip_server;branch=z9hG4bK3e35.3ed9b366.0;received=sip_server. Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag="cid:Orange@cisco_gw". Record-Route: <sip:sip_server;lr=on;did=015.864b8107>. From: <sip:911873699@cisco_gw>;tag=4F226C8-2DC. To: <sip:911111500@sip_server>. Call-ID: 4D776A24-1E5611E0-9B81F289-1B94787@cisco_gw. CSeq: 101 INVITE. Server: Asterisk PBX 1.6.2.13. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO. Supported: replaces, timer. Require: timer. Session-Expires: 1800;refresher=uas. Contact: <sip:911111500@asterisk_server>. Content-Length: 0. . U 2011/01/13 15:14:43.793770 asterisk_server:5060 -> sip_server:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP sip_server;branch=z9hG4bK3e35.3ed9b366.0;received=sip_server. Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag="cid:Orange@cisco_gw". Record-Route: <sip:sip_server;lr=on;did=015.864b8107>. From: <sip:911873699@cisco_gw>;tag=4F226C8-2DC. To: <sip:911111500@sip_server>;tag=as19e8a82f. Call-ID: 4D776A24-1E5611E0-9B81F289-1B94787@cisco_gw. CSeq: 101 INVITE. Server: Asterisk PBX 1.6.2.13. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO. Supported: replaces, timer. Require: timer. Session-Expires: 1800;refresher=uas. Contact: <sip:911111500@asterisk_server>. Content-Type: application/sdp. Content-Length: 260. . v=0. o=root 1750021131 1750021131 IN IP4 asterisk_server. s=Asterisk PBX 1.6.2.13. c=IN IP4 asterisk_server. t=0 0. m=audio 10798 RTP/AVP 18 101. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. a=sendrecv. U 2011/01/13 15:14:43.794688 sip_server:5060 -> cisco_gw:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag="cid:Orange@cisco_gw". Record-Route: <sip:sip_server;lr=on;did=015.864b8107>. From: <sip:911873699@cisco_gw>;tag=4F226C8-2DC. To: <sip:911111500@sip_server>;tag=as19e8a82f. Call-ID: 4D776A24-1E5611E0-9B81F289-1B94787@cisco_gw. CSeq: 101 INVITE. Server: Asterisk PBX 1.6.2.13. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO. Supported: replaces, timer. Require: timer. Session-Expires: 1800;refresher=uas. Contact: <sip:911111500@asterisk_server>. Content-Type: application/sdp. Content-Length: 316. . v=0. o=root 1750021131 1750021131 IN IP4 79.125.41.121. s=Asterisk PBX 1.6.2.13. c=IN IP4 79.125.41.121. t=0 0. m=audio 10798 RTP/AVP 18 101. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. a=sendrecv. a=oldmediaip:asterisk_server. a=oldmediaip:asterisk_server. U 2011/01/13 15:14:43.856520 cisco_gw:57947 -> sip_server:5060 ACK sip:sip_server:5060;lr=on;did=015.864b8107 SIP/2.0. Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag="cid:Orange@cisco_gw". From: <sip:911873699@cisco_gw>;tag=4F226C8-2DC. To: <sip:911111500@sip_server>;tag=as19e8a82f. Date: Thu, 13 Jan 2011 14:14:43 GMT. Call-ID: 4D776A24-1E5611E0-9B81F289-1B94787@cisco_gw. Route: <sip:911111500@asterisk_server:5060>. Max-Forwards: 6. Content-Length: 0. CSeq: 101 ACK. . U 2011/01/13 15:14:43.993417 asterisk_server:5060 -> sip_server:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP sip_server;branch=z9hG4bK3e35.3ed9b366.0;received=sip_server. Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag="cid:Orange@cisco_gw". Record-Route: <sip:sip_server;lr=on;did=015.864b8107>. From: <sip:911873699@cisco_gw>;tag=4F226C8-2DC. To: <sip:911111500@sip_server>;tag=as19e8a82f. Call-ID: 4D776A24-1E5611E0-9B81F289-1B94787@cisco_gw. CSeq: 101 INVITE. Server: Asterisk PBX 1.6.2.13. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO. Supported: replaces, timer. Require: timer. Session-Expires: 1800;refresher=uas. Contact: <sip:911111500@asterisk_server>. Content-Type: application/sdp. Content-Length: 260. . v=0. o=root 1750021131 1750021131 IN IP4 asterisk_server. s=Asterisk PBX 1.6.2.13. c=IN IP4 asterisk_server. t=0 0. m=audio 10798 RTP/AVP 18 101. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. a=sendrecv. U 2011/01/13 15:14:43.993613 sip_server:5060 -> cisco_gw:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag="cid:Orange@cisco_gw". Record-Route: <sip:sip_server;lr=on;did=015.864b8107>. From: <sip:911873699@cisco_gw>;tag=4F226C8-2DC. To: <sip:911111500@sip_server>;tag=as19e8a82f. Call-ID: 4D776A24-1E5611E0-9B81F289-1B94787@cisco_gw. CSeq: 101 INVITE. Server: Asterisk PBX 1.6.2.13. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO. Supported: replaces, timer. Require: timer. Session-Expires: 1800;refresher=uas. Contact: <sip:911111500@asterisk_server>. Content-Type: application/sdp. Content-Length: 316. . v=0. o=root 1750021131 1750021131 IN IP4 79.125.41.121. s=Asterisk PBX 1.6.2.13. c=IN IP4 79.125.41.121. t=0 0. m=audio 10798 RTP/AVP 18 101. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. a=sendrecv. a=oldmediaip:asterisk_server. a=oldmediaip:asterisk_server. U 2011/01/13 15:14:44.038774 cisco_gw:57947 -> sip_server:5060 ACK sip:sip_server:5060;lr=on;did=015.864b8107 SIP/2.0. Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag="cid:Orange@cisco_gw". From: <sip:911873699@cisco_gw>;tag=4F226C8-2DC. To: <sip:911111500@sip_server>;tag=as19e8a82f. Date: Thu, 13 Jan 2011 14:14:43 GMT. Call-ID: 4D776A24-1E5611E0-9B81F289-1B94787@cisco_gw. Route: <sip:911111500@asterisk_server:5060>. Max-Forwards: 6. Content-Length: 0. CSeq: 101 ACK. . U 2011/01/13 15:14:44.193431 asterisk_server:5060 -> sip_server:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP sip_server;branch=z9hG4bK3e35.3ed9b366.0;received=sip_server. Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag="cid:Orange@cisco_gw". Record-Route: <sip:sip_server;lr=on;did=015.864b8107>. From: <sip:911873699@cisco_gw>;tag=4F226C8-2DC. To: <sip:911111500@sip_server>;tag=as19e8a82f. Call-ID: 4D776A24-1E5611E0-9B81F289-1B94787@cisco_gw. CSeq: 101 INVITE. Server: Asterisk PBX 1.6.2.13. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO. Supported: replaces, timer. Require: timer. Session-Expires: 1800;refresher=uas. Contact: <sip:911111500@asterisk_server>. Content-Type: application/sdp. Content-Length: 260. . v=0. o=root 1750021131 1750021131 IN IP4 asterisk_server. s=Asterisk PBX 1.6.2.13. c=IN IP4 asterisk_server. t=0 0. m=audio 10798 RTP/AVP 18 101. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. a=sendrecv. -- ------------------------------ Aviso legal: Este mensaje electrónico está dirigido únicamente a la(s) dirección(es) indicadas anteriormente; el carácter confidencial, personal e intransferible del mismo está protegido legalmente. Cualquier revelación, uso o reenvío no autorizado, completo o en parte, está prohibido. Si ha recibido este mensaje por equivocación, notifíquelo inmediatamente a la persona que lo ha enviado y borre el mensaje original junto con sus ficheros anexos sin leerlo ni grabarlo, total o parcialmente.

2 1

Kamailio 1.5 and Asterisk 1.8 issue (Protocol Error, Unspecified)
by Rowie 24 Feb '13

24 Feb '13

Hi, We are having an issue where a phone (snom in particular) cannot make a call through Asterisk. It just hangup and does not allow the call to go through. I am including a a sip trace on this thread to show what is happening within the call. Please see below: Received from udp:10.1.10.80:5060 at 26/10/2011 10:22:41:476 (490 bytes): SIP/2.0 481 Call/Transaction Does Not Exist Via: SIP/2.0/UDP 10.30.0.64:5060;received=10.30.0.64;branch=z9hG4bK-wowp1kmdy4rl;rport=5060 From: "Virgil Menendez" <sip:91421@ser.gowireless.net>;tag=6wkdms1r20 To: <sip:9513261429@ser.gowireless.net;user=phone>;tag=as0b87218f Call-ID: 3c26755bf15c-9iq08xqqblo6 CSeq: 4 INVITE Server: Asterisk PBX 1.8.7.1 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer Content-Length: 0 -------------------------------------------------------------------------------- Sent to udp:10.1.10.80:5060 at 26/10/2011 10:22:41:481 (387 bytes): ACK sip:vm9513261429@10.1.10.83:5060 SIP/2.0 v: SIP/2.0/UDP 10.30.0.64:5060;branch=z9hG4bK-wowp1kmdy4rl;rport Route: <sip:10.1.10.80;lr=on> f: "Virgil Menendez" <sip:91421@ser.gowireless.net>;tag=6wkdms1r20 t: <sip:9513261429@ser.gowireless.net;user=phone>;tag=as0b87218f i: 3c26755bf15c-9iq08xqqblo6 CSeq: 4 ACK Max-Forwards: 70 m: <sip:91421@10.30.0.64:5060>;reg-id=1 l: 0 -------------------------------------------------------------------------------- Received from udp:10.1.10.80:5060 at 26/10/2011 10:22:42:130 (868 bytes): SIP/2.0 200 OK Via: SIP/2.0/UDP 10.30.0.64:5060;received=10.30.0.64;branch=z9hG4bK-5evtiw6dm0po;rport=5060 Record-Route: <sip:10.1.10.80;lr=on> From: "Virgil Menendez" <sip:91421@ser.gowireless.net>;tag=qi3i8ze6z8 To: <sip:9513261429@ser.gowireless.net;user=phone>;tag=as3f8c0f96 Call-ID: 3c2676547a8d-2t5yi6jok1sv CSeq: 2 INVITE Server: Asterisk PBX 1.8.7.1 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer Session-Expires: 1800;refresher=uas Contact: <sip:9513261429@10.1.10.83:5060> Content-Type: application/sdp Content-Length: 256 v=0 o=root 1355451627 1355451627 IN IP4 10.1.10.83 s=Asterisk PBX 1.8.7.1 c=IN IP4 10.1.10.83 t=0 0 m=audio 16094 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv -------------------------------------------------------------------------------- Sent to udp:10.1.10.80:5060 at 26/10/2011 10:22:42:132 (385 bytes): ACK sip:9513261429@10.1.10.83:5060 SIP/2.0 v: SIP/2.0/UDP 10.30.0.64:5060;branch=z9hG4bK-wszafb7cbzpw;rport Route: <sip:10.1.10.80;lr=on> f: "Virgil Menendez" <sip:91421@ser.gowireless.net>;tag=qi3i8ze6z8 t: <sip:9513261429@ser.gowireless.net;user=phone>;tag=as3f8c0f96 i: 3c2676547a8d-2t5yi6jok1sv CSeq: 2 ACK Max-Forwards: 70 m: <sip:91421@10.30.0.64:5060>;reg-id=1 l: 0 -------------------------------------------------------------------------------- Received from udp:10.1.10.80:5060 at 26/10/2011 10:22:42:232 (503 bytes): BYE sip:91421@10.30.0.64:5060 SIP/2.0 Via: SIP/2.0/UDP 10.1.10.80;branch=z9hG4bKe723.bf70c1f4.0 Via: SIP/2.0/UDP 10.1.10.83:5060;branch=z9hG4bK69f53cf1 Max-Forwards: 69 From: <sip:9513261429@ser.gowireless.net;user=phone>;tag=as3f8c0f96 To: "Virgil Menendez" <sip:91421@ser.gowireless.net>;tag=qi3i8ze6z8 Call-ID: 3c2676547a8d-2t5yi6jok1sv CSeq: 102 BYE User-Agent: Asterisk PBX 1.8.7.1 X-Asterisk-HangupCause: Protocol error, unspecified X-Asterisk-HangupCauseCode: 111 Content-Length: 0 -- View this message in context: http://old.nabble.com/Kamailio-1.5-and-Asterisk-1.8-issue-%28Protocol-Error… Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

4 3

pseudovariable values written from app_lua sometimes appear incorrect
by elactrum＠jamailca.com 12 Feb '13

12 Feb '13

Hi, I am using app_lua to frequently store some data in htable and avp entries, using sr.pv.sets. When I read the values using sr.pv.get immediately after writing them, they seem correct. However, when I read them later from Lua, I have noticed that sometimes the value is incorrect or nil. Am I doing something wrong? The following code uses rtimer to duplicate the problem on startup, printing the errors to syslog. Tested on version: kamailio 3.3.1 (i386/linux) 2d0f6f ############### # kamailio.cfg ############### loadmodule "pv.so" loadmodule "xlog.so" loadmodule "htable.so" loadmodule "rtimer.so" loadmodule "app_lua" modparam("htable", "htable", "status=>size=14;autoexpire=0;") modparam("rtimer", "timer", "name=ta;interval=10;mode=1") modparam("rtimer", "exec", "timer=ta;route=LUA_TEST") # the following path may need to change depending on filesystem setup modparam("app_lua", "load", "/etc/kamailio/kamailio.lua") route { route(LUA_TEST); } route[LUA_TEST] { $var(lua_test_key) = $(pp{s.toupper}) + "::"; lua_runstring("htable_test([[status=>$var(lua_test_key)]])"); lua_runstring("avp_test([[status=>$var(lua_test_key)]])"); } ---------------- -- kamailio.lua ---------------- -- Test of sr.pv operations in Lua function htable_test (namekey) local pvar_prefix = "$sht("..namekey pvar_test(pvar_prefix) end function avp_test ( name ) local pvar_prefix = "$avp("..name pvar_test(pvar_prefix) end function pvar_test ( pvar_prefix ) for value = 10000, 10050 do local pvar = pvar_prefix..value..")" --sr.log("info", "Lua attempting to set '"..pvar.."' to value '"..value.."'") sr.pv.sets(pvar, value) end for value = 10000, 10050 do -- now we check what was stored local pvar = pvar_prefix..value..")" local checkvar = sr.pv.get(pvar) if ( tostring(checkvar) ~= tostring(value) ) then sr.err(string.format("CHECK: Lua checking pvar '%s' and got value '%s' which is NOT '%s'", tostring(pvar), tostring(checkvar), tostring(value) )) end end end -- end of kamailio.lua Thanks, -Andrew

2 6

Core fm_realloc function
by Bruno Bresciani 08 Jan '13

08 Jan '13

Hi all, I observed two at 0x08173bf0 in fm_realloc (qm=0xb5f7d000, p=0xb61f0bc0, size=0) at mem/f_malloc.c:536. I don't know exactly what may be caused this core because the debug of kamailio is disabled, but looking at backtrace (gdb) and source code I could notice a relationship with TLS connection establishment (handshake). Other important fact is that core was generated by the kamalio itself with signal 6 (abort) because it can't find the pointer to memory realloc. I'd like to know if someone already observed this issue and if my analyse above is correct? Bellow is backtrace full with gdb: Core was generated by `/home2/local/kamailio/sbin/kamailio -P /var/run/kamailio.pid'. Program terminated with signal 6, Aborted. #0 0x00f30402 in __kernel_vsyscall () (gdb) (gdb) (gdb) (gdb) (gdb) bt full #0 0x00f30402 in __kernel_vsyscall () No symbol table info available. #1 0x009fec10 in raise () from /lib/libc.so.6 No symbol table info available. #2 0x00a00521 in abort () from /lib/libc.so.6 No symbol table info available. #3 0x08173bf0 in fm_realloc (qm=0xb5f7d000, p=0xb61f0bc0, size=0) at mem/f_malloc.c:536 f = (struct fm_frag *) 0xb61f0bb8 pf = <value optimized out> orig_size = 18 L=ÃbÂ¬Ã2n = (struct fm_frag *) 0xb61f0bd2 ptr = <value optimized out> hash = 23548 #4 0x0051a87f in ser_realloc (ptr=0xb61f0bc0, size=32) at ../../mem/shm_mem.h:266 No locals. #5 0x00460295 in OPENSSL_cleanse () from /lib/libcrypto.so.6 No symbol table info available. #6 0x004609f7 in CRYPTO_realloc () from /lib/libcrypto.so.6 No symbol table info available. #7 0x003efb22 in sk_insert () from /lib/libcrypto.so.6 No symbol table info available. #8 0x003efbaa in sk_push () from /lib/libcrypto.so.6 No symbol table info available. #9 0x007c2ac3 in ssl_bytes_to_cipher_list () from /lib/libssl.so.6 No symbol table info available. #10 0x007aa9f3 in ssl3_get_client_hello () from /lib/libssl.so.6 No symbol table info available. #11 0x007ab815 in ssl3_accept () from /lib/libssl.so.6 No symbol table info available. #12 0x007c1c3a in SSL_accept () from /lib/libssl.so.6 No symbol table info available. #13 0x005278e3 in tls_accept (c=0xb621af88, error=0xbf91dfc8) at tls_server.c:346 ret = <value optimized out> ssl = (SSL *) 0xb61c1878 cert = <value optimized out> tls_c = (struct tls_extra_data *) 0xb6208e58 tls_log = <value optimized out> #14 0x0052da8e in tls_read_f (c=0xb621af88, flags=0xbf91e200) at tls_server.c:1028 r = (struct tcp_req *) 0xb621affc bytes_free = 4095 bytes_read = 70 read_size = 4095 ssl_error = 0 ssl_read = 0 ssl = (SSL *) 0xb61c1878 rd_buf = "\026\003\001\000A\001\000\000=\003\001OÃ¿\vÂ¡ywP\fkÃDÃ 0/\000\a\000\005\001\000ÃÃÃÃ¯000\000\026\0009\0008\0005\000\026\000\023\000\n\0003\0002\00 202i<Ã¤<Ã¥Ã¾\031Ã¬234Â \237Ãª030Y){lÑ¶"...06Ã'Ãr9Ã¬Ã«Â¸{[Â©\t\205\037\036Ã¿HPH5Âµ\t(Ã©32Ã027Ã¦Ã²036Â¾\"\rÔ¤YÃ215uÂº\027)Ã¶000Ã±215\vÃÃ Ã©Ea\023xÃ©J\206T\204CÃ wr_buf = "\027\003\001\003Â wÂ²'\016Ñ¼Ã033ÃLÃ021Ã)Ã\220hnLÂ¦\020XÃª\236\200\tIhÃÂ¸Sf\234Ã\rÃ ?Â¯Â¼\024FÃ\200Âª/\2264RÃaÃÂ¤IpXÂ»Â¨Ã035Ã¤Qh\211Ã026Ã½4ÃU+\asrÂ£/`Â¤OÃ»1AÊ¹qUÜ¿Â·vÂ±Ã¼\205"... rd = {buf = 0xbf90dfa4 "\026\003\001", pos = 70, used = 70, size = 65536} wr = { buf = 0xbf8fdfa4 "\027\003\001\003Â wÂ²'\016Ñ¼Ã033ÃLÃ021Ã)Ã\220hnLÂ¦\020XÃª\236\200\tIhÃÂ¸Sf\234Ã\rÃ ?Â¯Â¼\024FÃ\200Âª/\2264RÃaÃÂ¤IpXÂ»Â¨Ã035Ã¤Qh\211Ã026Ã½4ÃU+\asrÂ£/`Â¤OÃ»1AÊ¹qUÜ¿Â·vÂ±Ã¼\205"..., pos = 0, used = 0, size = 65536} tls_c = (struct tls_extra_data *) 0xb6208e58 enc_rd_buf = (struct tls_rd_buf *) 0x0 n = 0 flush_flags = <value optimized out> err_src = 0x541a83 "TLS read:" x = <value optimized out> #15 0x08158ade in tcp_read_headers (c=0xb621af88, read_flags=0xbf91e200) at tcp_read.c:406 bytes = -1 remaining = <value optimized out> p = <value optimized out> r = (struct tcp_req *) 0xb621affc #16 0x08158fd4 in tcp_read_req (con=0xb621af88, bytes_read=0xbf91e204, read_flags=0xbf91e200) at tcp_read.c:871 bytes = <value optimized out> total_bytes = 0 resp = <value optimized out> size = <value optimized out> req = (struct tcp_req *) 0xb621affc dst = {send_sock = 0x1, to = {s = {sa_family = 57540, sa_data = "\221Â¿\020\000\000\000\000\000\000\000\020\000\000"}, sin = {sin_family = 57540, sin_port = 49041, sin_addr = {s_addr = 16}, sin_zero = "\000\000\000\000\020\000\000"}, sin6 = {sin6_family = 57540, sin6_port = 49041, sin6_flowinfo = 16, sin6_addr = {in6_u = {u6_addr8 = "\000\000\000\000\020\000\000\000\001\000\000\000\001\000\000", u6_addr16 = {0, 0, 16, 0, 1, 0, 1, 0}, u6_addr32 = {0, 16, 1, 1}}}, sin6_scope_id = 12}}, id = -1080958468, proto = 4 '\004', send_flags = {f = 0 '\0', blst_imask = 0 '\0'}} c = 10 '\n' #17 0x08159a0f in handle_io (fm=0x83296b0, events=1, idx=-1) at tcp_read.c:1150 ret = 4 n = 4 read_flags = 1 con = (struct tcp_connection *) 0xb621af88 s = 12 resp = <value optimized out> t = <value optimized out> #18 0x0815d653 in tcp_receive_loop (unix_sock=35) at io_wait.h:1091 No locals. ---Type <return> to continue, or q <return> to quit--- #19 0x0812885b in tcp_init_children () at tcp_main.c:4819 r = 3 reader_fd_1 = 35 pid = <value optimized out> si = <value optimized out> #20 0x080ad412 in main_loop () at main.c:1632 i = 4 pid = <value optimized out> si = (struct socket_info *) 0x0 si_desc = "udp receiver child=3 sock=192.168.166.31:5060 \000\221Â¿\002\000\000\000/\200\220\000\001\000\000\000\000\000H\000Â¨Ã¤21Â¿\001\000\000\000Â°Â¶Ã¨026Â¶\000\000\000\000\000ÃÂµ\030s2\b\002\000\000\000Ã¢f\b\000ÃÂµ\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000Ã¿Ã¿Ã¿Ã¿Â¸Ã¤21Â¿" #21 0x080afbe7 in main (argc=3, argv=dwarf2_read_address: Corrupted DWARF expression. ) at main.c:2398 cfg_stream = (FILE *) 0x8a2d008 c = <value optimized out> r = 0 tmp = 0xbf91e674 "\212Ã¾\221Â¿\233Ã¾\221Â¿Â°Ã¾\221Â¿Â»Ã¾\221Â¿Ã\221Â¿Ã¹1Â¿\020Ã¿\221Â¿DÃ¿\221Â¿LÃ¿\221Â¿WÃ¿\221Â¿]Ã¿\221Â¿oÃ¿\221Â¿{Ã¿\221Â¿\202Ã¿\221 tmp_len = 10492229 port = 136192361 proto = -1080957480 ret = <value optimized out> seed = 21782655 rfd = 4 debug_save = <value optimized out> debug_flag = 0 dont_fork_cnt = 0 n_lst = <value optimized out> p = <value optimized out> Best Regards

4 24

TCP Path received quotes
by Spencer Thomason 07 Jan '13

07 Jan '13

Hello, I'm forwarding registrations to Freeswitch and adding a Path header using add_path_received() for endpoints behind NAT. When TCP is used, this results in a header like this: Path: <sip:a.a.a.a:5070;lr;received="sip:b.b.b.b:35430;transport=tcp"> Freeswitch doesn't like the transport protocol inside the quotations and refuses to route a call to the registered user. Constructing the header manually without the quotes such as: append_hf("Path: <sip:$Ri:$Rp;lr;received=sip:$si:$sp;transport=$pr>\r\n"); solves the problem. Is there a reason for the quotes? Best Regards, Spencer

4 7

Dialog module not decrementing profile size
by Grant Bagdasarian 17 Dec '12

17 Dec '12

Hello Community, I've recently started to use the Dialog module to manage the amount of incoming calls from our SIP provider allowed to pass through by using profiles_with_values and setting the size of these profiles to a certain amount. Most of the time this works as it should, but sometimes the 'slots' available for a profile aren't cleared even though a dialog has finished. This seems to happen when an high amount of regular traffic is hitting kamailio. Has anyone else experienced this? Are there perhaps any other ways to control the slots available for certain incoming SIP traffic? Below parts of my configuration file. Perhaps I'm doing something wrong which causes this to happen. In my route[WITHINDLG] -> loose_route -> is_method("BYE") I'm not calling dlg_manage(), could this be the problem? Other comments are welcome too, as I'm fairly new to Kamailio. modparam("dialog", "enable_stats", 1) modparam("dialog", "dlg_flag", 4) modparam("dialog", "hash_size", 4096) modparam("dialog", "profiles_with_value", "318005004"); modparam("dialog", "default_timeout", 43200) modparam("dialog", "dlg_match_mode",2) modparam("dialog", "detect_spirals", 1) request_route { # per request initial checks route(REQINIT); # handle requests within SIP dialogs route(WITHINDLG); ### only initial requests (no To tag) # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) t_relay(); exit; } t_check_trans(); # record routing for dialog forming requests (in case they are routed) # - remove preloaded route headers remove_hf("Route"); if (is_method("INVITE")) { xlog("L_INFO", "Incoming request for $rU from $fU"); if ($rU == "318005004") { route(DIALOG); } } # handle registrations route(REGISTRAR); if ($rU==$null) { # request with no Username in RURI sl_send_reply("484","Address Incomplete"); exit; } # dispatch destinations route(DISPATCH); route(RELAY); } route[DIALOG] { dlg_manage(); record_route(); $var(SIZE) = 0; sql_query("vf", "exec dbo.SelectAvailableSlots '00$rU'", "ra"); $avp(s:limit) = $dbr(ra=>[0,7]); xlog("L_INFO", "Maximum simultaneous calls is configured at $avp(s:limit) ...."); sql_result_free("ra"); if ($rU == "318005004") { get_profile_size("318005004", "$rU", "$var(SIZE)"); } xlog("L_INFO", "There are currently $var(SIZE) calls for $rU, excluding the current call"); if($var(SIZE) >= $avp(s:limit)) { xlog("L_INFO", "Simultaneous calls limit of $avp(s:limit) reached for $rU: $var(SIZE)\n"); sl_send_reply("603", "Simultaneous calls limit reached"); exit; } if ($rU == "318005004") { set_dlg_profile("318005004", "$rU"); } if ($rU == "318005004") { if(get_profile_size("318005004", "$var(SIZE)")) { xlog("L_INFO", "There are currently $var(SIZE) calls for $rU, including the current call"); } } } route[WITHINDLG] { if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { #Used for call transfer if($fU == "318005004") { if (is_method("UPDATE")) { sl_send_reply("405","Method not allowed"); xlog("L_INFO", "Dropping UPDATE message...\n"); exit; } if (is_method("INVITE")) { record_route(); } if (is_method("BYE")) { dlg_manage(); } } if (is_method("BYE")) { setflag(1); # do accounting ... setflag(3); # ... even if the transaction fails } route(RELAY); } else { if (is_method("SUBSCRIBE") && uri == myself) { # in-dialog subscribe requests route(PRESENCE); exit; } if ( is_method("ACK") ) { if ( t_check_trans() ) { # non loose-route, but stateful ACK; # must be ACK after a 487 or e.g. 404 from upstream server t_relay(); exit; } else { # ACK without matching transaction ... ignore and discard. exit; } } sl_send_reply("404","Not here"); } exit; } } Regards, Grant

2 8

Syntax of xavp
by Andreas Granig 12 Dec '12

12 Dec '12

Hi, I'm playing around with xavp, but there are some things I can't wrap my head around. What basically works is this: $xavp(a=>foo) = 'foo'; $xavp(a[0]=>bar) = 'bar'; Getting the value like this: xlog("L_INFO", "a-foo='$xavp(a=>foo)' and a-bar='$xavp(a=>bar)'"); as well as xlog("L_INFO", "a-foo='$xavp(a[0]=>foo)' and a-bar='$xavp(a[0]=>bar)'"); ... works, because when omitting the index, it assumes [0]. I really like to avoid such implicit assumptions though, to make the config really clear, so I prefer the second approach. What doesn't work for me then is explicit assignment of the very first value, like this: $xavp(a[0]=>foo) = 'foo'; $xavp(a[0]=>bar) = 'bar'; If I do this, the "a" xavp is never created. Wouldn't it be good practice to create the xavp on first assignment? That way, I don't have to take care in the config file whether the xavp is used for the first time, where I have to omit the index. What I'm also wondering is whether it's possible to directly access nested xavps, like this: $xavp(a=>foo) = 'afoo'; $xavp(b=>foo) = 'bfoo'; $xavp(c=>a) = $xavp(a); $xavp(c=>b) = $xavp(b); xlog("L_INFO", "a-foo='$xavp(c=>a[0]=>foo)'"); or xlog("L_INFO", "a-foo='$xavp(c=>a=>foo)'"); Both ways give me "a-foo='<<xavp:0x7f0d387fe178>>'". Is this even intended? Would be really cool if that's possible! Thanks, Andreas

3 4

dns resolver issue (RFC3263)
by MÉSZÁROS Mihály 05 Dec '12

05 Dec '12

Hi All, I am experiencing an issue when i try to contact xy(a)cisco.com. I found that kamailio/sip-router can't resolve by default resolving way a TCP + SRV records from domain cisco.com. e.g. cisco.com misi@alma:~$ host -t NAPTR cisco.com cisco.com has no NAPTR record misi@alma:~$ host -t SRV _sip._udp.cisco.com Host _sip._udp.cisco.com not found: 3(NXDOMAIN) misi@alma:~$ host -t SRV _sip._tcp.cisco.com _sip._tcp.cisco.com has SRV record 1 0 5060 vcsgw.cisco.com. misi@alma:~$ host -t SRV _sips._tcp.cisco.com _sips._tcp.cisco.com has SRV record 1 0 5061 vcsgw.cisco.com. I can't call xy(a)cisco.com because it does not exists an NAPTR record in domain cisco.com, and furthermore no SRV with udp. But it exists sip+tcp record and also exists an secure sip SRV, so sips+tcp record! I read rfc3263 I find kamailio dns resolver is not working as it should according RFC3263. http://tools.ietf.org/html/rfc3263 _If no NAPTR records are found, the client constructs SRV queries for those transport protocols it supports, and does a query for each._ So kamailio should query all (udp, tcp, tls, sctp whatever) protocols. Can anyone help/guide me to create a fix to this issue? My plan is to create a patch to kamailio resolver, to correct and behave according RFC3263. Any help or guidance appreciated! Thanks, Misi

4 14

[Kamailio-Users] BYE message not relayed to caller
by Vikram Ragukumar 04 Dec '12

04 Dec '12

Hello, My setup includes a cellphone that uses Wi-Fi to hookup to the internet with IP 192.168.1.101. Cellphone app, tries to register with VOIPSwitch through an outbound proxy server(Kamailio + rtpproxy), which rewrites SDP to force rtp through an rtpproxy. I can make a call from the cellphone to a PSTN number. When the PSTN endpoint hangs up, VOIPSwitch relays a BYE message to the proxy that looks like : No. Time Source Destination Protocol Info 27 18.383929 IPaddr_VoipSwitch IPaddr_proxy SIP Request: BYE sip:1234@IPaddr_VoipSwitch Frame 27 (420 bytes on wire, 420 bytes captured) Ethernet II, Src: Unispher_40:b5:39 (00:90:1a:40:b5:39), Dst: Supermic_bd:b9:bc (00:30:48:bd:b9:bc) Internet Protocol, Src: IPaddr_VoipSwitch , Dst: IPaddr_proxy User Datagram Protocol, Src Port: sip (5060), Dst Port: 7160 (7160) Session Initiation Protocol Request-Line: BYE sip:1234@IPaddr_VoipSwitch SIP/2.0 Method: BYE [Resent Packet: False] Message Header Route: <sip:IPaddr_proxy:7160;lr=on;nat=yes> CSeq: 1 BYE Via: SIP/2.0/UDP IPaddr_VoipSwitch:5060; branch=z9hG4bk180242100434182912333954 From: sip:5678@IPaddr_VoipSwitch;tag=18024210041929123187506289 Call-ID: LUOyIDm-ecy36NcUfj5G3v1lM6g5snkM To: "1234" <sip:1234@IPaddr_VoipSwitch>;tag=9XHJmiuf58vTrF7.vwflEK-G63JVPQSi Content-Length: 0 The request URI in the above message is the IP address of VOIPSwitch itself, which causes the proxy to forward the BYE message back to VOIPSwitch. The cellphone never receives the BYE message and consequently never hangs up. Any suggestions on how i can get around this problem ? Thanks and Regards, Vikram.

3 9

Kamailio v3.3.2 Released
by Daniel-Constantin Mierla 04 Dec '12

04 Dec '12

Hello, Kamailio SIP Server v3.3.2 stable release is out. This is a maintenance release of the latest stable branch, 3.3, that includes fixes since release of v3.3.1. There is no change to database schema or configuration language structure that you have to do on installations of v3.3.0 or v3.3.1. Deployments running previous v3.x.x versions are strongly recommended to be upgraded to v3.3.2. For more details about version 3.3.2 (including links and hints to download the tarball or from GIT repository), visit: * http://www.kamailio.org/w/2012/10/kamailio-v3-3-2-released/ RPM, Debian/Ubuntu packages will be available soon as well. Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu

4 4

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