sr-users

sr-users@lists.kamailio.org

37 participants
37511 discussions

Start a nNew thread

Kamailio SIP protocol over WSS
by Washington Costa 31 Aug '17

31 Aug '17

Hello, I'm using kamailio 5.0.2 (x86_64/linux). And it works with WS. Regards, Washington Costa

1 0

Kamailio SIP protocol over WSS
by Washington Costa 31 Aug '17

31 Aug '17

Hi. I'm trying use the JSSIP cliente and Kamailio with WSS. On these sites I generated my certificates: https://letsencrypt.org/ and https://certbot.eff.org/ My browser identify the certificates but SIP client just say: failed: WebSocket opening handshake was canceled Do you have any idea how to fix it? Do you can say a checklist with everything I need to do for use Kamailio with WSS? Here is my log on Kamailio: Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection: 187.41.60.10 Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/tcp_main.c:985]: tcpconn_new(): on port 44630, type 3 Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/tcp_main.c:1291]: tcpconn_add(): hashes: 3062:1194:1491, 2 Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/io_wait.h:380]: io_watch_add(): DBG: io_watch_add(0xa4ac60, 53, 2, 0x7f259df9cd80), fd_no=44 Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/io_wait.h:602]: io_watch_del(): DBG: io_watch_del (0xa4ac60, 53, -1, 0x0) fd_no=45 called Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/tcp_main.c:4139]: handle_tcpconn_ev(): sending to child, events 1 Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/tcp_main.c:3818]: send2child(): selected tcp worker 1 26(13225) for activity on [tls:172.31.39.220:4443], 0x7f259df9cd80 Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: <core> [core/tcp_read.c:1574]: handle_io(): received n=8 con=0x7f259df9cd80, fd=9 Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: tls [tls_server.c:197]: tls_complete_init(): completing tls connection initialization Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: tls [tls_server.c:226]: tls_complete_init(): Using initial TLS domain TLSs<default> (dom 0x7f259ddc4a80 ctx 0x7f259de03bc0 sn []) Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: tls [tls_domain.c:715]: sr_ssl_ctx_info_callback(): SSL handshake started Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: <core> [core/tcp_main.c:2430]: tcpconn_do_send(): sending... Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: <core> [core/tcp_main.c:2464]: tcpconn_do_send(): after real write: c= 0x7f259df9cd80 n=2568 fd=9 Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: <core> [core/tcp_main.c:2465]: tcpconn_do_send(): buf= Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: #026#003#001 Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: <core> [core/io_wait.h:380]: io_watch_add(): DBG: io_watch_add(0xa93f00, 9, 2, 0x7f259df9cd80), fd_no=1 Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: <core> [core/tcp_read.c:195]: tcp_emit_closed_event(): TCP closed event creation triggered Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: <core> [core/tcp_read.c:202]: tcp_emit_closed_event(): no callback registering for handling TCP closed event - dropping! Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: <core> [core/tcp_read.c:305]: tcp_read_data(): EOF on 0x7f259df9cd80, FD 9 ([187.41.60.10]:44630 ->26(13225) DEBUG: <core> [core/tcp_read.c:306]: tcp_read_data(): -> [172.31.39.220]:4443) Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: <core> [core/tcp_read.c:1341]: tcp_read_req(): EOF Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: <core> [core/io_wait.h:602]: io_watch_del(): DBG: io_watch_del (0xa93f00, 9, -1, 0x10) fd_no=2 called Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: <core> [core/tcp_read.c:1495]: release_tcpconn(): releasing con 0x7f259df9cd80, state -1, fd=9, id=2 ([187.41.60.10]:44630 -> [187.41.60.10]:4443) Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: <core> [core/tcp_read.c:1499]: release_tcpconn(): extra_data 0x7f259dfb6488 Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/tcp_main.c:3250]: handle_tcp_child(): reader response= 7f259df9cd80, -1 from 1 Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: tls [tls_server.c:665]: tls_h_close(): Closing SSL connection 0x7f259dfb6488 Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection: 187.41.60.10 Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/tcp_main.c:985]: tcpconn_new(): on port 44692, type 3 Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/tcp_main.c:1291]: tcpconn_add(): hashes: 2869:1129:1296, 3 Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/io_wait.h:380]: io_watch_add(): DBG: io_watch_add(0xa4ac60, 53, 2, 0x7f259df9cd80), fd_no=44 Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/io_wait.h:602]: io_watch_del(): DBG: io_watch_del (0xa4ac60, 53, -1, 0x0) fd_no=45 called Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/tcp_main.c:4139]: handle_tcpconn_ev(): sending to child, events 1 Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/tcp_main.c:3818]: send2child(): selected tcp worker 2 27(13226) for activity on [tls:172.31.39.220:4443], 0x7f259df9cd80 Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: <core> [core/tcp_read.c:1574]: handle_io(): received n=8 con=0x7f259df9cd80, fd=9 Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: tls [tls_server.c:197]: tls_complete_init(): completing tls connection initialization Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: tls [tls_server.c:226]: tls_complete_init(): Using initial TLS domain TLSs<default> (dom 0x7f259ddc4a80 ctx 0x7f259de05708 sn []) Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: tls [tls_domain.c:715]: sr_ssl_ctx_info_callback(): SSL handshake started Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: <core> [core/tcp_main.c:2430]: tcpconn_do_send(): sending... Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: <core> [core/tcp_main.c:2464]: tcpconn_do_send(): after real write: c= 0x7f259df9cd80 n=2568 fd=9 Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: <core> [core/tcp_main.c:2465]: tcpconn_do_send(): buf= Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: #026#003#001 Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: <core> [core/io_wait.h:380]: io_watch_add(): DBG: io_watch_add(0xa93f00, 9, 2, 0x7f259df9cd80), fd_no=1 Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: <core> [core/tcp_read.c:195]: tcp_emit_closed_event(): TCP closed event creation triggered Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: <core> [core/tcp_read.c:202]: tcp_emit_closed_event(): no callback registering for handling TCP closed event - dropping! Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: <core> [core/tcp_read.c:305]: tcp_read_data(): EOF on 0x7f259df9cd80, FD 9 ([187.41.60.10]:44692 ->27(13226) DEBUG: <core> [core/tcp_read.c:306]: tcp_read_data(): -> [172.31.39.220]:4443) Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: <core> [core/tcp_read.c:1341]: tcp_read_req(): EOF Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: <core> [core/io_wait.h:602]: io_watch_del(): DBG: io_watch_del (0xa93f00, 9, -1, 0x10) fd_no=2 called Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: <core> [core/tcp_read.c:1495]: release_tcpconn(): releasing con 0x7f259df9cd80, state -1, fd=9, id=3 ([187.41.60.10]:44692 -> [187.41.60.10]:4443) Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: <core> [core/tcp_read.c:1499]: release_tcpconn(): extra_data 0x7f259dfb6488 Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/tcp_main.c:3250]: handle_tcp_child(): reader response= 7f259df9cd80, -1 from 2 Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: tls [tls_server.c:665]: tls_h_close(): Closing SSL connection 0x7f259dfb6488

2 1

question for best way to remove sips uris - TLS and sips in $ru - get_send_socket2(): protocol/port mismatch
by Karsten Horsmann 31 Aug '17

31 Aug '17

Hello List, of course - best way is not to use sips: uri scheme. But i have to deal with that. I try to configure an multihomed kamailio (public/private IP) in front of my SIP-Servers. One of my softphones variants used TLS for connection but the INVITES of this softphone use the "sips" URI scheme. As i saw in other posts, this seems to be an issue for many people. In my case it breaks the routing to my internal sip-server (only plain udp). Most of my config is similar to havfos example + TLS. https://github.com/havfo/WEBRTC-to-SIP/blob/master/etc/kamailio/kamailio.cfg I tried to fixed that with this extra route - but this breaks the dialog somewhere - after 60 seconds i have no audio and the BYE becomes another CSeq: in the request_route right after route(AUTH) i add my route(FIX_SIPS) if (is_method("INVITE|SUBSCRIBE")) { if ($ru =~ "^sips:") { route(FIX_SIPS); } else { record_route(); } } route[FIX_SIPS] { if ($ru =~ "^sips:") { xlog("L_INFO","---FIX_SIPS-before: ru:($ru)"); $var(orig_uri) = $ru; $ru = "sip:" + $rU + "@" + $td; xlog("L_INFO","---FIX_SIPS-now: $rU $td ru:($ru) orig_uri:($var(orig_uri))"); record_route(); #$ru = $var(orig_uri); xlog("L_INFO","---FIX_SIPS-after: ru:($ru)"); } } 172.20.120.81 = Kamailio private IP 172.20.120.79 = My internal SIP-Server (B2BUA) I used kamailio with CentOS 7 and RTPENGINE 63bdd615 from master kamailio-5.0.2-3.1.x86_64 kamailio-tls-5.0.2-3.1.x86_64 kamailio-mysql-5.0.2-3.1.x86_64 kamailio-websocket-5.0.2-3.1.x86_64 -- Kind Regards *Karsten Horsmann*

1 2

sql_do_query_async(): the db driver module doesn't support async query
by Juha Heinanen 31 Aug '17

31 Aug '17

sqlops README tells: 4.5. sql_query_async(connection, query) Make an async SQL query using 'connection', if implemented by db driver module (e.g., db_mysql) my sqlops sqlcon parameter specifies mysql driver, but still i get to syslog: Aug 24 08:02:05 rox1 /usr/bin/sip-proxy[13886]: ERROR: sqlops [sql_api.c:427]: sql_do_query_async(): the db driver module doesn'tsupport async query any idea why? -- juha

2 7

kamailio asterisk + provider sip trunks
by Жан Базаров 31 Aug '17

31 Aug '17

Good morning! kamailio + dispatcher + provider trunks. How to make RR for incoming calls from pstn? my trunks are authorized on an asterisk, but i have problem with multiple calls on each asterisk. If I do through uac then I have a problem with BYE, and in general the module is uncomfortable. Please tell me how to implement a bunch: kamailio + asterisk + provider trunks..

2 1

Kamailio failover - dialog (transaction) that is available on different proxies
by Donat Zenichev 30 Aug '17

30 Aug '17

Hi. I came up with idea to set up stand with two kamailio and one b2bua server (for routing). The idea consists of failover for dialogs, transactions. So if one of kamailio nodes is down, another one is able to catch up the dialog and let users to properly end up the session. For better realizing of it, I will try to describe the idea step by step: 1. UAC invites UAS, they've done three-way-handshake, media stream is up. 2. Kamailio that processed this dialog is down. 3. Users decided to end the session with BYE method, but proxy that processed their three-way-handshake recently is down, so one of ua sends BYE to the destination route that contains domain name (that both kamailio serve), BYE achieves the second kamailio to let him properly end the dialog. But, there is a big but, this second kamailio hasn't ever known about this dialog, he doesn't support any transactions for it and furthermore he doesn't know anything about this call-id. So the solution for it, as I think, is hidden in db mode for user location (columns that contain call-ids, branches etc. But I need to be sure, if I'm on the right way. For purpose, where one ip is served by two nodes, I have two solutions: -First one. I want to create heartbeat cluster with two kamailio nodes, they will have one shared ip address, so when one node gets down, another one brings up shared ip interface and implements the same actions that master does. -Another method is to assign a few ip addresses to one domain name (ip addresses of different kamailio proxies). So the goal looks simple, if someone has ever done something like that, I will be glad to read the ideas. -- -- BR, Donat Zenichev Wnet VoIP team Tel: +380(44) 5-900-808 http://wnet.ua

3 5

Simultaneous calls in kamailio
by Logeshwaran G 30 Aug '17

30 Aug '17

Hi, Is there any way(tools) to place Simultaneous Calls in kamailio: For Example: 1000 calls simultaneously in Kamailio. Input Please?? Thanks & Kind Regards, Logeshwaran G

4 6

Fwd: sdp extra \r\n in multipart body
by Diego Nadares 29 Aug '17

29 Aug '17

Hi Daniel! Thanks for your reply. The rtpengine module I think it's expecting two \r\n like: ...pcma/8000\r\n \r\n --uniqueboundary .... cpc,9\r\n \r\n --uniqueboundary-- I saw the code and I modified it but Can any one cofirm if multipart has to be like ...pcma/8000\r\n \r\n --uniqueboundary Or ...pcma/8000\r\n --uniqueboundary Or any one of those? Thanks again! Diego El El lun, 21 de ago. de 2017 a las 02:33, Daniel-Constantin Mierla < miconda(a)gmail.com> escribió: > Hello, > > there is \r\n after > > a=rtpmap:8 PCMA/8000 > > because > > --uniqueBoundary-- > > is on next line. > > Maybe is the fault of the code extracting sdp from multi-part body. Open > an issue on github bug tracker not to forget about it. If nobody looks at > it, I will try to do it, but it may take few days given traveling. > > Cheers, > Daniel > > On 18.08.17 22:21, Diego Nadares wrote: > > Hi guys, > > I have the following multipart body > > Content-Type: multipart/mixed;boundary=uniqueBoundary > Remote-Party-ID: <tel:1112222;phone-context=+54> > <1112222;phone-context=+54> > Content-Length: 364 > > --uniqueBoundary > Content-Type: application/sdp > > v=0 > o=user1 53655765 2353687637 IN IP4 111.111.111.111 > s=- > c=IN IP4 111.111.111.111 > t=0 0 > m=audio 6000 RTP/AVP 8 > *a=rtpmap:8 PCMA/8000* > *--uniqueBoundary--* > Content-Type: application/gtd > Content-Disposition: signal;handling=optional > > IAM, > CPC,20 > GCI,885sdfasdf1123 > > --uniqueBoundary-- > > > As you can see *--uniqueBoundary *before *a=rtpmap:8 PCMA/8000* has not > an extra '\r\n'. Is this correct? Or should have it? > > The thing is that rtpengine is receiving sdp with no final '\r'n' from > kamailio: > > Dump for 'offer' from 127.0.0.1:37388: { "sdp": "v=0#015#012o=user1 > 53655765 2353687637 IN IP4 111.111.111.111#015#012s=-#015#012c=IN IP4 > 111.111.111.111#015#012t=0 0#015#012m=audio 6000 RTP/AVP 8#015#012*a=rtpmap:8 > PCMA/8000"*, "ICE": "remove", "direction": [ "pub", "priv" ], "replace": > [ "origin", "session-connection" ], "transport-protocol": "RTP/AVP", > "call-id": "1-17755(a)111.111.111.111", "received-from": [ "IP4", > "111.111.111.111" ], "from-tag": "1", "command": "offer" } > > And the resulting sdp from rtpengine is this: > > --uniqueBoundary > Content-Type: application/sdp > > v=0 > o=user1 53655765 2353687637 IN IP4 172.16.213.16 > s=- > c=IN IP4 172.16.213.16 > t=0 0 > m=audio 35066 RTP/AVP 8 > *a=rtpmap:8 PCMA/8000a=sendrecv* > a=rtcp:35067 > > The problem is related with that '\r\n' but Is this a malformed message or > a possible bug? > > Thanks in advance! > > Diego > > > > > > > _______________________________________________ > Kamailio (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > -- > Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda > Kamailio Advanced Training - www.asipto.com > Kamailio World Conference - www.kamailioworld.com > >

2 3

Query in LCR Rule Target Table:
by Logeshwaran G 29 Aug '17

29 Aug '17

Hi, I need to know What is the Purpose of Priority and Weight column in Lcr_rule_target table: Example: | id | lcr_id | rule_id | gw_id | priority | weight | status | createdBy | createdDate | modifiedBy | modifiedDate | +----+--------+---------+-------+----------+--------+--------+-----------+-------------+------------+--------------+ | 1 | 1 | 1 | 1 | 1 | 1 | 1 | NULL | NULL | NULL | NULL | | 2 | 1 | 4 | 1 | 1 | 2 | 1 | NULL | NULL | NULL | NULL Kindly someone please Guide me. Thanks & Kind Regards, Logeshwaran G

2 4

LCR dont_strip_or_prefix_flag
by Patrick Wakano 29 Aug '17

29 Aug '17

Hello list, I am using Kamailio 5.0.2 on centos7 and I am trying to use the dont_strip_or_prefix_flag ( https://www.kamailio.org/docs/modules/5.0.x/modules/lcr.html#idp49131644) for LCR routing but I discovered that just by declaring the flag like this the module won't prefix my calls: #!define LCR_DONT_STRIP_OR_TAG 7 modparam("lcr", "dont_strip_or_prefix_flag", LCR_DONT_STRIP_OR_TAG) It doesn't matter if I set or reset the flag it never prefix the ReqUR if the declaration is present. I have to remove the declaration to make the module prefix it correctly. But then the whole purpose of the flag is lost....Anyone aware of this behaviour? Regards, Patrick Wakano

3 4

Jump to page:

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