sr-users July 2009

sr-users@lists.kamailio.org

71 participants
104 discussions

[Serusers] call limit (capacity) per gateway

by Ilya Pichugin

Hi all! How can I set call limit (capacity) per gateway? What module does provide this feature? Thanks a lot. --------------- Ilya Pichugin i.pichugin(a)ptl.ru

15 years

[Kamailio-Users] nonce_reuse protection issues

by Klaus Darilion

Hi! I really wonder if the nonce_reuse protection feature is useful and if anybody uses it without problems. One problem I have is with retransmission: e.g: ----INV1 ---> <---407------ ----ACK-----> ----INV2------> here happens a delay to the INVITE (e.g. jam in the access uplink, SIP proxy slow, ... whatever) which causes a retransmission of the INVITE ----INV3------> (retransmission of INV2) the proxy processes INV2, authenticates the user successful and forwards the requests then the proxy processes INV3, finds out that the nonce is reused and sends back 407 --> client gives up, but the request was also forwarded by the proxy :-( How do you handle such a scenario? Do you always create the transaction before authentication? One other thing I just found out is that reuse-check is done after successful authentication - shouldn't it be done the other way round? regards Klaus

15 years

Re: [Kamailio-Users] received=IP added in Via

by Klaus Darilion

Hi! catalina oancea schrieb: > No, actually the value in the received parameter is not equal to the > IP in the Via. I looked in the code and this seems to be the intended > behavior. It would be nice to be able to disable it, but I don't think > there is one. Then it is standard conform. If the request is received from a different address then advertised, this parameter must be added. This is because SIP requires to send the response to the IP address from which the request was received. regards klaus > > Thanks anyway > Catalina > > > 2009/7/16 Klaus Darilion <klaus.mailinglists(a)pernau.at>: >> catalina oancea wrote: >>> Form what I found in >>> http://lists.kamailio.org/pipermail/devel/2008-August/015080.html, it >>> seems to me that it's a bug that kamailio adds received=IP parameter >>> although force_rport was not called. >> The bug was something else. >> >>>> Does anybody know how to disable the received=IP Via parameter that is >>>> added by default from kamailio? For the case I want to disable it in, >>>> I have no NAT handling. Also, I have: >>>> dns=no >>>> rev_dns=no >> >> In this case "received" will only be added if the advertised IP is different >> than the IP from which the request was received. (according to RFC). >> >> So, you do not use rport but kamailio adds the received parameter and the >> value in the received parameter is identical to the IP in the Via? >> >> regards >> klaus >>

15 years

[Kamailio-Users] sanity_check question

by Dubravko Caric

Hi all, I have a question regarding sanity module (kamailio 1.5.1). Module documentation says "The function returns true if one of the checks failed", but as you can see in case 1 (request is valid) and case 2 (request is not valid because bad request uri) requests always enter function block. Does anybody else have the same problem? Any help would be appreciated... Thanks a lot /dubravko *Case 1:* if (is_method("REGISTER")) { xlog("L_INFO", "ENTER REGISTER\n"); if (sanity_check("128","6")) { xlog("L_NOTICE", "SANITY $si:$sp TIME $Tf USER $fu METHOD $rm\n"); exit; } } ENTER REGISTER Jul 20 13:30:13 [8180] DBG:core:parse_headers: flags=2000 Jul 20 13:30:13 [8180] DBG:core:get_hdr_field: cseq <CSeq>: <1> <REGISTER> Jul 20 13:30:13 [8180] DBG:core:get_hdr_field: content_length=0 Jul 20 13:30:13 [8180] DBG:core:parse_headers: flags=ffffffffffffffff Jul 20 13:30:13 [8180] DBG:core:get_hdr_field: found end of header Jul 20 13:30:13 [8180] DBG:sanity:sanity_check: all sanity checks passed SANITY xxx.xxx.xxx.xxx:22355 TIME Mon Jul 20 13:30:13 2009 USER sip:bob@exmaple.com METHOD REGISTER Jul 20 13:30:13 [8180] DBG:core:destroy_avp_list: destroying list (nil) Jul 20 13:30:13 [8180] DBG:core:receive_msg: cleaning up *Case 2:* ... if (sanity_check("130","6")) { ... ENTER REGISTER Jul 20 13:34:06 [8226] WARNING:sanity:check_ruri_scheme: failed to parse request uri Jul 20 13:34:06 [8226] DBG:core:parse_headers: flags=2000 Jul 20 13:34:06 [8226] DBG:core:get_hdr_field: cseq <CSeq>: <1> <REGISTER> Jul 20 13:34:06 [8226] DBG:core:get_hdr_field: content_length=0 Jul 20 13:34:06 [8226] DBG:core:parse_headers: flags=ffffffffffffffff Jul 20 13:34:06 [8226] DBG:core:get_hdr_field: found end of header Jul 20 13:34:06 [8226] SANITY xxx.xxx.xxx.xxx:22359 TIME Mon Jul 20 13:34:06 2009 USER sip:bob@exmaple.com METHOD REGISTER Jul 20 13:34:06 [8226] DBG:core:destroy_avp_list: destroying list (nil) Jul 20 13:34:06 [8226] DBG:core:receive_msg: cleaning up

15 years

[Kamailio-Users] Runtime errors from libpurple when using purple module

by German Becker

Hi, I'm trying to test the purple module, and I am getting the following runtime errors, which I think are generated by libpurple: ** (process:13916): CRITICAL **: x509_tls_peers_init: assertion `ret == 0' failed ** (process:13916): CRITICAL **: purple_presence_set_status_active: assertion `status != NULL' failed ** (process:13916): CRITICAL **: purple_presence_set_status_active: assertion `status != NULL' failed ** (process:13916): CRITICAL **: purple_presence_is_online: assertion `presence != NULL' failed ** (process:13916): CRITICAL **: purple_status_type_get_attr: assertion `status_type != NULL' failed ** (process:13916): CRITICAL **: purple_status_type_get_id: assertion `status_type != NULL' failed ** (process:13916): CRITICAL **: purple_account_set_status_list: assertion `status_id != NULL' failed ** (process:13916): CRITICAL **: purple_status_type_get_attr: assertion `status_type != NULL' failed ** (process:13916): CRITICAL **: purple_status_type_get_id: assertion `status_type != NULL' failed ** (process:13916): CRITICAL **: purple_account_set_status_list: assertion `status_id != NULL' failed Attached the logfile. Any ideas about what might be causing this? I'm using version 1.5.0

15 years

Re: [Kamailio-Users] 603 goes to onreply_route?

by catalina oancea

Even if I don't activate reply_route, it still doesn't use the failure route. I also tried 503 and 403, for these replies kamailio goes through both reply and failure routes. 2009/7/17 Klaus Darilion <klaus.mailinglists(a)pernau.at>: > > > catalina oancea schrieb: >> >> In my case, when 603 reply arrives, only the reply route is triggered. >> I added debug messages in both reply and failure routes and only the >> one in reply route is printed. > > What happens if you do not activated the reply_route. Is then the > failure_route called? > > Is it only for 603 or for all responses >400 ? > > regards > klaus > >> >> >> 2009/7/17 Klaus Darilion <klaus.mailinglists(a)pernau.at>: >>> >>> catalina oancea schrieb: >>>> >>>> Hello >>>> >>>> From my tests I found the following situation: >>>> >>>> Kamailio ------INVITE----------> I set t_on_failure and t_on_reply >>>> Kamailio <----100 Trying------- >>>> Kamailio <----603 Declined--- Here the reply goes in onreply_route (I >>>> added an xlog to prove it), not failure_route as expected. Is this the >>>> intended behavior or is it a bug (if it's a bug I can provide more >>>> details)? >>> >>> IIRC both routes should be executed. >>> >>> regards >>> klaus >>> >

15 years

[Kamailio-Users] 603 goes to onreply_route?

by catalina oancea

Hello >From my tests I found the following situation: Kamailio ------INVITE----------> I set t_on_failure and t_on_reply Kamailio <----100 Trying------- Kamailio <----603 Declined--- Here the reply goes in onreply_route (I added an xlog to prove it), not failure_route as expected. Is this the intended behavior or is it a bug (if it's a bug I can provide more details)? Thanks, Catalina

15 years

Re: [Kamailio-Users] Problem upgrading from 1.4.x to 1.5.1 notls

by Henning Westerholt

On Donnerstag, 16. Juli 2009, Uriel Rozenbaum wrote: > I downloaded 1.5.2-notls and installed it. Hello Uriel, > The issue was fixed but I get the following: > Jul 16 16:56:52 sbci1pri /opt/kamailio/sbin/kamailio[3921]: > INFO:core:init_mod: initializing module exec > Jul 16 16:56:52 sbci1pri /opt/kamailio/sbin/kamailio[3921]: > ERROR:carrierroute:domain_fixup: could not find domain name '0' in map you need to specify the domain name, not the id. The id is used internally, the name is what is visible external. > [..] > In domain_name table i have this configured: > id domain > 0 domain0 > 1 domain1 Just try "domain0" as parameter. Cheers, Henning

15 years

Re: [Kamailio-Users] received=IP added in Via

by catalina oancea

No, actually the value in the received parameter is not equal to the IP in the Via. I looked in the code and this seems to be the intended behavior. It would be nice to be able to disable it, but I don't think there is one. Thanks anyway Catalina > 2009/7/16 Klaus Darilion <klaus.mailinglists(a)pernau.at>: >> catalina oancea wrote: >>> >>> Form what I found in >>> http://lists.kamailio.org/pipermail/devel/2008-August/015080.html, it >>> seems to me that it's a bug that kamailio adds received=IP parameter >>> although force_rport was not called. >> >> The bug was something else. >> >>>> Does anybody know how to disable the received=IP Via parameter that is >>>> added by default from kamailio? For the case I want to disable it in, >>>> I have no NAT handling. Also, I have: >>>> dns=no >>>> rev_dns=no >> >> >> In this case "received" will only be added if the advertised IP is different >> than the IP from which the request was received. (according to RFC). >> >> So, you do not use rport but kamailio adds the received parameter and the >> value in the received parameter is identical to the IP in the Via? >> >> regards >> klaus >> >

15 years

[Kamailio-Users] Kamailio Revision: 5487 1.4.3-notls (x86_64) -m 4096 -- Crashing Randomly

by Brandon Armstead

Hey guys, Here is the response from backtrace: Core was generated by `/sbin/kamailio -P /var/run/kamailio.pid -m 4096'. Program terminated with signal 11, Segmentation fault. [New process 29118] #0 0x00007f37499be44d in relay_reply (t=0x7f3645019f88, p_msg=0x857350, branch=0, msg_status=487, cancel_bitmap=0x7fff53aa3428) at t_reply.c:1101 1101 relayed_code=relayed_msg->REPLY_STATUS; (gdb) bt #0 0x00007f37499be44d in relay_reply (t=0x7f3645019f88, p_msg=0x857350, branch=0, msg_status=487, cancel_bitmap=0x7fff53aa3428) at t_reply.c:1101 #1 0x00007f37499bf8fb in reply_received (p_msg=0x857350) at t_reply.c:1404 #2 0x00000000004218fc in forward_reply (msg=0x857350) at forward.c:507 #3 0x000000000045cf35 in receive_msg ( buf=0x744aa0 "SIP/2.0 487 Request Terminated\r\nTo: <sip:+1XXXXXXXXXX@PSTN:5060>;tag=63c9393246a9a5d6i0\r\nFrom: \"XXXXX X & X \" <sip:XXXXXXXXXX@PSTN>;tag=VPSF506071629460\r\nCall-ID: STMMGC012009071521"..., len=997, rcv_info=0x7fff53aa3520) at receive.c:203 #4 0x000000000049c486 in udp_rcv_loop () at udp_server.c:449 #5 0x000000000042882b in main (argc=<value optimized out>, argv=<value optimized out>) at main.c:780 As far as syslog/kernel message: Jul 15 21:07:28 sip-XXXX kernel: [526828.616918] kamailio[29118]: segfault at 40 ip 7f37499be44d sp 7fff53aa32b0 error 4 in tm.so[7f374997f000+4d000] The server load seems to randomly jump to ~ 8 - 10 and this happens, any thoughts / help is appreciated, thanks! One other thing that may be relevant, is we have disabled TCP support on this proxy, because previously (I have another mailing list thread) about, with TCP enabled kamailio will not start due to epoll alloc failure, thanks!

15 years

← Newer
1
2
3
4
5
6
7
8
...
11
Older →

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 July 2009