June 2018 - FreeSWITCH-users - FreeSWITCH Mailing Lists

Can't get release cause on dialplan
by David Villasmil 07 Jun '18

07 Jun '18

Hello guys, I've got the following extension: <include> <extension name="public_did0"> <condition field="destination_number" expression="^9999999$"> <action application="set" data="failure_causes=USER_BUSY,NO_ANSWER"/> <action application="bridge" data="{continue_on_fail=true,hangup_after_bridge=false}sofia/external/ 9999999@1.2.3.4:5080 <http://9999999@54.84.149.30:5080>"/> <action application="log" data="CRIT Hangup cause was: ${bridge_hangup_cause}"/> </condition> </extension> </include> But it just shows: 2018-06-07 18:29:42.639898 [DEBUG] switch_ivr_originate.c:3848 Originate Resulted in Error Cause: 65 [BEARERCAPABILITY_NOTIMPL] 2018-06-07 18:29:42.639898 [INFO] mod_dptools.c:3436 Originate Failed. Cause: BEARERCAPABILITY_NOTIMPL 2018-06-07 18:29:42.639898 [DEBUG] switch_channel.c:4758 Failure causes [USER_BUSY,NO_ANSWER]: Cause: BEARERCAPABILITY_NOTIMPL EXECUTE sofia/external/david.villasmil@test-fs02 log(CRIT Hangup cause was: ) 2018-06-07 18:29:42.639898 [CRIT] mod_dptools.c:1742 Hangup cause was: 2018-06-07 18:29:42.639898 [NOTICE] Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337 ᐧ

2 2

warn and hangup after xx seconds
by Francesco Facco de Lagarda 07 Jun '18

07 Jun '18

I am scripting in js I have both analogue and digital trunks out (analogue trunks out don't give me the "answer" event) Lets say we have a "totTime" variable for max length of call I need to play a warning at totTime - 30 And hangup at totTime.. I have tried using: sessOut.execute("set", "execute_on_answer_1=sched_hangup +" + totTime + " alloted_timeout"); sessOut.execute("set", "execute_on_answer_2=sched_broadcast +" + (totTime - 30) + "layback::" + soundDir + "time_off.wav both"); But I can only get one or the other to work.. never both! Also, how would I schedule there two events for analogue lines (where I don't have "on_answer") Thanks all

1 1

Eavesdrop - allow bleg whisper and conference but deny aleg whisper
by Alexis 07 Jun '18

07 Jun '18

Hi, Is it possible to permit one-leg whispering and deny other-leg whispering using eavesdrop application ? I want to permit my users to whisper "company employee leg" or do 3 ways conference but not to whisper only "other leg peoples". It seems that eavesdrop_whisper_aleg=false set which "eavesdrop mode" is set at the beginning of eavesdrop application but doesn't restrict any DTMF (i.e doesn't disable DTMF 2 [whisper with the other half]). -- Alexis

1 0

FS skips an RTP timestamp after an RTCP Sender Report
by David Witham 07 Jun '18

07 Jun '18

Hi all, Wondering if others have seen this. Running FS 1.6.20 on Debian 8 as B2BUA, no proxy media. I'm not sure if this is a bug or whether its environmental in some way. If we dig further and think it really is a bug we'll log a proper bug tomorrow. A call comes in interface A, does not have any RTCP packets. Call is bridged to interface B which does contain RTCP packets. Same confg on both sofia profiles. The RTP packet in the A->B stream immediately after the RTCP packet sent by FS skips a timestamp, even though the sequence number increments correctly. e.g Interface A packets 4.58 seconds RTP timestamp=855198950 seq=53269 4.60 seconds RTP timestamp=855199110 seq=53270 4.62 seconds RTP timestamp=855199270 seq=53271 4.64 seconds RTP timestamp=855199430 seq=53272 Interface B packets 4.77 seconds RTP timestamp=855198950 seq=20446 4.79 seconds RTP timestamp=855199110 seq=20447 4.80 seconds RTCP Sender Report ??? 4.83 seconds RTP timestamp=855199430 seq=20448 In the above example, the packet with timestamp 855199270 does not appear at 4.81 seconds as expected and the next packet contains the next timestamp 855199430 but the sequence numbers keep incrementing normally. Its like FS has dropped that packet internally. We can hear this as an audio artefact when listening to the call. In this case I don't think rewriting timestamps will help if the packet is being dropped - we'll still hear the missing audio. Secondly, in troubleshooting this issue, I've noticed that most of our traffic does not contain RTCP packets, but some do and I can't seem to find any rhyme or reason for this behaviour. Does anyone know why a call will or won't contain RTCP? I had 2 calls in a minute go via 2 FS boxes running the same config, same FS version, same A to B numbers and path through the network and one had RTCP and one didn't. You'd think if the same CPE made the same call to the same FS configuration (albeit a different physical box on the same LAN segment), that you'd see the same behaviour. thanks, David

1 0

What is wrong with my originate ?
by Pierre Couderc 06 Jun '18

06 Jun '18

originate sofia/internal/98%free.couderc.eu 0033484253887 XML int.example.net See my traces below. The strange is that if I call from my extension 98 the same number all is fine. I understand it may be question of CODEC, as when calling from 98 I see PCMA, PCMU in the traces. But how to correct? Thanks to read me. Pierre Couderc ...... 2018-06-02 08:47:43.279349 [DEBUG] sofia_glue.c:1295 sofia/external/0033484253887 sending invite version: 1.6.20 -37-987c9b9 64bit Local SDP: v=0 o=FreeSWITCH 1527903329 1527903330 IN IP4 192.168.163.67 s=FreeSWITCH c=IN IP4 192.168.163.67 t=0 0 m=audio 25934 RTP/AVP 9 101 13 a=rtpmap:9 G722/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 a=ptime:20 a=sendrecv 2018-06-02 08:47:43.279349 [DEBUG] switch_core_state_machine.c:40 sofia/external/0033484253887 Standard INIT 2018-06-02 08:47:43.279349 [DEBUG] switch_core_state_machine.c:48 (sofia/external/0033484253887) State Change CS_INIT -> CS_ROUTING 2018-06-02 08:47:43.279349 [DEBUG] switch_core_state_machine.c:627 (sofia/external/0033484253887) State INIT going to sleep 2018-06-02 08:47:43.279349 [DEBUG] switch_core_state_machine.c:584 (sofia/external/0033484253887) Running State Change CS_ROUTING (Cur 2 Tot 201) 2018-06-02 08:47:43.279349 [DEBUG] sofia.c:7084 Channel sofia/external/0033484253887 entering state [calling][0] 2018-06-02 08:47:43.279349 [DEBUG] switch_core_state_machine.c:643 (sofia/external/0033484253887) State ROUTING 2018-06-02 08:47:43.279349 [DEBUG] mod_sofia.c:143 sofia/external/0033484253887 SOFIA ROUTING 2018-06-02 08:47:43.279349 [DEBUG] switch_ivr_originate.c:67 (sofia/external/0033484253887) State Change CS_ROUTING -> CS_CONSUME_MEDIA 2018-06-02 08:47:43.279349 [DEBUG] switch_core_state_machine.c:643 (sofia/external/0033484253887) State ROUTING going to sleep 2018-06-02 08:47:43.279349 [DEBUG] switch_core_state_machine.c:584 (sofia/external/0033484253887) Running State Change CS_CONSUME_MEDIA (Cur 2 Tot 2 01) 2018-06-02 08:47:43.279349 [DEBUG] switch_core_state_machine.c:662 (sofia/external/0033484253887) State CONSUME_MEDIA 2018-06-02 08:47:43.279349 [DEBUG] switch_core_state_machine.c:662 (sofia/external/0033484253887) State CONSUME_MEDIA going to sleep 2018-06-02 08:47:43.339353 [DEBUG] switch_rtp.c:7308 Correct audio ip/port confirmed. 2018-06-02 08:47:43.339353 [DEBUG] sofia.c:7084 Channel sofia/external/0033484253887 entering state [calling][0] 2018-06-02 08:47:43.399358 [DEBUG] sofia.c:7084 Channel sofia/external/0033484253887 entering state [terminated][488] 2018-06-02 08:47:43.399358 [NOTICE] sofia.c:8273 Hangup sofia/external/0033484253887 [CS_CONSUME_MEDIA] [INCOMPATIBLE_DESTINATION] 2 ....

2 2

Re: [Freeswitch-users] Achieving TLS + SRTP for inbound calls
by David P 06 Jun '18

06 Jun '18

While waiting for suggestions, I tried more things. In particular, I tested whether gentls_cert was present in our FS install (which is at /opt/freeswitch/ on ubuntu). It is present, but the CA root cert step writes to {prefix}/etc/freeswitch/tls/CA/ instead of {prefix}/conf/ssl/CA/. In particular, the root CA step generates: etc/freeswitch/tls/ cafile.pem etc/freeswitch/tls/CA/ cacert.pem cakey.pem config.tpl And the server cert step generates: etc/freeswitch/tls/ agent.pem etc/freeswitch/tls/CA/ cacert.srl Reviewing agent.pem shows it's fine: openssl x509 -noout -inform pem -text -in /opt/freeswitch/etc/freeswitch/tls/agent.pem But it's owned by user root group root, so: cd /opt/freeswitch/etc/freeswitch/tls/ chmod 640 agent.pem CA/cacert.pem chown root.freeswitch agent.pem CA/cacert.pem Then I edited /opt/freeswitch/etc/freeswitch/vars.xml to set internal_ssl_enable and external_ssl_enable to true. Then I restarted FS. I checked the CLI and it shows "WS SETUP FAILED" repeatedly. *Any suggestion?* Blazing ahead...then I exposed the public IP of the FS machine under a subdomain of the CA root cert's domain. (I used a wildcard subdomain for -org when generating both certs; maybe giving a wildcard this way is unnecessary or counterproductive.) Now, the part that puzzles me: I'm already using a "real CA" cert in order to serve my verto client files over https from my DNS name, so browsers won't show security warnings. But I bet I need to have the same CA root cert installed in FS as I use in the webserver, right? I saw the note that commercial certs should work, but *it's not clear what steps to follow to install one*. Cheers, David On Tue, May 22, 2018 at 9:50 PM, David P <davidswalkabout(a)gmail.com> wrote: > We use conferences to allow a verto user to call and connect with an > Asterisk channel. We would like to secure both signalling and media via TLS > + SRTP, and I've read https://freeswitch.org/ > confluence/display/FREESWITCH/SIP+TLS a few times to understand how to do > this. Note that that page has a broken link: https://wiki.freeswitch.org/ > wiki/Secure_RTP > > First, is it still true that FS doesn't offer prebuilt installs (for > Ubuntu) to support this kind of security? > > Assuming that it must be compiled, I began to follow > https://freeswitch.org/confluence/display/FREESWITCH/Debian+8+Jessie with > the additional first step of: apt-get install libssl-dev > > I soon ran into "Unable to locate package freeswitch-video-deps-most". > > What should I try next? > > Cheers, > David >

2 2

Energy level for record_session
by Ciprian Dosoftei 05 Jun '18

05 Jun '18

Hello everyone! I have checked the Confluence documentation and I cannot seem to find energy level settings for the record_session application (not record). I do however see references to a RECORD_SILENCE_THRESHOLD variable in the source code, if I am looking at the right file ( https://docs.freeswitch.org/switch__ivr__async_8c_source.html line 2688). Could it be enforced through a channel variable setting prior to executing the application? My usage scenario is pretty straight forward: I am using record_session (with RECORD_READ_ONLY set) to record each individual channel in a conference separately, which works great, but it also captures much more background noise than ideal, which for muxed mod_conference recordings is not an issue as the energy level setting will naturally clean the recording prior to muxing. I also want the recording to continue should there be excessive silence from a channel (unlike record for which a silence hits threshold is almost always desirable). Thank you! -- Best Regards, Ciprian Dosoftei The information transmitted is intended only for the addressee and may contain privileged and/or confidential material. If you are not the intended recipient, kindly contact the sender and delete the message. Any disclosure, distribution or copying of this message is strictly prohibited without the expressed permission of the sender.

1 0

Re: [Freeswitch-users] No ACK for 200 OK
by Xenia Obolenskaya 05 Jun '18

05 Jun '18

Dear Michael Jerris, Thank you for your consideration! sofia loglevel tport 9 Sofia log level for component [tport] has been set to [9] Here is the log when the parameter in the gateway was commented out  In the received packet in the header Contact: <sip:1000@[2a02:7b43:1eb0:eb21::2]:5060;transport=udp> the selected transport is udp!!! Freeswitch does not sent ACK As for tport log I do not see any fatal errors in this case, maybe you, as a specialist, can see? tport.c:3023 tport_deliver() tport_deliver(0x7f4e6c0ce360): msg 0x7f4e6c0e7520 (1184 bytes) from tls/[2a02:7b43:1eb0:eb21::2]:5061/sips next=(nil) tport.c:2296 tport_set_secondary_timer() tport(0x7f4e6c0ce360): reset timer tport.c:2773 tport_wakeup() tport_wakeup(0x7f4e58096970): events IN tport.c:2864 tport_recv_event() tport_recv_event(0x7f4e58096970) tport_type_tls.c:434 tport_tls_recv() tport_tls_recv(0x7f4e58096970): tls_read() returned 4 tport.c:3205 tport_recv_iovec() tport_recv_iovec(0x7f4e58096970) msg 0x7f4e58068390 from (tls/181.201.33.15:39478) has 4 bytes, veclen = 1 tport.c:2296 tport_set_secondary_timer() tport(0x7f4e58096970): reset timer tport.c:2773 tport_wakeup() tport_wakeup(0x7f4e6c0ce360): events IN tport.c:2864 tport_recv_event() tport_recv_event(0x7f4e6c0ce360) tport_type_tls.c:434 tport_tls_recv() tport_tls_recv(0x7f4e6c0ce360): tls_read() returned 845 tport.c:3205 tport_recv_iovec() tport_recv_iovec(0x7f4e6c0ce360) msg 0x7f4e6c0e7520 from (tls/[2a02:7b43:1eb0:eb21::2]:5061) has 845 bytes, veclen = 1 tport.c:2296 tport_set_secondary_timer() tport(0x7f4e6c0ce360): reset timer tport.c:2773 tport_wakeup() tport_wakeup(0x7f4e6c0ce360): events IN tport.c:2864 tport_recv_event() tport_recv_event(0x7f4e6c0ce360) tport_type_tls.c:434 tport_tls_recv() tport_tls_recv(0x7f4e6c0ce360): tls_read() returned 339 tport.c:3205 tport_recv_iovec() tport_recv_iovec(0x7f4e6c0ce360) msg 0x7f4e6c0e7520 from (tls/[2a02:7b43:1eb0:eb21::2]:5061) has 339 bytes, veclen = 1 recv 1184 bytes from tls/[2a02:7b43:1eb0:eb21::2]:5061 at 07:05:06.088128: ------------------------------------------------------------------------ SIP/2.0 200 OK Via: SIP/2.0/TLS [2a02:f680:e0:1210::2123]:5061;branch=z9hG4bK0UjgcDj2ae5Zr;rport=54911 From: "Extension 1000" <sip:1000@ [2a02:f680:e0:1210::2123]>;tag=1mKgNjj91mpSe To: <sip:1000@[2a02:7b43:1eb0:eb21::2]:5061>;tag=jmg806XU07Dee Call-ID: 6368d0a7-e318-1236-2fbf-525400af4b7f CSeq: 123749671 INVITE Contact: <sip:1000@[2a02:7b43:1eb0:eb21::2]:5060;transport=udp> User-Agent: FreeSWITCH-mod_sofia/1.6.19+git~20171120T163416Z~b1b21d0695~64bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: timer, path, replaces Allow-Events: talk, hold, conference, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 339 X-FS-Display-Name: Outbound Call X-FS-Display-Number: sip:1000%@[2a02:7b43:1eb0:eb21::2] X-FS-Support: update_display,send_info v=0 o=FreeSWITCH 1528150294 1528150295 IN IP6 2a02:7b43:1eb0:eb21::2 s=FreeSWITCH c=IN IP6 2a02:7b43:1eb0:eb21::2 t=0 0 m=audio 21180 RTP/SAVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=crypto:1 AEAD_AES_256_GCM_8 inline:eezgaWEZZUvKciFAkpVWpZhdv39wLjvIyzMZMbmk6FbkYfnrFAm9eziQq5M ------------------------------------------------------------------------ tport.c:3023 tport_deliver() tport_deliver(0x7f4e6c0ce360): msg 0x7f4e6c0e7520 (1184 bytes) from tls/[2a02:7b43:1eb0:eb21::2]:5061/sips next=(nil) tport.c:2296 tport_set_secondary_timer() tport(0x7f4e6c0ce360): reset timer tport.c:2296 tport_set_secondary_timer() tport(0x7f4e6c0ce360): reset timer tport.c:2773 tport_wakeup() tport_wakeup(0x7f4e58096970): events IN tport.c:2864 tport_recv_event() tport_recv_event(0x7f4e58096970) tport_type_tls.c:434 tport_tls_recv() tport_tls_recv(0x7f4e58096970): tls_read() returned 565 tport.c:3205 tport_recv_iovec() tport_recv_iovec(0x7f4e58096970) msg 0x7f4e58068390 from (tls/181.201.33.15:39478) has 565 bytes, veclen = 1 tport.c:3023 tport_deliver() tport_deliver(0x7f4e58096970): msg 0x7f4e58068390 (573 bytes) from tls/181.201.33.15:39478/sips next=(nil) tport.c:2296 tport_set_secondary_timer() tport(0x7f4e58096970): reset timer tport.c:3257 tport_tsend() tport_tsend(0x7f4e58096970) tpn = TLS/ 181.201.33.15:39478 tport_type_tls.c:534 tport_tls_send() tport_tls_writevec: vec 0x7f4e58047300 0x7f4e58097d90 628 (628) tport.c:3594 tport_vsend() tport_vsend(0x7f4e58096970): 628 bytes of 628 to tls/181.201.33.15:39478 tport.c:3492 tport_send_msg() tport_vsend returned 628 tport.c:2296 tport_set_secondary_timer() tport(0x7f4e58096970): reset timer tport.c:2296 tport_set_secondary_timer() tport(0x7f4e58096970): reset timer tport.c:2773 tport_wakeup() tport_wakeup(0x7f4e58096970): events IN tport.c:2864 tport_recv_event() tport_recv_event(0x7f4e58096970) tport_type_tls.c:434 tport_tls_recv() tport_tls_recv(0x7f4e58096970): tls_read() returned 562 tport.c:3205 tport_recv_iovec() tport_recv_iovec(0x7f4e58096970) msg 0x7f4e58068390 from (tls/181.201.33.15:39478) has 562 bytes, veclen = 1 tport.c:3023 tport_deliver() tport_deliver(0x7f4e58096970): msg 0x7f4e58068390 (562 bytes) from tls/181.201.33.15:39478/sips next=(nil) tport.c:2296 tport_set_secondary_timer() tport(0x7f4e58096970): reset timer =========================================================================== And here is the log when the parameter in the gateway was uncommented <param name="register-transport" value="tls"/> and Freeswitch worked smoothly recv 1184 bytes from tls/[2a02:7b43:1eb0:eb21::2]:5061 at 07:10:20.917599: ------------------------------------------------------------------------ SIP/2.0 200 OK Via: SIP/2.0/TLS [2a02:f680:e0:1210::2123]:5061;branch=z9hG4bKFKyaBgKr06NHH;rport=48779 From: "Extension 1000" <sip:1000@ [2a02:f680:e0:1210::2123]>;tag=FQ30U1X208Qje To: <sip:1000@[2a02:7b43:1eb0:eb21::2]:5061>;tag=prNB8j19mB7rc Call-ID: 31efea17-e319-1236-2fbf-525400af4b7f CSeq: 123749844 INVITE Contact: <sip:1000@[2a02:7b43:1eb0:eb21::2]:5061;transport=tls> User-Agent: FreeSWITCH-mod_sofia/1.6.19+git~20171120T163416Z~b1b21d0695~64bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: timer, path, replaces Allow-Events: talk, hold, conference, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 339 X-FS-Display-Name: Outbound Call X-FS-Display-Number: sip:1000%@[2a02:7b43:1eb0:eb21::2] X-FS-Support: update_display,send_info v=0 o=FreeSWITCH 1528143500 1528143501 IN IP6 2a02:7b43:1eb0:eb21::2 s=FreeSWITCH c=IN IP6 2a02:7b43:1eb0:eb21::2 t=0 0 m=audio 28320 RTP/SAVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=crypto:1 AEAD_AES_256_GCM_8 inline:7/8wl/6LKSgPhTNg1czXmvO1xFiiRNmC4Ugk8MYVqOFe+SMuWdbCWdH6hCE ------------------------------------------------------------------------ tport.c:3023 tport_deliver() tport_deliver(0x7f4e740d82a0): msg 0x7f4e740b6be0 (1184 bytes) from tls/[2a02:7b43:1eb0:eb21::2]:5061/sips next=(nil) tport.c:4222 tport_release() tport_release(0x7f4e740d82a0): 0x7f4e740d7590 by 0x7f4e740d2e30 with 0x7f4e740b6be0 tport.c:2296 tport_set_secondary_timer() tport(0x7f4e740d82a0): reset timer 2018-06-05 07:10:20.914430 [INFO] sofia.c:1279 sofia/external-ipv6/1000 Update Callee ID to "Outbound Call" <sip:1000%@[2a02:7b43:1eb0:eb21::2]> 2018-06-05 07:10:20.914430 [DEBUG] sofia.c:7084 Channel sofia/external-ipv6/1000 entering state [completing][200] 2018-06-05 07:10:20.914430 [DEBUG] sofia.c:7094 Remote SDP: v=0 o=FreeSWITCH 1528143500 1528143501 IN IP6 2a02:7b43:1eb0:eb21::2 s=FreeSWITCH c=IN IP6 2a02:7b43:1eb0:eb21::2 t=0 0 m=audio 28320 RTP/SAVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=crypto:1 AEAD_AES_256_GCM_8 inline:7/8wl/6LKSgPhTNg1czXmvO1xFiiRNmC4Ugk8MYVqOFe+SMuWdbCWdH6hCE tport.c:4588 tport_by_name() tport(0x7f4e74083b20): found 0x7f4e740d82a0 by name tls/[2a02:7b43:1eb0:eb21::2]:5061 tport.c:3257 tport_tsend() tport_tsend(0x7f4e740d82a0) tpn = tls/[2a02:7b43:1eb0:eb21::2]:5061 tport_type_tls.c:534 tport_tls_send() tport_tls_writevec: vec 0x7f4e74085160 0x7f4e740d8840 483 (483) tport.c:3594 tport_vsend() tport_vsend(0x7f4e740d82a0): 483 bytes of 483 to tls/[2a02:7b43:1eb0:eb21::2]:5061 tport.c:3492 tport_send_msg() tport_vsend returned 483 send 483 bytes to tls/[2a02:7b43:1eb0:eb21::2]:5061 at 07:10:20.921598: ------------------------------------------------------------------------ ACK sip:1000@[2a02:7b43:1eb0:eb21::2]:5061;transport=tls SIP/2.0 Via: SIP/2.0/TLS [2a02:f680:e0:1210::2123]:5061;branch=z9hG4bKgvQ3cB4UXFc4c Max-Forwards: 70 From: "Extension 1000" <sip:1000@ [2a02:f680:e0:1210::2123]>;tag=FQ30U1X208Qje To: <sip:1000@[2a02:7b43:1eb0:eb21::2]:5061>;tag=prNB8j19mB7rc Call-ID: 31efea17-e319-1236-2fbf-525400af4b7f CSeq: 123749844 ACK Contact: <sip:gw+lt_ipv6@ [2a02:f680:e0:1210::2123]:5061;tport=tcp;transport=tls;gw=lt_ipv6> Content-Length: 0 ------------------------------------------------------------------------ tport.c:2296 tport_set_secondary_timer() tport(0x7f4e740d82a0): reset timer Regards, Xenia Obolenskaya

1 0

Re: [Freeswitch-users] No ACK for 200 OK
by Xenia Obolenskaya 04 Jun '18

04 Jun '18

Hi, All! Thank All! I apologize for my negligence and inadvertence. Because a bare-bones gateway was setup for outbound calls with no username/pass and without registration I omitted an important parameter <param name="register-transport" value="tls"/> Now, with this parameter, the situation has returned to normal. A lot of thanks to All! Xenia Obolenskaya

2 1

How to get working leg timeout
by Sergey Safarov 04 Jun '18

04 Jun '18

Hello i want hangup call if caller not responded for 20 sec. When bleg send RINGING message then leg_timeout works as expected. But if bleg send SESSION_PROGGRESS message then leg_timeout help. Is exist other way to get this working?

6 8