sr-users

sr-users@lists.kamailio.org

20 participants
37472 discussions

users@kamailio and sr-users@sip-router merged
by Daniel-Constantin Mierla 10 Apr '10

10 Apr '10

Hello, the process of merging users(a)list.kamailio.org and sr-users(a)lists.sip-router.org is completed, offering a single place for community discussions via email related to stable versions and generic topics, also removing confusion for new comers which to use for best feedback. Because sr-users was a rather new mailing list, I imported the archive from users. It will help to continue the topics and have the entire knowledge base built over years in the same place, for web searches. The old Users mailing list archive still exists separately, link at: http://lists.kamailio.org/pipermail/users/ No new posts will get there, subscription is disabled, messages to users list are directed to sr-users (therefore replying to existing threads on either of the mailing lists work just fine). No matter you were a Users or SR-Users subscriber, updates to your profile can be done at: http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users I case your password is no longer valid, you can retrieve it via password reminder at: http://lists.sip-router.org/cgi-bin/mailman/options/sr-users Thanks, Daniel PS. Some of you may have received an unintentional "unsubscribed from sr-users-new mailing list" message, just ignore it - happened when I simulated synchronization of members on temporary name sr-users-new, no unsubscribe action was actually done -- sorry for inconvenience. -- Daniel-Constantin Mierla

1 0

[Kamailio-Users] merging users mailing list
by Daniel-Constantin Mierla 10 Apr '10

10 Apr '10

Hello, I am starting the merging process of users mailing list. Please ignore any notifications you get, if you get them is by mistake in my config -- none of subscribed users will be affected, the work is done for testing on a temporary new list, therefore everyone is safe. Sorry for any inconvenience! I will announce when it is finished. Daniel

1 0

[Kamailio-Users] dispatcher has problems
by Vic Jolin 09 Apr '10

09 Apr '10

I just noticed that if I have 4 servers set like this # group sip addresses of your * units 1 sip:XXX.XXX.XXX.XXX:5060 1 sip:XXX.XXX.XXX.XXX:5060 1 sip:XXX.XXX.XXX.XXX:5060 1 sip:XXX.XXX.XXX.XXX:5060 the registration does not work and I get 401 unauthorized. My setup is like this Openser as proxy sends all SIP messages to load balanced asterisk servers So sip phones should be able to register to the asterisk server The routing part in kamailio.cfg looks like this if ( method=="REGISTER" || method=="NOTIFY" || method=="OPTIONS" || method=="ACK" || method=="MESSAGE") { fix_nated_contact(); fix_nated_register(); ds_select_dst("1","4"); forward();#uri:host, uri:port); exit(); } if (method=="BYE" || method=="CANCEL") { unforce_rtp_proxy(); } else if (method=="INVITE"){ log("VCTOR: Got an invite\n"); fix_nated_contact(); force_rtp_proxy(); ds_select_dst("1","4"); forward();#uri:host, uri:port); t_on_failure("1"); }; search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes'); t_on_reply("1"); if (!is_method("INVITE|REGISTER|MESSAGE|BYE|NOTIFY|ACK|CANCEL|REFER|SUBSCRIBE|OPTIONS|INFO")) { xlog("L_INFO", "=== [$rm] Method Not Implement ===========\n"); sl_send_reply("501", "Not implemented here"); return; }; any thoughts?

2 2

[Kamailio-Users] lcr module creating extra branch
by Jon Bonilla 09 Apr '10

09 Apr '10

Hi I am using Kamailio 3.0.1 and experiencing a strange behaviour of the lcr module. In short: Using next_gw() function makes my server to send two INVITEs to different destinations! The INVITE Kamailio receives is like: R=sip:4644235465675757@77.77.77.77 F=sip:manwe2@77.77.77.77 T=sip:4644235465675757@77.77.77.77 To try this I have set this in my gw table: sercmd lcr.dump_gws { lcr_id: 1 grp_id: 17 ip_addr: 91.121.117.27 hostname: sindominio.net port: 5080 scheme: sip transport: UDP strip: 0 tag: weight: 1 flags: 37 defunct_until: 268313248 } sercmd lcr.dump_lcrs { lcr_id: 1 prefix: from_uri: grp_id: 17 priority: 1 } Hostname and ip_addr don't match (sindominio.net points to 82.144.4.26). What I capture leaving Kamailio is: U 2010/04/08 17:51:09.614055 77.77.77.77:5060 -> 91.121.117.27:5080 INVITE sip:+4644235465675757@77.77.77.77 SIP/2.0' Record-Route: <sip:77.77.77.77;lr=on;ftag=hgtcn;nat=yes;vsf=czFwOgs5JCAEJEYoJGk3ajxNYmBrPBYC>' Via: SIP/2.0/UDP 77.77.77.77;branch=z9hG4bK90e8.cd3135e1.0' Via: SIP/2.0/UDP 10.0.0.92;received=91.115.172.34;rport=53658;branch=z9hG4bKiwibmejv' Max-Forwards: 69' To: <sip:4644235465675757@77.77.77.77>' From: "1102" <sip:1102@77.77.77.77>;tag=hgtcn' Call-ID: qxvyddwlnmurqvi@multivac' CSeq: 571 INVITE' Contact: <sip:manwe2@91.115.172.34:53658>' Content-Type: application/sdp' Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE' Supported: replaces,norefersub,100rel' User-Agent: Twinkle/1.4.2' Content-Length: 226' ' v=0' o=twinkle 1296734594 70729915 IN IP4 77.77.77.77' s=-' c=IN IP4 77.77.77.77' t=0 0' m=audio 38232 RTP/AVP 8 101' a=rtpmap:8 PCMA/8000' a=rtpmap:101 telephone-event/8000' a=fmtp:101 0-15' a=ptime:20' a=nortpproxy:yes' # U 2010/04/08 17:51:09.614074 77.77.77.77:5060 -> 82.144.4.26:5060 INVITE sip:+4644235465675757@sindominio.net SIP/2.0' Record-Route: <sip:77.77.77.77;lr=on;ftag=hgtcn;nat=yes;vsf=czFwOgs5JCAEJEYoJGk3ajxNYmBrPBYC>' Via: SIP/2.0/UDP 77.77.77.77;branch=z9hG4bK90e8.cd3135e1.1' Via: SIP/2.0/UDP 10.0.0.92;received=91.115.172.34;rport=53658;branch=z9hG4bKiwibmejv' Max-Forwards: 69' To: <sip:4644235465675757@77.77.77.77>' From: "1102" <sip:1102@77.77.77.77>;tag=hgtcn' Call-ID: qxvyddwlnmurqvi@multivac' CSeq: 571 INVITE' Contact: <sip:manwe2@91.115.172.34:53658>' Content-Type: application/sdp' Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE' Supported: replaces,norefersub,100rel' User-Agent: Twinkle/1.4.2' Content-Length: 226' ' v=0' o=twinkle 1296734594 70729915 IN IP4 77.77.77.77' s=-' c=IN IP4 77.77.77.77' t=0 0' m=audio 38232 RTP/AVP 8 101' a=rtpmap:8 PCMA/8000' a=rtpmap:101 telephone-event/8000' a=fmtp:101 0-15' a=ptime:20' a=nortpproxy:yes' My kamailio.cfg script does something like this: if(!load_gws("1", "$ru")) ... if(!next_gw()) ... t_on_branch("BRANCH_ROUTE_CLI_RTP"); if(!t_relay_to("0x01")) ... Branch route_cli_rtp: do rtpproxy stuff No append_branch is executed at all. I have two INVITES IMHO because next_gw() function does create the second one. Any idea about this behaviour?

3 10

[Kamailio-Users] sr-docs mailing list
by Daniel-Constantin Mierla 09 Apr '10

09 Apr '10

Hello, I renamed kamailio-docs(a)lists.kamailio.org to sr-docs(a)lists.sip-router.org. Info about it at: http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-docs Lately, several discussions touched the documentation aspects, in a need for a better structuring and updates for the new context of sip router project. The old mailing list was active for a while, but with the start of sip router project was ignored because of more focus on integration work. I hope some of you will join, help to build new documentation and spot mistakes in existing versions. Volunteers that want to lead various documentation efforts are more than welcome! Just say what you need... Thanks, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ * http://twitter.com/miconda * http://www.linkedin.com/in/danielconstantinmierla

1 0

[Kamailio-Users] Kamailio Blocking
by dotnetdub 09 Apr '10

09 Apr '10

Hello List, I have been running a very stable Kamailio 1.4 install for over a year now with no downtime. From time to time I get a message from the OS telling me that task kamailio:xxxx blocked for more than 120 seconds and a dump into syslog. I recently setup Kamailio 3.01 and it's been running for around 3 weeks now. Purely testing at the moment, there is only 1 SIP registration and almost no activity most of the time. I was checking dmesg and: [269844.208011] INFO: task kamailio:28504 blocked for more than 120 seconds. [269844.208093] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [269844.208178] kamailio D f6d77bf8 0 28504 28484 [269844.208180] f771e140 00000082 00000002 f6d77bf8 f7091390 f771e2cc c4019020 00000000 [269844.208184] 00000000 011615c9 f7091398 00000282 00000000 00000000 00000000 ffffffff [269844.208188] f5cba384 f5cba38c f5cba388 f771e140 c02c91ec f6969d68 f5cba38c f771e140 [269844.208191] Call Trace: [269844.208203] [<c02c91ec>] __mutex_lock_slowpath+0x50/0x7b [269844.208208] [<c02c9082>] mutex_lock+0xa/0xb [269844.208210] [<c02b7d4d>] unix_dgram_recvmsg+0x3e/0x231 [269844.208214] [<c0161beb>] get_page_from_freelist+0xc1/0x3e9 [269844.208218] [<c0161045>] __rmqueue_smallest+0x83/0xe3 [269844.208221] [<c025f771>] sock_recvmsg+0xde/0xf9 [269844.208226] [<c01387b0>] autoremove_wake_function+0x0/0x2d [269844.208231] [<c01620e9>] __alloc_pages_internal+0xb5/0x34e [269844.208236] [<c0260595>] sys_recvfrom+0xb4/0x116 [269844.208239] [<c011af13>] do_page_fault+0x0/0x8f9 [269844.208242] [<c0108540>] do_notify_resume+0x5f8/0x649 [269844.208247] [<c011b3c5>] do_page_fault+0x4b2/0x8f9 [269844.208250] [<c0260a48>] sys_socketcall+0x135/0x19e [269844.208254] [<c0108853>] sysenter_past_esp+0x78/0xb1 [269844.208257] [<c02c0000>] xenfb_probe+0xd1/0x35b [269844.208261] ======================= [269844.208262] INFO: task kamailio:28506 blocked for more than 120 seconds. [269844.208314] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [269844.208395] kamailio D d0e00947 0 28506 28484 [269844.208397] f77f8e60 00000082 00000002 d0e00947 00004292 f77f8fec c4024020 00000001 [269844.208401] 00000000 00000001 00000002 00000000 f7091398 00000001 00000001 c01211f2 [269844.208404] f5cba384 f5cba38c f5cba388 f77f8e60 c02c91ec f5cba38c f60add68 f77f8e60 [269844.208408] Call Trace: [269844.208410] [<c01211f2>] __wake_up_sync+0x2a/0x3e [269844.208413] [<c02c91ec>] __mutex_lock_slowpath+0x50/0x7b [269844.208416] [<c02c9082>] mutex_lock+0xa/0xb [269844.208418] [<c02b7d4d>] unix_dgram_recvmsg+0x3e/0x231 [269844.208421] [<c0161beb>] get_page_from_freelist+0xc1/0x3e9 [269844.208424] [<c0161045>] __rmqueue_smallest+0x83/0xe3 [269844.208427] [<c025f771>] sock_recvmsg+0xde/0xf9 [269844.208431] [<c01387b0>] autoremove_wake_function+0x0/0x2d [269844.208435] [<c01620e9>] __alloc_pages_internal+0xb5/0x34e [269844.208440] [<c0260595>] sys_recvfrom+0xb4/0x116 [269844.208444] [<c0180d0d>] cp_new_stat64+0xfc/0x10e [269844.208449] [<c011b3c5>] do_page_fault+0x4b2/0x8f9 [269844.208452] [<c0260a48>] sys_socketcall+0x135/0x19e [269844.208456] [<c0108853>] sysenter_past_esp+0x78/0xb1 [269844.208459] [<c02c0000>] xenfb_probe+0xd1/0x35b [269844.208462] ======================= [274198.229285] INFO: task kamailio:28504 blocked for more than 120 seconds. [274198.229340] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [274198.229422] kamailio D f6d77bf8 0 28504 28484 [274198.229425] f771e140 00000082 00000002 f6d77bf8 f7091390 f771e2cc c4019020 00000000 [274198.229429] 00000000 011615c9 f7091398 00000282 00000000 00000000 00000000 ffffffff [274198.229432] f5cba384 f5cba38c f5cba388 f771e140 c02c91ec f6969d68 f5cba38c f771e140 [274198.229436] Call Trace: [274198.229447] [<c02c91ec>] __mutex_lock_slowpath+0x50/0x7b [274198.229453] [<c02c9082>] mutex_lock+0xa/0xb [274198.229455] [<c02b7d4d>] unix_dgram_recvmsg+0x3e/0x231 [274198.229459] [<c0161beb>] get_page_from_freelist+0xc1/0x3e9 [274198.229463] [<c0161045>] __rmqueue_smallest+0x83/0xe3 [274198.229466] [<c025f771>] sock_recvmsg+0xde/0xf9 [274198.229471] [<c01387b0>] autoremove_wake_function+0x0/0x2d [274198.229476] [<c01620e9>] __alloc_pages_internal+0xb5/0x34e [274198.229481] [<c0260595>] sys_recvfrom+0xb4/0x116 [274198.229484] [<c011af13>] do_page_fault+0x0/0x8f9 [274198.229487] [<c0108540>] do_notify_resume+0x5f8/0x649 [274198.229492] [<c011b3c5>] do_page_fault+0x4b2/0x8f9 [274198.229495] [<c0260a48>] sys_socketcall+0x135/0x19e [274198.229499] [<c0108853>] sysenter_past_esp+0x78/0xb1 [274198.229502] [<c02c0000>] xenfb_probe+0xd1/0x35b [274198.229506] ======================= [274198.229507] INFO: task kamailio:28506 blocked for more than 120 seconds. [274198.229559] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [274198.229641] kamailio D d0e00947 0 28506 28484 [274198.229643] f77f8e60 00000082 00000002 d0e00947 00004292 f77f8fec c4024020 00000001 [274198.229646] 00000000 00000001 00000002 00000000 f7091398 00000001 00000001 c01211f2 [274198.229650] f5cba384 f5cba38c f5cba388 f77f8e60 c02c91ec f5cba38c f60add68 f77f8e60 [274198.229653] Call Trace: [274198.229656] [<c01211f2>] __wake_up_sync+0x2a/0x3e [274198.229659] [<c02c91ec>] __mutex_lock_slowpath+0x50/0x7b [274198.229662] [<c02c9082>] mutex_lock+0xa/0xb [274198.229664] [<c02b7d4d>] unix_dgram_recvmsg+0x3e/0x231 [274198.229667] [<c0161beb>] get_page_from_freelist+0xc1/0x3e9 [274198.229670] [<c0161045>] __rmqueue_smallest+0x83/0xe3 [274198.229673] [<c025f771>] sock_recvmsg+0xde/0xf9 [274198.229677] [<c01387b0>] autoremove_wake_function+0x0/0x2d [274198.229681] [<c01620e9>] __alloc_pages_internal+0xb5/0x34e [274198.229686] [<c0260595>] sys_recvfrom+0xb4/0x116 [274198.229690] [<c0180d0d>] cp_new_stat64+0xfc/0x10e [274198.229696] [<c011b3c5>] do_page_fault+0x4b2/0x8f9 [274198.229699] [<c0260a48>] sys_socketcall+0x135/0x19e [274198.229703] [<c0108853>] sysenter_past_esp+0x78/0xb1 [274198.229706] [<c02c0000>] xenfb_probe+0xd1/0x35b There was no activity when this happened. ON the 1.4 box there could be about 10 sessions setup when it happens. kamctl ps: Process:: ID=14 PID=28504 Type=MI DATAGRAM Process:: ID=15 PID=28505 Type=MI DATAGRAM Process:: ID=16 PID=28506 Type=MI DATAGRAM Even on the old install this doesn't seem to cause any problem and same here on 3.01 but would like to try and solve it. Any idea? Regards, Stephen

4 5

[Kamailio-Users] fr_inv_timer in kam-3.0
by Andreas Granig 09 Apr '10

09 Apr '10

Hi, In the docs at http://kamailio.org/docs/modules/3.0.x/modules/tm.html#fr_inv_timer it says that fr_inv_timer_avp should be defined like this, without $ or $avp: modparam("tm", "fr_inv_timer_avp", "my_fr_inv_timer") In kam <= 1.5 I did it like that: modparam("tm", "fr_inv_timer_avp", "$avp(s:callee_fr_inv_timer)") which doesn't give me an error on startup with kam-3.0 either, but the timer doesn't get fired (I use seconds for that as noted in the docs). If I change it to modparam("tm", "fr_inv_timer_avp", "callee_fr_inv_timer") then I get the error "malformed or non AVP callee_fr_inv_timer AVP definition", same with setting it to "s:callee_fr_inv_timer". Anyhow, it seems to be deprecated anyways, so I'm looking to get t_set_fr() working. I'm just curious how I can use a var or AVP loaded from DB to set the value on-the-fly? t_set_fr(...) seems to allow only constants to be set. Couldn't find anything in the docs regarding that one. Thanks, Andreas

5 14

[Kamailio-Users] drop in branch/onsend-route in kam-3.0
by Andreas Granig 08 Apr '10

08 Apr '10

Hi, Looks like behavior of drop has changed in Kamailio 3.0. Before, I was able to drop() a specific branch in branch_route depending on various checks. http://www.kamailio.org/dokuwiki/doku.php/core-cookbook:3.0.x#drop still says this is possible, http://kamailio.org/docs/modules/3.0.x/modules/tm.html#t_on_branch says it's not possible. So calling drop() in branch_route has no effect, and I have no idea how to mark a branch in branch_route to be dropped in onsend_route, because checking a bflag doesn't work there, and neither does checking $rU. Any ideas on how to accomplish dropping a specific branch? Andreas

5 7

[Kamailio-Users] Understanding memory-leaks by inspecting PKG/SHM memory status at shutdown
by Iñaki Baz Castillo 08 Apr '10

08 Apr '10

Hi, according to the wiki page: http://www.kamailio.org/dokuwiki/doku.php/troubleshooting:memory In order to detect a possible memory leak (in PGK or SHM) a good way is enabling memory debugging and shuting down the server, so: "the memory manager will dump the memory status. Normally most of the memory is cleaned during shutdown. If there is memory leak, it should be visible as not-freed memory." But I would like to know how exactly to detect if there is a memoty leak by inspecting the SHM/PKG status, something like this: ----------------------------------------------------------------------------------------------------------------------------- [32715]: Memory status (pkg): [32715]: fm_status (0x701a40): [32715]: heap size= 16777216 [32715]: used= 189696, used+overhead=247392, free=16529824 [32715]: max used (+overhead)= 247392 [32715]: dumping free list: [32715]: hash = 1 fragments no.: 1, unused: 0#012#011#011 bucket size: 8 - 8 (first 8) [32715]: hash = 2058 fragments no.: 1, unused: 0#012#011#011 bucket size: 8388608 - 16777216 (first 16530136) [32715]: TOTAL: 2 free fragments = 16530144 free bytes [32678]: Memory status (shm): [32678]: fm_status (0x7fa57921c000): [32678]: heap size= 67108864 [32678]: used= 16, used+overhead=35872, free=67072992 [32678]: max used (+overhead)= 2821064 [32678]: dumping free list: [32678]: hash = 1 fragments no.: 45, unused: 0#012#011#011 bucket size: 8 - 8 (first 8) [32678]: hash = 2 fragments no.: 4, unused: 0#012#011#011 bucket size: 16 - 16 (first 16) [32678]: hash = 3 fragments no.: 16, unused: 0#012#011#011 bucket size: 24 - 24 (first 24) [32678]: hash = 4 fragments no.: 2, unused: 0#012#011#011 bucket size: 32 - 32 (first 32) [32678]: hash = 5 fragments no.: 1, unused: 0#012#011#011 bucket size: 40 - 40 (first 40) [32678]: hash = 6 fragments no.: 1, unused: 0#012#011#011 bucket size: 48 - 48 (first 48) [32678]: hash = 7 fragments no.: 39, unused: 0#012#011#011 bucket size: 56 - 56 (first 56) [32678]: hash = 8 fragments no.: 1, unused: 0#012#011#011 bucket size: 64 - 64 (first 64) [32678]: hash = 9 fragments no.: 1, unused: 0#012#011#011 bucket size: 72 - 72 (first 72) [32678]: hash = 10 fragments no.: 2, unused: 0#012#011#011 bucket size: 80 - 80 (first 80) [32678]: hash = 15 fragments no.: 1, unused: 0#012#011#011 bucket size: 120 - 120 (first 120) [32678]: hash = 25 fragments no.: 1, unused: 0#012#011#011 bucket size: 200 - 200 (first 200) [32678]: hash = 40 fragments no.: 5, unused: 0#012#011#011 bucket size: 320 - 320 (first 320) [32678]: hash = 112 fragments no.: 1, unused: 0#012#011#011 bucket size: 896 - 896 (first 896) [32678]: hash = 128 fragments no.: 4, unused: 0#012#011#011 bucket size: 1024 - 1024 (first 1024) [32678]: hash = 129 fragments no.: 2, unused: 0#012#011#011 bucket size: 1032 - 1032 (first 1032) [32678]: hash = 224 fragments no.: 1, unused: 0#012#011#011 bucket size: 1792 - 1792 (first 1792) [32678]: hash = 258 fragments no.: 3, unused: 0#012#011#011 bucket size: 2064 - 2064 (first 2064) [32678]: hash = 473 fragments no.: 1, unused: 0#012#011#011 bucket size: 3784 - 3784 (first 3784) [32678]: hash = 1026 fragments no.: 1, unused: 0#012#011#011 bucket size: 8208 - 8208 (first 8208) [32678]: hash = 2049 fragments no.: 2, unused: 0#012#011#011 bucket size: 16384 - 32768 (first 16512) [32678]: hash = 2051 fragments no.: 1, unused: 0#012#011#011 bucket size: 65536 - 131072 (first 98336) [32678]: hash = 2056 fragments no.: 1, unused: 0#012#011#011 bucket size: 2097152 - 4194304 (first 2621440) [32678]: hash = 2060 fragments no.: 1, unused: 0#012#011#011 bucket size: 33554432 - 67108864 (first 64287800) [32678]: TOTAL: 137 free fragments = 67072992 free bytes ----------------------------------------------------------------------------------------------------------------------------- This is, how should look this SHM/PKG status example (after shutdown) in case there is a memory leak? how to detect not-freed memory? Thanks a lot. -- Iñaki Baz Castillo <ibc(a)aliax.net>

2 5

[Kamailio-Users] irc devel meeting
by Daniel-Constantin Mierla 08 Apr '10

08 Apr '10

Hello, I know some of devels are still in Easter vacation, but I hope we can get together soon on irc to sketch the plan for 3.1 release. I propose next week, Wednesday, April 14, 15:00UTC, on #sip-router channel hosted by irc.freenode.net If you are a developer and want to participate, please announce. If it is not possible to attend for major contributors, we can look for another date (eventually start a pool to see the day were most of us are available). Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ * http://twitter.com/miconda * http://www.linkedin.com/in/danielconstantinmierla

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