sr-users July 2019

sr-users@lists.kamailio.org

68 participants
77 discussions

(no subject)
by jay binks 02 Aug '19

02 Aug '19

Hey all, looking for a little help. I've been tracking an issue, where a number of SIP Messages ( typically INVITE ) are sent, but Kamailio only see one of them ( the last one). I have verified that the messages are definitely received on the host, as verified with TCPDUMP, but the INVITES never hit the request route block. ( the very first thing is to log the message ) What i've managed to find is, that if I increase worker children, the problem goes away. So I've got a problem, I think I've found the solution, but what I'm struggling with is how to monitor better, so I can be alerted to this in the future. I started by looking at "kamctl stats | grep drop" "core:drop_replies = 14", "core:drop_requests = 10577" however drop_requests seems to include explicit drops in my config. which I do for many reasons, but mainly bad UA or blocked IP's, so this dosnt seem to be what im after. I then went digging in the code ( often the best way to find things ). in receive.c receive_msg() we find some conditions, where we drop the packet ( before calling request route ). right now im looking around line 251 at LM_DBG("dropping the received message\n"); goto error00; Following error00 I see it calls STATS_RX_DROPS which increments stats->received_drops. This is where it gets fun, I cant find where received_drops is ever returned in the stats output. I can see where -SIGUSR1 will trigger this to be dumped, if Kamailio is compiled with that option ( dosnt seem the debian packages are ). however, what im seeking clarification on is, does this get reported in "kamctl stats" Am I just going crazy or is something not quite right here? TLDNR; how do I monitor for Kamailio not having enough worker threads to process incoming messages. FYI I'm seeing about 50Mbps of incoming SIP on this box, and I do perform a decent amount of work on some message types. -- Sincerely Jay

5 7

Deleting extra location attribute(location_attrs table) when contact is expired
by Pintu Lohar 31 Jul '19

31 Jul '19

Hi All, Regarding modparam("tm|usrloc", "xavp_contact", "ulattrs") #ref : https://www.kamailio.org/docs/modules/devel/modules/usrloc.html#usrloc.p.xa… . There is some requirement where we need to save some extra location attributes to location_attrs <https://kamailio.org/docs/db-tables/kamailio-db-4.3.x.html#gen-db-location-…> tables $xavp(ulattrs=>deviceIdentify)= "Some str values" and calling save(“location”) , It works well and saved location attribute table but But when contact expired callback is received, udomain_contact_expired_db() does not it delete the extra location attribute from database but deleting the record from location table only ? If not, is there any recommended approach to delete the extra location attributes from the database? or am I missing something to set? Alternate I was thinking could be running timer from Kamailio config and check last_modified time and delete those(based on our UAC expiry setting), is it the right approach. Kamailio Version: 5.2.0. Thanks for your valuable suggestion in advance. Regards Pintu Lohar

2 10

29 Jul '19

Hello, I would like to know if it is possible to enable registration for users that have not been created with kamctl. For example, if I can register a user with a random name without a password, or obtain from another database other than kamailio; I would also like it to be allowed at the same time as there are users with password registered with kamctl. Thanks you, José Antonio Gutiérrez Delgado Responsable técnico Oficina: (+34) 923040031 <http://www.arsoft-company.com> *De conformidad a lo establecido en el REGLAMENTO (UE) 2016/679 DEL PARLAMENTO EUROPEO Y DEL CONSEJO de 27 de abril de 2016 relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos y por el que se deroga la Directiva 95/46/CE (Reglamento general de protección de datos), le informamos que todos los datos pasaran a formar parte de un fichero automatizado cuyo responsable es AUGMENTED REALITY SOFTWARE S.L siendo la única finalidad de dicho fichero la gestión de carácter comercial y el posible envío de comunicaciones comerciales sobre nuestros productos. Si lo desea puede ejercer sus derechos de acceso, rectificación, cancelación y oposición de sus datos en C/ Duero 12, Parque Científico, ARSOFT, 37185 o enviando un mensaje electrónico a info(a)arsoft-company.com <info(a)arsoft-company.com> indicando en el asunto el derecho que desea ejercitar.Este mensaje y sus archivos adjuntos van dirigidos exclusivamente a su destinatario, pudiendo contener información confidencial sometida a secreto profesional. No está permitida su reproducción o distribución sin nuestra autorización expresa. Si usted no es el destinatario final por favor elimínelo e infórmenos por esta vía.*

3 4

Dialog missing when BYE is received from trunk
by Andrew White 28 Jul '19

28 Jul '19

Hi all, I’ve got a call flow where PBX makes a call via Kamailio, which uses the UAC modules to make the call to the trunk. This works great, however I’ve noticed recently that when the BYE comes from the trunk, Kamailio doesn’t recognise the dialog and throws back a 404. Due to this, the PBX never knows the session has ended, and keeps its session open. Here’s the flow from Wireshark: https://i.imgur.com/BxPRrXP.png <https://i.imgur.com/BxPRrXP.png> As you can see, the BYE is received from the trunk, and Kamailio throws a 404. I checked with an rpc dlg.list and at this point the dialog had gone. 30 seconds later, I threw a BYE from the PBX, and because the dialog no longer existed, it got a 481 back. The INVITE to the trunk has the following Record-Route header: Record-Route: <sip:kamailio.public-ip;lr;ftag=mjKtcKaBteQ4Q;vst=AAAAAAYFBQUHAwYHBgRzMwIRGRMcAgJBWBEVCwAbBhtADxBjdGVkLmNvbS5hdQ--;did=624.b2e1> When the first BYE comes in, it still has same did in the Route header. Below I’ve put the output from the dialog list rpc call (before the first BYE) and the relevant log lines. { h_entry: 1062 h_id: 7723 ref: 2 call-id: a9d32620-2b68-1238-048a-0cc47a18705a from_uri: sip:61400123123@pbx.local:5060 to_uri: sip:61400123123@10.0.0.2 state: 4 start_ts: 1564269942 init_ts: 1564269929 end_ts: 0 timeout: 1564313142 lifetime: 43200 dflags: 643 sflags: 0 iflags: 16 caller: { tag: mjKtcKaBteQ4Q contact: sip:pbx.local cseq: 7581172 route_set: socket: udp:10.0.0.2:5060 } callee: { tag: SD5ptp899-1177933201-1564269931305 contact: sip:SDd3mt8-nn9jnirnmqcrvfmvkpm0hmhvgggjgv2io788of70s84u9@trunk.remote:5060;transport=udp cseq: 0 route_set: socket: udp:10.0.0.2:5060 } profiles: { } variables: { { cseq_diff: 1 } } } Jul 28 09:27:30 ip-10-0-0-2 /usr/local/sbin/kamailio[11061]: NOTICE: {2 450917085 BYE a9d32620-2b68-1238-048a-0cc47a18705a} acc [acc.c:279]: acc_log_request(): ACC: transaction answered: timestamp=1564270050;method=BYE;from_tag=SD5ptp899-1177933201-1564269931305;to_tag=mjKtcKaBteQ4Q;call_id=a9d32620-2b68-1238-048a-0cc47a18705a;code=404;reason=Not here;src_user=0400123123;src_domain=trunk.remote;src_ip=trunk.remote;dst_ouser=0400123123;dst_user=0400123123;dst_domain=kamailio.public-ip I’m assuming the 404 is because the Contact header I sent from Kamailio -> Trunk is rewritten, that Contact is Kamailio’s public contact IP. However the dialog has the caller contact within it referencing back to the local PBX, so I would think when Kamailio gets this dialog ID back with a BYE it would relay it back to the original contact, wouldn’t it? Thanks! Andrew

2 3

IMS_ISC technical specification
by Ali Shirvani 26 Jul '19

26 Jul '19

Hi all, I read some portion of imc_isc_mod.c, specially isc_from_as function. In that function there is some function call that searching for some marks in the SIP message. Also I read section 5.7.3 from TS 24.229 but I didn't find the marking mechanism that used in isc_from_as function. Would you please point me to the technical specification that implemented in IMS_ISC module? Regards, Ali

3 4

Concatenating strings in $hdr
by David Cunningham 26 Jul '19

26 Jul '19

Hello, I'm having an issue where this doesn't work: #!trydef PRODUCT "Foo" if( $hdr("X-" + PRODUCT + "-Transport") != "" ) { add_uri_param( $hdr("X-" + PRODUCT + "-Transport") ); } It seems Kamailio doesn't like the concatenation within the $hdr(). Concatenation does work in other places though: append_hf( "X-" + PRODUCT + "-Transport: tcp\r\n" ); Can anyone advise how to make the concatenation within $hdr() work? Thanking you in advance. -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782

2 2

IM Chat facility in Kamailio
by Gaurav Bmotra 25 Jul '19

25 Jul '19

hi i m using kamailio 5.1.2 , on Ubuntu 18. LTS existing setup is working fine with audio and video call ,,, ut now i wan to add chat feature in it ... so plz help me how can i implement chat IM in to it thanks -- *Regards:* Gaurav Kumar

2 1

Malformed Route Header
by Duarte Rocha 25 Jul '19

25 Jul '19

Greetings, When a in-dialog request has Route headers, Kamailio will remove the Route Header with it's address when routing the packet. This works perfectly for me in every situation. However, in one of the calls I found a weird behaviour in the removal. So, this is the scenario : Kamailio has two IP's 1.1.1.209 and 1.1.1.205. This is BYE request received in the on 1.1.1.209 The header Route looks like this when it arrives at 1.1.1.209 : Route : <sip:1.1.1.209;r2=on;lr;ftag=5AE0303037363132017D0E65;tbk_i=2_2_Y;tbk_o=128_11_Y;vsf=AAAAABgGBAMDAAUBBQECA3ByAwMcHwIdHQsWHwUMOA--;vst=AAAAABgHDQgBAwsIBQECdnIDAxwfAh0aBB4cAgU5;did=8f5.67c2>,<sip:1.1.1.205;r2=on;lr;ftag=5AE0303037363132017D0E65;tbk_i=2_2_Y;tbk_o=128_11_Y;vsf=AAAAABgGBAMDAAUBBQECA3ByAwMcHwIdHQsWHwUMOA--;vst=AAAAABgHDQgBAwsIBQECdnIDAxwfAh0aBB4cAgU5;did=8f5.67c2> It reaches 1.1.1.205 like this : Route : As you can see, the header is empty and it should contain the 1.1.1.205 URI. Is the header Router malformatted and creating this error ? Best Regards, Duarte Rocha

2 1

Re: [SR-Users] [EXT] Re: P-CSCF and I-CSCF ports -RESOLVED
by Woscek, Martin W. 24 Jul '19

24 Jul '19

Hi Ali, Looking through the source code, its not that the port for I-CSCF is hard coded to 5060, its just that it defaults to 5060 if the following is set in the Kamailio.cfg file: dns_try_naptr=no which we had left it disabled. Well I assumed I had all the DNS worked out, I had NAPTR records set for the P,I and S-CSCF. Looking though the pcscf.cfg there is a setting for NETWORKNAME which is set to ims522.ims.org, and is a separate FQDN from the P,I,S-cscf FQDN’s. I always kept the NAPTR rec for ims522 as the same port of the P-CSCF (pcscf522) in DNS. Two things I needed to fix: 1. Enable the DNS NAPTR lookups: dns_try_naptr=yes 2. Modify the NAPR for ims522 to be that of 4060 Thanks to you and Amar for the pointing to DNS. _Martin From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of Ali Shirvani Sent: Tuesday, July 23, 2019 1:40 PM To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org> Subject: [EXT] Re: [SR-Users] P-CSCF and I-CSCF ports Hi Martin, As Amar pointed out it may some DNS configuration. You can check the DNS entry of I-CSCF with: $ dig -t srv <FQDN of I-CSCF> Regards, Ali On Tue, Jul 23, 2019 at 7:15 PM Amar Tinawi <amar.tinawi(a)gmail.com<mailto:amar.tinawi@gmail.com>> wrote: Hello Martin I think you are missing the DNS part. On Tue, Jul 23, 2019, 5:30 PM Woscek, Martin W. <mwoscek(a)mitre.org<mailto:mwoscek@mitre.org>> wrote: Hi IMS users, I can configure the P-CSCF to use 5060, and the I-CSCF to use 4060 and both come up listening to their respective ports when each module is started. But the P-CSCF is hardcoded to use 5060 for the I-CSCF. Before I make code changes to the executable: Is there some additional configuration to allow for me to switch ports? Why is Kamailio IMS hardcoded and why not enforce it at the .cfg load time? Thanks, Martin _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

1 0

kamailio 4.4.4 fills IPv6 contact address when sending packet over IPv4
by Pali Rohár 24 Jul '19

24 Jul '19

Hi! I detected strange problem that sip.linphone.org refuse to accept presence information re-transmitted by kamailio 4.4.4 server. I debug this problem with tcpdump and I found out that problem is in kamailio which fills IPv6 address into UDP datagram and that datagram is sent via IPv4 socket to IPv4 address, to sip.linphone.org server. And sip.linphone.org server does not have IPv6 connectivity, so correctly return over IPv4 to sender just "400 Bad Contact Header" error. On my server is running kamailio 4.4.4 from Debian Stretch and I can 100% reproduce this problem against public sip.linphone.org server. My server has both IPv4 and IPv6 connectivity and kamailio is listening for both IPv4 and IPv6 connections. So why is kamailio sending IPv6 address over IPv4 and therefore makes it impossible to communicate with non-IPv6 enabled servers? Looks like a problem with choosing default/correct socket for Contact header. And how to fix this problem? Can you help me? I would like to have working interconnection with linphone servers. Just to note I'm seeing this problem only for presence information packets. Other requests, like INVITE or MESSAGE seems to work. Below is relevant tcpdump output. Some parts were replaced by {VAR}. PS: I'm not subscribed to list, so please CC my address when sending reply. Thank you! 17:22:58.121719 IP (tos 0x10, ttl 64, id 21629, offset 0, flags [none], proto UDP (17), length 1266) {MY_IPV4_ADDRESS}.5060 > 91.121.209.194.5060: [bad udp cksum 0xa099 -> 0x9825!] SIP, length: 1238 NOTIFY sip:{REMOTE_NAME}@{REMOTE_USER_IPV4_ADDRESS}:5060;registering_acc=sip_linphone_org SIP/2.0 Via: SIP/2.0/UDP {MY_IPV4_ADDRESS};branch=z9hG4bK2b55.88f93c20000000000000000000000000.0 To: <sip:{REMOTE_NAME}@sip.linphone.org>;tag=75559182 From: <sip:{MY_SIP_URI}>;tag=97d8e785fdf42bf9622a64c13c504961-2708 CSeq: 2 NOTIFY Call-ID: 26cf9d5c019af2dc3302b770887bcc2e@0:0:0:0:0:0:0:0 Route: <sip:91.121.209.194:5060;lr> Content-Length: 597 User-Agent: kamailio (4.4.4 (x86_64/linux)) Max-Forwards: 70 Event: presence Contact: <sip:{MY_IPV6_ADDRESS}:5060;transport=udp> Subscription-State: active;expires=3600 Content-Type: application/pidf+xml <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" entity="Pali <sip:{MY_SIP_URI}>"> <tuple id="sg89ae"> <status><basic>open</basic></status> <contact priority="0.8">Pali <sip:{MY_SIP_URI}></contact> </tuple> <tuple xmlns="urn:ietf:params:xml:ns:pidf" id="TA0C538B2"> <status> <basic>closed</basic> </status> <contact priority="1">sip:{MY_SIP_URI}</contact> <timestamp>2019-04-19T17:20:36+02:00</timestamp> </tuple> </presence> 17:22:58.151188 IP (tos 0x0, ttl 52, id 22949, offset 0, flags [none], proto UDP (17), length 373) 91.121.209.194.5060 > {MY_IPV4_ADDRESS}.5060: [udp sum ok] SIP, length: 345 SIP/2.0 400 Bad Contact Header Via: SIP/2.0/UDP {MY_IPV4_ADDRESS};branch=z9hG4bK2b55.88f93c20000000000000000000000000.0;rport=5060 From: <sip:{MY_SIP_URI}>;tag=97d8e785fdf42bf9622a64c13c504961-2708 To: <sip:{REMOTE_NAME}@sip.linphone.org>;tag=75559182 Call-ID: 26cf9d5c019af2dc3302b770887bcc2e@0:0:0:0:0:0:0:0 CSeq: 2 NOTIFY Content-Length: 0 -- Pali Rohár pali.rohar(a)gmail.com

4 10

2026

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