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
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
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
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
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
> 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.
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
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.
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.
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
