sr-users October 2010

sr-users@lists.kamailio.org

77 participants
157 discussions

tm.t_uac_wait asynchronous?
by Alex Balashov 24 Nov '10

24 Nov '10

Does tm.t_uac_wait RPC call block a worker process while waiting for a reply, or use some sort of asynchronous callback? Thanks, -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/

2 1

Problem with Kamailio not routing ACK to a 200 OK
by Morten Isaksen 15 Nov '10

15 Nov '10

Hi, I have a strange problem with Kamailio 3.0.2. When one of our end users makes a call Kamailio does not route the ACK (in response to the 200 OK). For all other end users it works fine. For me it looks the the has_totag() checks for some reason fails and then t_check_trans() thinks it is a ACK to a local transactions and then terminates the script. Otherwise there should be more lines in the log file. The conf is pretty standard. route{ xlog("L_WARN", "New request - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); xlog("L_WARN", "ua=$ua"); if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if(!sanity_check("1511", "7")) { xlog("Malformed SIP message from $si:$sp\n"); exit; } if (has_totag()) { xlog("L_WARN", "has_totag start - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { xlog("L_WARN", "loose_route - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); route(RELAY); } else { if (is_method("SUBSCRIBE") && uri == myself) { # in-dialog subscribe requests #route(PRESENCE); exit; } if ( is_method("ACK") ) { if ( t_check_trans() ) { xlog("L_WARN", "ACK t_check_trans - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); # non loose-route, but stateful ACK; must be an ACK after a 487 or e.g. 404 from upstream server t_relay(); exit; } else { xlog("Ignoring ACK - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); # ACK without matching transaction ... ignore and discard.\n"); exit; } } sl_send_reply("404","Not here"); } xlog("L_WARN", "has_totag end - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); exit; } #initial requests # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) t_relay(); exit; } setflag(4); t_check_trans(); ... The log files show: Oct 28 10:51:13 sip-core-1 /usr/local/sbin/kamailio[10503]: WARNING: <script>: New request - M=ACK RURI=sip:1105@178.21.248.56:5060 F=sip:87776688@sip.uni-tel.dk T=sip:869 87106(a)sip.uni-tel.dk IP=178.21.248.20 ID=AI231CA9BD0A4A1C53(a)10.0.0.150 Oct 28 10:51:13 sip-core-1 /usr/local/sbin/kamailio[10503]: WARNING: <script>: ua=Aastra Intelligate The trace U 2010/10/28 10:51:02.616337 178.21.248.7:5060 -> 178.21.248.56:5060 INVITE sip:86987106@178.21.248.56 SIP/2.0. Record-Route: <sip:178.21.248.7;lr;ftag=AI8DA85D59B9B6634F;did=f48.5fd1db02>. Record-Route: <sip:178.21.248.20;lr;ftag=AI8DA85D59B9B6634F>. Via: SIP/2.0/UDP 178.21.248.7;branch=z9hG4bK690c.9cfea506.0. Via: SIP/2.0/UDP 178.21.248.20;branch=z9hG4bK690c.97354e4.0. Via: SIP/2.0/UDP 87.104.233.108:5060;rport=5060;branch=z9hG4bK3c70fae55c8b362ff34e6c782cc21592. To: <sip:86987106@sip.uni-tel.dk>. From: <sip:87776688@sip.uni-tel.dk>;tag=AI8DA85D59B9B6634F. Call-ID: AI231CA9BD0A4A1C53(a)10.0.0.150. CSeq: 2 INVITE. Max-Forwards: 68. Contact: <sip:87776688@87.104.233.108:5060;line=AI7EFC34995E724DD7>. Accept: application/sdp. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER. P-Preferred-Identity: <sip:87776688@sip.uni-tel.dk>. Privacy: none. User-Agent: Aastra Intelligate. Content-Type: application/sdp. Content-Length: 280. X-trunktype: IC. . v=0. o=intelligate 1194032777 1194032777 IN IP4 87.104.233.106. s=call. c=IN IP4 178.21.248.22. t=0 0. m=audio 60984 RTP/AVP 8 0 18 101. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:18 G729/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendrecv. a=ptime:20. # U 2010/10/28 10:51:02.636854 178.21.248.56:5060 -> 178.21.248.7:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 178.21.248.7;branch=z9hG4bK690c.9cfea506.0. Via: SIP/2.0/UDP 178.21.248.20;branch=z9hG4bK690c.97354e4.0. Via: SIP/2.0/UDP 87.104.233.108:5060;rport=5060;branch=z9hG4bK3c70fae55c8b362ff34e6c782cc21592. From: <sip:87776688@sip.uni-tel.dk>;tag=AI8DA85D59B9B6634F. To: <sip:86987106@sip.uni-tel.dk>;tag=1c2073920452. Call-ID: AI231CA9BD0A4A1C53(a)10.0.0.150. CSeq: 2 INVITE. Supported: em,timer,replaces,path,early-session,resource-priority. Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE. Server: Audiocodes-Sip-Gateway-Mediant 2000/v.5.60A.035.002. Content-Length: 0. . ##### U 2010/10/28 10:51:04.134445 178.21.248.56:5060 -> 178.21.248.7:5060 SIP/2.0 183 Session Progress. Via: SIP/2.0/UDP 178.21.248.7;branch=z9hG4bK690c.9cfea506.0. Via: SIP/2.0/UDP 178.21.248.20;branch=z9hG4bK690c.97354e4.0. Via: SIP/2.0/UDP 87.104.233.108:5060;rport=5060;branch=z9hG4bK3c70fae55c8b362ff34e6c782cc21592. From: <sip:87776688@sip.uni-tel.dk>;tag=AI8DA85D59B9B6634F. To: <sip:86987106@sip.uni-tel.dk>;tag=1c2073920452. Call-ID: AI231CA9BD0A4A1C53(a)10.0.0.150. CSeq: 2 INVITE. Contact: <sip:1105@178.21.248.56:5060>. Record-Route: <sip:178.21.248.7;lr;ftag=AI8DA85D59B9B6634F;did=f48.5fd1db02>,<sip:178.21.248.20;lr;ftag=AI8DA85D59B9B6634F>. Supported: em,timer,replaces,path,early-session,resource-priority. Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE. Server: Audiocodes-Sip-Gateway-Mediant 2000/v.5.60A.035.002. Content-Type: application/sdp. Content-Length: 259. . v=0. o=AudiocodesGW 2073965634 2073965290 IN IP4 178.21.248.56. s=Phone-Call. c=IN IP4 178.21.248.56. t=0 0. m=audio 6050 RTP/AVP 8 101. c=IN IP4 178.21.248.56. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. a=sendrecv. # U 2010/10/28 10:51:04.134748 178.21.248.7:5060 -> 178.21.248.20:5060 SIP/2.0 183 Session Progress. Via: SIP/2.0/UDP 178.21.248.20;branch=z9hG4bK690c.97354e4.0. Via: SIP/2.0/UDP 87.104.233.108:5060;rport=5060;branch=z9hG4bK3c70fae55c8b362ff34e6c782cc21592. From: <sip:87776688@sip.uni-tel.dk>;tag=AI8DA85D59B9B6634F. To: <sip:86987106@sip.uni-tel.dk>;tag=1c2073920452. Call-ID: AI231CA9BD0A4A1C53(a)10.0.0.150. CSeq: 2 INVITE. Contact: <sip:1105@178.21.248.56:5060>. Record-Route: <sip:178.21.248.7;lr;ftag=AI8DA85D59B9B6634F;did=f48.5fd1db02>,<sip:178.21.248.20;lr;ftag=AI8DA85D59B9B6634F>. Supported: em,timer,replaces,path,early-session,resource-priority. Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE. Server: Audiocodes-Sip-Gateway-Mediant 2000/v.5.60A.035.002. Content-Type: application/sdp. Content-Length: 259. . v=0. o=AudiocodesGW 2073965634 2073965290 IN IP4 178.21.248.56. s=Phone-Call. c=IN IP4 178.21.248.56. t=0 0. m=audio 6050 RTP/AVP 8 101. c=IN IP4 178.21.248.56. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. a=sendrecv. # U 2010/10/28 10:51:04.136586 178.21.248.56:5060 -> 178.21.248.7:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 178.21.248.7;branch=z9hG4bK690c.9cfea506.0. Via: SIP/2.0/UDP 178.21.248.20;branch=z9hG4bK690c.97354e4.0. Via: SIP/2.0/UDP 87.104.233.108:5060;rport=5060;branch=z9hG4bK3c70fae55c8b362ff34e6c782cc21592. From: <sip:87776688@sip.uni-tel.dk>;tag=AI8DA85D59B9B6634F. To: <sip:86987106@sip.uni-tel.dk>;tag=1c2073920452. Call-ID: AI231CA9BD0A4A1C53(a)10.0.0.150. CSeq: 2 INVITE. Contact: <sip:1105@178.21.248.56:5060>. Record-Route: <sip:178.21.248.7;lr;ftag=AI8DA85D59B9B6634F;did=f48.5fd1db02>,<sip:178.21.248.20;lr;ftag=AI8DA85D59B9B6634F>. Supported: em,timer,replaces,path,early-session,resource-priority. Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE. Server: Audiocodes-Sip-Gateway-Mediant 2000/v.5.60A.035.002. Content-Type: application/sdp. Content-Length: 259. . v=0. o=AudiocodesGW 2073965634 2073965290 IN IP4 178.21.248.56. s=Phone-Call. c=IN IP4 178.21.248.56. t=0 0. m=audio 6050 RTP/AVP 8 101. c=IN IP4 178.21.248.56. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. a=sendrecv. # U 2010/10/28 10:51:04.136837 178.21.248.7:5060 -> 178.21.248.20:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 178.21.248.20;branch=z9hG4bK690c.97354e4.0. Via: SIP/2.0/UDP 87.104.233.108:5060;rport=5060;branch=z9hG4bK3c70fae55c8b362ff34e6c782cc21592. From: <sip:87776688@sip.uni-tel.dk>;tag=AI8DA85D59B9B6634F. To: <sip:86987106@sip.uni-tel.dk>;tag=1c2073920452. Call-ID: AI231CA9BD0A4A1C53(a)10.0.0.150. CSeq: 2 INVITE. Contact: <sip:1105@178.21.248.56:5060>. Record-Route: <sip:178.21.248.7;lr;ftag=AI8DA85D59B9B6634F;did=f48.5fd1db02>,<sip:178.21.248.20;lr;ftag=AI8DA85D59B9B6634F>. Supported: em,timer,replaces,path,early-session,resource-priority. Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE. Server: Audiocodes-Sip-Gateway-Mediant 2000/v.5.60A.035.002. Content-Type: application/sdp. Content-Length: 259. . v=0. o=AudiocodesGW 2073965634 2073965290 IN IP4 178.21.248.56. s=Phone-Call. c=IN IP4 178.21.248.56. t=0 0. m=audio 6050 RTP/AVP 8 101. c=IN IP4 178.21.248.56. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. a=sendrecv. ############################## U 2010/10/28 10:51:12.881179 178.21.248.56:5060 -> 178.21.248.7:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 178.21.248.7;branch=z9hG4bK690c.9cfea506.0. Via: SIP/2.0/UDP 178.21.248.20;branch=z9hG4bK690c.97354e4.0. Via: SIP/2.0/UDP 87.104.233.108:5060;rport=5060;branch=z9hG4bK3c70fae55c8b362ff34e6c782cc21592. From: <sip:87776688@sip.uni-tel.dk>;tag=AI8DA85D59B9B6634F. To: <sip:86987106@sip.uni-tel.dk>;tag=1c2073920452. Call-ID: AI231CA9BD0A4A1C53(a)10.0.0.150. CSeq: 2 INVITE. Contact: <sip:1105@178.21.248.56:5060>. Record-Route: <sip:178.21.248.7;lr;ftag=AI8DA85D59B9B6634F;did=f48.5fd1db02>,<sip:178.21.248.20;lr;ftag=AI8DA85D59B9B6634F>. Supported: em,timer,replaces,path,early-session,resource-priority. Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE. Server: Audiocodes-Sip-Gateway-Mediant 2000/v.5.60A.035.002. Content-Type: application/sdp. Content-Length: 259. . v=0. o=AudiocodesGW 2073965634 2073965290 IN IP4 178.21.248.56. s=Phone-Call. c=IN IP4 178.21.248.56. t=0 0. m=audio 6050 RTP/AVP 8 101. c=IN IP4 178.21.248.56. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. a=sendrecv. # U 2010/10/28 10:51:12.882388 178.21.248.7:5060 -> 178.21.248.20:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 178.21.248.20;branch=z9hG4bK690c.97354e4.0. Via: SIP/2.0/UDP 87.104.233.108:5060;rport=5060;branch=z9hG4bK3c70fae55c8b362ff34e6c782cc21592. From: <sip:87776688@sip.uni-tel.dk>;tag=AI8DA85D59B9B6634F. To: <sip:86987106@sip.uni-tel.dk>;tag=1c2073920452. Call-ID: AI231CA9BD0A4A1C53(a)10.0.0.150. CSeq: 2 INVITE. Contact: <sip:1105@178.21.248.56:5060>. Record-Route: <sip:178.21.248.7;lr;ftag=AI8DA85D59B9B6634F;did=f48.5fd1db02>,<sip:178.21.248.20;lr;ftag=AI8DA85D59B9B6634F>. Supported: em,timer,replaces,path,early-session,resource-priority. Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE. Server: Audiocodes-Sip-Gateway-Mediant 2000/v.5.60A.035.002. Content-Type: application/sdp. Content-Length: 259. . v=0. o=AudiocodesGW 2073965634 2073965290 IN IP4 178.21.248.56. s=Phone-Call. c=IN IP4 178.21.248.56. t=0 0. m=audio 6050 RTP/AVP 8 101. c=IN IP4 178.21.248.56. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. a=sendrecv. ##### <<<<<<<<<<<<<<<<<<<<<< This is the problem packet >>>>>>>>>>>>>>>>>>>>> U 2010/10/28 10:51:13.267863 178.21.248.20:5060 -> 178.21.248.7:5060 ACK sip:1105@178.21.248.56:5060 SIP/2.0. Record-Route: <sip:178.21.248.20;lr;ftag=AI8DA85D59B9B6634F>. Via: SIP/2.0/UDP 178.21.248.20;branch=z9hG4bK690c.97354e4.2. Via: SIP/2.0/UDP 87.104.233.108:5060;rport=5060;branch=z9hG4bK07103fe69c8af048b9b8216eb2f7233f. To: <sip:86987106@sip.uni-tel.dk>;tag=1c2073920452. From: <sip:87776688@sip.uni-tel.dk>;tag=AI8DA85D59B9B6634F. Call-ID: AI231CA9BD0A4A1C53(a)10.0.0.150. CSeq: 2 ACK. Max-Forwards: 69. Route: <sip:178.21.248.7;lr=on;ftag=AI8DA85D59B9B6634F;did=f48.5fd1db02>. User-Agent: Aastra Intelligate. Content-Length: 0. -- Morten Isaksen

2 8

udp_send "Invalid argument"
by Juha Heinanen 04 Nov '10

04 Nov '10

in some of my tests i get the following udp send related errors, when request is t_relayed: Oct 24 11:20:20 test /usr/sbin/sip-proxy[10032]: INFO: Routing initial INVITE <sip:+35892223333@test.fi> to <sip:+35892223333@193.166.3.2;transport=udp> Oct 24 11:20:20 test /usr/sbin/sip-proxy[10032]: ERROR: <core> [udp_server.c:566]: ERROR: udp_send: sendto(sock,0xb2d1f1e8,1190,0,193.166.3.2:5060,16): Invalid argument(22) Oct 24 11:20:20 test /usr/sbin/sip-proxy[10032]: : <core> [udp_server.c:571]: CRITICAL: invalid sendtoparameters one possible reason is the server is bound to localhost and attempts to send to the net Oct 24 11:20:20 test /usr/sbin/sip-proxy[10032]: ERROR: tm [../../forward.h:148]: msg_send: ERROR: udp_send failed Oct 24 11:20:20 test /usr/sbin/sip-proxy[10032]: ERROR: tm [t_fwd.c:1244]: ERROR: t_send_branch: sending request on branch 0 failed $du is set to sip:+35892223333@193.166.3.2;transport=udp and the proxy is listening on many sockets, both 127.0.0.1 and external ip address. any idea what might cause the errors? -- juha

5 8

SMS module not found parameter.
by peter_green lion 02 Nov '10

02 Nov '10

hi all, i am a new bie in kamailio. i use SMS module to send message to GSM net work. my kamailio.cfg is : modparam("sms", "modems", "wavecom[d=/dev/ttyS;c=+84900000022;b=57600; m=new;l=20]") modparam("sms", "networks", "D1[m=10]; d2[m=10]") modparam("sms", "links", "wavecom[D1;d2]") modparam("sms", "default_net", "localhost") modparam("sms", "domain_str", "D1.d2") modparam("sms", "max_sms_parts", 10) modparam("sms", "use_contact", 1) modparam("sms", "sms_report_type", 1) if(method == "MESSAGE"){ if(has_body("text/plain")){ sms_send_msg_to_net("D1"); } } but when i start kamailio the log show : Oct 25 06:28:26 localhost kamailio: ERROR: <core> [modparam.c:143]: set_mod_param_regex: parameter <domain_str> not found in module <sms> Oct 25 06:28:26 localhost kamailio: : <core> [cfg.y:3333]: parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 173, column 42: Can't set module parameter please help to configure it correct. i use wavecom modem and some infomation: baudrate=57600 c=+84900000022 ip server:192.168.1.100 modem connect with server via com1 (/dev/ttyS0) and kamailio version 3.0.2 thanks for help me. Peter Green

2 3

Setting up TLS between proxy and authentication server
by Couprie Geoffroy 01 Nov '10

01 Nov '10

Hello, I am testing TLS communication with Kamailio 3.0.2, and I encounter a strange problem. My setup is like this: Client <-UDP-> Proxy server <- TLS with client certificate authentication -> Authentication server 192.168.24.1 192.168.24.128 192.168.24.129 The two servers are instance of Kamailio 3.0.2 When the client sends a REGISTER, the proxy retransmits the message to the authentication server, which sends back a 401 Unauthorized. But it seems the proxy closes the TLS connexion right after forwarding the REGISTER, and doesn't receive the 401 message. The TLS handshake is OK, and the client certificate is required (I didn't add the verification part yet). The REGISTER message goes through TLS, and is received by the authentication server. Then, the proxy sends a TLS alert (Close-notify), and after that message, the authentication server sends back the 401, and the proxy ignores that message. Could it be caused by a timeout? Is there a way to keep the TLS connection opened? Here are the relevant files (I don't like to send mails of more than 100 lines): authentication server configuration: http://pastebin.com/QBmnNc4e authentication server log: http://pastebin.com/uYdHDG5G proxy server configuration: http://pastebin.com/8WPPJBtM proxy server log: http://pastebin.com/JTwJSKtk I am just testing TLS, so I have tried to remove most of the irrelevant parts. Best regards, Geoffroy ________________________________ Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? du groupe Atos Origin ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

3 5

drop in branch route
by Juha Heinanen 31 Oct '10

31 Oct '10

based on core cookbokk, it is not clear to me what happens when drop is executed in branch route: drop Stop the execution of the configuration script and alter the implicit action which is done afterwards. If the function is called in a 'branch_route' then the branch is discarded (implicit action for 'branch_route' is to forward the request). i understand that request is not forwarded to that branch, but if that branch is the only branch, does t_relay() then return -1 or is script execution terminated? -- juha

1 0

setdebug() and 3.X
by Sergey Okhapkin 30 Oct '10

30 Oct '10

setdebug() function is no longer provided by core. How to change debug level dynamically in the script to trace execution of a few statements only?

3 11

How to log local SIP replies?
by Sergey Okhapkin 30 Oct '10

30 Oct '10

Is there a way to log local replies sent by kamailio? For example, I want to log a reply sent by kamailio in response to REGISTER request.

2 1

Check out Elias's photos on Facebook
by Elias Gitonga 30 Oct '10

30 Oct '10

Hi Serusers, I set up a Facebook profile where I can post my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile. Thanks, Elias To sign up for Facebook, follow the link below: http://www.facebook.com/p.php?i=100001050585836&k=Z6E3Y6W5U2VBWABJPB63QUTTV… Already have an account? Add this email address to your account: http://www.facebook.com/n/?merge_accounts.php&e=serusers%40iptel.org&c=2814… ======================================= serusers(a)iptel.org was invited to join Facebook by Elias Gitonga. If you do not wish to receive this type of email from Facebook in the future, please follow the link below to unsubscribe. http://www.facebook.com/o.php?k=679489&u=100001575534555&mid=335e9d2G5af36e… Facebook, Inc. P.O. Box 10005, Palo Alto, CA 94303

1 0

Re: [SR-Users] setdebug() and 3.X
by Daniel-Constantin Mierla 30 Oct '10

30 Oct '10

On 10/29/10 5:40 PM, Sergey Okhapkin wrote: > I can't test now - high volume traffic is running. But I looked at the diff, it > seems to me OK, I see no reason why it could not work:-) Because of the law, the Murphy law ;-) Probably I will test sometime next week if you don't do it before and then backport. Cheers, Daniel > On Friday 29 October 2010, you wrote: >> On 10/29/10 4:33 PM, Daniel-Constantin Mierla wrote: >>> On 10/29/10 4:09 PM, Sergey Okhapkin wrote: >>>> I just realized that 3.1 executes main routing block when broken SIP >>>> message >>>> is received! But sanity_check() function returns 0 on failed checks >>>> and script >>>> execution stops, my favorite xlog() is not executed. >>> OK, that can be fixed very easy. Iirc, in some cases you don't get the >>> sip message in the config if it is really broken, but I am not sure if >>> error_route was executed for that case anyhow. >> I committed on git master, id: >> >> 39a8108c62a2beafba18417613b9660a8abef86a >> >> >> Can you take the patch and test it on 3.1? If all is fine, then I can >> backport - even the default cfg expects non-drop behavior since it >> attempts to print a log message there. >> >> Cheers, >> Daniel >> >>> Cheers, >>> Daniel >>> >>>> Oct 29 09:48:54 west /usr/local/sbin/kamailio[12225]: ERROR:<core> >>>> [parser/msg_parser.c:177]: ERROR: get_hdr_field: bad to header >>>> Oct 29 09:48:54 west /usr/local/sbin/kamailio[12225]: INFO:<core> >>>> [parser/msg_parser.c:351]: ERROR: bad header field [To: Chi Nhung<sip: >>>> ] >>>> Oct 29 09:48:54 west /usr/local/sbin/kamailio[12225]: ERROR:<core> >>>> [parser/msg_parser.c:177]: ERROR: get_hdr_field: bad to header >>>> Oct 29 09:48:54 west /usr/local/sbin/kamailio[12225]: INFO:<core> >>>> [parser/msg_parser.c:351]: ERROR: bad header field [To: Chi Nhung<sip: >>>> ] >>>> Oct 29 09:48:54 west /usr/local/sbin/kamailio[12225]: ERROR:<core> >>>> [parser/msg_parser.c:177]: ERROR: get_hdr_field: bad to header >>>> Oct 29 09:48:54 west /usr/local/sbin/kamailio[12225]: INFO:<core> >>>> [parser/msg_parser.c:351]: ERROR: bad header field [To: Chi Nhung<sip: >>>> ] >>>> Oct 29 09:48:54 west /usr/local/sbin/kamailio[12225]: ERROR:<core> >>>> [msg_translator.c:1946]: ERROR: build_res_buf_from_sip_req: alas, parse >>>> _headers failed >>>> Oct 29 09:48:54 west /usr/local/sbin/kamailio[12225]: WARNING: sanity >>>> [sanity.c:253]: sanity_check(): check_required_headers(): failed to s >>>> end 400 via sl reply >>>> >>>> On Friday 29 October 2010, Daniel-Constantin Mierla wrote: >>>>> On 10/29/10 11:53 AM, Sergey Okhapkin wrote: >>>>>> Daniel, I think this could be implemented without re-introduction of >>>>>> error_route, >>>>> it will not be re-introduced for sure, we have now a different core >>>>> framework which care reuse event_route mechanism. >>>>> >>>>> In the past the error route was executed when the error was discovered, >>>>> so it several places of the code, and I am not sure that the core can >>>>> continue up to config execution of something is really broken. >>>>> >>>>> I will have it in mind when I get some spare time. >>>>> >>>>> Cheers, >>>>> Daniel >>>>> >>>>>> what about core parameter route_on_error=yes/no (default no)? If >>>>>> route on error is enabled, then sanity module will do the trick: >>>>>> >>>>>> route{ >>>>>> if(!sanity_check("1159")) { >>>>>> xlog("L_INFO","Bad message from >>>>>> $proto:$si:$sp\n$mb\n"); >>>>>> break; >>>>>> } >>>>>> .... >>>>>> >>>>>> It will be up to script writer what to do in main routing block if >>>>>> message parsing fails. >>>>>> >>>>>> On Friday 29 October 2010, Sergey Okhapkin wrote: >>>>>>> It would be nice to get error_route back. The route was trivial in my >>>>>>> cfg file: >>>>>>> >>>>>>> error_route { >>>>>>> xlog("L_INFO","Bad message from $proto:$si:$sp\n$mb\n"); >>>>>>> drop(); >>>>>>> } >>>>>>> >>>>>>> On Friday 29 October 2010, Daniel-Constantin Mierla wrote: >>>>>>>> On 10/28/10 1:41 PM, Sergey Okhapkin wrote: >>>>>>>>> I've found one more feature missed in 3.1 - error_route is >>>>>>>>> eliminated >>>>>>>>> and sanity module added. But if received SIP message is >>>>>>>>> malformed and >>>>>>>>> can't be parsed, routing script is not executed and I have no >>>>>>>>> way to >>>>>>>>> log the message to kamailio log. I did it in error_route before. >>>>>>>>> >>>>>>>>> This logging is important to me to support customers. SIP ALG in >>>>>>>>> routers often breaks Via line :-( >>>>>>>> Since I developed error_route, I remember that it handled just >>>>>>>> sporadic >>>>>>>> cases, but I can add an event_route to pass the buffer and some >>>>>>>> hints >>>>>>>> to configuration file in case the initial parsing fails and the >>>>>>>> message >>>>>>>> is dropped before getting to config file. >>>>>>>> >>>>>>>> It is good to know that someone use such case, introduction of >>>>>>>> sanity >>>>>>>> was clearly mentioned and so far there was no complain. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Daniel >>>>>>>> >>>>>>>>> On Thursday 28 October 2010, Daniel-Constantin Mierla wrote: >>>>>>>>>> On 10/26/10 2:22 PM, Sergey Okhapkin wrote: >>>>>>>>>>> setdebug() function is no longer provided by core. How to change >>>>>>>>>>> debug level dynamically in the script to trace execution of a few >>>>>>>>>>> statements only? >>>>>>>>>> seems was lost in transition to 3.0, I will check to see what >>>>>>>>>> can be >>>>>>>>>> done with the new architecture. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Daniel >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> _______________________________________________ >>>>>> 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 >>>> _______________________________________________ >>>> 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 -- Daniel-Constantin Mierla http://www.asipto.com

2 1

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 2010