- freeswitch-dev@lists.freeswitch.org - FreeSWITCH Mailing Lists

[Freeswitch-dev] ClueCon 2020 Online
by Anthony Minessale 23 Jul '20

23 Jul '20

Hi, If you haven't already noticed. We are holding ClueCon 2020 online this year due to Covid. If you haven't already, sign up and attend. There is no cost this year. We have prizes, so also sign up for our hackathon and Dangerous Demos which will be live on video along with all of the presentations. -- Anthony Minessale II Founder, FreeSWITCH. http://freeswitch.com https://youtu.be/l_hOxzCt6X4 https://www.youtube.com/watch?v=oAxXgyx5jUw https://www.youtube.com/watch?v=9XXgW34t40s https://www.youtube.com/watch?v=NLaDpGQuZDA

1 0

[Freeswitch-dev] Consultancy?
by Andy Newlands 29 Jun '20

29 Jun '20

We are using Freeswitch as the core of our UK-based SIP platform, which connects with main carriers in the UK, and have a couple of issues which we have been unable to properly resolve ourselves. We are now seeking a Freeswitch expert who can assist in achieving resolution, on a consultancy/contract basis. Where is the most appropriate place to find suitably qualified experts, with proven track-records and endorsements? Layout is basically PSTN_CARRIER<->FS<-->CUSTOMER_PBX (there are also proxies and FS-based SBCs (Kamailio)) At high-level, the issues are: - Loss of RTP when a call is transferred or diverted by the CUSTOMER_PBX - Attempting to transfer a call from the CUSTOMER_PBX can result in ringback continuing, after the transfer-to endpoint answers (again, no RTP). - Behaviour varies depending on which PSTN_CARRIER calls are routed through (we have multiple interconnects) - We can see nothing obviously wrong in the call traces. Thank you Kind regards, Andy

5 4

Re: [Freeswitch-dev] ADD 2 ICE CANDIDATES mod_verto
by Brian West 03 Jun '20

03 Jun '20

What are your settings in the profile set to? /b On Tue, Jun 2, 2020 at 10:55 AM Jazmin Marina Florez Marino < Jazmin.Marino(a)on24.com> wrote: > Hi Brian > > > > I did it. However, the behavior that I got setting it, was getting > duplicated ice candidates:public IP. > > > > Check the email that I replied you one month ago. > > > > FYI > > ################################################################# > > *De:* Jazmin Marina Florez Marino > *Enviado el:* miércoles, 29 de abril de 2020 8:25 p. m. > *Para:* Brian West <brian(a)freeswitch.com>; FreeSWITCH Users Help < > freeswitch-users(a)lists.freeswitch.org> > *Asunto:* RE: [Freeswitch-users] ADD 2 ICE CANDIDATES mod_verto > > > > Hello Brian > > > > I included that variable in vars.xml configuration file and after that > change I get this. > > > > CASE 1: When I added the ext-rtp-ip value in verto.conf.xml, I got 2 ice > candidates. However, they are the same (public ip). <param > name="ext-rtp-ip" value="190.84.118.88"/> > > CASE 2: When I commented the ext-rtp-ip value in verto.conf.xml file, I > only got local IP as ice candidate > > > > In these configurations ext-rtp-ip in internal and external sip_profiles > are set with auto-nat values. > > > > How can I get both IPs (local and public) as valid Ice candidates in the > SDP? > > > > *CASE 1* > > 2020-04-29 19:50:56.535350 [DEBUG] switch_core_media.c:8498 Audio params > are unchanged for verto.rtc/5715976. > > 2020-04-29 19:50:56.535350 [DEBUG] mod_verto.c:2502 Local SDP > verto.rtc/5715976: > > v=0 > > o=FreeSWITCH 1588188372 1588188373 IN IP4 190.84.118.88 > > s=FreeSWITCH > > c=IN IP4 190.84.118.88 > > t=0 0 > > a=msid-semantic: WMS RQn2gdt1uxyuNrfyPxHSSO3S0hq5M1jt > > m=audio 19484 UDP/TLS/RTP/SAVPF 111 110 > > a=rtpmap:111 opus/48000/2 > > a=fmtp:111 useinbandfec=1; minptime=10; stereo=1; sprop-stereo=1 > > a=rtpmap:110 telephone-event/48000 > > a=silenceSupp:off - - - - > > a=ptime:20 > > a=sendrecv > > a=fingerprint:sha-256 > FD:DF:48:02:C3:F8:D9:57:F8:C8:97:CD:3A:AB:6A:A6:97:4A:BA:A5:48:5A:3A:2D:0F:18:14:EC:D5:A9:21:86 > > a=setup:active > > a=rtcp-mux > > a=rtcp:19484 IN IP4 190.84.118.88 > > a=ice-ufrag:ICIqgB97Jp2mgcFO > > a=ice-pwd:yRsZnXKhQPN10ISzbqQhSPes > > a=candidate:2978044633 1 udp 659136 190.84.118.88 19484 typ host > generation 0 > > a=candidate:3048048785 1 udp 659136 190.84.118.88 19484 typ host > generation 0 > > a=end-of-candidates > > a=ssrc:917829176 cname:HwmNAFFU33fGlk40 > > a=ssrc:917829176 msid:RQn2gdt1uxyuNrfyPxHSSO3S0hq5M1jt a0 > > a=ssrc:917829176 mslabel:RQn2gdt1uxyuNrfyPxHSSO3S0hq5M1jt > > a=ssrc:917829176 label:RQn2gdt1uxyuNrfyPxHSSO3S0hq5M1jta0 > > m=video 0 UDP/TLS/RTP/SAVPF 19 > > > > > > *CASE 2* > > 2020-04-29 20:05:01.563371 [DEBUG] mod_verto.c:2502 Local SDP > verto.rtc/5715976: > > v=0 > > o=FreeSWITCH 1588191001 1588191002 IN IP4 192.168.1.170 > > s=FreeSWITCH > > c=IN IP4 192.168.1.170 > > t=0 0 > > a=msid-semantic: WMS uwE5jFb2y1vHfnFvS07p6MR0MiZh3hfo > > m=audio 17700 UDP/TLS/RTP/SAVPF 111 110 > > a=rtpmap:111 opus/48000/2 > > a=fmtp:111 useinbandfec=1; minptime=10; stereo=1; sprop-stereo=1 > > a=rtpmap:110 telephone-event/48000 > > a=silenceSupp:off - - - - > > a=ptime:20 > > a=sendrecv > > a=fingerprint:sha-256 > FD:DF:48:02:C3:F8:D9:57:F8:C8:97:CD:3A:AB:6A:A6:97:4A:BA:A5:48:5A:3A:2D:0F:18:14:EC:D5:A9:21:86 > > a=setup:active > > a=rtcp-mux > > a=rtcp:17700 IN IP4 192.168.1.170 > > a=ice-ufrag:yBbvdTlQ2aXVi29M > > a=ice-pwd:CipItVdvMfCRN6EcxGxApIhh > > *a=candidate:8338699166 1 udp 659136 192.168.1.170 17700 typ host > generation 0* > > a=end-of-candidates > > a=ssrc:1119156645 cname:EKjNgkFEb1cheIDW > > a=ssrc:1119156645 msid:uwE5jFb2y1vHfnFvS07p6MR0MiZh3hfo a0 > > a=ssrc:1119156645 mslabel:uwE5jFb2y1vHfnFvS07p6MR0MiZh3hfo > > a=ssrc:1119156645 label:uwE5jFb2y1vHfnFvS07p6MR0MiZh3hfoa0 > > m=video 0 UDP/TLS/RTP/SAVPF 19 > > > > > > > > *De:* Brian West [mailto:brian@freeswitch.com] > *Enviado el:* martes, 2 de junio de 2020 10:42 a. m. > *Para:* freeswitch-dev(a)lists.freeswitch.org > *CC:* Shishir Pokharel <Shishir.Pokharel(a)on24.com> > *Asunto:* Re: [Freeswitch-dev] ADD 2 ICE CANDIDATES mod_verto > > > > Just set the variable include_external_ip=true > > > > /b > > > > On Tue, Jun 2, 2020 at 10:07 AM Jazmin Marina Florez Marino < > Jazmin.Marino(a)on24.com> wrote: > > Hi Mike > > > > In our scenario we need to send both IPs (public and private). if a FW is > blocking some ports between WebRTC client and FS, we need to guarantee the > SDP negotiation. If the ice candidate (by public IP) option is blocked for > any reason in client side, we deployed a TURN server to negotiate SDP by > local IP. That’s why we need to send both IPs, to reach FS using its local > IP through TURN server. > > > > > > *De:* Mike Jerris [mailto:mike@freeswitch.org] > *Enviado el:* viernes, 29 de mayo de 2020 3:07 p. m. > *Para:* Jazmin Marina Florez Marino <Jazmin.Marino(a)on24.com>; > FreeSWITCH-dev <freeswitch-dev(a)lists.freeswitch.org> > *Asunto:* Re: [Freeswitch-dev] ADD 2 ICE CANDIDATES mod_verto > > > > Adding the line to the sdp is the easy part. All the other code to > properly handle that we did that is a different story. Doing it in a way > that doesn't impact performance at scale is again a different story. > Setting up split dns so you dont need to do any of that is trivial. > > > > On May 28, 2020, at 12:40 PM, Jazmin Marina Florez Marino < > Jazmin.Marino(a)on24.com> wrote: > > > > > > Hi Mike > > In my dev tests, I modified switch_core_media.c file including a localRTP > variable which I set in vars.conf.xml and then in the process to create > SDP I added this condition to include it. > > > > if (include_localrtp && !zstr(smh->mparams->rtpip) && > strcmp(ice_out->cands[0][0].con_addr, smh->mparams->rtpip)) > > > > So, Now, the final SDP includes both, local and public IP as ICE > candidates. > > > > > > 2020-05-13 12:04:55.581400 [DEBUG] mod_verto.c:2507 Local SDP > verto.rtc/5715976: > > v=0 > > o=FreeSWITCH 1589367521 1589367522 IN IP4 190.84.118.88 > > s=FreeSWITCH > > c=IN IP4 190.84.118.88 > > t=0 0 > > a=msid-semantic: WMS ayYpTBb6zUWvNcxrUbbVUikqTtFA7AR7 > > m=audio 21974 UDP/TLS/RTP/SAVPF 111 110 > > a=rtpmap:111 opus/48000/2 > > a=fmtp:111 useinbandfec=1; minptime=10; stereo=1; sprop-stereo=1 > > a=rtpmap:110 telephone-event/48000 > > a=silenceSupp:off - - - - > > a=ptime:20 > > a=sendrecv > > a=fingerprint:sha-256 > FD:DF:48:02:C3:F8:D9:57:F8:C8:97:CD:3A:AB:6A:A6:97:4A:BA:A5:48:5A:3A:2D:0F:18:14:EC:D5:A9:21:86 > > a=setup:active > > a=rtcp-mux > > a=rtcp:21974 IN IP4 190.84.118.88 > > a=ice-ufrag:h601eaiYuOore5o4 > > a=ice-pwd:BCDyR8UQpBtKHoOOkEFoEOdY > > a=candidate:0477192457 1 udp 659136 190.84.118.88 21974 typ host > generation 0 > > a=candidate:0841264532 1 udp 659136 192.168.1.170 21974 typ host > generation 0 > > a=end-of-candidates > > a=ssrc:1455801103 cname:ZFnI6oEw9rRMuf4e > > a=ssrc:1455801103 msid:ayYpTBb6zUWvNcxrUbbVUikqTtFA7AR7 a0 > > a=ssrc:1455801103 mslabel:ayYpTBb6zUWvNcxrUbbVUikqTtFA7AR7 > > a=ssrc:1455801103 label:ayYpTBb6zUWvNcxrUbbVUikqTtFA7AR7a0 > > m=video 0 UDP/TLS/RTP/SAVPF 19 > > > > > > *De:* Mike Jerris [mailto:mike@freeswitch.org <mike(a)freeswitch.org>] > *Enviado el:* martes, 26 de mayo de 2020 3:21 p. m. > *Para:* FreeSWITCH-dev <freeswitch-dev(a)lists.freeswitch.org> > *Asunto:* Re: [Freeswitch-dev] ADD 2 ICE CANDIDATES mod_verto > > > > Use different profiles and splits dns to point the internal and external > to different profiles. You cant send both. > > > > On Apr 27, 2020, at 7:29 AM, Jazmin Marina Florez Marino < > Jazmin.Marino(a)on24.com> wrote: > > > > > > Hello all, > > > > I am working with mod_verto in a scenario where I need to send public and > private IP addresses as ICE candidates. > > When I modify the ext-rtp-ip parameter, it only sends one option as typ > host ice candidate. However, for my implementation I need to send both. > > > > What I need is the combination of those ice candidates, something like > this: > > a=candidate:8228103366 1 udp 659136 190.84.118.88 31028 typ host > generation 0 > > a=candidate:3496438569 1 udp 659136 192.168.1.170 24210 typ host > generation 0 > > > > Is it possible to add both ice candidates in the same SDP from > configuration files? > > > > Thanks > > Jazmin Florez Marino > > +57 304 564 0193 > > Jazmin.marino(a)on24.com > > > > *SDP with local IP* > > 2020-04-24 14:13:49.395900 [DEBUG] mod_verto.c:2502 Local SDP > verto.rtc/5715976: > > v=0 > > o=FreeSWITCH 1587731419 1587731420 IN IP4 192.168.1.170 > > s=FreeSWITCH > > c=IN IP4 192.168.1.170 > > t=0 0 > > a=msid-semantic: WMS t9mERteVPrwT3aZbexPlp2U6Cspg78dq > > m=audio 24210 UDP/TLS/RTP/SAVPF 111 110 > > a=rtpmap:111 opus/48000/2 > > a=fmtp:111 useinbandfec=1; minptime=10; stereo=1; sprop-stereo=1 > > a=rtpmap:110 telephone-event/48000 > > a=silenceSupp:off - - - - > > a=ptime:20 > > a=sendrecv > > a=fingerprint:sha-256 > FD:DF:48:02:C3:F8:D9:57:F8:C8:97:CD:3A:AB:6A:A6:97:4A:BA:A5:48:5A:3A:2D:0F:18:14:EC:D5:A9:21:86 > > a=setup:active > > a=rtcp-mux > > a=rtcp:24210 IN IP4 192.168.1.170 > > a=ice-ufrag:mScCKXydfOjcMntK > > a=ice-pwd:Depc4PrcDqdqfgirZlTz8iCe > > *a=candidate:3496438569 1 udp 659136 192.168.1.170 24210 typ host > generation 0* > > a=end-of-candidates > > a=ssrc:3132020181 cname:7pVPJ0AphX8bXYd1 > > a=ssrc:3132020181 msid:t9mERteVPrwT3aZbexPlp2U6Cspg78dq a0 > > a=ssrc:3132020181 mslabel:t9mERteVPrwT3aZbexPlp2U6Cspg78dq > > a=ssrc:3132020181 label:t9mERteVPrwT3aZbexPlp2U6Cspg78dqa0 > > m=video 0 UDP/TLS/RTP/SAVPF 19 > > > > 2020-04-24 14:13:49.395900 [NOTICE] mod_dptools.c:1360 Channel > [verto.rtc/5715976] has been answered > > > > > > *SDP with Public IP* > > *<param name="ext-rtp-ip" value="190.84.118.88"/>* > > 2020-04-24 14:17:23.715620 [DEBUG] mod_verto.c:2502 Local SDP > verto.rtc/5715976: > > v=0 > > o=FreeSWITCH 1587724815 1587724816 IN IP4 190.84.118.88 > > s=FreeSWITCH > > c=IN IP4 190.84.118.88 > > t=0 0 > > a=msid-semantic: WMS 8gumHFWDC0sD12iPvVhSeEhUfLdXQBVO > > m=audio 31028 UDP/TLS/RTP/SAVPF 111 110 > > a=rtpmap:111 opus/48000/2 > > a=fmtp:111 useinbandfec=1; minptime=10; stereo=1; sprop-stereo=1 > > a=rtpmap:110 telephone-event/48000 > > a=silenceSupp:off - - - - > > a=ptime:20 > > a=sendrecv > > a=fingerprint:sha-256 > FD:DF:48:02:C3:F8:D9:57:F8:C8:97:CD:3A:AB:6A:A6:97:4A:BA:A5:48:5A:3A:2D:0F:18:14:EC:D5:A9:21:86 > > a=setup:active > > a=rtcp-mux > > a=rtcp:31028 IN IP4 190.84.118.88 > > a=ice-ufrag:BiYFM6pSItFoUq2t > > a=ice-pwd:wTz7x9b00ImLonRPvGl8CBRb > > *a=candidate:8228103366 1 udp 659136 190.84.118.88 31028 typ host > generation 0* > > a=end-of-candidates > > a=ssrc:2930644107 cname:If1gLNJdD1HvUPbg > > a=ssrc:2930644107 msid:8gumHFWDC0sD12iPvVhSeEhUfLdXQBVO a0 > > a=ssrc:2930644107 mslabel:8gumHFWDC0sD12iPvVhSeEhUfLdXQBVO > > a=ssrc:2930644107 label:8gumHFWDC0sD12iPvVhSeEhUfLdXQBVOa0 > > m=video 0 UDP/TLS/RTP/SAVPF 19 > > > > > > > > _________________________________________________________________________ > > The FreeSWITCH project is sponsored by SignalWire https://signalwire.com > Enhance your FreeSWITCH install with disruptive priced SMS and PSTN > services. > Build your next product on our scalable cloud platform. > > Join our online community to chat in real time > https://signalwire.community > > Professional FreeSWITCH Services > sales(a)freeswitch.com > https://freeswitch.com > > Official FreeSWITCH Sites > https://freeswitch.com/oss > https://freeswitch.org/confluence > https://cluecon.com > > FreeSWITCH-dev mailing list > FreeSWITCH-dev(a)lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > https://freeswitch.com > > > > > -- > > > > Brian West | Co-founder and Developer > > Need Commercial support? email sales(a)freeswitch.com > > FreeSWITCH Solutions | 17345 Civic Drive #2531 Brookfield, WI 53045 > <https://maps.google.com/?q=17345+Civic+Drive+%232531+Brookfield,+WI+53045&e…> > > Email: brian(a)freeswitch.com > > Mobile: 918-424-9378 > > Website: https://www.FreeSWITCH.com <https://www.freeswitch.com/> > > [image: https://www.facebook.com/signalwireinc?src=email] > <https://www.facebook.com/freeswitch>[image: > https://twitter.com/freeswitch] <https://twitter.com/freeswitch> > -- Brian West | Co-founder and Developer Need Commercial support? email sales(a)freeswitch.com FreeSWITCH Solutions | 17345 Civic Drive #2531 Brookfield, WI 53045 <https://maps.google.com/?q=17345+Civic+Drive+%232531+Brookfield,+WI+53045&e…> Email: brian(a)freeswitch.com Mobile: 918-424-9378 Website: https://www.FreeSWITCH.com <https://www.freeswitch.com/> [image: https://www.facebook.com/signalwireinc?src=email] <https://www.facebook.com/freeswitch> [image: https://twitter.com/freeswitch] <https://twitter.com/freeswitch>

2 1

[Freeswitch-dev] ADD 2 ICE CANDIDATES mod_verto
by Jazmin Marina Florez Marino 02 Jun '20

02 Jun '20

Hello all, I am working with mod_verto in a scenario where I need to send public and private IP addresses as ICE candidates. When I modify the ext-rtp-ip parameter, it only sends one option as typ host ice candidate. However, for my implementation I need to send both. What I need is the combination of those ice candidates, something like this: a=candidate:8228103366 1 udp 659136 190.84.118.88 31028 typ host generation 0 a=candidate:3496438569 1 udp 659136 192.168.1.170 24210 typ host generation 0 Is it possible to add both ice candidates in the same SDP from configuration files? Thanks Jazmin Florez Marino +57 304 564 0193 Jazmin.marino(a)on24.com<mailto:Jazmin.marino@on24.com> SDP with local IP 2020-04-24 14:13:49.395900 [DEBUG] mod_verto.c:2502 Local SDP verto.rtc/5715976: v=0 o=FreeSWITCH 1587731419 1587731420 IN IP4 192.168.1.170 s=FreeSWITCH c=IN IP4 192.168.1.170 t=0 0 a=msid-semantic: WMS t9mERteVPrwT3aZbexPlp2U6Cspg78dq m=audio 24210 UDP/TLS/RTP/SAVPF 111 110 a=rtpmap:111 opus/48000/2 a=fmtp:111 useinbandfec=1; minptime=10; stereo=1; sprop-stereo=1 a=rtpmap:110 telephone-event/48000 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv a=fingerprint:sha-256 FD:DF:48:02:C3:F8:D9:57:F8:C8:97:CD:3A:AB:6A:A6:97:4A:BA:A5:48:5A:3A:2D:0F:18:14:EC:D5:A9:21:86 a=setup:active a=rtcp-mux a=rtcp:24210 IN IP4 192.168.1.170 a=ice-ufrag:mScCKXydfOjcMntK a=ice-pwd:Depc4PrcDqdqfgirZlTz8iCe a=candidate:3496438569 1 udp 659136 192.168.1.170 24210 typ host generation 0 a=end-of-candidates a=ssrc:3132020181 cname:7pVPJ0AphX8bXYd1 a=ssrc:3132020181 msid:t9mERteVPrwT3aZbexPlp2U6Cspg78dq a0 a=ssrc:3132020181 mslabel:t9mERteVPrwT3aZbexPlp2U6Cspg78dq a=ssrc:3132020181 label:t9mERteVPrwT3aZbexPlp2U6Cspg78dqa0 m=video 0 UDP/TLS/RTP/SAVPF 19 2020-04-24 14:13:49.395900 [NOTICE] mod_dptools.c:1360 Channel [verto.rtc/5715976] has been answered SDP with Public IP <param name="ext-rtp-ip" value="190.84.118.88"/> 2020-04-24 14:17:23.715620 [DEBUG] mod_verto.c:2502 Local SDP verto.rtc/5715976: v=0 o=FreeSWITCH 1587724815 1587724816 IN IP4 190.84.118.88 s=FreeSWITCH c=IN IP4 190.84.118.88 t=0 0 a=msid-semantic: WMS 8gumHFWDC0sD12iPvVhSeEhUfLdXQBVO m=audio 31028 UDP/TLS/RTP/SAVPF 111 110 a=rtpmap:111 opus/48000/2 a=fmtp:111 useinbandfec=1; minptime=10; stereo=1; sprop-stereo=1 a=rtpmap:110 telephone-event/48000 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv a=fingerprint:sha-256 FD:DF:48:02:C3:F8:D9:57:F8:C8:97:CD:3A:AB:6A:A6:97:4A:BA:A5:48:5A:3A:2D:0F:18:14:EC:D5:A9:21:86 a=setup:active a=rtcp-mux a=rtcp:31028 IN IP4 190.84.118.88 a=ice-ufrag:BiYFM6pSItFoUq2t a=ice-pwd:wTz7x9b00ImLonRPvGl8CBRb a=candidate:8228103366 1 udp 659136 190.84.118.88 31028 typ host generation 0 a=end-of-candidates a=ssrc:2930644107 cname:If1gLNJdD1HvUPbg a=ssrc:2930644107 msid:8gumHFWDC0sD12iPvVhSeEhUfLdXQBVO a0 a=ssrc:2930644107 mslabel:8gumHFWDC0sD12iPvVhSeEhUfLdXQBVO a=ssrc:2930644107 label:8gumHFWDC0sD12iPvVhSeEhUfLdXQBVOa0 m=video 0 UDP/TLS/RTP/SAVPF 19

3 6

[Freeswitch-dev] mod_callcenter - the configuration property "max-wait-time-with-no-agent" doesn't work
by Alexander Haugg 26 May '20

26 May '20

Hi, The properties "max-wait-time" and "max-wait-time-with-no-agent" have no effect. If the delay is reached, I get the correct debug logs but without an effect. CLI output for the "max-wait-time-with-no-agent" time reached (every 500ms): 2020-04-25 16:29:40.907298 [DEBUG] mod_callcenter.c:2818 Member 170 <+4989840798170> in queue 'myQueue' reached max wait of 60 sec. with no agent plus join grace period of 5 sec. Is it possible, we need the following condition in the 'cc_member_thread_run' function in the mod_callcenter.cs if (switch_channel_test_flag(channel, CF_BREAK)) { switch_channel_clear_flag(channel, CF_BREAK); break; } At the moment, der CF_BREAK will set, but not tested. my config is: <queue name="myQueue"> <param name="strategy" value="agent-with-least-talk-time" /> <param name="max-wait-time" value="300" /> <param name="max-wait-time-with-no-agent" value="60" /> <param name="max-wait-time-with-no-agent-time-reached" value="5" /> <param name="tier-rule-wait-second" value="300" /> <param name="discard-abandoned-after" value="60" /> <param name="announce-frequency" value="0" /> <param name="announce-sound" value="" /> <param name="moh-sound" value="local_stream://moh" /> <param name="time-base-score" value="system" /> <param name="tier-rules-apply" value="false" /> <param name="tier-rule-wait-multiply-level" value="true" /> <param name="tier-rule-no-agent-no-wait" value="false" /> <param name="abandoned-resume-allowed" value="false" /> </queue> If I'm right, I'll open a Jira ticket and add a possible solution. Thanks a lot, Alex

4 4

[Freeswitch-dev] Freeswitch support for generating an SRTP offer from an incoming 3PCC INVITE?
by Guy Mesika 30 Apr '20

30 Apr '20

I'm using Freeswitch ESL (Event Socket Library) in Node.js When I receive an invite to SIP.js from a classic sip endpoint the SDP content is regular RTP. I need to be able to connect RTP endpoint to SRTP endpoint using Freeswitch in the middle. In order to do so we need to be able create an endpoint on Freeswitch without SDP (3PCC INVITE) but we want this endpoint to return SRTP SDP and not RTP SDP. *Main question: Does Freeswitch supports generating SRTP offer from an incoming 3PCC INVITE?* I believe this is the part to handle 3PCC INVITE in Freeswitch 1.8.5: https://github.com/signalwire/freeswitch/blob/v1.8.5/src/mod/endpoints/mod_… if (sofia_test_pflag(profile, PFLAG_3PCC)) { if (switch_channel_test_flag(channel, CF_PROXY_MODE) || switch_channel_test_flag(channel, CF_PROXY_MEDIA)) { switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_INFO, "No SDP in INVITE and 3pcc=yes cannot work with bypass or proxy media, hanging up.\n"); switch_channel_set_variable(channel, SWITCH_ENDPOINT_DISPOSITION_VARIABLE, "3PCC DISABLED"); switch_channel_hangup(channel, SWITCH_CAUSE_MANDATORY_IE_MISSING); } else { switch_channel_set_variable(channel, SWITCH_ENDPOINT_DISPOSITION_VARIABLE, "RECEIVED_NOSDP"); switch_core_media_choose_port(tech_pvt->session, SWITCH_MEDIA_TYPE_AUDIO, 0); switch_core_media_prepare_codecs(session, 1); switch_channel_set_state(channel, CS_HIBERNATE); switch_core_media_gen_local_sdp(session, SDP_TYPE_REQUEST, NULL, 0, NULL, 0); sofia_set_flag_locked(tech_pvt, TFLAG_3PCC); if (sofia_use_soa(tech_pvt)) { nua_respond(tech_pvt->nh, SIP_200_OK, SIPTAG_CONTACT_STR(tech_pvt->reply_contact), SOATAG_USER_SDP_STR(tech_pvt->mparams.local_sdp_str), SOATAG_REUSE_REJECTED(1), SOATAG_AUDIO_AUX("cn telephone-event"), TAG_IF(sofia_test_pflag(profile, PFLAG_DISABLE_100REL), NUTAG_INCLUDE_EXTRA_SDP(1)), TAG_END()); } else { nua_respond(tech_pvt->nh, SIP_200_OK, NUTAG_MEDIA_ENABLE(0), SIPTAG_CONTACT_STR(tech_pvt->reply_contact), SIPTAG_CONTENT_TYPE_STR("application/sdp"), SIPTAG_PAYLOAD_STR(tech_pvt->mparams.local_sdp_str), TAG_END()); } }} Maybe the same pattern they used for mod_verto can be used: https://github.com/signalwire/freeswitch/blob/v1.8.5/src/mod/endpoints/mod_… This function *switch_core_media_gen_local_sdp* seems to be the one to create the RTP SDP: https://github.com/signalwire/freeswitch/blob/v1.8.5/src/switch_core_media.c How can we change this to SRTP SDP instead? static const char *get_media_profile_name(switch_core_session_t *session, int secure){ switch_assert(session); if (switch_channel_test_flag(session->channel, CF_AVPF)) { if (switch_channel_test_flag(session->channel, CF_DTLS) || secure) { if (switch_channel_test_flag(session->channel, CF_AVPF_MOZ)) { return "UDP/TLS/RTP/SAVPF"; } else { return "RTP/SAVPF"; } } else { if (switch_channel_test_flag(session->channel, CF_AVPF_MOZ)) { return "UDP/AVPF"; } else { return "RTP/AVPF"; } } } if (secure) { return "RTP/SAVP"; } return "RTP/AVP"; } There are 3 conditions to enable SRTP: session->channel->flags['CF_AVPF'](session->channel->flags['CF_DTLS'] || secure) session->channel->flags['CF_AVPF_MOZ'] The conditions to put *CF_AVPF* flag are calling *switch_core_session_set_ice* or: if (is_outbound || switch_channel_test_flag(session->channel, CF_RECOVERING) || switch_channel_test_flag(session->channel, CF_3PCC)) { if (!switch_channel_test_flag(session->channel, CF_AVPF) && switch_true(switch_channel_get_variable(session->channel, "media_webrtc"))) { switch_channel_set_flag(session->channel, CF_AVPF); switch_channel_set_flag(session->channel, CF_ICE); smh->mparams->rtcp_audio_interval_msec = SWITCH_RTCP_AUDIO_INTERVAL_MSEC; smh->mparams->rtcp_video_interval_msec = SWITCH_RTCP_VIDEO_INTERVAL_MSEC; } if (switch_true(switch_channel_get_variable(session->channel, "add_ice_candidates"))) { switch_channel_set_flag(session->channel, CF_ICE); } if ( switch_rtp_has_dtls() && dtls_ok(session)) { if (switch_channel_test_flag(session->channel, CF_AVPF) || switch_true(switch_channel_get_variable(smh->session->channel, "rtp_use_dtls"))) { switch_channel_set_flag(smh->session->channel, CF_DTLS); switch_channel_set_flag(smh->session->channel, CF_SECURE); generate_local_fingerprint(smh, SWITCH_MEDIA_TYPE_AUDIO); } } switch_core_session_parse_crypto_prefs(session); switch_core_session_check_outgoing_crypto(session);} The conditions to put *CF_DTLS* flag are the same as above (*CF_AVPF*) or calling *check_ice*: if (switch_rtp_has_dtls() && dtls_ok(smh->session) && !strcasecmp(attr->a_name, "fingerprint") && !zstr(attr->a_value)) { char *p; engine->remote_dtls_fingerprint.type = switch_core_session_strdup(smh->session, attr->a_value); if ((p = strchr(engine->remote_dtls_fingerprint.type, ' '))) { *p++ = '\0'; if (switch_channel_test_flag(smh->session->channel, CF_REINVITE) && !switch_channel_test_flag(smh->session->channel, CF_RECOVERING) && !zstr(engine->remote_dtls_fingerprint.str) && !strcmp(engine->remote_dtls_fingerprint.str, p)) { engine->new_dtls = 0; } else { switch_set_string(engine->remote_dtls_fingerprint.str, p); engine->new_dtls = 1; engine->new_ice = 1; } } generate_local_fingerprint(smh, type); switch_channel_set_flag(smh->session->channel, CF_DTLS); } There is also the possibility to send true for the *secure* parameter but the conditions are many. The conditions to put *CF_AVPF_MOZ* flag: if (m->m_proto_name && !strcasecmp(m->m_proto_name, "UDP/TLS/RTP/SAVPF")) { switch_channel_set_flag(session->channel, CF_AVPF_MOZ);} if (m->m_proto_name && !strcasecmp(m->m_proto_name, "UDP/RTP/AVPF")) { switch_channel_set_flag(session->channel, CF_AVPF_MOZ);}

1 0

[Freeswitch-dev] Recording speech maximum load
by Mody, Darshan Arvindkumar (Darshan) 06 Apr '20

06 Apr '20

Hi We are using Freeswitch to record voice of the caller in some scenarios. I wanted to enquire as to how much is the maximum load permitted when Freeswitch is recording voice. Thanks Darshan

1 0

[Freeswitch-dev] Pointer to memory pool not always passed when calling switch_core_speech_open()
by SanveanRu . 19 Mar '20

19 Mar '20

Hi, list! I am currently studying the internals of TTS features in Freeswitch. There is an unclear moment: switch_core_speech_open() is called from several locations, but pointer to session's memory pool is not always passed during the function call, namely: mod_rss.c -- passed conference_member.c -- passed mod_conference.c -- not passed mod_ssml.c -- not passed switch_ivr_play_say.c -- not passed Is there some rule or reason, that defines in which case pointer should be passed and in which not? Passing pointer to the memory pool may be convenient way to provide speech handle with information about the session, that uses this handle. This may be useful when emitting log messages or events, that should be fired in context of some active session. PS Also, this pointer is always passed to switch_core_asr_open() call. -- Denis Fokin

2 1

[Freeswitch-dev] Torture Test Support
by Mody, Darshan Arvindkumar (Darshan) 26 Nov '19

26 Nov '19

Hi Does FS stack support RFC 4475 - Session Initiation Protocol (SIP) Torture Test Messages? Thanks and Regards Darshan

3 2

[Freeswitch-dev] Freeswitch ESL application with audio stream
by Rui Mendes 19 Nov '19

19 Nov '19

Hello! I’m not very experienced with freeswitch and audio streams so I would like some feedback I’ve set up a freeswitch server with a ESL application that records the caller’s audio. Then, on a separate service, I treat it and respond with audio files I generate with Text-to-speech. I’m thinking of setting up an audio stream on that service and exposing it so I can playback to the caller using mod_shout. Do you think that’s the correct approach or do you have any suggestion of modules I can look into? I also checked mod_rtmp but I’m not sure it could be helpful to me. Thanks in advance! :)

1 0