November 2017 - sr-users

parse_from_header(): bad From header
by Donat Zenichev 29 Nov '17

29 Nov '17

Hi community. We experience the problem with malformed messages. First of all, I want to say, that most of time kamailio works well and nothing happens that can drop sessions. But from time-to-time something changes (may be in the network) and kamailio receives requests with malformed headers (To or From hfs). The schema: uplinks -> kamailio <-> routing server (asterisk) Malformed messages were received only from asterisk server. Sip debug on asterisk showed that messages were transmitted correctly and headers were nice. But kamailio obtains changed (broken) packets or perhaps can't read them properly. How does it look like: Nov 10 12:37:06 kamailio-name kamailio[965]: INFO: <script>: Going to NATMANAGE for BYE from sip:useragent7122@kamailio_address:5068 (IP=wss:client_address:62881) - R=sip:dialed_did_service@asterisk_address:50600 ID=1b0044070de406153bf0e4b84d6bb793@asterisk_address:50600 Nov 10 12:37:06 kamailio-name kamailio[965]: NOTICE: <script>: Relaying request to <null> - R=sip:dialed_did_service@asterisk_address:50600 ID=1b0044070de406153bf0e4b84d6bb793@asterisk_address:50600 Nov 10 12:37:06 kamailio-name kamailio[965]: ERROR: <core> [parser/parse_addr_spec.c:719]: parse_addr_spec(): unexpected char [<] in status 6: [<sip:useragent6] . Nov 10 12:37:06 kamailio-name kamailio[965]: ERROR: <core> [parser/parse_from.c:75]: parse_from_header(): bad From header [<sip:useragent6<+.w>;tag=jja7l45gd1] Nov 10 12:37:06 kamailio-name kamailio[965]: ERROR: dialog [dlg_cseq.c:89]: dlg_cseq_prepare_msg(): cannot parse FROM header Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core> [parser/parse_addr_spec.c:719]: parse_addr_spec(): unexpected char [<] in status 6: [<sip:useragent6] . Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core> [parser/parse_from.c:75]: parse_from_header(): bad From header [<sip:useragent6<+.w>;tag=jja7l45gd1] Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: dialog [dlg_cseq.c:89]: dlg_cseq_prepare_msg(): cannot parse FROM header Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core> [parser/parse_addr_spec.c:719]: parse_addr_spec(): unexpected char [<] in status 6: [<sip:useragent6] . Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core> [parser/parse_from.c:75]: parse_from_header(): bad From header [<sip:useragent6<+.w>;tag=jja7l45gd1] Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: uac [replace.c:783]: restore_uris_reply(): failed to find/parse FROM hdr Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core> [parser/parse_addr_spec.c:719]: parse_addr_spec(): unexpected char [<] in status 6: [<sip:useragent6] . Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core> [parser/parse_from.c:75]: parse_from_header(): bad From header [<sip:useragent6<+.w>;tag=jja7l45gd1] Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: pv [pv_core.c:465]: pv_get_from_attr(): cannot parse From header Nov 10 12:37:06 kamailio-name kamailio[937]: INFO: <script>: Skip manage DEVICE_STATE for BYE from <null> (IP=udp:asterisk_address:50600) with (200 - OK) - R=<null> ID=1b0044070de406153bf0e4b84d6bb793@asterisk_address:50600 Nov 10 12:37:06 kamailio-name kamailio[937]: INFO: <script>: ------------------------------------MANAGE BYE by DEVICE_STATE_BYE_MANAGE route - 200 - OK M=BYE IP=udp:asterisk_address:50600 ID=1b0044070de406153bf0e4b84d6bb793@asterisk_address:50600 Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core> [parser/parse_addr_spec.c:719]: parse_addr_spec(): unexpected char [<] in status 6: [<sip:useragent6] . Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core> [parser/parse_from.c:75]: parse_from_header(): bad From header [<sip:useragent6<+.w>;tag=jja7l45gd1] Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: pv [pv_core.c:465]: pv_get_from_attr(): cannot parse From header Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core> [parser/parse_addr_spec.c:719]: parse_addr_spec(): unexpected char [<] in status 6: [<sip:useragent6] . Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core> [parser/parse_from.c:75]: parse_from_header(): bad From header [<sip:useragent6<+.w>;tag=jja7l45gd1] Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: rtpengine [rtpengine_funcs.c:331]: get_from_tag(): failed to parse From header Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: rtpengine [rtpengine.c:2252]: rtpp_function_call(): can't get From tag Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core> [parser/parse_addr_spec.c:719]: parse_addr_spec(): unexpected char [<] in status 6: [<sip:useragent6] . Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core> [parser/parse_from.c:75]: parse_from_header(): bad From header [<sip:useragent6<+.w>;tag=jja7l45gd1] Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: pv [pv_core.c:465]: pv_get_from_attr(): cannot parse From header Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core> [parser/parse_addr_spec.c:719]: parse_addr_spec(): unexpected char [<] in status 6: [<sip:useragent6] . Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core> [parser/parse_from.c:75]: parse_from_header(): bad From header [<sip:useragent6<+.w>;tag=jja7l45gd1] Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: pv [pv_core.c:465]: pv_get_from_attr(): cannot parse From header How the packet looks like: ACK sip:tt7etmau@bb0pd5t63b26.invalid;alias=client_address~57573~6;transport=ws SIP/2.0 Via: SIP/2.0/UDP asterisk_address:50600;branch=z9hG4bK117106ca;rport Route: <sip:kam2.domain.com:5068 ;nat=yes;transport=udp;r2=on;ftag=as06869a5d;lr=on;vsf=AAAAAEZZSVVDVV1VRBlUUkUpFQxdVUZYXiRCHU1RQl1HRVNaXhhAQ3RuLnR3aWxpby5jb20-;vst=AAAAAAAAAAAAAAAAAAAAAAAfBwQRQE8NBR9BChIFAwddCgADFEVDQlYudHdpbGlvLmNvbQ--;did=b0c.7331>,<sip:kam2.callision.com:5068 ;nat=yes;transport=ws;r2=on;ftag=as06869a5d;lr=on;vsf=AAAAAEZZSVVDVV1VRBlUUkUpFQxdVUZYXiRCHU1RQl1HRVNaXhhAQ3RuLnR3aWxpby5jb20-;vst=AAAAAAAAAAAAAAAAAAAAAAAfBwQRQE8NBR9BChIFAwddCgADFEVDQlYudHdpbGlvLmNvbQ--;did=b0c.7331> Max-Forwards: 70 From: "19172423539" <sip:19172423539@asterisk_address:50600>;tag=as06869a5d To: <sip:useragent7122@10.0.1.18:5068>;tag=nmv7kmpau3 Contact: <sip:19172423539@asterisk_address:50600> Call-ID: 629d5a132c194c536b5f5c1a2a3c6e32@asterisk_address:50600 CSeq: 102 ACK User-Agent: asterisk PBX Content-Length: 0 The transport is used to send messages between asterisk and kamailio is TCP. TCP configurations: tcp_connection_lifetime=3604 tcp_accept_no_cl=yes tcp_connect_timeout=5 tcp_send_timeout=5 tcp_rd_buf_size=16384 tcp_keepalive=yes tcp_crlf_ping=yes tcp_keepcnt=3 tcp_keepidle=30 tcp_keepintvl=15 tcp_max_connections=4096 I found the idea, that we need to change following parameters: modparam("uac","restore_mode","auto") modparam("uac","restore_dlg",1) to: modparam("uac","restore_mode","none") modparam("uac","restore_dlg",0) I did that, now it looks like all is fine, but I think it can get back. Thanks in advance. -- -- BR, Donat Zenichev Wnet VoIP team Tel Ukraine: +380(44) 5-900-800 Tel USA: +164(67) 8-174-17 https://w-net.us/ <http://wnet.ua>

3 5

Source socket/port for in-dialog requests
by Donat Zenichev 29 Nov '17

29 Nov '17

Hi community. My apologies for so frequent appealing to you. I'm trying to solve problem with ending of sessions. The problem consists of no 200 OK coming from uplink on our BYE requests. Topology. First leg: Webrtc client <-wss-> kamailio <-sip tcp-> asterisk routing server Second leg: Uplink <-sip tcp-> kamailio <-sip tcp-> asterisk routing server The problem appears only in case when dialog was ended by webrtc client. The first leg (dialog) of the call ends nice, without any hints on problem. But the second leg (with uplink) has problem with no 200 OK (coming from uplink) on BYE request coming from asterisk. Handshake between asterisk server and uplink establishes properly. It looks like: uplink.domain.com:5060 -> INVITE tcp -> our.kamailio.server:5060 -> INVITE tcp -> our.asterisk.server:5060 . uplink.domain.com:5060 <- 100 trying tcp <- our.kamailio.server:5060 . uplink.domain.com:5060 <- 180 ringing tcp <- our.kamailio.server:5060 <- 180 ringing tcp <- our.asterisk.server:5060 . uplink.domain.com:5060 <- 200 OK tcp <- our.kamailio.server:5060 <- 200 OK tcp <- our.asterisk.server:5060 . uplink.domain.com:5060 -> ACK tcp -> our.kamailio.server:5060 -> ACK tcp -> our.asterisk.server:5060 . uplink.domain.com <-media stream-> rtpengine <-media stream-> our.asterisk.server . Here kamailio starts to use random source port for relaying in-dialog BYE uplink.domain.com:5060 <- BYE tcp <- our.kamailio.server:45355 <- BYE tcp <- our.asterisk.server:5060 . And here the leg with uplink is expected to end with 200 OK (coming from uplink proxy). But uplink doesn't answer at all. We requested a tcpdump from uplink to see how packets are forwared from their side. And I saw that that 200 OK tries to be sent within first tcp session - to 5060 port of kamailio server. But sngrep on our side shows nothing, nothing appears in kamailio log, so 200 OK can't reach the 5060 socket because of some transport problem I think. Top via hf of our BYE request, contains kamailio record = uplink.domain.com:5060 My main thought on this count is to suppress using of random source ports for in-dialog requests, this behaviour looks irrelevant. We have turned on mhomed parameter (mhomed=1). And cookbook says: "Set the server to try to locate outbound interface on multihomed host. This parameter affects the selection of the outgoing socket for forwarding requests." But, there is a big but - we can not turn of this parameter for this moment, because routing script made with using of this one. Kamilio works on AWS EC2 platform. It has following IP address schema: private address atouched to container -> public address assinged to this private address (so this is standard ip address schema for AWS containers). For this example private address will be: 10.0.0.1 and public address will be: 100.0.0.1 Configuration - main parameters (all values are changed for an example): advertised_address=our.kamailio.server advertised_port=5060 alias=our.kamailio.server alias=our.kamailio.server:5060 alias=100.0.0.1 alias=100.0.0.1:5060 alias=10.0.0.1 alias=10.0.0.1:5060 auto_aliases=no port=5060 listen=100.0.0.1 listen=10.0.0.1 listen=tcp:100.0.0.1:5060 listen=tcp:10.0.0.1:5060 mhomed=1 fork=yes fork_delay=5000 children=6 tcp_connection_lifetime=3604 tcp_accept_no_cl=yes tcp_connect_timeout=5 tcp_send_timeout=5 tcp_rd_buf_size=16384 tcp_keepalive=yes tcp_crlf_ping=yes tcp_keepcnt=3 tcp_keepidle=30 tcp_keepintvl=15 tcp_max_connections=4096 One of the solutions to this problem was to add following inside the relaying route block: $fs = "tcp:" + "10.0.0.1" + ":5060"; if (!t_relay()) { sl_reply_error(); } But it seems to me it's not a smart solution. -- -- BR, Donat Zenichev Wnet VoIP team Tel Ukraine: +380(44) 5-900-800 Tel USA: +164(67) 8-174-17 https://w-net.us/ <http://wnet.ua> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> Virus-free. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

1 1

Best way to do routing against a list of gateways
by voipspace voipspace 29 Nov '17

29 Nov '17

3 6

allow_trusted not passing
by voipspace voipspace 29 Nov '17

29 Nov '17

4 5

URL problems connecting to external (Azure) MySQL database
by Floimair Florian 29 Nov '17

29 Nov '17

Hi! I'm having troubles connecting Kamailio to an external MySQL database (on Microsoft Azure Cloud). Initially creating the database with kamctl worked fine, but accessing it at runtime via db_url fails. A somewhat unusual thing about the connection to a MySQL database on Azure is that the username contains an '@' character. This leads me to believe that this case is somewhat unhandled when parsing the database URI. Trying to connect to something like modparam("sipcapture", "db_url", "mysql://user@clouddb:password@clouddb.mysql.database.azure.com/db") Results in errors starting Kamailio ERROR: db_mysql [km_my_con.c:124]: db_mysql_new_connection(): driver error: Unknown MySQL server host 'clouddb' (-2) ERROR: <core> [db.c:318]: db_do_init2(): could not add connection to the pool ERROR: sipcapture [sipcapture.c:1146]: child_init(): unable to connect to database [mysql://user@clouddb:password@clouddb.mysql.database.azure.com/db] from capture_mode param. Is there a trick on how to achieve a connection in this case like some sort of escape character probably? Mit freundlichen Grüßen Florian Floimair (IMS) 1568

2 4

lcr_id vs lcr_count
by Patrick Wakano 29 Nov '17

29 Nov '17

Hello Kamailio list! I've been working with the LCR module and I wanted to use the lcr_id to match some ID's I have somewhere else. However, due to the lcr_count my lcr_ids must be less than the lcr_count. I understand the reason behind the lcr_count, what I think is a mistake is to have the lcr_id dependent of the lcr_count. Ideally we should be able to use any lcr_id value, just observing that the total amount of lcr groups should not exceed the lcr_count. The problem is this if that appears in the load_gws, to_gw and from_gw functions in lcr_mod.c: if ((lcr_id < 1) || (lcr_id > lcr_count_param)) { LM_ERR("invalid lcr_id parameter value %d\n", lcr_id); return -1; } I ended up using another table to make the conversion of ids, but this is horrible.... Any other reason to force the lcr_id to be less than the lcr_count? Best Regards, Patrick Wakano

3 3

how to add new media server in dispatcher table through "ANSIBLE"
by Narayan P 29 Nov '17

29 Nov '17

Hello Experts, I am new to ansible and deploying kamailio through ansible.Sucessfully deployed kamailio but my requirement is to add media server through ansible.As I am using dispatcher module in kamailio,not able to find any script that directly insert one media server IP and port into dispatcher table from ansible.(I am using ansible in one system and deploying kamailio in other). Any suggestion will be highly appreciated as always. Thanks, Narayan +91-9035438928

3 4

Re: [SR-Users] Using SIP tools through Kamailio and Asterisk - chrome issue.
by otron2016＠gmail.com 29 Nov '17

29 Nov '17

Through Firefox likely means via websockets (wss) rather than via the sip port. Many things could interfere with the latter. Take heart, though: websockets is harder to set up so you're likely through the worst. Look at logs and see what iftop shows you about traffic on the server as you try to make sip connections. Also try your sip client with a known-good sip server (e.g. Iptel) just to make sure the problem isn't with the client. -------- Original message -------- From: "Wilkins, Steve" <swwilkins(a)mitre.org> Date: 11/28/2017 6:39 AM (GMT-08:00) To: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org> Subject: [SR-Users] Using SIP tools through Kamailio and Asterisk - chrome issue. Has anyone seen the issue where, when using a sip tool and going from Kamailio to Asterisk, that audio and video won’t work, yet it works fine through Firefox? I am almost sure this not an issue with Kamailio, but I am pretty new to SIP and don’t know 100% for sure. Thank you

1 0

Using SIP tools through Kamailio and Asterisk - chrome issue.
by Wilkins, Steve 28 Nov '17

28 Nov '17

Has anyone seen the issue where, when using a sip tool and going from Kamailio to Asterisk, that audio and video won't work, yet it works fine through Firefox? I am almost sure this not an issue with Kamailio, but I am pretty new to SIP and don't know 100% for sure. Thank you

1 0

dmq replicate
by Aidar Kamalov 28 Nov '17

28 Nov '17

Hello, I set up kamailio cluster. dmq_usrloc works fine, but PUSBLISH and SUBSCRIBE replication not. If I make a call to first node I've got many(hundreds) PUBLISH messages from first node to first node and some messages (8 for example) to other nodes. And second xnotice in config not executes. And errors n log ERROR: <core> [core/sr_module.c:1726]: get_int_fparam(): Unsupported param type for int value: 32 How to replicate publish and subscribe, is it wrong way? my confiig: request_route { if(is_method("KDMQ")) { if ($Rp == 5050) { dmq_handle_message(); exit; } else { drop; } } ..... ..... if(is_method("PUBLISH|SUBSCRIBE")) { if(!dmq_is_from_node()) { xnotice("AAAAAAAA"); dmq_t_replicate("1"); xnotice("AAAAAAAABBBBBBBBBBB"); } } 2017/11/28 12:56:06.415601 192.168.8.213:5060 -> 192.168.8.213:5060 PUBLISH sip:34200@siptest. SIP/2.0 Via: SIP/2.0/UDP 192.168.8.213;branch=z9hG4bKc7a5.cee84051000000000000000000000000.0 To: <sip:34200@siptest> From: <sip:34200@siptest.>;tag=ae81df16b5a52fc1f62f9b45f337e660-db10 CSeq: 10 PUBLISH Call-ID: 4c8f9e6e799efcd7-57244(a)192.168.8.213 Content-Length: 556 User-Agent: kamailio (5.0.4 (x86_64/linux)) Max-Forwards: 70 Event: dialog Expires: 125 Content-Type: application/dialog-info+xml <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:34200@siptest."> <dialog id="898932197-5060-86(a)BJC.BGI.D.DB" call-id="898932197-5060-86(a)BJC.BGI.D.DB" direction="initiator"> <state>Trying</state> <remote> <identity>sip:53003@siptest.t</identity> <target uri="sip:53003@siptest.tg"/> </remote> <local> <identity>sip:34200@siptest</identity> <target uri="sip:34200@siptest"/> </local> </dialog> </dialog-info> -- Aydar A. Kamalov

1 1