sr-users April 2020

sr-users@lists.kamailio.org

70 participants
99 discussions

nat_uac_test(8)
by Sergiu Pojoga 24 Apr '20

24 Apr '20

When receiving an INVITE over a specific LTE carrier, I'm seeing 'c=IN IP4 192.0.0.4' in SDP, which isn't technically a RFC1918 or RFC6598 IP address and thus nat_uac_test(8) fails. What elegant workaround can be done to catch such specific cases? Thanks.

5 11

Kamailio like SBC with Teams
by sip user 24 Apr '20

24 Apr '20

Hello good morning ... I am new to this list and I was starting to mess with Kamailio, mainly to set it up as SBC against Teams, in this case. But I can't get it to work for me. If I launch a call from the Teams, in the Kamailio I see: 1.- In syslog: Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: <core> [ip_addr.c:243]: print_ip(): tcpconn_new: new tcp connection: 52.114.7.24 Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: <core> [tcp_main.c:1073]: tcpconn_new(): tcpconn_new: on port 4160, type 3 Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: <core> [tcp_main.c:1382]: tcpconn_add(): tcpconn_add: hashes: 171:1857:1187, 30 Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: <core> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0xa1f240, 23, 2, 0x7f90f2438f80), fd_no=17 Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: <core> [io_wait.h:610]: io_watch_del(): DBG: io_watch_del (0xa1f240, 23, -1, 0x0) fd_no=18 called Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: <core> [tcp_main.c:4219]: handle_tcpconn_ev(): tcp: DBG: sending to child, events 1 Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: <core> [tcp_main.c:3902]: send2child(): selected tcp worker 1 10(23159) for activity on [tls:SBC_IP:5061], 0x7f90f2438f80 Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: <core> [tcp_read.c:1507]: handle_io(): received n=8 con=0x7f90f2438f80, fd=9 Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: tls [tls_server.c:184]: tls_complete_init(): Using TLS domain TLSs<default> Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: tls [tls_domain.c:700]: sr_ssl_ctx_info_callback(): SSL handshake started Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: <core> [tcp_main.c:2516]: tcpconn_do_send(): tcp_send: sending... Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: <core> [tcp_main.c:2550]: tcpconn_do_send(): tcp_send: after real write: c= 0x7f90f2438f80 n=1468 fd=9 Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: <core> [tcp_main.c:2551]: tcpconn_do_send(): tcp_send: buf= Apr 15 11:11:41 vps793907 kamailio[23122]: #026#003#003 Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: <core> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x9c1700, 9, 2, 0x7f90f2438f80), fd_no=1 Apr 15 11:11:42 vps793907 kamailio[23122]: 10(23159) DEBUG: <core> [tcp_read.c:296]: tcp_read_data(): EOF on 0x7f90f2438f80, FD 9 Apr 15 11:11:42 vps793907 kamailio[23122]: 10(23159) DEBUG: <core> [tcp_read.c:1291]: tcp_read_req(): tcp_read_req: EOF Apr 15 11:11:42 vps793907 kamailio[23122]: 10(23159) DEBUG: <core> [io_wait.h:610]: io_watch_del(): DBG: io_watch_del (0x9c1700, 9, -1, 0x10) fd_no=2 called Apr 15 11:11:42 vps793907 kamailio[23122]: 10(23159) DEBUG: <core> [tcp_read.c:1434]: release_tcpconn(): releasing con 0x7f90f2438f80, state -1, fd=9, id=30 Apr 15 11:11:42 vps793907 kamailio[23122]: 10(23159) DEBUG: <core> [tcp_read.c:1435]: release_tcpconn(): extra_data 0x7f90f2432b40 Apr 15 11:11:42 vps793907 kamailio[23122]: 13(23167) DEBUG: <core> [tcp_main.c:3331]: handle_tcp_child(): handle_tcp_child: reader response= 7f90f2438f80, -1 from 1 Apr 15 11:11:42 vps793907 kamailio[23122]: 13(23167) DEBUG: tls [tls_server.c:604]: tls_h_close(): Closing SSL connection 0x7f90f2432b40 2.- With TCPDUMP: 11:13:09.311797 IP SBC_IP .1024 > SBC_IP .eu.sip-tls: Flags [S], seq 261244614, win 64240, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0 11:13:09.311898 IP SBC_IP .eu.sip-tls > 52.114.76.76.1024: Flags [S.], seq 812357247, ack 261244615, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 11:13:09.340358 IP 52.114.76.76.1024 > SBC_IP .eu.sip-tls: Flags [.], ack 1, win 2053, length 0 11:13:09.340560 IP 52.114.76.76.1024 > SBC_IP .eu.sip-tls: Flags [P.], seq 1:187, ack 1, win 2053, length 186 11:13:09.340578 IP SBC_IP .eu.sip-tls > 52.114.76.76.1024: Flags [.], ack 187, win 237, length 0 11:13:09.341361 IP SBC_IP .eu.sip-tls > 52.114.76.76.1024: Flags [P.], seq 1:1469, ack 187, win 237, length 1468 11:13:09.369606 IP 52.114.76.76.1024 > SBC_IP .eu.sip-tls: Flags [.], ack 1469, win 2053, length 0 11:13:12.451498 IP 52.114.7.24.1216 > SBC_IP .eu.sip-tls: Flags [S], seq 309084204, win 64240, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0 11:13:12.451587 IP SBC_IP .eu.sip-tls > 52.114.7.24.1216: Flags [S.], seq 3275066862, ack 309084205, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 11:13:12.707119 IP 52.114.7.24.1216 > SBC_IP .eu.sip-tls: Flags [.], ack 1, win 2053, length 0 11:13:12.707311 IP 52.114.7.24.1216 > SBC_IP .eu.sip-tls: Flags [P.], seq 1:187, ack 1, win 2053, length 186 11:13:12.707345 IP SBC_IP .eu.sip-tls > 52.114.7.24.1216: Flags [.], ack 187, win 237, length 0 11:13:12.708273 IP SBC_IP .eu.sip-tls > 52.114.7.24.1216: Flags [P.], seq 1:1469, ack 187, win 237, length 1468 11:13:12.965101 IP 52.114.7.24.1216 > SBC_IP .eu.sip-tls: Flags [.], ack 1469, win 2053, length 0 11:13:12.965156 IP 52.114.7.24.1216 > SBC_IP .eu.sip-tls: Flags [F.], seq 187, ack 1469, win 2053, length 0 11:13:12.965688 IP SBC_IP .eu.sip-tls > 52.114.7.24.1216: Flags [F.], seq 1469, ack 188, win 237, length 0 11:13:13.220871 IP 52.114.7.24.1216 > SBC_IP .eu.sip-tls: Flags [.], ack 1470, win 2053, length 0 I can't "receive" anything. I have generated the certificates and configured in the tls.cfg of the Kamailio: [server:default] method = TLSv1.2 verify_certificate = no require_certificate = no private_key = /etc/letsencrypt/ssl/cert.key certificate = /etc/letsencrypt/ssl/cert.crt ca_list = /etc/letsencrypt/ssl/ca.crt Within Kamailio itself I have it configured to return a 200 KeepAlive to Teams when it receives an OPTIONS: event_route[tm:local-request] { if(is_method("OPTIONS") && $ru =~ "pstnhub.microsoft.com") { append_hf("Contact: <sip: SBC_DNS :5061;transport=tls>\r\n"); } xlog("L_INFO", "Sent out tm request: $mb\n"); } And I have measured the record_route for this new one: record_route_preset(" SBC_DNS :5061;transport=tls", " SBC_IP :5061"); I have created a dispatcher.list: # setid(integer) destination(sip uri) flags (integer, optional), priority(int,opt), attrs (str,optional) 1:1:sip:sip.pstnhub.microsoft.com;transport=tls 0 3 socket=tls: SBC_IP :5061;ping_from= sip:SBC_DNS 2:1:sip:sip2.pstnhub.microsoft.com;transport=tls 0 2 socket=tls: SBC_IP :5061;ping_from=sip: SBC_DNS 3:1:sip:sip3.pstnhub.microsoft.com;transport=tls 0 1 socket=tls: SBC_IP :5061;ping_from=sip: SBC_DNS 4:1:sip:sip-all.pstnhub.microsoft.com;transport=tls 0 1 socket=tls: SBC_IP :5061;ping_from=sip: SBC_DNS I think that one of the problems is that I do not send the OPTIONS to the Teams well, since it is on their panel, it indicates that the SBC is INACTIVE. I don't know if you could help me straighten this out a bit ... Thank you so much for everything.. a greeting

5 15

Check if Kamailio is going to CANCEL branch
by Ivan Ribakov 24 Apr '20

24 Apr '20

Hi all, Upon receiving a provisional response from callee in a branch route, is there a way of telling if Kamailio is going to automatically CANCEL that branch because a final reply was received from another branch before that? The closest I got is finding “cancel_b_method” parameter of the TM module, but that is not what I’m after. Previously I was recommended to debug via logging onreply_route but I’m not really sure what information may contain hints of intention to send CANCEL. Does anyone have any suggestions/guesses in which direction I should be digging? Thanks, Ivan

1 0

[info] matrix chat room for kamailio
by Daniel-Constantin Mierla 23 Apr '20

23 Apr '20

Thanks to the efforts made by Fred Posner, a matrix.org server has been installed on Kamailio project infrastructure (matrix.kamailio.dev - server sponsored by lod.com), which enables us to create chat rooms as we need for our community of users and developers. It tries to be an alternative to the existing IRC #kamailio channel, given that a while ago freenode.net had to enforce user registration to join the channels on their service (not complaining about it, they did it for good reasons to protect against spammers and D/DoS attacks). The #kamailio channel on freenode.net will still be in use by the people that like it, there is no plan to consider it obsolete. One of the main benefits of running own matrix server is the ability to allow guest access during the devel online meetings, so people that do not want to create an account can still participate by using a web browser. Also, it offers modern encryption and privacy, along with richer collaboration features (e.g., file sharing), many considering it a viable open source alternative to Slack or other private team collaboration services. The first room created is #kamailio:matrix.kamailio.dev : * https://riot.kamailio.dev/#/room/#kamailio:matrix.kamailio.dev The matrix server is federated, so you can join if you have an account on any other public federated matrix server or one that you can host yourself. The server on matrix.kamailio.dev is not allowing public registrations. If you are a registered developer (have git commit access) and need a matrix account, let us know and we will find solutions. It is the first phase now and based on the interest from the community, its usage can be increased (e.g., creating rooms for development notifications (commits, pull requests, issue); bridge to irc channel; etc...) or the server can be shut down if proves not useful. We will try to do the next online devel meeting (scheduled for Wednesday, April 29, 2020, at 14:00UTC) on the matrix chat room mentioned above. More details at: * https://www.kamailio.org/w/2020/04/matrix-chat-room-for-kamailio/ Stay safe and healthy! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

1 0

Kamailio, TSILO and "local" calls
by German Cancio 23 Apr '20

23 Apr '20

Dear All, does somebody know up to which point TSILO can handle calls from one UA to another UA, when both are registered on the same Kamailio instance? Is a routing through a backend (such as Asterisk) required in that case? thanks and best regards, Germán

2 2

Integrating Push Notifications with iOS
by German Cancio 22 Apr '20

22 Apr '20

Dear All, we are working on the integration of VoIP Push Notifications with iOS devices via Kamailio. From what we observe, the time window between receiving a VoIP APNS notification that wakes up the client app and the client app being sent back to the background by iOS is extremely narrow. It is around 1-2 seconds, with a (seemingly random) variance of say ~0.5s. So 1-2s is the time window available for getting the client app to properly REGISTER and to receive the INVITE back from Kamailio (using e.g. TSILO); otherwise the call is lost. (On Android, the equivalent time window extends to 10s or more.) Have others observed the same on iOS? We are using a client app that still uses the iOS 12 SDK (with Xcode10). Can we expect changes in that regard with iOS13/Xcode13? many thanks and cheers, Germán

3 5

doubt about xflags
by David Escartin 22 Apr '20

22 Apr '20

Dear all one quick question, reading the module corex doc, seems that xflag are message(transaction) flags. But I made a test and seems for some reason the flag is not seeing activated at the onreply_route, when it's activated on the request route. Seemed more like a script flag behaviour. Maybe I'm missing something? thanks a lot and regards david

2 8

Parallel forking - first responder wins
by Ivan Ribakov 21 Apr '20

21 Apr '20

Hi all, What I’m trying to achieve is to have Kamailio fork an INVITE to multiple endpoints in parallel but only maintain the branch that responds first (first to respond with 200 OK I guess). I’ve read the TM module documentation on forking (https://www.kamailio.org/docs/modules/stable/modules/tm.html#tm.serial_fork… <https://www.kamailio.org/docs/modules/stable/modules/tm.html#tm.serial_fork…>) and as far as I understood a combination of “seturi()” + “append_branch()” + “t_relay()” command calls will allow me to send multiple forked INVITEs in parallel. What I couldn't find information about in the documentation (please point me to it in case I missed it) is what controls (if any) do I have over forked requests. Do I need to keep track of the branches myself and cancel others when first succeeds or does Kamailio have some kind of setting for implementing such behaviour? Thanks, Ivan

7 12

NAT pinging after service restart
by Jacob Greene 21 Apr '20

21 Apr '20

Hello everyone! When I restart the Kamailio service, NAT pinging for all existing location records stops and does not start until the UA registers again. I'm using db_mode 2, and all of the registrations will be there, but for some reason Kamailio wont restart the pinging cycle. Is it possible to configure Kamailio to restart NAT pinging in the event of a service restart? Thanks for reading! Jake Greene Voice Engineer

1 1

Join us for SIP Chronicles Live #1, featuring Giovanni Maruzelli
by Maxim Sobolev 20 Apr '20

20 Apr '20

Dear Real-Time Friends and Colleagues! As many of you we have been totally devastated that we will have no chance to see you in the next few months to come. :-/ Some people in the community believe it might be years. I don’t necessarily agree with that opinion myself. Over the course of the last few years our team had a great time extending live coverage for some of those events that have been affected, got some experience and equipment. Instead of just waiting for the virus to clear, we decided to organize a series of bi-weekly live casts with some of the speakers that we have hoped to see at those events presenting their latest developments live and then answering questions from the audience. So without further ado, let me introduce our first guest Giovanni Maruzzelli, who is going to introduce his newest project SaraPhone ( https://github.com/gmaruzz/saraphone). Join us this Saturday, April 25th 4:30pm UTC and get a chance to ask Giovanni a question about his project live: https://youtu.be/mF9elIcVGE8 Or if you miss that opportunity, you can always watch the recording later on Sippy Labs channel on YouTube and email Giovanni your question at < gmaruzz(a)gmail.com>. SaraPhone is a bare bone SIP WebRTC phone, complete with most features real companies want to use in real world: HotDesking, Redial, BLFs, MWI, DND, PhoneBook, Hold, Transfer, Mute, Attended Transfer, Notifications, running on all Browsers both on Desktop and SmartPhone. SaraPhone is fully integrated with FusionPBX, the full-featured domain based multi-tenant PBX and voice switch for FreeSwitch. Based on SIP.js, SaraPhone works with all WebRTC compliant SIP proxies, gateways, and servers (Asterisk, OpenSIPS, Kamailio, Janus, etc). Initial author is Giovanni Maruzzelli, and SaraPhone gets its name from Giovanni's wife, Sara Hosseini. In addition to providing all of the usual DeskPhone functionality, SaraPhone got: - Desktop Notification for Incoming Calls - Live MWI update - Real Time BLFs status update - BLF click to call - Caller Name and Number Display - Call Error Cause Display - AutoAnswer - Network Disconnect Reload - Show and Set Caller-ID (incoming-outbound) Stay healthy, optimistic and productive! Also share, like and subscribe. See you soon!!! Regards, Max

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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 April 2020