sr-users November 2019

sr-users@lists.kamailio.org

67 participants
99 discussions

Query regarding Kamailio Sip Server for IMS supporting VOLTE

by Shubhendu Das

Hi , I have a query regarding Kamailio open source SIP server. Does it have any release, where its supports the feature of IMS supporting VOLTE with real commercial mobile phones(IMSI based) ? If so, what is the release number ? Please also let me know about the supported mobile phones list. BR, Shubhendu -- _Disclaimer: This email and any files transmitted along with it may contain Azcom confidential and proprietary information. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action based on the contents of the information contained herein is strictly prohibited. If you are not an intended recipient of this transmission and you received it in error, please inform the sender by reply e-mail and destroy this and all other copies of this transmission to which you have access. The sender of this email or Azcom does not accept liability for any errors or omissions in the contents of this message that may occur as a result._

4 years, 5 months

How to intercept an INVITE after (ts_append)

by Oleg Podguyko

Hello everybody! Kamailio works as a Registrar. Additionally, rtpengine is deployed next to it. Using rtpgngine module I proxy media stream via rtpengine(rtpengine_manage()). I change SDP. SiP2SIP calls work fine. Now I would like to have possibility to "wake up" sip-clients(at the android and ios phones) which are usually not on-line via push notification. Trying to use TSILO module. # User location service route[LOCATION] { lookup("location"); $var(rc) = $rc; if (is_method("INVITE")) { if (t_newtran()) { ts_store(); # if it a new transuction ,it will be store for some time. } } switch ($var(rc)) { case 1: route(RELAY); break; case -1: break; case -3: send_reply("404", "Not Found"); exit; case -2: send_reply("405", "Method Not Allowed"); exit; } } # Handle SIP registrations route[REGISTRAR] { if (!is_method("REGISTER")) return; if (!save("location")) { sl_reply_error(); } ts_append("location", "$tu"); # if transuction for this sip-client is exist. The invite will be send. exit; } If the client is not registered at the kamailio during the call. Then such calls are stored through the "ts_store" function for some time. And if during this time the client send register, kamailio will be sent INVITE to it. But I have the problem. Such calls after "wake up"go through a special branch route that I don't know how to intercept. As a result, I can't change SDP(using rtpengite_manage commands) and rtp stream do not proxy via rtpengine… and call failed. /usr/sbin/kamailio[9957]: exec: {1 2 REGISTER JxPcA9D1hIJ8PmkcnOvI7g..} *** cfgtrace:request_route=[REGISTRAR] c=[/etc/kamailio/kamailio.cfg] l=428 a=26 n=ts_append /usr/sbin/kamailio[9957]: DEBUG: {1 2 REGISTER JxPcA9D1hIJ8PmkcnOvI7g..} tsilo [ts_append.c:72]: ts_append(): transaction 36343:92182831 found for 777777777, going to append branches /usr/sbin/kamailio[9957]: DEBUG: {1 2 REGISTER JxPcA9D1hIJ8PmkcnOvI7g..} tm [t_lookup.c:1629]: t_lookup_ident_filter(): transaction found /usr/sbin/kamailio[9957]: DEBUG: {1 2 REGISTER JxPcA9D1hIJ8PmkcnOvI7g..} registrar [lookup.c:255]: lookup_helper(): contact for [777777777] found by address /usr/sbin/kamailio[9957]: DEBUG: {1 2 REGISTER JxPcA9D1hIJ8PmkcnOvI7g..} registrar [lookup.c:456]: lookup_helper(): instance is /usr/sbin/kamailio[9957]: DEBUG: {1 2 REGISTER JxPcA9D1hIJ8PmkcnOvI7g..} tm [t_append_branches.c:77]: t_append_branches(): transaction 36343:92182831 in status 0 /usr/sbin/kamailio[9957]: DEBUG: {1 2 REGISTER JxPcA9D1hIJ8PmkcnOvI7g..} tm [t_append_branches.c:99]: t_append_branches(): Call uvAzTGsEV9N2ReDjmWoo8A..: 0 (1) outgoing branches /usr/sbin/kamailio[9957]: DEBUG: {1 2 REGISTER JxPcA9D1hIJ8PmkcnOvI7g..} tm [t_append_branches.c:126]: t_append_branches(): Current uri sip:77777777@95.165.146.181:63618;transport=TCP;rinstance=8b1865b95767b7ba /usr/sbin/kamailio[9957]: DEBUG: {1 2 REGISTER JxPcA9D1hIJ8PmkcnOvI7g..} <core> [core/msg_translator.c:2933]: create_via_hf(): id added: <;i=1>, rcv proto=2 /usr/sbin/kamailio[9957]: DEBUG: {1 2 REGISTER JxPcA9D1hIJ8PmkcnOvI7g..} tm [t_append_branches.c:149]: t_append_branches(): added branch [sip:777777777@95.165.146.181:63618;transport=TCP;rinstance=8b1865b95767b7ba] with ruid [uloc-5dd2faa0-26e5-1] /usr/sbin/kamailio[9957]: DEBUG: {1 2 REGISTER JxPcA9D1hIJ8PmkcnOvI7g..} tm [t_append_branches.c:163]: t_append_branches(): Call uvAzTGsEV9N2ReDjmWoo8A..: 0 (0) outgoing branches after clear_branches() /usr/sbin/kamailio[9957]: DEBUG: {1 2 REGISTER JxPcA9D1hIJ8PmkcnOvI7g..} <core> [core/tcp_main.c:2238]: tcpconn_send_put(): send from reader (9957 (22)), reusing fd /usr/sbin/kamailio[9957]: DEBUG: {1 2 REGISTER JxPcA9D1hIJ8PmkcnOvI7g..} <core> [core/tcp_main.c:2473]: tcpconn_do_send(): sending... -- Oleg Podguyko

4 years, 5 months

TLS v 1.3 failed call

by Andrew Chen

Hi guys, I was wondering if someone can help decipher what these few lines mean? Nov 19 20:12:50 sjomainkama51 /usr/sbin/kamailio[21501]: DEBUG: tls [tls_server.c:431]: tls_accept(): tls_accept: new connection from 10.94.98.18:51698 using TLSv1.3 TLS_AES_256_GCM_SHA384 256 Nov 19 20:12:50 sjomainkama51 /usr/sbin/kamailio[21501]: DEBUG: tls [tls_server.c:434]: tls_accept(): tls_accept: local socket: 206.81.191.45:443 Nov 19 20:12:50 sjomainkama51 /usr/sbin/kamailio[21501]: DEBUG: tls [tls_server.c:445]: tls_accept(): tls_accept: client did not present a certificate Nov 19 20:12:50 sjomainkama51 /usr/sbin/kamailio[21501]: DEBUG: tls [tls_server.c:1189]: tls_read_f(): Reading on a renegotiation of connection (n:1652) (0) Nov 19 20:12:50 sjomainkama51 /usr/sbin/kamailio[21501]: DEBUG: <core> [core/tcp_read.c:1527]: tcp_read_req(): EOF Nov 19 20:12:50 sjomainkama51 /usr/sbin/kamailio[21501]: DEBUG: <core> [core/io_wait.h:602]: io_watch_del(): DBG: io_watch_del (0x56367f8b8f80, 12, -1, 0x10) fd_no=2 called Nov 19 20:12:50 sjomainkama51 /usr/sbin/kamailio[21501]: DEBUG: <core> [core/tcp_read.c:1680]: release_tcpconn(): releasing con 0x7fcfc20c57b0, state -1, fd=12, id=23 ([10.94.98.18]:51698 -> [10.94.98.18]:443) Nov 19 20:12:50 sjomainkama51 /usr/sbin/kamailio[21501]: DEBUG: <core> [core/tcp_read.c:1684]: release_tcpconn(): extra_data 0x7fcfc2089f88 Nov 19 20:12:50 sjomainkama51 /usr/sbin/kamailio[21517]: DEBUG: <core> [core/tcp_main.c:3320]: handle_tcp_child(): reader response= 7fcfc20c57b0, -1 from 16 Nov 19 20:12:50 sjomainkama51 /usr/sbin/kamailio[21517]: DEBUG: tls [tls_server.c:683]: tls_h_close(): Closing SSL connection 0x7fcfc2089f88 Bottom line is kamailio closed the connection and I have method setting to this: root@sjomainkama51:/etc/kamailio # grep method tls.cfg method = TLSv1.1+ Supposedly this should work? -- Andy Chen Sr. Telephony Lead Engineer achen@ <achen(a)thinkingphones.com>fuze.com -- *Confidentiality Notice: The information contained in this e-mail and any attachments may be confidential. If you are not an intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the sender and permanently delete the e-mail and any attachments immediately. You should not retain, copy or use this e-mail or any attachment for any purpose, nor disclose all or any part of the contents to any other person. Thank you.*

4 years, 5 months

Fwd: Websocket immediately disconnecting

by Tom D

Gentlemen, Thanks for your feedback. Yes, I've doubled the RAM last night (between my posts) and I am monitoring the behavior. It *feels* that it is definitely working better. I haven't enabled memjoin yet - are there any repercussions that should be expected for enabling memjoin=yes? Thanks for your guidance. Tom

4 years, 5 months

Websocket immediately disconnecting

by Tom D

Hi David, Thanks for your reply. After increasing the verbosity of the debugging, I found the following entries. So am I understanding the log correctly: the websocket module is trying to get some free memory (from Kamilio's general pool?). It doesn't receive any yet proceeds with parsing the response (I get this same parsing error even when it's working) and ultimately, it doesn't register the websocket? I appreciate your (or anyone's) thoughts. Regards, Tom Nov 19 02:44:44 MY-HOSTNAME /usr/sbin/kamailio[14928]: CRITICAL: tls [tls_domain.c:737]: sr_ssl_ctx_info_callback(): SSL handshake started Nov 19 02:44:44 MY-HOSTNAME /usr/sbin/kamailio[14928]: CRITICAL: tls [tls_domain.c:749]: sr_ssl_ctx_info_callback(): SSL handshake done Nov 19 02:44:44 MY-HOSTNAME /usr/sbin/kamailio[14928]: CRITICAL: tls [tls_domain.c:753]: sr_ssl_ctx_info_callback(): SSL disable renegotiation Nov 19 02:44:44 MY-HOSTNAME /usr/sbin/kamailio[14928]: CRITICAL: tls [tls_server.c:431]: tls_accept(): tls_accept: new connection from HI.DD.E.N:63356 using TLSv1/SSLv3 AES256-GCM-SHA384 256 Nov 19 02:44:44 MY-HOSTNAME /usr/sbin/kamailio[14928]: CRITICAL: tls [tls_server.c:434]: tls_accept(): tls_accept: local socket: HI.DD.E.N:8089 Nov 19 02:44:44 MY-HOSTNAME /usr/sbin/kamailio[14928]: CRITICAL: tls [tls_server.c:445]: tls_accept(): tls_accept: client did not present a certificate Nov 19 02:44:45 MY-HOSTNAME /usr/sbin/kamailio[14928]: CRITICAL: <script>: 857:HTTP Request Received Nov 19 02:44:45 MY-HOSTNAME /usr/sbin/kamailio[14928]: ERROR: <core> [core/mem/q_malloc.c:291]: qm_find_free(): qm_find_free(0x7f8b8cdcd000, 65728); Free fragment not found! Nov 19 02:44:45 MY-HOSTNAME /usr/sbin/kamailio[14928]: ERROR: <core> [core/mem/q_malloc.c:425]: qm_malloc(): qm_malloc(0x7f8b8cdcd000, 65728) called from websocket: ws_conn.c: wsconn_add(197), module: websocket; Free fragment not found! Nov 19 02:44:45 MY-HOSTNAME /usr/sbin/kamailio[14928]: ERROR: websocket [ws_conn.c:199]: wsconn_add(): allocating shared memory Nov 19 02:44:45 MY-HOSTNAME /usr/sbin/kamailio[14928]: ERROR: <core> [core/parser/parse_fline.c:262]: parse_first_line(): parse_first_line: bad message (offset: 22) Nov 19 02:44:45 MY-HOSTNAME /usr/sbin/kamailio[14928]: ERROR: <core> [core/parser/msg_parser.c:681]: parse_msg(): ERROR: parse_msg: message=<HTTP/1.1 101 Switching Protocols#015#012Sia: SIP/2.0/TLS HI.DD.E.N:63356#015#012Access-Control-Allow-Origin: https://www.doubango.org#015#012Sec-WebSocket-Protocol: sip#015#012Upgrade: websocket#015#012Connection: upgrade#015#012Sec-WebSocket-Accept: taS0s3Z7t4tOhklSbJDLGmSSYsY=#015#012Server: kamailio (5.2.5 (x86_64/linux))#015#012Content-Length: 0#015#012#015#012> Nov 19 02:44:45 MY-HOSTNAME /usr/sbin/kamailio[14928]: ERROR: websocket [ws_frame.c:583]: ws_frame_receive(): WebSocket connection not found

4 years, 5 months

Asterisk text messages not delivered to SIP client

by Adesh Pandey

Hi Guys, I have been using Kamailio as dispatcher but I have been facing a weird situation that when asterisk SendText command says that message was delivered successfully but webrtc sip client did not receive the message. My deployment has Kamailio as registrar where sip users are registered and when they make any outgoing call, the call is proxied by RTPEngine and then dispatched to Asterisk boxes. Asterisk boxes send some text to the client using SendText but the message is not received by the SIP client. My config as follows: https://gist.github.com/adeshpandey/2c338db7f5d992267f7415de0325e0b4

4 years, 5 months

Kamailio meeting Istanbul and Cairo

by Henning Westerholt

Hello, I will be in about 2 weeks in Istanbul and in Cairo a few days later. I am thinking of organizing a Kamailio/SIP/VoIP social networking event (perhaps a dinner or a pub meeting). Possible dates are the 19th- 20th November in Istanbul and the 23th - 24th November in Cairo. Are people from the community interested in joining such event? If yes, write me your preferred date -- based on feedback in the next days, it will be decided whether it is going to happen and when. Best regards, Henning -- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://skalatan.de/services

4 years, 5 months

Re: [SR-Users] call disconnected in 45 min

by Liu, Charles

Hi All, I have install kamailio IMS using the example config files for P/S/I-cscf with version 5.2... call randomly disconnected between 15 to 45 minutes. Wireshark log show scscf sent BYE to the caller and callee. Any idea what maybe the problem? Scscf debug output ......... ............ 20(25) INFO: ims_registrar_scscf [cxdx_avp.c:138]: cxdx_get_avp(): cxdx_get_experimental_result_code: Failed finding avp 20(25) INFO: ims_registrar_scscf [cxdx_sar.c:84]: create_return_code(): created AVP successfully : [saa_return_code] - [1] 13(18) DEBUG: ims_dialog [dlg_handlers.c:1923]: print_all_dlgs(): ********************13(18) DEBUG: ims_dialog [dlg_handlers.c:1924]: print_all_dlgs(): printing 4096 dialogs 13(18) DEBUG: ims_dialog [dlg_handlers.c:1862]: internal_print_all_dlg(): Trying to get lock for printing 13(18) DEBUG: ims_dialog [dlg_handlers.c:1868]: internal_print_all_dlg(): ----------------------------13(18) DEBUG: ims_dialog [dlg_handlers.c:1869]: internal_print_all_dlg(): Dialog h_entry:h_id = [3396 : 2798] 13(18) DEBUG: ims_dialog [dlg_handlers.c:1870]: internal_print_all_dlg(): Dialog age: 2749 13(18) DEBUG: ims_dialog [dlg_handlers.c:1871]: internal_print_all_dlg(): Dialog call-id: ATokIPEjouNpuwSo6MpHUw.. 13(18) DEBUG: ims_dialog [dlg_handlers.c:1872]: internal_print_all_dlg(): Dialog state: 4 13(18) DEBUG: ims_dialog [dlg_handlers.c:1873]: internal_print_all_dlg(): Dialog ref counter: 2 13(18) DEBUG: ims_dialog [dlg_handlers.c:1874]: internal_print_all_dlg(): Dialog did: 13(18) DEBUG: ims_dialog [dlg_handlers.c:1875]: internal_print_all_dlg(): Dialog from_tag: 8975d611 13(18) DEBUG: ims_dialog [dlg_handlers.c:1876]: internal_print_all_dlg(): Dialog from_uri: sip:bob@ims.mnc001.mcc001.3gppnetwork.org;transport=UDP 13(18) DEBUG: ims_dialog [dlg_handlers.c:1877]: internal_print_all_dlg(): Dialog caller contact: sip:bob@192.168.164.23:39180;transport=UDP 13(18) DEBUG: ims_dialog [dlg_handlers.c:1878]: internal_print_all_dlg(): Dialog first request cseq: 1 13(18) DEBUG: ims_dialog [dlg_handlers.c:1879]: internal_print_all_dlg(): Dialog caller route set: <sip:mo@10.1.1.1;lr=on;ftag=8975d611;rm=8> 13(18) DEBUG: ims_dialog [dlg_handlers.c:1880]: internal_print_all_dlg(): Dialog lifetime: 43200 13(18) DEBUG: ims_dialog [dlg_handlers.c:1881]: internal_print_all_dlg(): Dialog bind_address: udp:172.26.1.60:6060 13(18) DEBUG: ims_dialog [dlg_handlers.c:1882]: internal_print_all_dlg(): Dialog-creating transaction pointer [0x7f8bb2a51858] 13(18) DEBUG: ims_dialog [dlg_handlers.c:1888]: internal_print_all_dlg(): ----------13(18) DEBUG: ims_dialog [dlg_handlers.c:1889]: internal_print_all_dlg(): Dialog out h_entry:h_id = [3296 : 0] 13(18) DEBUG: ims_dialog [dlg_handlers.c:1890]: internal_print_all_dlg(): Dialog out did: 13(18) DEBUG: ims_dialog [dlg_handlers.c:1891]: internal_print_all_dlg(): Dialog out to_tag: c9eb5e55 13(18) DEBUG: ims_dialog [dlg_handlers.c:1892]: internal_print_all_dlg(): Dialog out caller cseq: 1 13(18) DEBUG: ims_dialog [dlg_handlers.c:1893]: internal_print_all_dlg(): Dialog out callee cseq: 1 13(18) DEBUG: ims_dialog [dlg_handlers.c:1894]: internal_print_all_dlg(): Dialog out callee contact: sip:alice@192.168.164.84:49153;alias=192.168.164.84~49153~1 13(18) DEBUG: ims_dialog [dlg_handlers.c:1895]: internal_print_all_dlg(): Dialog out callee route set: <sip:mt@172.26.1.60:6060;lr;ftag=8975d611;did=44d.eea>,<sip:mt@10.1.1.1;lr;ftag=8975d611;rm=7> 13(18) DEBUG: ims_dialog [dlg_handlers.c:1896]: internal_print_all_dlg(): Dialog out branch: z9hG4bKb7d5.6f11b9b34a8a493a3a1b7949831e2f47.0 13(18) DEBUG: ims_dialog [dlg_handlers.c:1897]: internal_print_all_dlg(): Dialog out state (deleted): 0 13(18) DEBUG: ims_dialog [dlg_handlers.c:1899]: internal_print_all_dlg(): ----------13(18) DEBUG: ims_dialog [dlg_handlers.c:1903]: internal_print_all_dlg(): Releasing lock for dlgout 13(18) DEBUG: ims_dialog [dlg_handlers.c:1906]: internal_print_all_dlg(): ----------------------------13(18) DEBUG: ims_dialog [dlg_handlers.c:1934]: print_all_dlgs(): ********************13(18) DEBUG: ims_auth [authorize.c:187]: reg_await_timer(): Looking for expired/useless at 44469727 13(18) DEBUG: ims_auth [authorize.c:192]: reg_await_timer(): Slot 121 <alice(a)ims.mnc001.mcc001.3gppnetwork.org<mailto:alice@ims.mnc001.mcc001.3gppnetwork.org>> 13(18) DEBUG: ims_auth [authorize.c:197]: reg_await_timer(): .. AV 1 - 3 Exp 44469993 0x7f8bb2a5c988 13(18) DEBUG: ims_auth [authorize.c:192]: reg_await_timer(): Slot 914 <bob(a)ims.mnc001.mcc001.3gppnetwork.org<mailto:bob@ims.mnc001.mcc001.3gppnetwork.org>> 13(18) DEBUG: ims_auth [authorize.c:197]: reg_await_timer(): .. AV 1 - 3 Exp 44470022 0x7f8bb2a54e88 13(18) DEBUG: ims_auth [authorize.c:197]: reg_await_timer(): .. AV 1 - 2 Exp 44469974 0x7f8bb2a506a8 13(18) DEBUG: ims_auth [authorize.c:203]: reg_await_timer(): ... dropping av 1 - 2 13(18) DEBUG: ims_auth [authorize.c:232]: reg_await_timer(): [DONE] Looking for expired/useless at 44469727 13(18) DEBUG: ims_dialog [dlg_hash.c:887]: lookup_dlg(): ref dlg 0x7f8bb2a551f8 with 1 -> 3 13(18) DEBUG: ims_dialog [dlg_hash.c:889]: lookup_dlg(): dialog id=2798 found on entry 3396 13(18) DEBUG: ims_dialog [dlg_hash.c:1066]: unref_dlg(): unref dlg 0x7f8bb2a551f8 with 1 -> 2 13(18) DEBUG: ims_dialog [dlg_req_within.c:379]: dlg_terminate(): terminating confirmed dialog 13(18) DEBUG: ims_dialog [dlg_req_within.c:272]: send_bye(): sending BYE to caller 13(18) DEBUG: ims_dialog [dlg_hash.c:1047]: ref_dlg(): ref dlg 0x7f8bb2a551f8 with 1 -> 3 13(18) DEBUG: ims_dialog [dlg_req_within.c:289]: send_bye(): BYE sent to caller 13(18) DEBUG: ims_dialog [dlg_req_within.c:272]: send_bye(): sending BYE to callee 13(18) DEBUG: ims_dialog [dlg_hash.c:1047]: ref_dlg(): ref dlg 0x7f8bb2a551f8 with 1 -> 4 13(18) DEBUG: ims_dialog [dlg_req_within.c:289]: send_bye(): BYE sent to callee 1(6) ERROR: <script>: BYE (sip:bob@ims.mnc001.mcc001.3gppnetwork.org;transport=UDP (172.26.1.60:6060) to sip:alice@ims.mnc001.mcc001.3gppnetwork.org, ATokIPEjouNpuwSo6MpHUw..) 1(6) DEBUG: ims_dialog [dlg_handlers.c:844]: dlg_onroute(): route param is '44d.eea' (len=7) 1(6) DEBUG: ims_dialog [dlg_hash.c:887]: lookup_dlg(): ref dlg 0x7f8bb2a551f8 with 1 -> 5 1(6) DEBUG: ims_dialog [dlg_hash.c:889]: lookup_dlg(): dialog id=2798 found on entry 3396 1(6) DEBUG: ims_dialog [dlg_hash.h:459]: match_dialog(): searching dlg_outs 1(6) DEBUG: ims_dialog [dlg_hash.h:496]: match_dialog(): p: 0x7f8bb2a68c48 ft[8975d611] tt [c9eb5e55] 1(6) DEBUG: ims_dialog [dlg_hash.h:520]: match_dialog(): dout: tt[c9eb5e55] 1(6) DEBUG: ims_dialog [dlg_profile.c:419]: set_current_dialog(): setting current dialog [3396:2798] 1(6) DEBUG: ims_dialog [dlg_hash.c:1293]: next_state_dlg(): dialog 0x7f8bb2a551f8 changed from state 4 to state 6, due event 7 CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving.

4 years, 5 months

Re: [SR-Users] Saving REGISTER status in kamailio database while REGSITER packets are forwarded.

by Voip support

I figured this finally out and all works for me very well. In usrloc dbmode i set value of 3 (its saving immediately changes into DB). In request route for REGISTER method i set t_on_reply("MANAGE_REPLY_REGISTER" and for REGISTER with expires set to 0 i set t_on_reply("MANAGE_REPLY_UNREGISTER") (used pseudovariable $expires(max)). I stored Contact header in $avp(contact) for unREGISTER request for further use when calling unregister(). Then in onreply_route for MANAGE_REPLY_REGISTER i call save lcoation and in MANAGE_REPLY_UNREGISTER for reply code 200 i call unregister function with the stored contact (i had to remove < > and display name using re.subst). So far it looks to work perfect. pon., 18 lis 2019 o 13:38 Voip support <voipexpert0(a)gmail.com> napisał(a): > > Thanks again for all replies... I need to try it out - did not have time > for it yet. > > I think i will go for the onreply_route answer and try to save location in > this place. > > pon., 18 lis 2019 o 06:23 Joel Serrano <joel(a)textplus.com> napisał(a): > >> Yes sir! Works perfectly! >> >> To give you a quick example: >> >> 1) Add in the appropriate place for the REGISTER request: >> t_on_reply("MANAGE_REG_REPLY"); >> 2) Create a new onreply route: >> >> # Manage registration incoming replies >> onreply_route[MANAGE_REG_REPLY] { >> if(status=~"2[0-9][0-9]") { >> if (save("location", "0x04")) { >> xlog("L_NOTICE", "[usrloc] saved user location\n"); >> } >> } >> } >> >> >> Note1: In my setup, I needed to strictly simulate asterisk (chan_sip) >> registrations, so only one AoR was allowed, thus the flags 0x04, if you are >> using PJSIP you might not need it. >> Note2: With this example code, a "unregister" (REGISTER with expires=0) >> will not remove the AoR from Kamailio, to achieve that I check >> independently if the header Expires exists and is 0, or if the contact >> param Expires exists and is 0, and in that case I use the unregister() >> function instead of the save(). >> >> Hope it helps! >> Joel. >> >> >> >> On Sun, Nov 17, 2019 at 5:42 PM Ovidiu Sas <osas(a)voipembedded.com> wrote: >> >>> Did it work calling save() on the reply route? >>> >>> -ovidiu >>> >>> On Thu, Nov 14, 2019 at 6:20 PM Voip support <voipexpert0(a)gmail.com> >>> wrote: >>> > >>> > I am using kamailio 5.3. >>> > >>> > Ovidiu Sas, i will try this tomorrow today is bit late. Maybe it could >>> work. >>> > >>> > David Villasmil , i know i can use SQLOPS but i was thinking of easier >>> method of doing this. >>> > By successful REGISTER i mean save only REGISTER attempt that >>> authenticated correctly at SIP server and in 200 OK a binding was returned. >>> > Same if the binding is later removed i would like remove it from >>> database. I need this because when i run REGISTER over kamailio to >>> destination SIP server i see all register from same IP. >>> > I need to be able to check what was the real source IP of client >>> REGISTER. >>> > >>> > Regards, >>> > Tomasz >>> > >>> > >>> > >>> > pt., 15 lis 2019 o 00:16 Mike from ApoloCore <mike(a)apolocore.com> >>> napisał(a): >>> >> >>> >> I am using kamailio 5.3. >>> >> >>> >> Ovidiu Sas, i will try this tomorrow today is bit late. Maybe it >>> could work. >>> >> >>> >> David Villasmil , i know i can use SQLOPS but i was thinking of >>> easier method of doing this. >>> >> By successful REGISTER i mean save only REGISTER attempt that >>> authenticated correctly at SIP server and in 200 OK a binding was returned. >>> >> Same if the binding is later removed i would like remove it from >>> database. I need this because when i run REGISTER over kamailio to >>> destination SIP server i see all register from same IP. >>> >> I need to be able to check what was the real source IP of client >>> REGISTER. >>> >> >>> >> Regards, >>> >> Tomasz >>> >> >>> >> >>> >> >>> >> >>> >> czw., 14 lis 2019 o 23:33 Ovidiu Sas <osas(a)voipembedded.com> >>> napisał(a): >>> >>> >>> >>> Try to use save() when you process the 200 ok reply for REGISTER in >>> >>> the reply route. >>> >>> >>> >>> Regards, >>> >>> Ovidiu Sas >>> >>> >>> >>> On Thu, Nov 14, 2019 at 3:40 PM Voip support <voipexpert0(a)gmail.com> >>> wrote: >>> >>> > >>> >>> > I setup kamailio to forward REGISTER packets using dispatcher to >>> two servers main and backup. >>> >>> > >>> >>> > The routing logic is quite simple i use the dispatcher probing >>> mechanism to detect if my main dispatcher set id (one server) is active or >>> inactive once it detect a failure all packets are sent to secondary SIP >>> server to achieve High Availability. >>> >>> > >>> >>> > I am looking for module or a way to save into kamailio database >>> client information such as IP address, register username (from FROM >>> header), digest username (authorization username), call-id for successful >>> registration. >>> >>> > >>> >>> > I tried to use registrar module but once i used function >>> save("location") the client was registered on kamailio and packets was not >>> forwarded to main/secondary SIP server (like dispatcher stopped working, >>> the destination did not override). >>> >>> > >>> >>> > REGISTER is sent to SIP URI of kamailio. >>> >>> > >>> >>> > Please let me know if you have any idea how to make this data >>> update in database (insert an entry on fresh successfull REGISTER, delete >>> on expired or removed binding). >>> >>> > >>> >>> > Best regards, >>> >>> > Tomasz >>> >>> > >>> >>> > _______________________________________________ >>> >>> > Kamailio (SER) - Users Mailing List >>> >>> > sr-users(a)lists.kamailio.org >>> >>> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> VoIP Embedded, Inc. >>> >>> http://www.voipembedded.com >>> >>> >>> >>> _______________________________________________ >>> >>> Kamailio (SER) - Users Mailing List >>> >>> sr-users(a)lists.kamailio.org >>> >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> > >>> > _______________________________________________ >>> > Kamailio (SER) - Users Mailing List >>> > sr-users(a)lists.kamailio.org >>> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> >>> >>> >>> -- >>> VoIP Embedded, Inc. >>> http://www.voipembedded.com >>> >>> _______________________________________________ >>> Kamailio (SER) - Users Mailing List >>> sr-users(a)lists.kamailio.org >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> >>

4 years, 5 months

Websocket immediately disconnecting

by Tom D

Hi Everyone, We're running Kamailio 5.2.5 with XHTTP, Websocket and TLS extensions - for the purpose of being able to provide WebRTC capability. The settings for the HTTP request are quite default as set out below. The SIP client we're using is SIP5ML in different web browsers. After a successful start of Kamailio, it is possible to use SIP5ML and its features - i.e. it REGISTER's properly, calls can be made, etc. After about a few hours of running, Kamailio refuses to interact and abruptly closes the TCP connection. The only solution (discovered so far) is to restart Kamailio, which is not feasible on a server that is serving production needs. (On our development server, where the load is only a fraction - this problem does not occur). When the problems does start to occur, in Wireshark I see: 1) Normal TLS negotiation and certificate exchange; followed by 2) SIP5ML initiating the initial HTTP GET 3) Kamailio responds to the upgrade with a 101/Switch Protocols. (4- SIP5ML outputs a SIP REGISTER on a defunct socket as its was closed) Immediately after the 101/Switching Protocol message is received, Kamailio closes down the TCP connection with a FIN message. Nothing in the message or Kamailio log files help to identify what module is responsible for this. Would anyone have any advise where to look further? BTW, I don't see the TCP connection being Reset in the exchanges - so any advise will be appreciated. Tom event_route[xhttp:request] { set_reply_close(); set_reply_no_connect(); if ($Rp != 8089) { xlogl("L_CRIT", "HTTP request received on $Rp\n"); xhttp_reply("403", "Forbidden - 0x24", "", ""); exit; } xlogl("L_CRIT", "HTTP Request Received\n"); if ($hdr(Upgrade)=~"websocket" && $hdr(Connection)=~"Upgrade" && $rm=~"GET") { # Validate Host - make sure the client is using the correct # alias for WebSockets if ($hdr(Host) == $null || !is_myself("sip:" + $hdr(Host))) { xlogl("L_CRIT", "Bad host $hdr(Host)\n"); xhttp_reply("403", "Forbidden - 0x25", "", ""); exit; } # ws_handle_handshake() exits (no further configuration file # processing of the request) when complete. if (ws_handle_handshake()) { # Optional... cache some information about the # successful connection exit; } } xhttp_reply("404", "Resource Not Found - 0x27", "", ""); } event_route[websocket:closed] { xlogl("L_CRIT", "WebSocket connection from $si:$sp has closed\n"); }

4 years, 5 months

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

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