- sr-users - kamailio.org

source websocket ip address
by jaflong jaflong 26 Feb '15

26 Feb '15

On a request received over websocket how can the ip address of the http server that jssip library connected through and send the call from be know?

2 1

Re: [SR-Users] kamailio asterisk
by Slava Bendersky 26 Feb '15

26 Feb '15

Hello Daniel, Thank you for all help and last solution getting closer, client register, but I see in log Feb 25 13:13:00 canlvprx01 kamailio: 3(5051) DEBUG: <core> [parser/msg_parser.c:190]: get_hdr_field(): DEBUG: get_hdr_field: <To> [52]; uri=[sip:sips:10101@public_ip:5066] Feb 25 13:13:00 canlvprx01 kamailio: 3(5051) DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to body [<sip:sips:10101@public_ip:5066> <--- SIP read from UDP:10.18.130.46:5060 ---> SIP/2.0 500 I'm terribly sorry, server error occurred (7/TM) Via: SIP/2.0/UDP 10.18.130.50:5060;branch=z9hG4bK1bddbf73;rport=5060;received=10.18.130.50 From: "capbxsrv01" <sip:capbxsrv01@10.18.130.50>;tag=as7c3f6955 To: <sip:sips:10101@public_ip:5063>;tag=6eb8dc78f5 Call-ID: 08a2c6f10b91e480 CSeq: 102 NOTIFY Server: kamailio (4.2.3 (x86_64/linux)) Content-Length: 0 I think need updated $ru for SUBSCRIBE and NOTIFY. Please let me know what additional information required for backtrace. Slava. From: "Daniel-Constantin Mierla" <miconda(a)gmail.com> To: "Slava Bendersky" <volga629(a)networklab.ca> Cc: "sr-users" <sr-users(a)lists.sip-router.org> Sent: Wednesday, February 25, 2015 12:04:28 PM Subject: Re: [SR-Users] kamailio asterisk Hello, On 25/02/15 17:19, Slava Bendersky wrote: Hello Daniel, substr you suggested didn't worked. See my previous email. your previous email didn't say anything about the results. That's why I asked. Be sure you don't have those spaces that are in the email you wrote. Also, I had more parenthesis in the parameter of the subst_uri(). Or you can try the alternative with: if($rz=="sips") { $ru = "sip" + $(ru{s.substr,4,0}); } I asked for more details from the backtrace to confirm that what I found is the cause for the crash in this case -- see one of my previous emails from today. Cheers, Daniel BQ_BEGIN Feb 25 09:12:33 canlvprx01 kamailio: 11(4104) ERROR: *** cfgtrace:request_route=[DEFAULT_ROUTE] c=[/etc/kamailio/kamailio-asterisk.cfg] l=506 a=25 n=subst_uri Feb 25 09:12:33 canlvprx01 kamailio: 11(4104) DEBUG: <core> [re.c:448]: subst_run(): subst_run: running. r=1 Feb 25 09:12:33 canlvprx01 kamailio: 11(4104) DEBUG: <core> [re.c:517]: subst_str(): subst_str: no match but I changed to subst("/sips:/ sip:/g "); and log says that it match, but still ask for sips and then crash Feb 25 11:22:24 canlvprx01 kamailio: 11(4770) ERROR: *** cfgtrace:request_route=[DEFAULT_ROUTE] c=[/etc/kamailio/kamailio-asterisk.cfg] l=507 a=25 n=subst Feb 25 11:22:24 canlvprx01 kamailio: 11(4770) DEBUG: <core> [re.c:448]: subst_run(): subst_run: running. r=0 Feb 25 11:22:24 canlvprx01 kamailio: 11(4770) DEBUG: <core> [re.c:469]: subst_run(): subst_run: matched (229, 5): [sips:] Feb 25 11:22:24 canlvprx01 kamailio: 11(4770) DEBUG: <core> [re.c:448]: subst_run(): subst_run: running. r=0 Feb 25 11:22:24 canlvprx01 kamailio: 11(4770) DEBUG: <core> [re.c:469]: subst_run(): subst_run: matched (299, 5): [sips:] Feb 25 11:22:24 canlvprx01 kamailio: 11(4770) DEBUG: <core> [re.c:448]: subst_run(): subst_run: running. r=0 Feb 25 11:22:24 canlvprx01 kamailio: 11(4770) DEBUG: <core> [re.c:469]: subst_run(): subst_run: matched (364, 5): [sips:] Feb 25 11:22:24 canlvprx01 kamailio: 11(4770) DEBUG: <core> [re.c:448]: subst_run(): subst_run: running. r=0 Feb 25 11:22:24 canlvprx01 kamailio: 11(4770) DEBUG: <core> [re.c:469]: subst_run(): subst_run: matched (538, 5): [sips:] Feb 25 11:22:24 canlvprx01 kamailio: 11(4770) DEBUG: <core> [re.c:448]: subst_run(): subst_run: running. r=1 Feb 25 11:22:24 canlvprx01 kamailio: 11(4770) DEBUG: textops [textops.c:695]: subst_f(): textops: replacing at offset 266 [sips:] with [sip:] Feb 25 11:22:24 canlvprx01 kamailio: 11(4770) DEBUG: textops [textops.c:695]: subst_f(): textops: replacing at offset 336 [sips:] with [sip:] Feb 25 11:22:24 canlvprx01 kamailio: 11(4770) DEBUG: textops [textops.c:695]: subst_f(): textops: replacing at offset 401 [sips:] with [sip:] Feb 25 11:22:24 canlvprx01 kamailio: 11(4770) DEBUG: textops [textops.c:695]: subst_f(): textops: replacing at offset 575 [sips:] with [sip:] Feb 25 11:22:24 canlvprx01 kernel: [87678.490671] kamailio[4774]: segfault at 88 ip 00000000004bd27c sp 00007fff9a126ea0 error 4 in kamailio[400000+3b9000] Feb 25 11:22:24 canlvprx01 kamailio: 11(4770) DEBUG: textops [textops.c:711]: subst_f(): lst was 0x7fd875e0dd98 That why I asked about this bug report, it close because of limitation in openser/kamailio. Slava. From: "Daniel-Constantin Mierla" <miconda(a)gmail.com> To: "Slava Bendersky" <volga629(a)networklab.ca> , "sr-users" <sr-users(a)lists.sip-router.org> Sent: Wednesday, February 25, 2015 10:57:29 AM Subject: Re: [SR-Users] kamailio asterisk Hello, that's from 2007, closed as invalid -- that was v1.2. Again, as in my previous email, you haven't described what is the state after using the subst as I suggested previously. Cheers, Daniel On 25/02/15 15:47, Slava Bendersky wrote: BQ_BEGIN Hello Daniel, I found this bug report http://sourceforge.net/p/openser/bugs/226/ Is this still valid ? Slava. From: "Slava Bendersky" <volga629(a)networklab.ca> To: miconda(a)gmail.com Cc: "sr-users" <sr-users(a)lists.sip-router.org> Sent: Wednesday, February 25, 2015 9:11:54 AM Subject: Re: [SR-Users] kamailio asterisk Hello Everyone, Feb 25 09:12:33 canlvprx01 kamailio: 11(4104) ERROR: *** cfgtrace:request_route=[DEFAULT_ROUTE] c=[/etc/kamailio/kamailio-asterisk.cfg] l=506 a=25 n=subst_uri Feb 25 09:12:33 canlvprx01 kamailio: 11(4104) DEBUG: <core> [re.c:448]: subst_run(): subst_run: running. r=1 Feb 25 09:12:33 canlvprx01 kamailio: 11(4104) DEBUG: <core> [re.c:517]: subst_str(): subst_str: no match I tried something like if (proto==TLS) { #subst_uri('/^sips.+)$/ sip:\1/ '); subst("/sips:/ sip:/g "); } but there some cases where client use ;transport=TLS which need remove too. Slava From: "Daniel-Constantin Mierla" <miconda(a)gmail.com> To: "Slava Bendersky" <volga629(a)networklab.ca> , "sr-users" <sr-users(a)lists.sip-router.org> Sent: Wednesday, February 25, 2015 5:44:53 AM Subject: Re: [SR-Users] kamailio asterisk Hello, change the r-uri to use sip instead of sips. You can try with: subst_uri('/^sips:(.+)$/ sip:\1/ '); Cheers, Daniel! On 25/02/15 01:14, Slava Bendersky wrote: BQ_BEGIN Hello Everyone, I wonder in my case why kamailio is not bridging between TLS and UDP ? Is there additional configuration required ? Slava. From: "Slava Bendersky" <volga629(a)networklab.ca> To: miconda(a)gmail.com Cc: "sr-users" <sr-users(a)lists.sip-router.org> Sent: Tuesday, February 24, 2015 11:42:02 AM Subject: Re: [SR-Users] kamailio asterisk Hello Everyone, Here link to core dump bt full. http://fpaste.org/189799/79603014/ password the same Slava. From: "Daniel-Constantin Mierla" <miconda(a)gmail.com> To: "volga629" <volga629(a)skillsearch.ca> , "Slava Bendersky" <volga629(a)networklab.ca> , "sr-users" <sr-users(a)lists.sip-router.org> Sent: Monday, February 23, 2015 3:56:48 AM Subject: Re: [SR-Users] kamailio asterisk You don't need to run kamailio through gdb. If it crashes, then you get a corefile -- in the logs it says the name of the file. It is usually located in / or in the path you gave to -w parameter. After you reproduced the crash, locate the corefile and run gdb like: gdb /path/to/kamailio /path/to/corefile bt full The /path/to/kamailio should be /usr/sbin/kamailio if you installed from rpms. If you have improvements to init or sysconfig kamailio file, send a patch and we will include the changes in kamailio repository. Cheers, Daniel On 23/02/15 01:00, Slava Bendersky wrote: > Hello Everyone, > I upgraded to 4.2.3 version, but crash still there. What is my options to meet case like this. > > Client TLS -------> KAMAILIO Proxy ------ UDP/TCP ----> asterisk > | > | > Public Private > > I will try try run gdb to get backtrace on crash. > Also here link for Fedora 21 server rpms. There are couple small fixes for init file and sysconfig/kamailio > > http://ftpsrv01.networklab.ca/fedora/21/RPMS/x86_64/ > > Slava. > > Sent from mobile device typos are expected. > > From: Daniel-Constantin Mierla <miconda(a)gmail.com> > Sent: Feb 22, 2015 5:34 PM > To: Slava Bendersky <volga629(a)networklab.ca> ;sr-users > Subject: Re: [SR-Users] kamailio asterisk > > > > Hello, > > looking at the logs, the process routing the register is forwarding it, > by opening a tls connection -- that is because the uri has sips as schema. > > The crash is reported in another process that doesn't print much logs > messages. As Olle suggested, can you get the backtrace with gdb from the > core file? That will help to see where the crash happened. > > gdb /path/to/kamailio /path/to/corefile > bt full > > And again, it would be good to upgrade to 4.2.3 -- it is same config and > database, just install new version and restart. In this way we rule out > issues that were fixed already, avoiding to spend time on something fixed. > > Cheers, > Daniel > > On 20/02/15 15:03, Slava Bendersky wrote: >> Hello Everyone, >> Thank you for reply, >> On client I configured user @ domain.org and proxy point to kamailio >> Here 1 debug where on client after doamin.org port is left configured >> to 5061 >> >> http://fpaste.org/188145/44047614/ >> >> Second debug where port set to 0 and kamailio tries resolve and crashed >> >> http://fpaste.org/188148/24440702/ >> >> Here config file >> >> http://fpaste.org/188149/24440841/ >> >> >> Thank you, >> Slava. >> >> >> ------------------------------------------------------------------------ >> *From: *"Olle E. Johansson" <oej(a)edvina.net> >> *To: *"Daniel Constantin Mierla" <miconda(a)gmail.com> , "sr-users" >> <sr-users(a)lists.sip-router.org> >> *Sent: *Thursday, February 19, 2015 4:34:04 AM >> *Subject: *Re: [SR-Users] kamailio asterisk >> >> We also need to check the core file from the crash. >> /O >> On 19 Feb 2015, at 09:30, Daniel-Constantin Mierla < miconda(a)gmail.com >> <mailto:miconda@gmail.com> > wrote: >> >> Hello, >> >> can you send the REGISTER request received by kamailio and your >> config to me? >> >> As you receive it over TLS, you can get the register by adding the >> next line in kamailio.cfg at the beginning of request_route: >> >> xlog("received request: [[$mb]]\n"); >> >> I will like to double check if the issue is still present. >> >> You should upgrade to 4.2.3, because it is the latest stable, you >> have 4.2.1 and there were many fixes meanwhile. >> >> If you preserve sips as uri schema, then you force tls further for >> forwarding. You should change that to sip:domain ... >> >> Cheers, >> Daniel >> >> On 18/02/15 00:37, Slava Bendersky wrote: >> >> Hello Everyone, >> I have standard case where kamailio play role of proxy for >> asterisk servers. >> Kamailio configured use TLS transport on public side and on >> private side UDP 5060. >> When client (SIP soft phone) connect to TLS socket everything >> goes well until kamailio trying forward request. Kamailio >> tries DNS resolve tls transport srv records instead of udp >> then it just crashed when no tls configured on private side of >> kamailio. >> >> Do I need manually fix sips in URI ? Or some different miss >> configuration ? >> >> >> [root@canlvprx01 kamailio]# rpm -qa | grep kamail >> kamailio-carrierroute-4.2.1-4.2.fc21.x86_64 >> kamailio-mysql-4.2.1-4.2.fc21.x86_64 >> kamailio-outbound-4.2.1-4.2.fc21.x86_64 >> kamailio-4.2.1-4.2.fc21.x86_64 >> kamailio-tls-4.2.1-4.2.fc21.x86_64 >> >> >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [parser/msg_parser.c:625]: parse_msg(): method: <REGISTER> >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [parser/msg_parser.c:627]: parse_msg(): uri: >> <sips:domain.org> ---> Client come with TLS transport >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [parser/msg_parser.c:629]: parse_msg(): version: <SIP/2.0> >> >> >> >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [socket_info.c:583]: grep_sock_info(): grep_sock_info - >> checking if host==us: 13==12 && [domain.org >> <http://domain.org> ] == [10.18.130.46 <callto:10.18.130.46> ] >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [socket_info.c:587]: grep_sock_info(): grep_sock_info - >> checking if port 5060 (advertise 0) matches port 5060 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [socket_info.c:583]: grep_sock_info(): grep_sock_info - >> checking if host==us: 13==11 && [domain.org >> <http://domain.org> ] == [67.34.12.56] >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [socket_info.c:587]: grep_sock_info(): grep_sock_info - >> checking if port 5081 (advertise 0) matches port 5060 >> Feb 17 11:13:49 canlvprx01 kernel: [4130713.518667] >> kamailio[22484]: segfault at 88 ip 00000000004bd30c sp >> 00007fffa2f73a20 error 4 in kamailio[400000+3b8000] >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [forward.c:448]: check_self(): check_self: host != me >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[SIPOUT] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=850 a=25 n=append_hf >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[SIPOUT] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=851 a=5 n=route >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=567 a=16 n=if >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=563 a=25 n=is_method >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=571 a=16 n=if >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=567 a=25 n=is_method >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=574 a=16 n=if >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=571 a=24 n=t_relay >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_lookup.c:1373]: t_newtran(): DEBUG: t_newtran: msg id=1 , >> global msg id=1 , T on entrance=(nil) >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_lookup.c:527]: t_lookup_request(): t_lookup_request: start >> searching: hash=48550, isACK=0 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_lookup.c:485]: matching_3261(): DEBUG: RFC3261 transaction >> matching failed >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_lookup.c:709]: t_lookup_request(): DEBUG: t_lookup_request: >> no transaction found >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_hooks.c:380]: run_reqin_callbacks_internal(): DBG: >> trans=0x7f598a9ced40, callback type 1, id 0 entered >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_hooks.c:380]: run_reqin_callbacks_internal(): DBG: >> trans=0x7f598a9ced40, callback type 1, id 0 entered >> Feb 17 11:13:49 canlvprx01 kernel: kamailio[22484]: segfault >> at 88 ip 00000000004bd30c sp 00007fffa2f73a20 error 4 in >> kamailio[400000+3b8000] >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [md5utils.c:67]: MD5StringArray(): DEBUG: MD5 calculated: >> 0475e0d0dd9778e889618cb724403b4d >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [dns_cache.c:566]: _dns_hash_find(): >> dns_hash_find(_sips._tcp.networklab.ca >> <http://tcp.networklab.ca> (24), 33), h=646 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [resolve.c:967]: get_record(): get_record: skipping 1 NS >> (p=0xa1f556, end=0xa1f588) >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [resolve.c:983]: get_record(): get_record: parsing 2 ARs >> (p=0xa1f568, end=0xa1f588) >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [dns_cache.c:1772]: dns_get_related(): >> dns_get_related(0x7f598a9e89b0 (_sips._tcp.domain.org >> <http://tcp.domain.org> , 33), 33, *0x7f5995bd55e0) (0) >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [dns_cache.c:869]: dns_cache_add_unsafe(): dns_cache_add: >> adding _sips._tcp.domain.org <http://tcp.domain.org> (24) 33 >> (flags=0) at 646 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [dns_cache.c:869]: dns_cache_add_unsafe(): dns_cache_add: >> adding camsgsrv02.domain.org >> <http://camsgsrv02.domain.org> (24) 1 (flags=0) at 967 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [dns_cache.c:566]: _dns_hash_find(): >> dns_hash_find(camsgsrv02.domain.org >> <http://camsgsrv02.domain.org> (24), 1), h=967 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [msg_translator.c:2871]: create_via_hf(): create_via_hf: id >> added: <;i=1>, rcv proto=3 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [tcp_main.c:1818]: tcp_send(): tcp_send: no open tcp >> connection found, opening new one >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [ip_addr.c:243]: print_ip(): tcpconn_new: new tcp connection: >> 10.18.130.50 <callto:10.18.130.50> >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [tcp_main.c:1073]: tcpconn_new(): tcpconn_new: on port 5061, >> type 3 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [tcp_main.c:1382]: tcpconn_add(): tcpconn_add: hashes: 3263:0:0, 2 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) WARNING: <core> >> [tcp_main.c:1221]: tcp_do_connect(): 10.18.130.50 >> <callto:10.18.130.50> :5061: could not find corresponding >> listening socket for 10.18.130.46 <callto:10.18.130.46> , using >> default... >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tls >> [tls_server.c:184]: tls_complete_init(): Using TLS domain >> TLSc<default> >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tls >> [tls_domain.c:700]: sr_ssl_ctx_info_callback(): SSL handshake >> started >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [tcp_main.c:2697]: tcpconn_1st_send(): pending write on new >> connection 0x7f598a9d4678 (-1/129 bytes written) >> Feb 17 11:13:49 canlvprx01 kamailio: 15(22484) DEBUG: <core> >> [tcp_main.c:3565]: handle_ser_child(): handle_ser_child: read >> response= 7f598a9d4678, 5, fd 31 from 11 (22480) >> Feb 17 11:13:49 canlvprx01 kamailio: 15(22484) DEBUG: <core> >> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x9daf00, >> 31, 2, 0x7f598a9d4678), fd_no=19 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_funcs.c:394]: t_relay_to(): SER: new transaction fwd'ed >> >> >> >> Thank you Slava. >> >> >> _______________________________________________ >> 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://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >> Kamailio World Conference, May 27-29, 2015 >> Berlin, Germany - http://www.kamailioworld.com >> >> _______________________________________________ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing >> list >> sr-users(a)lists.sip-router.org <mailto:sr-users@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://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com _______________________________________________ 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 BQ_END -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com _______________________________________________ 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 BQ_END -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com BQ_END -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com

3 2

usrloc table to redis
by Yuriy Gorlichenko 26 Feb '15

26 Feb '15

Hello. We try to use redis for maximum features of kamailio. We already realise dispatcher (not as module, but I want to do it at the future), and now we want to relocate usrloc to redis. Does anyone do this with Redis?

2 1

RTPEngine IPv4 to IPv6 bridging returning c=IN IP4 0.0.0.0 on answer?
by Anthony Messina 26 Feb '15

26 Feb '15

This is probably very likely a configuration issue on my part, but I wanted to check before reporting an RTPEngine bug... Thank you for any pointers or suggestions. This is a multi-homed server where em1: INTERNAL_IPv4 & GLOBAL_IPv6 em2: EXTERNAL_IPv4 Note that below, the IPv6 address on my server is the same on priv and pub and is reachable from "internal" and "external" endpoints. I have it set this way as I eventually want to use ICE and have it create the proper IPv4/IPv6 candidates regardless of the RTPEngine --interface. I'm running RTPEngine with the following: /usr/sbin/rtpengine --table=0 --interface=pub/EXTERNAL_IPv4 --interface=pub/GLOBAL_IPv6 --interface=priv/INTERNAL_IPv4 --interface=priv/GLOBAL_IPv6 --listen-ng=127.0.0.1:12221 --tos=184 --log-level=7 --pidfile=/run/rtpengine/rtpengine.test.pid I'm trying to bridge an IPv4-initated call to an IPv6 carrier. The call seems to flow properly until the carrier's SDP is passed through RTPEngine on answer. The snippets are here, and I have attached the full log. [TdBe4MJa1DC4teIllJkqq6U-PAw9Zh4y] Received command 'answer' from 127.0.0.1:38786 [TdBe4MJa1DC4teIllJkqq6U-PAw9Zh4y] Dump for 'answer' from 127.0.0.1:38786: { "sdp": "v=0 o=FreeSWITCH 1424799070 1424799071 IN IP6 CARRIER_IPv6 s=FreeSWITCH c=IN IP6 CARRIER_IPv6 t=0 0 m=audio 24308 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=rtcp:24309 IN IP6 CARRIER_IPv6 The CARRIER_IPv6 gets converted as follows with 0.0.0.0 in place of what should be the address of my RTPEngine instance. Shouldn't it be returning the IPv4 address of my RTPEngine instance (either priv or pub as called from Kamailio)? [TdBe4MJa1DC4teIllJkqq6U-PAw9Zh4y] Replying to 'answer' from 127.0.0.1:38786 [TdBe4MJa1DC4teIllJkqq6U-PAw9Zh4y] Response dump for 'answer' to 127.0.0.1:38786: { "sdp": "v=0 o=FreeSWITCH 1424799070 1424799071 IN IP4 0.0.0.0 s=FreeSWITCH c=IN IP4 0.0.0.0 t=0 0 m=audio 38914 RTP/SAVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv a=rtcp:38915 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:Jby5IPt4WlNySLd66eK+Mcky8yJeUwp7dWH7W3aO -- Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E

3 4

db_mysql module compile error
by jaflong jaflong 25 Feb '15

25 Feb '15

On compiling I get this error km_dbase.c:38:25: fatal error: mysql/mysql.h: No such file or directory #include <mysql/mysql.h> ^ I have installed mysql using the standard install from tar.gz binary This places the prefix for install in /usr/local/mysql the include dir is /usr/local/mysql/include result of running mysql_config --include is -I/usr/local/mysql/include #ls /usr/local/mysql/include big_endian.h little_endian.h my_config.h my_pthread.h mysql.h plugin.h typelib.h byte_order_generic.h m_ctype.h my_dbug.h mysql mysql_time.h plugin_validate_password.h byte_order_generic_x86_64.h m_string.h my_dir.h mysql_com.h mysql_version.h sql_common.h byte_order_generic_x86.h my_alloc.h my_getopt.h mysql_com_server.h my_sys.h sql_state.h decimal.h my_attribute.h my_global.h mysqld_ername.h my_xml.h sslopt-case.h errmsg.h my_byteorder.h my_list.h mysqld_error.h plugin_audit.h sslopt-longopts.h keycache.h my_compiler.h my_net.h mysql_embed.h plugin_ftparser.h sslopt-vars.h as listed the header files a here I notice mysql.h in in /usr/local/mysql/include and not in the sub directory (/usr/local/mysql/include/mysql) Any suggestion on how to get this compiled

2 2

Kamailio Security Policy - How to handle vulnerability reports
by Olle E. Johansson 25 Feb '15

25 Feb '15

Hello Kamailians! During our last developer meeting, we had a discussion about implementing a security policy for the project. I drafted a proposal that seemed fine with the developer team. At this point, I'm looking for your feedback. The proposal is short and brief at this point, we'll learn as we go. Much of it is inspired by the policy of the Asterisk project. You can find it here: http://www.kamailio.org/wiki/securitypolicy We encourage your feedback! - Is this a good thing for the project? - Do you have any changes to the policy to suggest? At this point, we're not looking for support systems for this, or any software platform - we're focusing on getting the policy right, then we're going to look on how to implement it. Looking forward to your responses! Best regards, /Olle

3 5

Re: [SR-Users] kamailio asterisk
by Slava Bendersky 25 Feb '15

25 Feb '15

Hello Daniel, I found this bug report http://sourceforge.net/p/openser/bugs/226/ Is this still valid ? Slava. From: "Slava Bendersky" <volga629(a)networklab.ca> To: miconda(a)gmail.com Cc: "sr-users" <sr-users(a)lists.sip-router.org> Sent: Wednesday, February 25, 2015 9:11:54 AM Subject: Re: [SR-Users] kamailio asterisk Hello Everyone, Feb 25 09:12:33 canlvprx01 kamailio: 11(4104) ERROR: *** cfgtrace:request_route=[DEFAULT_ROUTE] c=[/etc/kamailio/kamailio-asterisk.cfg] l=506 a=25 n=subst_uri Feb 25 09:12:33 canlvprx01 kamailio: 11(4104) DEBUG: <core> [re.c:448]: subst_run(): subst_run: running. r=1 Feb 25 09:12:33 canlvprx01 kamailio: 11(4104) DEBUG: <core> [re.c:517]: subst_str(): subst_str: no match I tried something like if (proto==TLS) { #subst_uri('/^sips.+)$/sip:\1/'); subst("/sips:/sip:/g"); } but there some cases where client use ;transport=TLS which need remove too. Slava From: "Daniel-Constantin Mierla" <miconda(a)gmail.com> To: "Slava Bendersky" <volga629(a)networklab.ca>, "sr-users" <sr-users(a)lists.sip-router.org> Sent: Wednesday, February 25, 2015 5:44:53 AM Subject: Re: [SR-Users] kamailio asterisk Hello, change the r-uri to use sip instead of sips. You can try with: subst_uri('/^sips:(.+)$/ sip:\1/ '); Cheers, Daniel! On 25/02/15 01:14, Slava Bendersky wrote: Hello Everyone, I wonder in my case why kamailio is not bridging between TLS and UDP ? Is there additional configuration required ? Slava. From: "Slava Bendersky" <volga629(a)networklab.ca> To: miconda(a)gmail.com Cc: "sr-users" <sr-users(a)lists.sip-router.org> Sent: Tuesday, February 24, 2015 11:42:02 AM Subject: Re: [SR-Users] kamailio asterisk Hello Everyone, Here link to core dump bt full. http://fpaste.org/189799/79603014/ password the same Slava. From: "Daniel-Constantin Mierla" <miconda(a)gmail.com> To: "volga629" <volga629(a)skillsearch.ca> , "Slava Bendersky" <volga629(a)networklab.ca> , "sr-users" <sr-users(a)lists.sip-router.org> Sent: Monday, February 23, 2015 3:56:48 AM Subject: Re: [SR-Users] kamailio asterisk You don't need to run kamailio through gdb. If it crashes, then you get a corefile -- in the logs it says the name of the file. It is usually located in / or in the path you gave to -w parameter. After you reproduced the crash, locate the corefile and run gdb like: gdb /path/to/kamailio /path/to/corefile bt full The /path/to/kamailio should be /usr/sbin/kamailio if you installed from rpms. If you have improvements to init or sysconfig kamailio file, send a patch and we will include the changes in kamailio repository. Cheers, Daniel On 23/02/15 01:00, Slava Bendersky wrote: > Hello Everyone, > I upgraded to 4.2.3 version, but crash still there. What is my options to meet case like this. > > Client TLS -------> KAMAILIO Proxy ------ UDP/TCP ----> asterisk > | > | > Public Private > > I will try try run gdb to get backtrace on crash. > Also here link for Fedora 21 server rpms. There are couple small fixes for init file and sysconfig/kamailio > > http://ftpsrv01.networklab.ca/fedora/21/RPMS/x86_64/ > > Slava. > > Sent from mobile device typos are expected. > > From: Daniel-Constantin Mierla <miconda(a)gmail.com> > Sent: Feb 22, 2015 5:34 PM > To: Slava Bendersky <volga629(a)networklab.ca> ;sr-users > Subject: Re: [SR-Users] kamailio asterisk > > > > Hello, > > looking at the logs, the process routing the register is forwarding it, > by opening a tls connection -- that is because the uri has sips as schema. > > The crash is reported in another process that doesn't print much logs > messages. As Olle suggested, can you get the backtrace with gdb from the > core file? That will help to see where the crash happened. > > gdb /path/to/kamailio /path/to/corefile > bt full > > And again, it would be good to upgrade to 4.2.3 -- it is same config and > database, just install new version and restart. In this way we rule out > issues that were fixed already, avoiding to spend time on something fixed. > > Cheers, > Daniel > > On 20/02/15 15:03, Slava Bendersky wrote: >> Hello Everyone, >> Thank you for reply, >> On client I configured user @ domain.org and proxy point to kamailio >> Here 1 debug where on client after doamin.org port is left configured >> to 5061 >> >> http://fpaste.org/188145/44047614/ >> >> Second debug where port set to 0 and kamailio tries resolve and crashed >> >> http://fpaste.org/188148/24440702/ >> >> Here config file >> >> http://fpaste.org/188149/24440841/ >> >> >> Thank you, >> Slava. >> >> >> ------------------------------------------------------------------------ >> *From: *"Olle E. Johansson" <oej(a)edvina.net> >> *To: *"Daniel Constantin Mierla" <miconda(a)gmail.com> , "sr-users" >> <sr-users(a)lists.sip-router.org> >> *Sent: *Thursday, February 19, 2015 4:34:04 AM >> *Subject: *Re: [SR-Users] kamailio asterisk >> >> We also need to check the core file from the crash. >> /O >> On 19 Feb 2015, at 09:30, Daniel-Constantin Mierla < miconda(a)gmail.com >> <mailto:miconda@gmail.com> > wrote: >> >> Hello, >> >> can you send the REGISTER request received by kamailio and your >> config to me? >> >> As you receive it over TLS, you can get the register by adding the >> next line in kamailio.cfg at the beginning of request_route: >> >> xlog("received request: [[$mb]]\n"); >> >> I will like to double check if the issue is still present. >> >> You should upgrade to 4.2.3, because it is the latest stable, you >> have 4.2.1 and there were many fixes meanwhile. >> >> If you preserve sips as uri schema, then you force tls further for >> forwarding. You should change that to sip:domain ... >> >> Cheers, >> Daniel >> >> On 18/02/15 00:37, Slava Bendersky wrote: >> >> Hello Everyone, >> I have standard case where kamailio play role of proxy for >> asterisk servers. >> Kamailio configured use TLS transport on public side and on >> private side UDP 5060. >> When client (SIP soft phone) connect to TLS socket everything >> goes well until kamailio trying forward request. Kamailio >> tries DNS resolve tls transport srv records instead of udp >> then it just crashed when no tls configured on private side of >> kamailio. >> >> Do I need manually fix sips in URI ? Or some different miss >> configuration ? >> >> >> [root@canlvprx01 kamailio]# rpm -qa | grep kamail >> kamailio-carrierroute-4.2.1-4.2.fc21.x86_64 >> kamailio-mysql-4.2.1-4.2.fc21.x86_64 >> kamailio-outbound-4.2.1-4.2.fc21.x86_64 >> kamailio-4.2.1-4.2.fc21.x86_64 >> kamailio-tls-4.2.1-4.2.fc21.x86_64 >> >> >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [parser/msg_parser.c:625]: parse_msg(): method: <REGISTER> >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [parser/msg_parser.c:627]: parse_msg(): uri: >> <sips:domain.org> ---> Client come with TLS transport >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [parser/msg_parser.c:629]: parse_msg(): version: <SIP/2.0> >> >> >> >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [socket_info.c:583]: grep_sock_info(): grep_sock_info - >> checking if host==us: 13==12 && [domain.org >> <http://domain.org> ] == [10.18.130.46 <callto:10.18.130.46> ] >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [socket_info.c:587]: grep_sock_info(): grep_sock_info - >> checking if port 5060 (advertise 0) matches port 5060 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [socket_info.c:583]: grep_sock_info(): grep_sock_info - >> checking if host==us: 13==11 && [domain.org >> <http://domain.org> ] == [67.34.12.56] >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [socket_info.c:587]: grep_sock_info(): grep_sock_info - >> checking if port 5081 (advertise 0) matches port 5060 >> Feb 17 11:13:49 canlvprx01 kernel: [4130713.518667] >> kamailio[22484]: segfault at 88 ip 00000000004bd30c sp >> 00007fffa2f73a20 error 4 in kamailio[400000+3b8000] >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [forward.c:448]: check_self(): check_self: host != me >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[SIPOUT] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=850 a=25 n=append_hf >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[SIPOUT] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=851 a=5 n=route >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=567 a=16 n=if >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=563 a=25 n=is_method >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=571 a=16 n=if >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=567 a=25 n=is_method >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=574 a=16 n=if >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=571 a=24 n=t_relay >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_lookup.c:1373]: t_newtran(): DEBUG: t_newtran: msg id=1 , >> global msg id=1 , T on entrance=(nil) >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_lookup.c:527]: t_lookup_request(): t_lookup_request: start >> searching: hash=48550, isACK=0 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_lookup.c:485]: matching_3261(): DEBUG: RFC3261 transaction >> matching failed >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_lookup.c:709]: t_lookup_request(): DEBUG: t_lookup_request: >> no transaction found >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_hooks.c:380]: run_reqin_callbacks_internal(): DBG: >> trans=0x7f598a9ced40, callback type 1, id 0 entered >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_hooks.c:380]: run_reqin_callbacks_internal(): DBG: >> trans=0x7f598a9ced40, callback type 1, id 0 entered >> Feb 17 11:13:49 canlvprx01 kernel: kamailio[22484]: segfault >> at 88 ip 00000000004bd30c sp 00007fffa2f73a20 error 4 in >> kamailio[400000+3b8000] >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [md5utils.c:67]: MD5StringArray(): DEBUG: MD5 calculated: >> 0475e0d0dd9778e889618cb724403b4d >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [dns_cache.c:566]: _dns_hash_find(): >> dns_hash_find(_sips._tcp.networklab.ca >> <http://tcp.networklab.ca> (24), 33), h=646 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [resolve.c:967]: get_record(): get_record: skipping 1 NS >> (p=0xa1f556, end=0xa1f588) >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [resolve.c:983]: get_record(): get_record: parsing 2 ARs >> (p=0xa1f568, end=0xa1f588) >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [dns_cache.c:1772]: dns_get_related(): >> dns_get_related(0x7f598a9e89b0 (_sips._tcp.domain.org >> <http://tcp.domain.org> , 33), 33, *0x7f5995bd55e0) (0) >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [dns_cache.c:869]: dns_cache_add_unsafe(): dns_cache_add: >> adding _sips._tcp.domain.org <http://tcp.domain.org> (24) 33 >> (flags=0) at 646 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [dns_cache.c:869]: dns_cache_add_unsafe(): dns_cache_add: >> adding camsgsrv02.domain.org >> <http://camsgsrv02.domain.org> (24) 1 (flags=0) at 967 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [dns_cache.c:566]: _dns_hash_find(): >> dns_hash_find(camsgsrv02.domain.org >> <http://camsgsrv02.domain.org> (24), 1), h=967 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [msg_translator.c:2871]: create_via_hf(): create_via_hf: id >> added: <;i=1>, rcv proto=3 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [tcp_main.c:1818]: tcp_send(): tcp_send: no open tcp >> connection found, opening new one >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [ip_addr.c:243]: print_ip(): tcpconn_new: new tcp connection: >> 10.18.130.50 <callto:10.18.130.50> >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [tcp_main.c:1073]: tcpconn_new(): tcpconn_new: on port 5061, >> type 3 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [tcp_main.c:1382]: tcpconn_add(): tcpconn_add: hashes: 3263:0:0, 2 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) WARNING: <core> >> [tcp_main.c:1221]: tcp_do_connect(): 10.18.130.50 >> <callto:10.18.130.50> :5061: could not find corresponding >> listening socket for 10.18.130.46 <callto:10.18.130.46> , using >> default... >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tls >> [tls_server.c:184]: tls_complete_init(): Using TLS domain >> TLSc<default> >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tls >> [tls_domain.c:700]: sr_ssl_ctx_info_callback(): SSL handshake >> started >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [tcp_main.c:2697]: tcpconn_1st_send(): pending write on new >> connection 0x7f598a9d4678 (-1/129 bytes written) >> Feb 17 11:13:49 canlvprx01 kamailio: 15(22484) DEBUG: <core> >> [tcp_main.c:3565]: handle_ser_child(): handle_ser_child: read >> response= 7f598a9d4678, 5, fd 31 from 11 (22480) >> Feb 17 11:13:49 canlvprx01 kamailio: 15(22484) DEBUG: <core> >> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x9daf00, >> 31, 2, 0x7f598a9d4678), fd_no=19 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_funcs.c:394]: t_relay_to(): SER: new transaction fwd'ed >> >> >> >> Thank you Slava. >> >> >> _______________________________________________ >> 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://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >> Kamailio World Conference, May 27-29, 2015 >> Berlin, Germany - http://www.kamailioworld.com >> >> _______________________________________________ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing >> list >> sr-users(a)lists.sip-router.org <mailto:sr-users@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://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com _______________________________________________ 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://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

2 1

Re: [SR-Users] kamailio asterisk
by Slava Bendersky 25 Feb '15

25 Feb '15

Hello Everyone, Feb 25 09:12:33 canlvprx01 kamailio: 11(4104) ERROR: *** cfgtrace:request_route=[DEFAULT_ROUTE] c=[/etc/kamailio/kamailio-asterisk.cfg] l=506 a=25 n=subst_uri Feb 25 09:12:33 canlvprx01 kamailio: 11(4104) DEBUG: <core> [re.c:448]: subst_run(): subst_run: running. r=1 Feb 25 09:12:33 canlvprx01 kamailio: 11(4104) DEBUG: <core> [re.c:517]: subst_str(): subst_str: no match I tried something like if (proto==TLS) { #subst_uri('/^sips.+)$/sip:\1/'); subst("/sips:/sip:/g"); } but there some cases where client use ;transport=TLS which need remove too. Slava From: "Daniel-Constantin Mierla" <miconda(a)gmail.com> To: "Slava Bendersky" <volga629(a)networklab.ca>, "sr-users" <sr-users(a)lists.sip-router.org> Sent: Wednesday, February 25, 2015 5:44:53 AM Subject: Re: [SR-Users] kamailio asterisk Hello, change the r-uri to use sip instead of sips. You can try with: subst_uri('/^sips:(.+)$/ sip:\1/ '); Cheers, Daniel! On 25/02/15 01:14, Slava Bendersky wrote: Hello Everyone, I wonder in my case why kamailio is not bridging between TLS and UDP ? Is there additional configuration required ? Slava. From: "Slava Bendersky" <volga629(a)networklab.ca> To: miconda(a)gmail.com Cc: "sr-users" <sr-users(a)lists.sip-router.org> Sent: Tuesday, February 24, 2015 11:42:02 AM Subject: Re: [SR-Users] kamailio asterisk Hello Everyone, Here link to core dump bt full. http://fpaste.org/189799/79603014/ password the same Slava. From: "Daniel-Constantin Mierla" <miconda(a)gmail.com> To: "volga629" <volga629(a)skillsearch.ca> , "Slava Bendersky" <volga629(a)networklab.ca> , "sr-users" <sr-users(a)lists.sip-router.org> Sent: Monday, February 23, 2015 3:56:48 AM Subject: Re: [SR-Users] kamailio asterisk You don't need to run kamailio through gdb. If it crashes, then you get a corefile -- in the logs it says the name of the file. It is usually located in / or in the path you gave to -w parameter. After you reproduced the crash, locate the corefile and run gdb like: gdb /path/to/kamailio /path/to/corefile bt full The /path/to/kamailio should be /usr/sbin/kamailio if you installed from rpms. If you have improvements to init or sysconfig kamailio file, send a patch and we will include the changes in kamailio repository. Cheers, Daniel On 23/02/15 01:00, Slava Bendersky wrote: > Hello Everyone, > I upgraded to 4.2.3 version, but crash still there. What is my options to meet case like this. > > Client TLS -------> KAMAILIO Proxy ------ UDP/TCP ----> asterisk > | > | > Public Private > > I will try try run gdb to get backtrace on crash. > Also here link for Fedora 21 server rpms. There are couple small fixes for init file and sysconfig/kamailio > > http://ftpsrv01.networklab.ca/fedora/21/RPMS/x86_64/ > > Slava. > > Sent from mobile device typos are expected. > > From: Daniel-Constantin Mierla <miconda(a)gmail.com> > Sent: Feb 22, 2015 5:34 PM > To: Slava Bendersky <volga629(a)networklab.ca> ;sr-users > Subject: Re: [SR-Users] kamailio asterisk > > > > Hello, > > looking at the logs, the process routing the register is forwarding it, > by opening a tls connection -- that is because the uri has sips as schema. > > The crash is reported in another process that doesn't print much logs > messages. As Olle suggested, can you get the backtrace with gdb from the > core file? That will help to see where the crash happened. > > gdb /path/to/kamailio /path/to/corefile > bt full > > And again, it would be good to upgrade to 4.2.3 -- it is same config and > database, just install new version and restart. In this way we rule out > issues that were fixed already, avoiding to spend time on something fixed. > > Cheers, > Daniel > > On 20/02/15 15:03, Slava Bendersky wrote: >> Hello Everyone, >> Thank you for reply, >> On client I configured user @ domain.org and proxy point to kamailio >> Here 1 debug where on client after doamin.org port is left configured >> to 5061 >> >> http://fpaste.org/188145/44047614/ >> >> Second debug where port set to 0 and kamailio tries resolve and crashed >> >> http://fpaste.org/188148/24440702/ >> >> Here config file >> >> http://fpaste.org/188149/24440841/ >> >> >> Thank you, >> Slava. >> >> >> ------------------------------------------------------------------------ >> *From: *"Olle E. Johansson" <oej(a)edvina.net> >> *To: *"Daniel Constantin Mierla" <miconda(a)gmail.com> , "sr-users" >> <sr-users(a)lists.sip-router.org> >> *Sent: *Thursday, February 19, 2015 4:34:04 AM >> *Subject: *Re: [SR-Users] kamailio asterisk >> >> We also need to check the core file from the crash. >> /O >> On 19 Feb 2015, at 09:30, Daniel-Constantin Mierla < miconda(a)gmail.com >> <mailto:miconda@gmail.com> > wrote: >> >> Hello, >> >> can you send the REGISTER request received by kamailio and your >> config to me? >> >> As you receive it over TLS, you can get the register by adding the >> next line in kamailio.cfg at the beginning of request_route: >> >> xlog("received request: [[$mb]]\n"); >> >> I will like to double check if the issue is still present. >> >> You should upgrade to 4.2.3, because it is the latest stable, you >> have 4.2.1 and there were many fixes meanwhile. >> >> If you preserve sips as uri schema, then you force tls further for >> forwarding. You should change that to sip:domain ... >> >> Cheers, >> Daniel >> >> On 18/02/15 00:37, Slava Bendersky wrote: >> >> Hello Everyone, >> I have standard case where kamailio play role of proxy for >> asterisk servers. >> Kamailio configured use TLS transport on public side and on >> private side UDP 5060. >> When client (SIP soft phone) connect to TLS socket everything >> goes well until kamailio trying forward request. Kamailio >> tries DNS resolve tls transport srv records instead of udp >> then it just crashed when no tls configured on private side of >> kamailio. >> >> Do I need manually fix sips in URI ? Or some different miss >> configuration ? >> >> >> [root@canlvprx01 kamailio]# rpm -qa | grep kamail >> kamailio-carrierroute-4.2.1-4.2.fc21.x86_64 >> kamailio-mysql-4.2.1-4.2.fc21.x86_64 >> kamailio-outbound-4.2.1-4.2.fc21.x86_64 >> kamailio-4.2.1-4.2.fc21.x86_64 >> kamailio-tls-4.2.1-4.2.fc21.x86_64 >> >> >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [parser/msg_parser.c:625]: parse_msg(): method: <REGISTER> >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [parser/msg_parser.c:627]: parse_msg(): uri: >> <sips:domain.org> ---> Client come with TLS transport >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [parser/msg_parser.c:629]: parse_msg(): version: <SIP/2.0> >> >> >> >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [socket_info.c:583]: grep_sock_info(): grep_sock_info - >> checking if host==us: 13==12 && [domain.org >> <http://domain.org> ] == [10.18.130.46 <callto:10.18.130.46> ] >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [socket_info.c:587]: grep_sock_info(): grep_sock_info - >> checking if port 5060 (advertise 0) matches port 5060 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [socket_info.c:583]: grep_sock_info(): grep_sock_info - >> checking if host==us: 13==11 && [domain.org >> <http://domain.org> ] == [67.34.12.56] >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [socket_info.c:587]: grep_sock_info(): grep_sock_info - >> checking if port 5081 (advertise 0) matches port 5060 >> Feb 17 11:13:49 canlvprx01 kernel: [4130713.518667] >> kamailio[22484]: segfault at 88 ip 00000000004bd30c sp >> 00007fffa2f73a20 error 4 in kamailio[400000+3b8000] >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [forward.c:448]: check_self(): check_self: host != me >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[SIPOUT] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=850 a=25 n=append_hf >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[SIPOUT] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=851 a=5 n=route >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=567 a=16 n=if >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=563 a=25 n=is_method >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=571 a=16 n=if >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=567 a=25 n=is_method >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=574 a=16 n=if >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=571 a=24 n=t_relay >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_lookup.c:1373]: t_newtran(): DEBUG: t_newtran: msg id=1 , >> global msg id=1 , T on entrance=(nil) >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_lookup.c:527]: t_lookup_request(): t_lookup_request: start >> searching: hash=48550, isACK=0 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_lookup.c:485]: matching_3261(): DEBUG: RFC3261 transaction >> matching failed >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_lookup.c:709]: t_lookup_request(): DEBUG: t_lookup_request: >> no transaction found >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_hooks.c:380]: run_reqin_callbacks_internal(): DBG: >> trans=0x7f598a9ced40, callback type 1, id 0 entered >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_hooks.c:380]: run_reqin_callbacks_internal(): DBG: >> trans=0x7f598a9ced40, callback type 1, id 0 entered >> Feb 17 11:13:49 canlvprx01 kernel: kamailio[22484]: segfault >> at 88 ip 00000000004bd30c sp 00007fffa2f73a20 error 4 in >> kamailio[400000+3b8000] >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [md5utils.c:67]: MD5StringArray(): DEBUG: MD5 calculated: >> 0475e0d0dd9778e889618cb724403b4d >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [dns_cache.c:566]: _dns_hash_find(): >> dns_hash_find(_sips._tcp.networklab.ca >> <http://tcp.networklab.ca> (24), 33), h=646 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [resolve.c:967]: get_record(): get_record: skipping 1 NS >> (p=0xa1f556, end=0xa1f588) >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [resolve.c:983]: get_record(): get_record: parsing 2 ARs >> (p=0xa1f568, end=0xa1f588) >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [dns_cache.c:1772]: dns_get_related(): >> dns_get_related(0x7f598a9e89b0 (_sips._tcp.domain.org >> <http://tcp.domain.org> , 33), 33, *0x7f5995bd55e0) (0) >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [dns_cache.c:869]: dns_cache_add_unsafe(): dns_cache_add: >> adding _sips._tcp.domain.org <http://tcp.domain.org> (24) 33 >> (flags=0) at 646 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [dns_cache.c:869]: dns_cache_add_unsafe(): dns_cache_add: >> adding camsgsrv02.domain.org >> <http://camsgsrv02.domain.org> (24) 1 (flags=0) at 967 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [dns_cache.c:566]: _dns_hash_find(): >> dns_hash_find(camsgsrv02.domain.org >> <http://camsgsrv02.domain.org> (24), 1), h=967 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [msg_translator.c:2871]: create_via_hf(): create_via_hf: id >> added: <;i=1>, rcv proto=3 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [tcp_main.c:1818]: tcp_send(): tcp_send: no open tcp >> connection found, opening new one >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [ip_addr.c:243]: print_ip(): tcpconn_new: new tcp connection: >> 10.18.130.50 <callto:10.18.130.50> >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [tcp_main.c:1073]: tcpconn_new(): tcpconn_new: on port 5061, >> type 3 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [tcp_main.c:1382]: tcpconn_add(): tcpconn_add: hashes: 3263:0:0, 2 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) WARNING: <core> >> [tcp_main.c:1221]: tcp_do_connect(): 10.18.130.50 >> <callto:10.18.130.50> :5061: could not find corresponding >> listening socket for 10.18.130.46 <callto:10.18.130.46> , using >> default... >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tls >> [tls_server.c:184]: tls_complete_init(): Using TLS domain >> TLSc<default> >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tls >> [tls_domain.c:700]: sr_ssl_ctx_info_callback(): SSL handshake >> started >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [tcp_main.c:2697]: tcpconn_1st_send(): pending write on new >> connection 0x7f598a9d4678 (-1/129 bytes written) >> Feb 17 11:13:49 canlvprx01 kamailio: 15(22484) DEBUG: <core> >> [tcp_main.c:3565]: handle_ser_child(): handle_ser_child: read >> response= 7f598a9d4678, 5, fd 31 from 11 (22480) >> Feb 17 11:13:49 canlvprx01 kamailio: 15(22484) DEBUG: <core> >> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x9daf00, >> 31, 2, 0x7f598a9d4678), fd_no=19 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_funcs.c:394]: t_relay_to(): SER: new transaction fwd'ed >> >> >> >> Thank you Slava. >> >> >> _______________________________________________ >> 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://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >> Kamailio World Conference, May 27-29, 2015 >> Berlin, Germany - http://www.kamailioworld.com >> >> _______________________________________________ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing >> list >> sr-users(a)lists.sip-router.org <mailto:sr-users@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://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com _______________________________________________ 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://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com

2 1

Re: [SR-Users] kamailio asterisk
by Slava Bendersky 25 Feb '15

25 Feb '15

Hello Everyone, Here link to core dump bt full. http://fpaste.org/189799/79603014/ password the same Slava. From: "Daniel-Constantin Mierla" <miconda(a)gmail.com> To: "volga629" <volga629(a)skillsearch.ca>, "Slava Bendersky" <volga629(a)networklab.ca>, "sr-users" <sr-users(a)lists.sip-router.org> Sent: Monday, February 23, 2015 3:56:48 AM Subject: Re: [SR-Users] kamailio asterisk You don't need to run kamailio through gdb. If it crashes, then you get a corefile -- in the logs it says the name of the file. It is usually located in / or in the path you gave to -w parameter. After you reproduced the crash, locate the corefile and run gdb like: gdb /path/to/kamailio /path/to/corefile bt full The /path/to/kamailio should be /usr/sbin/kamailio if you installed from rpms. If you have improvements to init or sysconfig kamailio file, send a patch and we will include the changes in kamailio repository. Cheers, Daniel On 23/02/15 01:00, Slava Bendersky wrote: > Hello Everyone, > I upgraded to 4.2.3 version, but crash still there. What is my options to meet case like this. > > Client TLS -------> KAMAILIO Proxy ------ UDP/TCP ----> asterisk > | > | > Public Private > > I will try try run gdb to get backtrace on crash. > Also here link for Fedora 21 server rpms. There are couple small fixes for init file and sysconfig/kamailio > > http://ftpsrv01.networklab.ca/fedora/21/RPMS/x86_64/ > > Slava. > > Sent from mobile device typos are expected. > > From: Daniel-Constantin Mierla <miconda(a)gmail.com> > Sent: Feb 22, 2015 5:34 PM > To: Slava Bendersky <volga629(a)networklab.ca>;sr-users > Subject: Re: [SR-Users] kamailio asterisk > > > > Hello, > > looking at the logs, the process routing the register is forwarding it, > by opening a tls connection -- that is because the uri has sips as schema. > > The crash is reported in another process that doesn't print much logs > messages. As Olle suggested, can you get the backtrace with gdb from the > core file? That will help to see where the crash happened. > > gdb /path/to/kamailio /path/to/corefile > bt full > > And again, it would be good to upgrade to 4.2.3 -- it is same config and > database, just install new version and restart. In this way we rule out > issues that were fixed already, avoiding to spend time on something fixed. > > Cheers, > Daniel > > On 20/02/15 15:03, Slava Bendersky wrote: >> Hello Everyone, >> Thank you for reply, >> On client I configured user @ domain.org and proxy point to kamailio >> Here 1 debug where on client after doamin.org port is left configured >> to 5061 >> >> http://fpaste.org/188145/44047614/ >> >> Second debug where port set to 0 and kamailio tries resolve and crashed >> >> http://fpaste.org/188148/24440702/ >> >> Here config file >> >> http://fpaste.org/188149/24440841/ >> >> >> Thank you, >> Slava. >> >> >> ------------------------------------------------------------------------ >> *From: *"Olle E. Johansson" <oej(a)edvina.net> >> *To: *"Daniel Constantin Mierla" <miconda(a)gmail.com>, "sr-users" >> <sr-users(a)lists.sip-router.org> >> *Sent: *Thursday, February 19, 2015 4:34:04 AM >> *Subject: *Re: [SR-Users] kamailio asterisk >> >> We also need to check the core file from the crash. >> /O >> On 19 Feb 2015, at 09:30, Daniel-Constantin Mierla <miconda(a)gmail.com >> <mailto:miconda@gmail.com>> wrote: >> >> Hello, >> >> can you send the REGISTER request received by kamailio and your >> config to me? >> >> As you receive it over TLS, you can get the register by adding the >> next line in kamailio.cfg at the beginning of request_route: >> >> xlog("received request: [[$mb]]\n"); >> >> I will like to double check if the issue is still present. >> >> You should upgrade to 4.2.3, because it is the latest stable, you >> have 4.2.1 and there were many fixes meanwhile. >> >> If you preserve sips as uri schema, then you force tls further for >> forwarding. You should change that to sip:domain... >> >> Cheers, >> Daniel >> >> On 18/02/15 00:37, Slava Bendersky wrote: >> >> Hello Everyone, >> I have standard case where kamailio play role of proxy for >> asterisk servers. >> Kamailio configured use TLS transport on public side and on >> private side UDP 5060. >> When client (SIP soft phone) connect to TLS socket everything >> goes well until kamailio trying forward request. Kamailio >> tries DNS resolve tls transport srv records instead of udp >> then it just crashed when no tls configured on private side of >> kamailio. >> >> Do I need manually fix sips in URI ? Or some different miss >> configuration ? >> >> >> [root@canlvprx01 kamailio]# rpm -qa | grep kamail >> kamailio-carrierroute-4.2.1-4.2.fc21.x86_64 >> kamailio-mysql-4.2.1-4.2.fc21.x86_64 >> kamailio-outbound-4.2.1-4.2.fc21.x86_64 >> kamailio-4.2.1-4.2.fc21.x86_64 >> kamailio-tls-4.2.1-4.2.fc21.x86_64 >> >> >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [parser/msg_parser.c:625]: parse_msg(): method: <REGISTER> >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [parser/msg_parser.c:627]: parse_msg(): uri: >> <sips:domain.org> ---> Client come with TLS transport >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [parser/msg_parser.c:629]: parse_msg(): version: <SIP/2.0> >> >> >> >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [socket_info.c:583]: grep_sock_info(): grep_sock_info - >> checking if host==us: 13==12 && [domain.org >> <http://domain.org>] == [10.18.130.46 <callto:10.18.130.46>] >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [socket_info.c:587]: grep_sock_info(): grep_sock_info - >> checking if port 5060 (advertise 0) matches port 5060 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [socket_info.c:583]: grep_sock_info(): grep_sock_info - >> checking if host==us: 13==11 && [domain.org >> <http://domain.org>] == [67.34.12.56] >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [socket_info.c:587]: grep_sock_info(): grep_sock_info - >> checking if port 5081 (advertise 0) matches port 5060 >> Feb 17 11:13:49 canlvprx01 kernel: [4130713.518667] >> kamailio[22484]: segfault at 88 ip 00000000004bd30c sp >> 00007fffa2f73a20 error 4 in kamailio[400000+3b8000] >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [forward.c:448]: check_self(): check_self: host != me >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[SIPOUT] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=850 a=25 n=append_hf >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[SIPOUT] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=851 a=5 n=route >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=567 a=16 n=if >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=563 a=25 n=is_method >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=571 a=16 n=if >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=567 a=25 n=is_method >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=574 a=16 n=if >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=571 a=24 n=t_relay >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_lookup.c:1373]: t_newtran(): DEBUG: t_newtran: msg id=1 , >> global msg id=1 , T on entrance=(nil) >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_lookup.c:527]: t_lookup_request(): t_lookup_request: start >> searching: hash=48550, isACK=0 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_lookup.c:485]: matching_3261(): DEBUG: RFC3261 transaction >> matching failed >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_lookup.c:709]: t_lookup_request(): DEBUG: t_lookup_request: >> no transaction found >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_hooks.c:380]: run_reqin_callbacks_internal(): DBG: >> trans=0x7f598a9ced40, callback type 1, id 0 entered >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_hooks.c:380]: run_reqin_callbacks_internal(): DBG: >> trans=0x7f598a9ced40, callback type 1, id 0 entered >> Feb 17 11:13:49 canlvprx01 kernel: kamailio[22484]: segfault >> at 88 ip 00000000004bd30c sp 00007fffa2f73a20 error 4 in >> kamailio[400000+3b8000] >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [md5utils.c:67]: MD5StringArray(): DEBUG: MD5 calculated: >> 0475e0d0dd9778e889618cb724403b4d >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [dns_cache.c:566]: _dns_hash_find(): >> dns_hash_find(_sips._tcp.networklab.ca >> <http://tcp.networklab.ca>(24), 33), h=646 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [resolve.c:967]: get_record(): get_record: skipping 1 NS >> (p=0xa1f556, end=0xa1f588) >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [resolve.c:983]: get_record(): get_record: parsing 2 ARs >> (p=0xa1f568, end=0xa1f588) >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [dns_cache.c:1772]: dns_get_related(): >> dns_get_related(0x7f598a9e89b0 (_sips._tcp.domain.org >> <http://tcp.domain.org>, 33), 33, *0x7f5995bd55e0) (0) >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [dns_cache.c:869]: dns_cache_add_unsafe(): dns_cache_add: >> adding _sips._tcp.domain.org <http://tcp.domain.org>(24) 33 >> (flags=0) at 646 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [dns_cache.c:869]: dns_cache_add_unsafe(): dns_cache_add: >> adding camsgsrv02.domain.org >> <http://camsgsrv02.domain.org>(24) 1 (flags=0) at 967 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [dns_cache.c:566]: _dns_hash_find(): >> dns_hash_find(camsgsrv02.domain.org >> <http://camsgsrv02.domain.org>(24), 1), h=967 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [msg_translator.c:2871]: create_via_hf(): create_via_hf: id >> added: <;i=1>, rcv proto=3 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [tcp_main.c:1818]: tcp_send(): tcp_send: no open tcp >> connection found, opening new one >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [ip_addr.c:243]: print_ip(): tcpconn_new: new tcp connection: >> 10.18.130.50 <callto:10.18.130.50> >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [tcp_main.c:1073]: tcpconn_new(): tcpconn_new: on port 5061, >> type 3 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [tcp_main.c:1382]: tcpconn_add(): tcpconn_add: hashes: 3263:0:0, 2 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) WARNING: <core> >> [tcp_main.c:1221]: tcp_do_connect(): 10.18.130.50 >> <callto:10.18.130.50>:5061: could not find corresponding >> listening socket for 10.18.130.46 <callto:10.18.130.46>, using >> default... >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tls >> [tls_server.c:184]: tls_complete_init(): Using TLS domain >> TLSc<default> >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tls >> [tls_domain.c:700]: sr_ssl_ctx_info_callback(): SSL handshake >> started >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [tcp_main.c:2697]: tcpconn_1st_send(): pending write on new >> connection 0x7f598a9d4678 (-1/129 bytes written) >> Feb 17 11:13:49 canlvprx01 kamailio: 15(22484) DEBUG: <core> >> [tcp_main.c:3565]: handle_ser_child(): handle_ser_child: read >> response= 7f598a9d4678, 5, fd 31 from 11 (22480) >> Feb 17 11:13:49 canlvprx01 kamailio: 15(22484) DEBUG: <core> >> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x9daf00, >> 31, 2, 0x7f598a9d4678), fd_no=19 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_funcs.c:394]: t_relay_to(): SER: new transaction fwd'ed >> >> >> >> Thank you Slava. >> >> >> _______________________________________________ >> 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://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >> Kamailio World Conference, May 27-29, 2015 >> Berlin, Germany - http://www.kamailioworld.com >> >> _______________________________________________ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing >> list >> sr-users(a)lists.sip-router.org <mailto:sr-users@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://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com

2 1

Re: [SR-Users] kamailio asterisk
by Slava Bendersky 25 Feb '15

25 Feb '15

Hello Everyone, I wonder in my case why kamailio is not bridging between TLS and UDP ? Is there additional configuration required ? Slava. From: "Slava Bendersky" <volga629(a)networklab.ca> To: miconda(a)gmail.com Cc: "sr-users" <sr-users(a)lists.sip-router.org> Sent: Tuesday, February 24, 2015 11:42:02 AM Subject: Re: [SR-Users] kamailio asterisk Hello Everyone, Here link to core dump bt full. http://fpaste.org/189799/79603014/ password the same Slava. From: "Daniel-Constantin Mierla" <miconda(a)gmail.com> To: "volga629" <volga629(a)skillsearch.ca>, "Slava Bendersky" <volga629(a)networklab.ca>, "sr-users" <sr-users(a)lists.sip-router.org> Sent: Monday, February 23, 2015 3:56:48 AM Subject: Re: [SR-Users] kamailio asterisk You don't need to run kamailio through gdb. If it crashes, then you get a corefile -- in the logs it says the name of the file. It is usually located in / or in the path you gave to -w parameter. After you reproduced the crash, locate the corefile and run gdb like: gdb /path/to/kamailio /path/to/corefile bt full The /path/to/kamailio should be /usr/sbin/kamailio if you installed from rpms. If you have improvements to init or sysconfig kamailio file, send a patch and we will include the changes in kamailio repository. Cheers, Daniel On 23/02/15 01:00, Slava Bendersky wrote: > Hello Everyone, > I upgraded to 4.2.3 version, but crash still there. What is my options to meet case like this. > > Client TLS -------> KAMAILIO Proxy ------ UDP/TCP ----> asterisk > | > | > Public Private > > I will try try run gdb to get backtrace on crash. > Also here link for Fedora 21 server rpms. There are couple small fixes for init file and sysconfig/kamailio > > http://ftpsrv01.networklab.ca/fedora/21/RPMS/x86_64/ > > Slava. > > Sent from mobile device typos are expected. > > From: Daniel-Constantin Mierla <miconda(a)gmail.com> > Sent: Feb 22, 2015 5:34 PM > To: Slava Bendersky <volga629(a)networklab.ca>;sr-users > Subject: Re: [SR-Users] kamailio asterisk > > > > Hello, > > looking at the logs, the process routing the register is forwarding it, > by opening a tls connection -- that is because the uri has sips as schema. > > The crash is reported in another process that doesn't print much logs > messages. As Olle suggested, can you get the backtrace with gdb from the > core file? That will help to see where the crash happened. > > gdb /path/to/kamailio /path/to/corefile > bt full > > And again, it would be good to upgrade to 4.2.3 -- it is same config and > database, just install new version and restart. In this way we rule out > issues that were fixed already, avoiding to spend time on something fixed. > > Cheers, > Daniel > > On 20/02/15 15:03, Slava Bendersky wrote: >> Hello Everyone, >> Thank you for reply, >> On client I configured user @ domain.org and proxy point to kamailio >> Here 1 debug where on client after doamin.org port is left configured >> to 5061 >> >> http://fpaste.org/188145/44047614/ >> >> Second debug where port set to 0 and kamailio tries resolve and crashed >> >> http://fpaste.org/188148/24440702/ >> >> Here config file >> >> http://fpaste.org/188149/24440841/ >> >> >> Thank you, >> Slava. >> >> >> ------------------------------------------------------------------------ >> *From: *"Olle E. Johansson" <oej(a)edvina.net> >> *To: *"Daniel Constantin Mierla" <miconda(a)gmail.com>, "sr-users" >> <sr-users(a)lists.sip-router.org> >> *Sent: *Thursday, February 19, 2015 4:34:04 AM >> *Subject: *Re: [SR-Users] kamailio asterisk >> >> We also need to check the core file from the crash. >> /O >> On 19 Feb 2015, at 09:30, Daniel-Constantin Mierla <miconda(a)gmail.com >> <mailto:miconda@gmail.com>> wrote: >> >> Hello, >> >> can you send the REGISTER request received by kamailio and your >> config to me? >> >> As you receive it over TLS, you can get the register by adding the >> next line in kamailio.cfg at the beginning of request_route: >> >> xlog("received request: [[$mb]]\n"); >> >> I will like to double check if the issue is still present. >> >> You should upgrade to 4.2.3, because it is the latest stable, you >> have 4.2.1 and there were many fixes meanwhile. >> >> If you preserve sips as uri schema, then you force tls further for >> forwarding. You should change that to sip:domain... >> >> Cheers, >> Daniel >> >> On 18/02/15 00:37, Slava Bendersky wrote: >> >> Hello Everyone, >> I have standard case where kamailio play role of proxy for >> asterisk servers. >> Kamailio configured use TLS transport on public side and on >> private side UDP 5060. >> When client (SIP soft phone) connect to TLS socket everything >> goes well until kamailio trying forward request. Kamailio >> tries DNS resolve tls transport srv records instead of udp >> then it just crashed when no tls configured on private side of >> kamailio. >> >> Do I need manually fix sips in URI ? Or some different miss >> configuration ? >> >> >> [root@canlvprx01 kamailio]# rpm -qa | grep kamail >> kamailio-carrierroute-4.2.1-4.2.fc21.x86_64 >> kamailio-mysql-4.2.1-4.2.fc21.x86_64 >> kamailio-outbound-4.2.1-4.2.fc21.x86_64 >> kamailio-4.2.1-4.2.fc21.x86_64 >> kamailio-tls-4.2.1-4.2.fc21.x86_64 >> >> >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [parser/msg_parser.c:625]: parse_msg(): method: <REGISTER> >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [parser/msg_parser.c:627]: parse_msg(): uri: >> <sips:domain.org> ---> Client come with TLS transport >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [parser/msg_parser.c:629]: parse_msg(): version: <SIP/2.0> >> >> >> >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [socket_info.c:583]: grep_sock_info(): grep_sock_info - >> checking if host==us: 13==12 && [domain.org >> <http://domain.org>] == [10.18.130.46 <callto:10.18.130.46>] >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [socket_info.c:587]: grep_sock_info(): grep_sock_info - >> checking if port 5060 (advertise 0) matches port 5060 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [socket_info.c:583]: grep_sock_info(): grep_sock_info - >> checking if host==us: 13==11 && [domain.org >> <http://domain.org>] == [67.34.12.56] >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [socket_info.c:587]: grep_sock_info(): grep_sock_info - >> checking if port 5081 (advertise 0) matches port 5060 >> Feb 17 11:13:49 canlvprx01 kernel: [4130713.518667] >> kamailio[22484]: segfault at 88 ip 00000000004bd30c sp >> 00007fffa2f73a20 error 4 in kamailio[400000+3b8000] >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [forward.c:448]: check_self(): check_self: host != me >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[SIPOUT] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=850 a=25 n=append_hf >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[SIPOUT] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=851 a=5 n=route >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=567 a=16 n=if >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=563 a=25 n=is_method >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=571 a=16 n=if >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=567 a=25 n=is_method >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=574 a=16 n=if >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** >> cfgtrace:request_route=[RELAY] >> c=[/etc/kamailio/kamailio-asterisk.cfg] l=571 a=24 n=t_relay >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_lookup.c:1373]: t_newtran(): DEBUG: t_newtran: msg id=1 , >> global msg id=1 , T on entrance=(nil) >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_lookup.c:527]: t_lookup_request(): t_lookup_request: start >> searching: hash=48550, isACK=0 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_lookup.c:485]: matching_3261(): DEBUG: RFC3261 transaction >> matching failed >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_lookup.c:709]: t_lookup_request(): DEBUG: t_lookup_request: >> no transaction found >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_hooks.c:380]: run_reqin_callbacks_internal(): DBG: >> trans=0x7f598a9ced40, callback type 1, id 0 entered >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_hooks.c:380]: run_reqin_callbacks_internal(): DBG: >> trans=0x7f598a9ced40, callback type 1, id 0 entered >> Feb 17 11:13:49 canlvprx01 kernel: kamailio[22484]: segfault >> at 88 ip 00000000004bd30c sp 00007fffa2f73a20 error 4 in >> kamailio[400000+3b8000] >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [md5utils.c:67]: MD5StringArray(): DEBUG: MD5 calculated: >> 0475e0d0dd9778e889618cb724403b4d >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [dns_cache.c:566]: _dns_hash_find(): >> dns_hash_find(_sips._tcp.networklab.ca >> <http://tcp.networklab.ca>(24), 33), h=646 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [resolve.c:967]: get_record(): get_record: skipping 1 NS >> (p=0xa1f556, end=0xa1f588) >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [resolve.c:983]: get_record(): get_record: parsing 2 ARs >> (p=0xa1f568, end=0xa1f588) >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [dns_cache.c:1772]: dns_get_related(): >> dns_get_related(0x7f598a9e89b0 (_sips._tcp.domain.org >> <http://tcp.domain.org>, 33), 33, *0x7f5995bd55e0) (0) >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [dns_cache.c:869]: dns_cache_add_unsafe(): dns_cache_add: >> adding _sips._tcp.domain.org <http://tcp.domain.org>(24) 33 >> (flags=0) at 646 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [dns_cache.c:869]: dns_cache_add_unsafe(): dns_cache_add: >> adding camsgsrv02.domain.org >> <http://camsgsrv02.domain.org>(24) 1 (flags=0) at 967 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [dns_cache.c:566]: _dns_hash_find(): >> dns_hash_find(camsgsrv02.domain.org >> <http://camsgsrv02.domain.org>(24), 1), h=967 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [msg_translator.c:2871]: create_via_hf(): create_via_hf: id >> added: <;i=1>, rcv proto=3 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [tcp_main.c:1818]: tcp_send(): tcp_send: no open tcp >> connection found, opening new one >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [ip_addr.c:243]: print_ip(): tcpconn_new: new tcp connection: >> 10.18.130.50 <callto:10.18.130.50> >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [tcp_main.c:1073]: tcpconn_new(): tcpconn_new: on port 5061, >> type 3 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [tcp_main.c:1382]: tcpconn_add(): tcpconn_add: hashes: 3263:0:0, 2 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) WARNING: <core> >> [tcp_main.c:1221]: tcp_do_connect(): 10.18.130.50 >> <callto:10.18.130.50>:5061: could not find corresponding >> listening socket for 10.18.130.46 <callto:10.18.130.46>, using >> default... >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tls >> [tls_server.c:184]: tls_complete_init(): Using TLS domain >> TLSc<default> >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tls >> [tls_domain.c:700]: sr_ssl_ctx_info_callback(): SSL handshake >> started >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> >> [tcp_main.c:2697]: tcpconn_1st_send(): pending write on new >> connection 0x7f598a9d4678 (-1/129 bytes written) >> Feb 17 11:13:49 canlvprx01 kamailio: 15(22484) DEBUG: <core> >> [tcp_main.c:3565]: handle_ser_child(): handle_ser_child: read >> response= 7f598a9d4678, 5, fd 31 from 11 (22480) >> Feb 17 11:13:49 canlvprx01 kamailio: 15(22484) DEBUG: <core> >> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x9daf00, >> 31, 2, 0x7f598a9d4678), fd_no=19 >> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm >> [t_funcs.c:394]: t_relay_to(): SER: new transaction fwd'ed >> >> >> >> Thank you Slava. >> >> >> _______________________________________________ >> 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://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >> Kamailio World Conference, May 27-29, 2015 >> Berlin, Germany - http://www.kamailioworld.com >> >> _______________________________________________ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing >> list >> sr-users(a)lists.sip-router.org <mailto:sr-users@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://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

2 1

TLS t_replicate
by Kelvin Chua 25 Feb '15

25 Feb '15

serverA listens on both UDP and TLS serverB listens on UDP only client registers to serverA via UDP. serverA uses t_replicate (;transport=udp) sends register to serverB all looks good client registers to serverA via TLS serverA uses t_replicate (;transport=udp) but no packet comes out of kamailio :( how is it supposed to be done? any ideas? Kelvin Chua

1 1

2 TLS issues/questions: per-client config & IPv6 client
by Anthony Messina 25 Feb '15

25 Feb '15

I'm wondering if anyone can point me in the right direction for the following two issues with Kamailio and tls.cfg 1. When attempting to configure TLS settings for connecting to a specific IPv4 client, it seems that the ca_list indicated in [client:default] overrides the one in the client-specific config. If I don't include the client's CA in the [client:default] section, I get the following, regardless of what is in [client:204.74.213.5:5061]. ERROR: tls [tls_server.c:1230]: tls_read_f(): TLS write:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed [client:default] method = TLSv1+ verify_certificate = yes require_certificate = no private_key = /etc/kamailio/key.pem certificate = /etc/kamailio/crt.pem verify_depth = 2 # In order for the client below to work, the ca_list here needs to support # contain the CA for the specific client. Not sure why, maybe a bug? #ca_list = /etc/pki/CA/myownCA.pem # Can't use this one ca_list = /etc/kamailio/kamailio.tls.ca_list.pem # Contains ALL client CA's [client:204.74.213.5:5061] method = TLSv1+ verify_certificate = yes require_certificate = yes verify_depth = 2 ca_list = /etc/kamailio/204.74.213.5.crt.pem 2. When attempting to configure TLS settings for connecting to a specific IPv6 client, I cannot figure out the syntax needed to specify the IPv6 client. What is the proper syntax? With [client:[2607:5300:60:1f93::0]:5061], I get: ERROR: tls [tls_config.c:71]: parse_ipv6(): tls.cfg:57:9: Invalid IPv6 address Any guidance is appreciated. Thanks. -A -- Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E

2 9

Re: [SR-Users] sr-users Digest, Vol 117, Issue 23
by Euan Thoms 24 Feb '15

24 Feb '15

> Date: Sun, 22 Feb 2015 04:25:14 +0100 > From: Markus <universe(a)truemetal.org> > To: "Kamailio (SER) - Users Mailing List" > <sr-users(a)lists.sip-router.org> > Subject: Re: [SR-Users] NAT SIPPING in a FreeBSD jail > Message-ID: <54E94C1A.6000704(a)truemetal.org> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Am 21.02.2015 um 08:47 schrieb Euan Thoms: > > ** My question is: how do I force the ping behaviour in NAT SIPping feature? I need a trigger to further debug. > > Just an idea in general: Attach to the kamailio process(es) with strace > with trace output to a file and the moment it crashes you should have > some more data. I think I found the problem. I think it was nothing to do with NAT SIPping. I had to patch ip_addr.h because Clang on FreeBSD was not finding the INADDR_LOCALHOST definition from netinet/in.h, despite it being there in FreeBSDs' /usr/include. So previously I defined it as an 'unsigned long'. Now that I have defined it in ip_addr.h as a 'u_int32_t' Kamailio has not crashed since. Also, I no longer get any errors in my /var/log/messages when Linphone closes. I have yet to re-enable WITH_NATSIPPING, I want to wait a bit longer before drawing any further conclussions. Thanks and regards to all the Kamailio devs, Euan Thoms.

1 0

Textops Module - Multipart Body conversion
by Federico San Martín 24 Feb '15

24 Feb '15

Hi guys, I'm trying to convert an SDP body to Multipart/Mixed and add an ISUP encapsulated part (SIP-I) on a 200OK reply. It seems like the module is having trouble with the delimiters. The scenario is like this: PSTN MGC Kamailio SEMS |-------IAM------>| | | | |----INVITE/IAM/SDP---> | | | | | ---INVITE/IAM/SDP--> | | | | <------200OK/SDP---- | | |<-----200OK/ACM/SDP--- | | |<------ACM-------| | | This is the config I'm using (just showing the relevant part, let me know if you need the whole config file): onreply_route[MANAGE_REPLY]{ if (status=~"200"){ xlog("L_INFO","Reply <$rs> Message Interception\n"); route(INSERT_ACM); } } route[INSERT_ACM]{ set_body_multipart(); $var(acm) = "06 02 04 01 29 01 01 00"; append_body_part("$var(acm)","application/isup; version=itu-t92+","signal; handling=optional"); return; } The original 200OK Message received is: #U 2015/02/20 11:40:38.687418 172.30.24.20:5080 -> 172.30.24.20:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 172.30.24.20;branch=z9hG4bK8a2b.41161a372680192aa4fdd9efbefd6696.0 Via: SIP/2.0/UDP 172.30.8.66:5060;branch=z9hG4bK+1010ce54853b2a3c7f7b8a220b4b69a41+3a836f1f+1 Call-ID: 4C6CD8F8@3a836f1f From: "Fede SM Test"<sip:1135349910@172.30.8.66:5060;user=phone>;tag=3a836f1f+1+1e100002+ef7ba2f0 To: <sip:100@172.30.24.20:5060;user=phone>;tag=3DF4D6A2-54E74766000A65EC-41B8C700 CSeq: 221937633 INVITE Server: Sip Express Media Server (1.5.1 (x86_64/linux)) Contact: <sip:100@172.30.24.20:5080> Content-Type: application/sdp Content-Length: 224 v=0 o=sems 351367313 715465045 IN IP4 172.30.24.20 s=sems c=IN IP4 172.30.24.20 t=0 0 m=audio 10054 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=direction:both And the mangled 200OK message I generate with Kamailio to send Upstream with this configuration is: # U 2015/02/20 11:40:38.690733 172.30.24.20:5060 -> 172.30.8.66:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 172.30.8.66:5060;branch=z9hG4bK+1010ce54853b2a3c7f7b8a220b4b69a41+3a836f1f+1 Call-ID: 4C6CD8F8@3a836f1f From: "Fede SM Test"<sip:1135349910@172.30.8.66:5060;user=phone>;tag=3a836f1f+1+1e100002+ef7ba2f0 To: <sip:100@172.30.24.20:5060;user=phone>;tag=3DF4D6A2-54E74766000A65EC-41B8C700 CSeq: 221937633 INVITE Server: Sip Express Media Server (1.5.1 (x86_64/linux)) Contact: <sip:100@172.30.24.20:5080> Content-Length: 301 Content-Type: multipart/mixed;boundary="unique-boundary-1" Mime-Version: 1.0 --unique-boundary-1 Content-Type: application/sdp v=0 o=sems 351367313 715465045 IN IP4 172.30.24.20 s=sems c=IN IP4 172.30.24.20 t=0 0 m=audio 10054 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=direction:both --unique-boundary-1 As you can see, the TEXTOPS module is not adding the ISUP part, also the boundary of the SDP is missing the last "--" to indicate this is the last part. But it is indeed changing the Content-Type to multipart/mixed, although the boundary has a set of quotes that I'm not sure if could be the problem. On the logs I get: Feb 20 11:51:49 KAMAILIO kamailio[19883]: INFO: Kamlog: Reply <200> Message Interception Feb 20 11:51:49 KAMAILIO kamailio[19883]: DEBUG: textops [textops.c:1582]: set_multibody_helper(): delimiter<17>:[unique-boundary-1] Feb 20 11:51:49 KAMAILIO kamailio[19883]: DEBUG: <core> [parser/msg_parser.c:204]: get_hdr_field(): DEBUG: get_hdr_body : content_length=225 Feb 20 11:51:49 KAMAILIO kamailio[19883]: DEBUG: <core> [parser/msg_parser.c:106]: get_hdr_field(): found end of header Feb 20 11:51:49 KAMAILIO kamailio[19883]: DEBUG: textops [textops.c:1491]: generate_boundary(): adding final CRLF+CRLF Feb 20 11:51:49 KAMAILIO kamailio[19883]: DEBUG: textops [textops.c:1719]: set_multibody_helper(): content-type<44>:[multipart/mixed;boundary="unique-boundary-1"] Feb 20 11:51:49 KAMAILIO kamailio[19883]: DEBUG: textops [textops.c:1771]: set_multibody_helper(): set flag FL_BODY_MULTIPART ### Error ### Feb 20 11:51:49 KAMAILIO kamailio[19883]: ERROR: textops [textops.c:1869]: append_multibody_helper(): Cannot get boundary. Is body multipart? ### ### Feb 20 11:51:49 KAMAILIO kamailio[19883]: DEBUG: tm [t_reply.c:1294]: t_should_relay_response(): ->>>>>>>>> T_code=100, new_code=200 Feb 20 11:51:49 KAMAILIO kamailio[19883]: DEBUG: tm [t_reply.c:1812]: relay_reply(): DEBUG: relay_reply: branch=0, save=0, relay=0 icode=0 Feb 20 11:51:49 KAMAILIO kamailio[19883]: DEBUG: <core> [msg_translator.c:470]: clen_builder(): clen_builder: content-length: 302 (302) Feb 20 11:51:49 KAMAILIO kamailio[19883]: DEBUG: <core> [msg_translator.c:2278]: generate_res_buf_from_sip_res(): old size: 804, new size: 844 Feb 20 11:51:49 KAMAILIO kamailio[19883]: DEBUG: <core> [msg_translator.c:2296]: generate_res_buf_from_sip_res(): copied size: orig:804, new: 844, rest: 0 msg=#012SIP/2.0 200 OK#015#012Via: SIP/2.0/UDP 172.30.8.66:5060;branch=z9hG4bK+68a818f192518f00b46eeddb5c81dd791+3a836f1f+1#015#012Call-ID: CE965967@3a836f1f#015#012From: "Fede SM Test"<sip:1135349910@172.30.8.66:5060;user=phone>;tag=3a836f1f+1+1e090003+66eb0deb#015#012To: <sip:100@172.30.24.20:5060;user=phone>;tag=21E58627-54E74A050009BACD-41C8D700#015#012CSeq: 525107355 INVITE#015#012Server: Sip Express Media Server (1.5.1 (x86_64/linux))#015#012Contact: <sip:100@172.30.24.20:5080>#015#012Content-Length: 302#015#012Content-Type: multipart/mixed;boundary="unique-boundary-1"#015#012Mime-Version: 1.0#015#012#015#012--unique-boundary-1#015#012Content-Type: application/sdp#015#012#015#012v=0#015#012o=sems 1379293612 709544991 IN IP4 172.30.24.20#015#012s=sems#015#012c=IN IP4 172.30.24.20#015#012t=0 0#015#012m=audio 10056 RTP/AVP 8 101#015#012a=rtpmap:8 PCMA/8000#015#012a=rtpmap:101 telephone-event/8000#015#012a=fmtp:101 0-15#015#012a=sendrecv#015#012a=direction:both#015#012#015#012--unique-boundary-1#015#012 Could it be that those missing "--" after the unique-boundary-1 delimiter are the ones giving trouble? Or could it be those extra quotes on the Content-Type boundary? Any help would be appreciated, thanks!! Federico Federico San Martín e-mail : fsanmartin(a)telecentro.net.ar

2 1

Re: [SR-Users] Regarding RTP in IMS Networks.
by Badri Ranganathan 24 Feb '15

24 Feb '15

Hi all, I'll make this question a little clearer. User 1 ---------------- SBC ----+ other IMS network components ---------------------- User 2 Same scenario User 1 Making the call + plays RTP Traffic User 2 Answering the call + records the RTP Traffic coming from User 1 and does a PESQ voice quality analysis If user 2, after answering the call, did not play RTP as well, the SBC will not forward the RTP from User 1 to User 2. [The media gateways responsible for the RTP traffic is also a part of the IMS network right?] So why this sort of bi-directional traffic imposition in an IMS Network ? Thanks, Badri. -----Original Message----- From: Badri Ranganathan Sent: 24 February 2015 15:13 To: sr-users(a)lists.sip-router.org Subject: Regarding RTP in IMS Networks. Hi all, I have a doubt w.r.t media traffic in IMS Networks. If I have a setting as follows - User 1 Making the call + plays RTP Traffic User 2 Answering the call + records the RTP Traffic coming from User 1 and does a PESQ voice quality analysis I see that User 2 has to play RTP Traffic before it can start recording the RTP coming from user 1. i.e., User 2 Answering the call + (Play RTP Traffic ) + records the RTP Traffic coming from User 1 and does a PESQ voice quality analysis. Why am I seeing this behaviour. Is it just a setting in the IMS network that can be changed or is it a standard behaviour in IMS Networks ? If yes, then could anyone please let me know the logic behind such a decision? Please do let me know if you have any ideas. Any responses really appreciated ! Thanks, Badri.

2 1

Regarding RTP in IMS Networks.
by Badri Ranganathan 24 Feb '15

24 Feb '15

Hi all, I have a doubt w.r.t media traffic in IMS Networks. If I have a setting as follows - User 1 Making the call + plays RTP Traffic User 2 Answering the call + records the RTP Traffic coming from User 1 and does a PESQ voice quality analysis I see that User 2 has to play RTP Traffic before it can start recording the RTP coming from user 1. i.e., User 2 Answering the call + (Play RTP Traffic ) + records the RTP Traffic coming from User 1 and does a PESQ voice quality analysis. Why am I seeing this behaviour. Is it just a setting in the IMS network that can be changed or is it a standard behaviour in IMS Networks ? If yes, then could anyone please let me know the logic behind such a decision? Please do let me know if you have any ideas. Any responses really appreciated ! Thanks, Badri.

1 0

Drouting Question
by Andrew Okri 24 Feb '15

24 Feb '15

Hi All, Does dropping set the $du or $ru uri when it finds a match in the database? I am getting destination not set error in my debug trace and he call request times out as a result. Regards Andrew Okri

1 0

kamailio crash
by kovarik＠odorik.cz 23 Feb '15

23 Feb '15

Hello, kamailio crash if receive this invite (full pcap in attach): INVITE sip:+420235356120@sip.odorik.cz SIP/2.0 Via: SIP/2.0/TCP 89.103.14.100:5060;branch=z9hG4bKader9m419p44oh1arfvg3q3;rport From: <sip:680114@sip.odorik.cz>;tag=n67dnvutedhc7h8g0723 To: <sip:+420235356120@sip.odorik.cz> Contact: <sip:4WJEcOsCK95r_THu1yoG@89.103.14.100:5060;comp=sigcomp> Supported: 100rel,timer CSeq: 2374 INVITE Call-ID: PKnr_QhkoIfgFw74ch7P9QzSx4Utqm Allow: UPDATE,PRACK,SUBSCRIBE,REFER,NOTIFY,INVITE,ACK,CANCEL,OPTIONS,BYE User-Agent: Nokia RM-469 091.003 (cs) Expires: 120 Privacy: None Session-Expires: 1800 Max-Forwards: 69 Proxy-Authorization: Digest realm="sip.odorik.cz",nonce="VOd181TndMfi5yGjm4maxIr8yb1s/ARs",algorithm=MD5,username="680114",uri="sip:+420235356120@sip.odorik.cz",response="11aa17ebbf02d284c1fa5b03bca7fd89" Content-Type: application/sdp Accept-Language: cs Content-Length: 540 v=0 o=680114 63592714297343250 63592714297343250 IN IP4 89.103.14.100 s=- c=IN IP4 89.103.14.100 t=0 0 m=audio 49152 RTP/AVP 100 96 0 8 97 18 98 13 a=sendrecv a=rtpmap:100 AMR-WB/16000 a=ptime:20 a=maxptime:200 a=fmtp:100 mode-change-period=2; mode-change-neighbor=1 a=rtpmap:96 AMR/8000 a=fmtp:96 mode-set=0,1,2,3,4,5,6,7; mode-change-neighbor=1 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:98 telephone-event/8000 a=fmtp:98 0-15 a=rtpmap:13 CN/8000 and in run im kamailio.cfg $var(codecs)="G729,PCMA,GSM,iLBC,speex,telephone-event"; sdp_keep_codecs_by_name($var(codecs)); Kamailio crash with gdb export crash_20.02.2015 in attachments. kamailio -v version: kamailio 4.2.3 (x86_64/linux) 9524b3-dirty flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, DBG_F_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 9524b3 -dirty compiled on 23:32:12 Feb 19 2015 with gcc 4.7.2 Thank you.

2 2

Best practices for unsetting PVs
by Alex Balashov 23 Feb '15

23 Feb '15

Hi, We have this approach for arrayable PVs (e.g. AVPs, XAVPs): $(avp(var)[*]) = $null; This defines the PV, but sets its value to null. I haven't tested, but I would assume, in the case of an AVP, that this would cause it to fail defined $avp(var) is_avp_set("$avp(var)") But, I see there is also in the 'pv' module now a function pv_unset(), i.e. pv_unset("$avp(var)"); pv_unset("$var(foo)"); I assume this actually deletes the variable itself from the namespace, instead of assigning it an undefined value. Are there pros and cons to using one or the other to mass-reset variables relevant to call processing at the beginning of route script? Thanks, -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/

1 0

Re: [SR-Users] kamailio asterisk
by Slava Bendersky 23 Feb '15

23 Feb '15

Hello Everyone, Thank you for reply, On client I configured user @ domain.org and proxy point to kamailio Here 1 debug where on client after doamin.org port is left configured to 5061 http://fpaste.org/188145/44047614/ Second debug where port set to 0 and kamailio tries resolve and crashed http://fpaste.org/188148/24440702/ Here config file http://fpaste.org/188149/24440841/ Thank you, Slava. From: "Olle E. Johansson" <oej(a)edvina.net> To: "Daniel Constantin Mierla" <miconda(a)gmail.com>, "sr-users" <sr-users(a)lists.sip-router.org> Sent: Thursday, February 19, 2015 4:34:04 AM Subject: Re: [SR-Users] kamailio asterisk We also need to check the core file from the crash. /O On 19 Feb 2015, at 09:30, Daniel-Constantin Mierla < miconda(a)gmail.com > wrote: Hello, can you send the REGISTER request received by kamailio and your config to me? As you receive it over TLS, you can get the register by adding the next line in kamailio.cfg at the beginning of request_route: xlog("received request: [[$mb]]\n"); I will like to double check if the issue is still present. You should upgrade to 4.2.3, because it is the latest stable, you have 4.2.1 and there were many fixes meanwhile. If you preserve sips as uri schema, then you force tls further for forwarding. You should change that to sip:domain ... Cheers, Daniel On 18/02/15 00:37, Slava Bendersky wrote: BQ_BEGIN Hello Everyone, I have standard case where kamailio play role of proxy for asterisk servers. Kamailio configured use TLS transport on public side and on private side UDP 5060. When client (SIP soft phone) connect to TLS socket everything goes well until kamailio trying forward request. Kamailio tries DNS resolve tls transport srv records instead of udp then it just crashed when no tls configured on private side of kamailio. Do I need manually fix sips in URI ? Or some different miss configuration ? [root@canlvprx01 kamailio]# rpm -qa | grep kamail kamailio-carrierroute-4.2.1-4.2.fc21.x86_64 kamailio-mysql-4.2.1-4.2.fc21.x86_64 kamailio-outbound-4.2.1-4.2.fc21.x86_64 kamailio-4.2.1-4.2.fc21.x86_64 kamailio-tls-4.2.1-4.2.fc21.x86_64 Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [parser/msg_parser.c:625]: parse_msg(): method: <REGISTER> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [parser/msg_parser.c:627]: parse_msg(): uri: <sips:domain.org> ---> Client come with TLS transport Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [parser/msg_parser.c:629]: parse_msg(): version: <SIP/2.0> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 13==12 && [ domain.org ] == [ 10.18.130.46 ] Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5060 (advertise 0) matches port 5060 Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 13==11 && [ domain.org ] == [67.34.12.56] Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5081 (advertise 0) matches port 5060 Feb 17 11:13:49 canlvprx 01 kernel: [4130713.518667] kamailio[22484]: segfault at 88 ip 0000000 0004bd30c sp 00007fffa2f73a20 error 4 in kamailio[400000+3b8000] Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [forward.c:448]: check_self(): check_self: host != me Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** cfgtrace:request_route=[SIPOUT] c=[/etc/kamailio/kamailio-asterisk.cfg] l=850 a=25 n=append_hf Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** cfgtrace:request_route=[SIPOUT] c=[/etc/kamailio/kamailio-asterisk.cfg] l=851 a=5 n=route Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** cfgtrace:request_route=[RELAY] c=[/etc/kamailio/kamailio-asterisk.cfg] l=567 a=16 n=if Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** cfgtrace:request_route=[RELAY] c=[/etc/kamailio/kamailio-asterisk.cfg] l=563 a=25 n=is_method Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** cfgtrace:request_route=[RELAY] c=[/etc/kamailio/kamailio-asterisk.cfg] l=571 a=16 n=if Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** cfgtrace:request_route=[RELAY] c=[/etc/kamailio/kamailio-asterisk.cfg] l=567 a=25 n=is_method Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** cfgtrace:request_route=[RELAY] c=[/etc/kamailio/kamailio-asterisk.cfg] l=574 a=16 n=if Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** cfgtrace:request_route=[RELAY] c=[/etc/kamailio/kamailio-asterisk.cfg] l=571 a=24 n=t_relay Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm [t_lookup.c:1373]: t_newtran(): DEBUG: t_newtran: msg id=1 , global msg id=1 , T on entrance=(nil) Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm [t_lookup.c:527]: t_lookup_request(): t_lookup_request: start searching: hash=48550, isACK=0 Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm [t_lookup.c:485]: matching_3261(): DEBUG: RFC3261 transaction matching failed Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm [t_lookup.c:709]: t_lookup_request(): DEBUG: t_lookup_request: no transaction found Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm [t_hooks.c:380]: run_reqin_callbacks_internal(): DBG: trans=0x7f598a9ced40, callback type 1, id 0 entered Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm [t_hooks.c:380]: run_reqin_callbacks_internal(): DBG: trans=0x7f598a9ced40, callback type 1, id 0 entered Feb 17 11:13:49 canlvprx 01 kernel: kamailio[22484]: segfault at 88 ip 00000000004bd30c sp 00007 fffa2f73a20 error 4 in kamailio[400000+3b8000] Feb 17 11:13: 49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [md5utils.c:67]: MD5St ringArray(): DEBUG: MD5 calculated: 0475e0d0dd9778e889618cb724403b4d Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [dns_cache.c:566]: _dns_hash_find(): dns_hash_find(_sips._ tcp.networklab.ca (24), 33), h=646 Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [resolve.c:967]: get_record(): get_record: skipping 1 NS (p=0xa1f556, end=0xa1f588) Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [resolve.c:983]: get_record(): get_record: parsing 2 ARs (p=0xa1f568, end=0xa1f588) Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [dns_cache.c:1772]: dns_get_related(): dns_get_related(0x7f598a9e89b0 (_sips._ tcp.domain.org , 33), 33, *0x7f5995bd55e0) (0) Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [dns_cache.c:869]: dns_cache_add_unsafe(): dns_cache_add: adding _sips._ tcp.domain.org (24) 33 (flags=0) at 646 Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [dns_cache.c:869]: dns_cache_add_unsafe(): dns_cache_add: adding camsgsrv02.domain.org (24) 1 (flags=0) at 967 Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [dns_cache.c:566]: _dns_hash_find(): dns_hash_find( camsgsrv02.domain.org (24), 1), h=967 Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [msg_translator.c:2871]: create_via_hf(): create_via_hf: id added: <;i=1>, rcv proto=3 Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [tcp_main.c:1818]: tcp_send(): tcp_send: no open tcp connection found, opening new one Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [ip_addr.c:243]: print_ip(): tcpconn_new: new tcp connection: 10.18.130.50 Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [tcp_main.c:1073]: tcpconn_new(): tcpconn_new: on port 5061, type 3 Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [tcp_main.c:1382]: tcpconn_add(): tcpconn_add: hashes: 3263:0:0, 2 Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) WARNING: <core> [tcp_main.c:1221]: tcp_do_connect(): 10.18.130.50 :5061: could not find corresponding listening socket for 10.18.130.46 , using default... Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tls [tls_server.c:184]: tls_complete_init(): Using TLS domain TLSc<default> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tls [tls_domain.c:700]: sr_ssl_ctx_info_callback(): SSL handshake started Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [tcp_main.c:2697]: tcpconn_1st_send(): pending write on new connection 0x7f598a9d4678 (-1/129 bytes written) Feb 17 11:13:49 canlvprx01 kamailio: 15(22484) DEBUG: <core> [tcp_main.c:3565]: handle_ser_child(): handle_ser_child: read response= 7f598a9d4678, 5, fd 31 from 11 (22480) Feb 17 11:13:49 canlvprx01 kamailio: 15(22484) DEBUG: <core> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x9daf00, 31, 2, 0x7f598a9d4678), fd_no=19 Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm [t_funcs.c:394]: t_relay_to(): SER: new transaction fwd'ed Thank you Slava. _______________________________________________ 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://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com _______________________________________________ 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 BQ_END _______________________________________________ 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

3 3

Dispatcher: Check uri string in Kamailio 3.3
by Jon Bonilla (Manwe) 22 Feb '15

22 Feb '15

Hi all I need to check a given uri against dispatcher destination entries. I see that it's possible in kamailio 4.2 using ds_is_from_list which allows "uri" parameter but it's not available in version 3.3. Moving to 4.x is not an option this time. Any hints about how to check this? Raw sql + string comparation or something more elegant out there? thanks, Jon

2 1

NAT SIPPING in a FreeBSD jail
by Euan Thoms 22 Feb '15

22 Feb '15

I've been running Kamailio 4.2.2/4.2.3 in a FreeBSD 10.1 jail for a few weeks, thanks to a recent port in the FreeBSD ports tree. However, it has been a bit unstable. It crashes randomly. It's hard to debug since it can go three days without crashing, and there is no obvious trigger. I'm also running 4.1.0 on FreeBSD 8.3, compiled from source manually. It is rock solid for a long time now. So, I have 2 theories: 1) My FreeBSd ports patch for ip_addr.h is wrong. I was having to define INADDR_LOOPBACK since compile would fail with 'undeclared identifier'. My patch was to define INADDR_LOOPBACK in ip_addr.h as a 'long' as such: #define INADDR_LOOPBACK (long) 0x7F000001 However, it appears this should have been: #define INADDR_LOOPBACK (unsigned long) 0x7F000001 The previous patch seemed to work, but could have caused the crashes I'm seeing. 2.) The NAT SIPPing feature defined with WITH_NATSIPPING is a new feature since 4.1.0. So my 4.1.0 installation does not use it. Now that I am using it on 4.2.3, I am getting this random crash. I suspect that the feature uses an ICMP ping at some stage. In FreeBSD jails, by default ping is not allowed (security feature). If you really need to ping then you need to explicitly allow raw sockets. So perhaps Kamailio doesn't know how to handle the "operation not permitted" and crashes. I am going to test without NAT SIPping and see if it crashes. Although it's hard to test, since I have no trigger and it can be days between crashes. ** My question is: how do I force the ping behaviour in NAT SIPping feature? I need a trigger to further debug. Output from /var/log/messages after crash: Feb 19 05:39:56 sip /usr/local/sbin/kamailio[52610]: CRITICAL: <core> [pass_fd.c:293]: receive_fd(): EOF on 24 Feb 19 05:39:56 sip /usr/local/sbin/kamailio[52578]: ALERT: <core> [main.c:784]: handle_sigs(): child process 52606 exited by a signal 6 Feb 19 05:39:56 sip /usr/local/sbin/kamailio[52578]: ALERT: <core> [main.c:787]: handle_sigs(): core was generated

2 1

Re-invites from carrier breaks the call
by Will Ferrer 21 Feb '15

21 Feb '15

Hi All We have any issue with re invites coming from the carrier. When a reinvite occurs, our softphone client gets the invite, sends a 100, and then sends 200 ok. However the 200 ok does not have the softphones ip in the record route. Since it's not in the record route the ack from the carrier never makes it's way all the back to the softphone. This causes the softphone to keep sending 200 oks since it never gets the ack. Eventually the softphone gets tired of sending 200 oks and sends a bye. Is there any way that Kamailio can help me correct for this, or do we need to have our clients use different softphones? If it has to be handled via softphones is there even a softphone that can account for this? Thanks for all your assistance in advance. All the best. Will Ferrer Switchsoft

10 29

xhttp module and IPv6
by Sergey Okhapkin 20 Feb '15

20 Feb '15

It looks like when http request comes from ipv6 address, the module inserts Via header without [] around the address: Feb 20 14:26:17 east /usr/local/sbin/kamailio[30965]: ERROR: <core> [parser/parse_via.c:2193]: parse_via(): ERROR:parse_via: bad port Feb 20 14:26:17 east /usr/local/sbin/kamailio[30965]: ERROR: <core> [parser/parse_via.c:2708]: parse_via(): ERROR: parse_via on: <SIP/2.0/TCP 2601:3:8840:A:172E:9CAD:6BB2:3F69:45306 Host: sip1.callwithus.com:5060 Connection: Upgrade Pragma: no-cache Cache-Control: no-cache Upgrade: websocket Origin: http://www.callwithus.com Sec-WebSocket-Version: 13 User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.93 Safari/537.36 Accept-Encoding: gzip, deflate, sdch Accept-Language: en-US,en;q=0.8 Sec-WebSocket-Key: nyAUyArASVRXTI+Nvx82/Q== Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits Sec-WebSocket-Protocol: sip > Feb 20 14:26:17 east /usr/local/sbin/kamailio[30965]: ERROR: <core> [parser/parse_via.c:2712]: parse_via(): ERROR: parse_via parse error, parsed so far:<SIP/2.0/TCP 2601:3> Feb 20 14:26:17 east /usr/local/sbin/kamailio[30965]: ERROR: <core> [parser/msg_parser.c:125]: get_hdr_field(): ERROR: get_hdr_field: bad via Feb 20 14:26:17 east /usr/local/sbin/kamailio[30965]: INFO: <core> [parser/msg_parser.c:338]: parse_headers(): ERROR: bad header field [Via: SIP/2.0/TCP 260] Feb 20 14:26:17 east /usr/local/sbin/kamailio[30965]: ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<GET / HTTP/1.1 *Via: SIP/2.0/TCP 2601:3:8840:A:172E:9CAD:6BB2:3F69:45306* Host: sip1.callwithus.com:5060 Connection: Upgrade Pragma: no-cache Cache-Control: no-cache Upgrade: websocket Origin: http://www.callwithus.com Sec-WebSocket-Version: 13 User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.93 Safari/537.36 Accept-Encoding: gzip, deflate, sdch Accept-Language: en-US,en;q=0.8 Sec-WebSocket-Key: nyAUyArASVRXTI+Nvx82/Q== Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits Sec-WebSocket-Protocol: sip > Feb 20 14:26:17 east /usr/local/sbin/kamailio[30965]: ERROR: xhttp [xhttp_mod.c:264]: xhttp_process_request(): parse_msg failed

2 4

CNXCC Max Call control on Version 4.1.4
by Jonathan Hunter 20 Feb '15

20 Feb '15

Hi Guys, Using kamailio Version 4.1.4 on Centos 6.5 I have an issue when using cnxcc to control max call duration for all outbound calls. In my configuration I set the following; # -----Dialog params -----modparam("dialog", "dlg_flag", 4)modparam("cnxcc", "dlg_flag", 4)modparam("cnxcc", "credit_check_period", 1) Then I look to set some parameters for outbound calls; ###########Set Max Call Duration for MT Call ############# $var(customer) = "MTPublic";$var(max_time) = $var(MTMaxCallDuration);xlog("L_INFO","For setting Call Duration we have ProfileID=$var(profileIDMD) and we have var(max_time)=$var(max_time)\n");cnxcc_set_max_time("$var(customer)", "$var(max_time)");xlog("L_INFO","Max Call duration set to $var(max_time) seconds\n"); Feb 20 14:20:26 voip01 /usr/sbin/kamailio[1950]: INFO: <script>: Max Call duration set to 600 secondsFeb 20 14:20:35 voip01 /usr/sbin/kamailio[1960]: ALERT: cnxcc [cnxcc_check.c:157]: check_calls_by_time(): [74d7c02e-33ae-1233-edba-005056a48754] call has exhausted its time. Breaking the loopFeb 20 14:20:35 voip01 /usr/sbin/kamailio[1960]: INFO: <script>: [74d7c02e-33ae-1233-edba-005056a48754]: call killed as Max Call Duration ExpiredFeb 20 14:20:35 voip01 /usr/sbin/kamailio[1960]: ERROR: cnxcc [cnxcc_mod.c:1068]: terminate_call(): Error executing dlg_end_dlg command. Return code was [404] Now as you can see, as soon as the Called party answers, the cnxcc module drops the call stating that Max Call duration has expired, however it was set to 600 seconds. If I restart kamailio this clears the issue and it works fine allowing calls to run up to 600 seconds. Any help/comment on this would be great, is it just configuration related? Thanks Jon

2 6

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