sr-users

sr-users@lists.kamailio.org

36 participants
37510 discussions

Freeradius Accounting [sql] Unsupported Acct-Status-Type = 15
by Suresh Talasaniya 23 Jan '18

23 Jan '18

Hey Guys, I have faced the issue when I am trying to store answered the call to PostgreSQL database using freeradius. *Mon Jan 22 06:48:39 2018 : Info: [sql] Unsupported Acct-Status-Type = 15* For more details, find here with attached radius.log. # freeradius -v freeradius: FreeRADIUS Version 2.2.5, for host x86_64-pc-linux-gnu, built on Aug 10 2017 at 07:25:15 Copyright (C) 1999-2013 The FreeRADIUS server project and contributors. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. You may redistribute copies of FreeRADIUS under the terms of the GNU General Public License. For more information about these matters, see the file named COPYRIGHT. Can someone help me to resolve this problem? -- Regards, Suresh Talasaniya. Contact : +91-9724264776 Skype : suresh.talsaniya

1 0

Kamailio v5.1.1 Released
by Daniel-Constantin Mierla 22 Jan '18

22 Jan '18

Hello, Kamailio SIP Server v5.1.1 stable release is out. This is a maintenance release of the latest stable branch, 5.1, that includes fixes since the release of v5.1.0. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.1.x. Deployments running previous v5.1.x versions are strongly recommended to be upgraded to v5.1.1. For more details about version 5.1.1 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2018/01/kamailio-v5-1-1-released/ RPM, Debian/Ubuntu packages will be available soon as well. Many thanks to all contributing and using Kamailio! Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com

1 0

Already called uac_replace for this dialog
by Евгений Голей 22 Jan '18

22 Jan '18

Tell me please. Logs periodically display messages 2018-01-22T14: 14: 46.7701 "INFO: uac [replace.c: 392]: replace_uri (): Already called uac_replace for this dialog" 2018-01-22T14: 14: 46.7704 "INFO: uac [replace.c: 401]: replace_uri (): Deleted <_uac_funew> var in dialog" The reason I know, the question is how in the dialog to overwrite the previously saved parameter, which was obtained with "uac_replace"? -- С уважением, Евгений Голей

1 0

Planning the release of v5.1.1
by Daniel-Constantin Mierla 22 Jan '18

22 Jan '18

Hello, I am considering to do the first patch release from 5.1 series at the beginning of next week (most likely on Monday or Tuesday), as usual, if there are issues you are aware of and not reported to bug tracker, do it as soon as possible in order to have a chance to be fixed: - https://github.com/kamailio/kamailio/issues Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com

1 1

sip invite proxy-authorization
by Dave & Hazel 21 Jan '18

21 Jan '18

Hello, Sorry, I'm not that familiar with Kamailio. I am trying to figure out how to configure proxy-authorization for incoming sip invites. I've defined WITH_AUTH in the configuration file but I think this only applies to sip register transactions. Any insight is most appreciated. Dave

4 9

Coredump while exchanging diameter capabilities
by Tsvetan Filev 19 Jan '18

19 Jan '18

Hi. I get a coredump which is caused by bad memory handling during the diameter capability exchange process. Here is part of the log file: =================================== 2018-01-16T09:16:39.890992+02:00 linux-o12d kamailio[13298]: 87(13388) INFO: cdp [worker.c:332]: worker_process(): [0] Worker process started... 2018-01-16T09:16:40.296393+02:00 linux-o12d systemd-coredump[13196]: Process 13193 (kamailio) of user 479 dumped core. 2018-01-16T09:16:40.871483+02:00 linux-o12d kamailio[13298]: 94(13395) DEBUG: cdp [peermanager.c:263]: peer_timer(): peer_timer(): taking care of peers... 2018-01-16T09:16:40.871545+02:00 linux-o12d kamailio[13298]: 94(13395) DEBUG: cdp [peermanager.c:280]: peer_timer(): peer_timer(): Peer hss.epc.mnc019.mcc425.3gppnetwork.org State 0 2018-01-16T09:16:40.871596+02:00 linux-o12d kamailio[13298]: 94(13395) DEBUG: cdp [peerstatemachine.c:90]: sm_process(): sm_process(): Peer hss.epc.mnc019.mcc425.3gppnetwork.org State Closed Event Start 2018-01-16T09:16:40.871612+02:00 linux-o12d kamailio[13298]: 94(13395) INFO: cdp [peerstatemachine.c:525]: I_Snd_Conn_Req(): I_Snd_Conn_Req(): Peer hss.epc.mnc019.mcc425.3gppnetwork.org 2018-01-16T09:16:40.871636+02:00 linux-o12d kamailio[13298]: 94(13395) INFO: cdp [receiver.c:869]: peer_connect(): peer_connect(): Trying to connect to 10.82.10.85 port 3868 2018-01-16T09:16:40.871782+02:00 linux-o12d kamailio[13298]: 94(13395) INFO: cdp [receiver.c:937]: peer_connect(): peer_connect(): Peer hss.epc.mnc019.mcc425.3gppnetwork.org:3868 connected 2018-01-16T09:16:40.871813+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [receiver.c:697]: receive_loop(): select_recv(): There is something on the fd exchange pipe 2018-01-16T09:16:40.871828+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [receiver.c:706]: receive_loop(): select_recv(): fd exchange pipe says fd [22] for peer 0x7f0626b91c98:[hss.epc.mnc019.mcc425.3gppnetwork.org] 2018-01-16T09:16:40.871910+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [peerstatemachine.c:90]: sm_process(): sm_process(): Peer hss.epc.mnc019.mcc425.3gppnetwork.org State Wait_Conn_Ack Event I_Rcv_Conn_Ack 2018-01-16T09:16:40.871933+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [diameter_msg.c:184]: AAANewMessage(): AAANewMessage: param session received null and it's a request!! 2018-01-16T09:16:40.872011+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [diameter_msg.c:81]: AAABuildMsgBuffer(): AAABuildMsgBuffer(): len=204 2018-01-16T09:16:40.872041+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [receiver.c:994]: peer_send_msg(): peer_send_msg(): Pipe push [0x7f0626c02548] 2018-01-16T09:16:40.872064+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [receiver.c:751]: receive_loop(): select_recv(): There is something on the send pipe 2018-01-16T09:16:40.872084+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [receiver.c:764]: receive_loop(): select_recv(): Send pipe says [0x7f0626c02548] 8 2018-01-16T09:16:40.872104+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [diameter_msg.c:410]: AAAFreeMessage(): AAAFreeMessage: Freeing message (0x7f0626c02548) 257 2018-01-16T09:16:40.872277+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [receiver.c:574]: do_receive(): receive_loop(): [hss.epc.mnc019.mcc425.3gppnetwork.org] Recv Version 1 Length 360 2018-01-16T09:16:40.872322+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [receiver.c:1088]: receive_message(): receive_message(): [hss.epc.mnc019.mcc425.3gppnetwork.org] Recv msg 257 2018-01-16T09:16:40.872345+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [peerstatemachine.c:90]: sm_process(): sm_process(): Peer hss.epc.mnc019.mcc425.3gppnetwork.org State Wait_I_CEA Event I_Rcv_CEA 2018-01-16T09:16:40.872372+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [peerstatemachine.c:692]: count_Supported_Vendor_Id_AVPS(): Found 4 Supported_Vendor AVPS92(13393) DEBUG: cdp [peerstatemachine.c:743]: save_peer_applications(): Found Supported Vendor for Application 0: 5535 2018-01-16T09:16:40.872389+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [peerstatemachine.c:743]: save_peer_applications(): Found Supported Vendor for Application 0: 10415 2018-01-16T09:16:40.872405+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [peerstatemachine.c:743]: save_peer_applications(): Found Supported Vendor for Application 0: 13019 2018-01-16T09:16:40.872420+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [peerstatemachine.c:743]: save_peer_applications(): Found Supported Vendor for Application 0: 58637 2018-01-16T09:16:40.872438+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [peerstatemachine.c:743]: save_peer_applications(): Found Supported Vendor for Application 0: 5535 2018-01-16T09:16:40.872453+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [peerstatemachine.c:743]: save_peer_applications(): Found Supported Vendor for Application 0: 10415 2018-01-16T09:16:40.872468+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [peerstatemachine.c:743]: save_peer_applications(): Found Supported Vendor for Application 0: 13019 2018-01-16T09:16:40.872486+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [peerstatemachine.c:743]: save_peer_applications(): Found Supported Vendor for Application 0: 58637 2018-01-16T09:16:40.872504+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [peerstatemachine.c:743]: save_peer_applications(): Found Supported Vendor for Application 0: 5535 2018-01-16T09:16:40.872523+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [peerstatemachine.c:743]: save_peer_applications(): Found Supported Vendor for Application 0: 10415 2018-01-16T09:16:40.872539+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [peerstatemachine.c:743]: save_peer_applications(): Found Supported Vendor for Application 0: 13019 2018-01-16T09:16:40.872554+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [peerstatemachine.c:743]: save_peer_applications(): Found Supported Vendor for Application 0: 58637 2018-01-16T09:16:40.872570+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [peerstatemachine.c:756]: save_peer_applications(): Found Supported Vendor for Application 1: 5535 2018-01-16T09:16:40.872586+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [peerstatemachine.c:756]: save_peer_applications(): Found Supported Vendor for Application 1: 10415 2018-01-16T09:16:40.872601+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [peerstatemachine.c:756]: save_peer_applications(): Found Supported Vendor for Application 1: 13019 2018-01-16T09:16:40.872616+02:00 linux-o12d kamailio[13298]: 92(13393) DEBUG: cdp [peerstatemachine.c:756]: save_peer_applications(): Found Supported Vendor for Application 1: 58637 2018-01-16T09:16:40.872634+02:00 linux-o12d kamailio[13298]: 92(13393) CRITICAL: <core> [core/mem/q_malloc.c:145]: qm_debug_frag(): BUG: qm: prev. fragm. tail overwritten(28af01000000, 0)[0x7f0626c038d0:0x7f0626c03908]! Memory allocator was called from cdp: diameter_avp.c:365. Fragment marked by cdp: diameter_avp.c:142. 2018-01-16T09:16:41.054292+02:00 linux-o12d kamailio[13298]: 0(13298) ALERT: <core> [main.c:746]: handle_sigs(): child process 13393 exited by a signal 6 2018-01-16T09:16:41.054403+02:00 linux-o12d kamailio[13298]: 0(13298) ALERT: <core> [main.c:749]: handle_sigs(): core was generated 2018-01-16T09:16:41.054422+02:00 linux-o12d kamailio[13298]: 0(13298) INFO: <core> [main.c:771]: handle_sigs(): terminating due to SIGCHLD 2018-01-16T09:16:41.054438+02:00 linux-o12d kamailio[13298]: 0(13298) DEBUG: <core> [main.c:773]: handle_sigs(): terminating due to SIGCHLD 2018-01-16T09:16:41.054464+02:00 linux-o12d kamailio[13298]: 2(13303) INFO: <core> [main.c:826]: sig_usr(): signal 15 received ... =================================== Attached is wireshark trace. Here is my DiameterPeer.xml: =================================== <?xml version="1.0" encoding="UTF-8"?> <DiameterPeer FQDN="ims110-scscf.epc.mnc019.mcc425.3gppnetwork.org" Realm="epc.mnc019.mcc425.3gppnetwork.org" Vendor_Id="10415" Product_Name="CDiameterPeer" AcceptUnknownPeers="1" DropUnknownOnDisconnect="1" Tc="30" Workers="4" QueueLength="8" TransactionTimeout="5" SessionsHashSize="128" DefaultAuthSessionTimeout="3600" MaxAuthSessionTimeout="3600"> <Peer FQDN="hss.epc.mnc019.mcc425.3gppnetwork.org" Realm="epc.mnc019.mcc425.3gppnetwork.org" port="3868" /> <Acceptor port="3869" bind="10.82.10.56" /> <Auth id="16777216" vendor="10415" />  <DefaultRoute FQDN="ims110-scscf.epc.mnc019.mcc425.3gppnetwork.org" metric="10" /> </DiameterPeer> =================================== It looks like buffer overflow to me but I'm not sure. kamailio version is: =================================== kamailio -v version: kamailio 5.1.0 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled on 05:30:36 Jan 15 2018 with gcc 4.8.5 =================================== OS is openSUSE Leap 42.3. Kernel: Linux linux-o12d 4.4.104-39-default #1 SMP Thu Jan 4 08:11:03 UTC 2018 (7db1912) x86_64 x86_64 x86_64 GNU/Linux Do you have any idea what might be wrong ? It could be bad config but still it should say something in the log without a crash. Regards.

3 5

Problem Proxy
by Nicolas Breuer 18 Jan '18

18 Jan '18

Hello the list, I have a problem on the proxy with the audio between two calls bridged by a UAC. When I made a normal call, no problems. My UAC is nated. UAC > Router > KAMAILIO Frames arrives with private IP in the SDP. U 2018/01/18 21:50:16.798581 217.112.180.235:1024 -> 217.112.180.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 217.112.180.10;branch=z9hG4bK2d06.2f2a1856bde881173a3fc413c4136b83.0. Via: SIP/2.0/UDP 84.14.241.179:5060;rport=5060;branch=z9hG4bK0dBe3143bcf7f60a70b. Record-Route: <sip:217.112.180.10;lr=on;ftag=gK0d4dfe6f;did=227.c0d2;nat=yes>. From: <sip:32XXXXXX87@ >;tag=gK0d4dfe6f. Call-ID: 940401290_111374574(a)84.14.241.179. CSeq: 29328 INVITE. Contact: <sip:32XXXXXX61@192.168.2.2:5060;transport=udp>. Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,INFO,NOTIFY. Supported: timer,100rel. Server: IP Office 10.1.0.0.0 build 237. Min-SE: 1800. Require: timer. Session-Expires: 1800;refresher=uas. To: <sip:32XXXXXX61@217.112.180.235>;tag=998e429e819ba686. Content-Type: application/sdp. Content-Length: 202. . v=0. o=UserA 3721571424 1025404311 IN IP4 192.168.2.2. s=Session SDP. c=IN IP4 192.168.2.2. t=0 0. m=audio 49154 RTP/AVP 9 101. a=rtpmap:9 G722/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. I don't understand why but the proxy (in case of an incoming call) succeed to determine the public IP. Jan 18 21:40:08 proxy1 rtpproxy[1314]: INFO:rxmit_packets:1fb3f1c6c8dfe738221842406be48450: caller's address filled in: 217.112.180.235:49154 (RTP) Jan 18 21:40:08 proxy1 rtpproxy[1314]: INFO:rxmit_packets:1fb3f1c6c8dfe738221842406be48450: guessing RTCP port for caller to be 49155 Jan 18 21:40:16 proxy1 rtpproxy[1314]: INFO:rxmit_packets:1fb3f1c6c8dfe738221842406be48450: caller's address latched in: 217.112.180.235:49155 (RTCP) Don't know why because the only information in SDP is 192.168.2.2 The Kamailio didn't send the information of the proxy to the UAC , but to the other end as this is an incoming call. So I have audio in this case. When I setup a bridge on the UAC to a second number, we have an issue. ( Kamailio 4.4.6 ) This is the same frames U 2018/01/18 21:51:26.607270 217.112.180.235:1024 -> 217.112.180.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 217.112.180.10;branch=z9hG4bK4181.bb7aab84b6fb0aea5836b4d8874406ec.0. Via: SIP/2.0/UDP 84.14.241.179:5060;rport=5060;branch=z9hG4bK0bB16ee5a3d300fee16. Record-Route: <sip:217.112.180.10;lr=on;ftag=gK0b5d7652;did=cc6.5452;nat=yes>. From: <sip:32XXXXXX87@ >;tag=gK0b5d7652. Call-ID: 940248136_13287504(a)84.14.241.179. CSeq: 21946 INVITE. Contact: <sip:32XXXXXX61@192.168.2.2:5060;transport=udp>. Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,INFO,NOTIFY. Supported: timer,100rel. Server: IP Office 10.1.0.0.0 build 237. Min-SE: 1800. Require: timer. Session-Expires: 1800;refresher=uas. To: <sip:32XXXXXX61@217.112.180.235>;tag=559c99f5edcab5d4. Content-Type: application/sdp. Content-Length: 202. . v=0. o=UserA 1781830446 4071482272 IN IP4 192.168.2.2. s=Session SDP. c=IN IP4 192.168.2.2. t=0 0. m=audio 49156 RTP/AVP 8 101. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. But in this case no audio RTCP detected but no the RTP. He took the private ip address "192.168.2.2" and this is the reason of the "no audio". Jan 18 21:51:26 proxy1 rtpproxy[1314]: INFO:rtpp_command_ul_handle:940248136_13287504@84.14.241.179: lookup on ports 11264/10446, session timer restarted Jan 18 21:51:26 proxy1 rtpproxy[1314]: INFO:rtpp_command_ul_handle:940248136_13287504@84.14.241.179: pre-filling callee's address with 192.168.2.2:49156 Jan 18 21:51:26 proxy1 rtpproxy[1314]: INFO:rxmit_packets:e1e387824e0753522b7bc55e02090784: callee's address latched in: 79.137.49.139:39176 (RTP) Jan 18 21:51:32 proxy1 rtpproxy[1314]: INFO:rxmit_packets:e1e387824e0753522b7bc55e02090784: caller's address filled in: 217.112.180.235:49155 (RTCP) Jan 18 21:51:32 proxy1 rtpproxy[1314]: INFO:rxmit_packets:940248136_13287504@84.14.241.179: callee's address filled in: 217.112.180.235:49157 (RTCP) I would like to understand why with the first call, no issues to determine the RTP IP and not in the second case,

1 0

SEMS Site?
by Mark Boyce 18 Jan '18

18 Jan '18

Hi all Could anyone tell me where the current SEMS site is? iptel seem to have lost all references and moved their site to wix. Everything search wise points me back at iptel :-( Or is the copy on github it at the moment? https://github.com/sems-server <https://github.com/sems-server> Cheers Mark

2 2

Problems with probing in dispatcher module
by Paulo Ferreira 18 Jan '18

18 Jan '18

Hi list, I'm using dispatcher module and I'm not able to figure it out how to accomplish a simple task regarding gateways availability and probings. My goal is to probe with SIP OPTIONS my three gatways every, for example, 30 seconds. When one, or more, of them respond with unexpected message or simply do not respond at all, dispatcher module put it/them as inactive automatically. I tried several conf scenarios but without success, all with gateway A off. Fore example: 1 -> I configure the three gateways (A, B and C) in conf file (sip.peers as configuration bellow) with flags 8 setted (probing destination). - When I start kamailio with probing mode equal to 1, all gateways present flags AP (using kamctl dispatcher dump) and nothing change (I only see OPTIONS sent to host B and C). - with probing mode setted to 0, all gateways start with flags AP, after 30 seconds, first OPTIONS are sent (only for B a C again), both B and C pass to AX and after more 30 seconds (ping interval defined) gateway A pass also to AX and OPTIONS stop being sent. 2-> Now I configured the gateways in conf file with flags 1 (inactive destination). - With prob mode 1, all started as IX, 30 seconds later it sends OPTIONS only for gw B and C and both change state to AP and A maintain IX. After more 30 seconds, no more OPTIONS are sent and gw A pass also to AP (hoped it remained IP or IX but not happened). I also tried other combinations of these two parameters, but only the onde I described above make me sense for my purpose. Maybe the solution is simple but I'm not getting there or maybe this it is only possible using failure or timeout routes and setting flags manually to gateways :( Can anyone point out the solution for this if it exists? module configuration used: modparam("dispatcher", "list_file", "sip.peers"); modparam("dispatcher", "flags", 2); modparam("dispatcher", "dst_avp", "$avp(AVP_DST)"); modparam("dispatcher", "grp_avp", "$avp(AVP_GRP)"); modparam("dispatcher", "cnt_avp", "$avp(AVP_CNT)"); modparam("dispatcher", "sock_avp", "$avp(AVP_SOCK)"); modparam("dispatcher", "ds_ping_method", "OPTIONS"); modparam("dispatcher", "ds_ping_from", "sip:ping@test.tt"); modparam("dispatcher", "ds_ping_interval", 30); modparam("dispatcher", "ds_probing_threshold", 1); modparam("dispatcher", "ds_inactive_threshold", 1); modparam("dispatcher", "ds_ping_reply_codes", "class=2;class=4;class=5;class=3"); modparam("dispatcher", "ds_probing_mode", 1); Thanks in advance, Paulo -- ------------------------------------------- Paulo Ferreira VoIP@RCTS - Área de Infraestruturas Aplicacionaisz FCCN http://www.fccn.pt/ Av. do Brasil, n.º 101 1700-066 Lisboa - Portugal Telefone|Phone: +351 218440100; Fax: +351 218472167 Aviso de Confidencialidade/Disclaimer Esta mensagem é exclusivamente destinada ao seu destinatário, podendo conter informação CONFIDENCIAL, cuja divulgação está expressamente vedada nos termos da lei. Caso tenha rececionado indevidamente esta mensagem,solicitamos-lhe que nos comunique esse mesmo facto por esta via ou para o telefone +351 218440100 devendo apagar o seu conteúdo de imediato. This message is intended exclusively for its addressee. It may contain CONFIDENTIAL information protected by law. If this message has been received by error, please notify us via e-mail or by telephone +351 218440100 and delete it immediately.

1 1

Dialog KeepAlive
by Duarte Rocha 18 Jan '18

18 Jan '18

Hey! I'm trying to use the KeepAlive options avaliable in the Dialog modules. For that I use the function dlg_set_property() like this : dlg_set_property("timeout-noreset"); dlg_set_property("ka-dst"); dlg_set_property("ka-src"); However, kamailio can't seem to get the answers from "ka-src". I've tried several scenarios and different call directions and i can never get the answer from the "ka-src". Is there any known issue about this feature ? What arguments kamailio uses to build the OPTIONS request? I think i might be albe to solve the issue if i know this. I have some endpoints behind NAT, Kamailio has multiple IP's and i do number normalization so my proxy works in E.164. I've made some tests and those features don't seem to be the problem, but i cannot be sure. The "ka-dst" works all the time under all situations. Thanks in advance, Cheers

1 0

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