- FreeSWITCH-users - FreeSWITCH Mailing Lists

unREGISTER not working
by Nathan Stratton 11 Mar '19

11 Mar '19

I have the client sending a REGISTER with Expires: 0 and Contact: *, my understanding is that should remove the bindings in freeswitch, but after that they all are still there. ------------------------------------------------------------------------ recv 762 bytes from udp/[10.0.2.96]:5080 at 11:00:45.651053: ------------------------------------------------------------------------ REGISTER sip:dev.illumy1.com SIP/2.0 Via: SIP/2.0/UDP 10.0.2.96:5080;branch=z9hG4bK3Wb8malgZHKDT;rport From: "Sudheer Muskula" <sip:sudheer@dev.illumy1.com >;tag=4D97D039-5C863FDD00079F56-8489E700 To: <sip:sudheer@dev.illumy1.com> CSeq: 11 REGISTER Call-ID: 0D7A1FE2-5C863FDD00079FC5-8489E700 Max-Forwards: 68 Authorization: Digest algorithm=MD5, username="sudheer", realm=" dev.illumy1.com", nonce="e9e0c79a-e471-4ba4-a750-220690c75562", uri="sip: dev.illumy1.com", response="f944dd3fa58e851565b6c53780309712", qop=auth, cnonce="972hv2e0m64m", nc=00000001 Expires: 0 Allow: INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO Supported: path,gruu,outbound User-Agent: JsSIP 3.3.4 X-Call-ID: kfn607uhetvkm8ei7gtn8a Content-Length: 0 Contact: * ------------------------------------------------------------------------ send 1949 bytes to udp/[10.0.2.96]:5080 at 11:00:45.661960: ------------------------------------------------------------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 10.0.2.96:5080;branch=z9hG4bK3Wb8malgZHKDT;rport=5080 From: "Sudheer Muskula" <sip:sudheer@dev.illumy1.com >;tag=4D97D039-5C863FDD00079F56-8489E700 To: <sip:sudheer@dev.illumy1.com>;tag=SvZvrB98HXHHH Call-ID: 0D7A1FE2-5C863FDD00079FC5-8489E700 CSeq: 11 REGISTER Contact: <sip:5ns435v6@10.0.2.96:5080 ;reg-alias=147444f1af106933;transport=udp>;expires=783 Contact: <sip:47vco39t@10.0.2.96:5080 ;reg-alias=f595a5e79733a707;transport=udp>;expires=878 Contact: <sip:ss1ipd1v@10.0.2.96:5080 ;reg-alias=14cd270bd191806e;transport=udp>;expires=941 Contact: <sip:3aovhluh@10.0.2.96:5080 ;reg-alias=e775190329ccf52d;transport=udp>;expires=1120 Contact: <sip:rf46cbig@10.0.2.96:5080 ;reg-alias=04527f3750b455c4;transport=udp>;expires=1147 Contact: <sip:qdqrgilu@10.0.0.5:5080 ;reg-alias=2ccc0c2f1d8215f7;transport=udp>;expires=1934 Contact: <sip:nlf4usu4@10.0.0.5:5080 ;reg-alias=6a066a0251e6341c;transport=udp>;expires=1968 Contact: <sip:d4rqb4d8@10.0.0.5:5080 ;reg-alias=995a6a9ad08d0d6f;transport=udp>;expires=2202 Contact: <sip:tm33f6ch@10.0.2.96:5080 ;reg-alias=f615726a7c3463e6;transport=udp>;expires=2425 Contact: <sip:hhmtmd1o@10.0.0.5:5080 ;reg-alias=3be356eaeaa536d6;transport=udp>;expires=2857 Contact: <sip:an6nqfld@10.0.0.5:5080 ;reg-alias=641ccc3f0a312625;transport=udp>;expires=2886 Contact: <sip:nf3v0st4@10.0.2.96:5080 ;reg-alias=d6088dc731387496;transport=udp>;expires=3291 Contact: <sip:hcd3mbt3@10.0.2.96:5080 ;reg-alias=260105000e403fc7;transport=udp>;expires=3298 Contact: <sip:ibnubs8e@10.0.2.96:5080 ;reg-alias=726e93a291f48c39;transport=udp>;expires=3354 Contact: <sip:55509s46@10.0.2.96:5080 ;reg-alias=d3d6ca3c56623cd2;transport=udp>;expires=3526 Date: Mon, 11 Mar 2019 11:00:45 GMT User-Agent: FreeSWITCH-mod_sofia/1.8.5~64bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, path, replaces Content-Length: 0 ><> nathan stratton

1 0

Variable no longer showing in channels
by Rick Jarvis 07 Mar '19

07 Mar '19

I got this working (with the help of this list) some time ago, but for some reason it seems to have stopped working. I’m setting a variable ‘callsubject’ in the dialplan via httapi, for which I added a column in the channels table: ALTER TABLE channels ADD COLUMN callsubject VARCHAR(256) <action application="httapi" data="{url=https://server/${destination_number}}”/>  <action application="log" data="CRIT callsubject: ${callsubject}”/>  And yet, whilst the column shows up in ’show channels’, the leg in question has an empty value. What am I missing, maybe?

3 4

Proxy Media and ICE Candidates
by Thomas Auge 07 Mar '19

07 Mar '19

Hello all! When using proxy media, it appears FS is passing through the ICE candidates from the a-leg unmodified. Shouldn't it replace them with its own? Is this a bug, or am I missing something? Thanks! Thomas

1 0

video banner
by Sowmya Venkat 06 Mar '19

06 Mar '19

Hi, I am trying to set the video banner from the admin control of Verto client as well as the fs_cli using conference <name> vid-banner <member-id> text. I see a dark blue banner showing up on the bottom of the member for whom I am setting the banner. But the text that I am providing does not show up. I tried to tweak the config files as per the mod_conference page, but no impact. Pls let me know if I need to add any configuration to see the banner properly. thanks Sowmya Venkat | Technical Architect [cid:image002.png@01D26784.4E61EC30]sowmya.venkat2@infinite.com |P: +919972700330 Communicate with me securely via NetSfere<http://www.netsfere.com/>: https://netsfere.me/sowmyavenkat3 Infinite Convergence Solutions <http://www.infinite-convergence.com/> | Enabling Communication This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify so to the sender by e-mail and delete the original message. In such cases, please notify us immediately at info(a)infinite.com <mailto:info@infinite.com> . Further, you are not to copy, disclose, or distribute this e-mail or its contents to any unauthorized person(s). Any such actions are considered unlawful. This e-mail may contain viruses. Infinite has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachments. Infinite reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infinite e-mail system. ***INFINITE******** End of Disclaimer********INFINITE********

1 0

Unable to establish WebRTC connection between Freeswitch 1.8.5 and Firefox
by Marko Seidenglanz 05 Mar '19

05 Mar '19

I've added another two network traces: - sip_ice_fs_firefox_flow.png: shows the flow graph between Freeswitch (10.240.0.102) our Message Proxy (137.74.91.166) and Firefox (89.246.67.250) - sip_ice_fs_chrome_flow.png: shows the flow graph between Freeswitch (10.240.0.102) our Message Proxy (137.74.91.166) and Google Chrome (89.246.67.250) As you can see, chrome has a much more aggressive ice behavior than firefox and so the connection is established since Freeswitch sends his ICE Check Message to the write Port at timestamp 4.177... which does not happen, when dealing with Firefox. -- Marko Seidenglanz Softwareentwicklung Telefon: +49 351-21324-261 E-Mail: marko.seidenglanz(a)modima.de modima GmbH Sitz der Gesellschaft: Altplauen 19, 01187 Dresden Amtsgericht Dresden HRB: 32806 Geschäftsführer: Wolfram Gürlich USt-IdNr: DE232950743

1 0

[Freeswitch] WebRTC connection problems with firefox behind symmetric nat (since 1.8.2)
by Marko Seidenglanz 05 Mar '19

05 Mar '19

Hello, Our setup is the following: SIP Message transfer: Freeswitch(10.240.0.130) ----INVITE(via UDP)----> INTERNET ----->Proxy(185.61.149.132) ----INVITE(via HTTP)----> Firefox ICE Message transfer: Freeswitch(10.240.0.130) <----> INTERNET <-----> NAT(89.246.67.250) <----> Firefox 10.240.0.130: Freeswitch 185.61.149.132: Proxy for SIP Message transfer to client 89.246.67.250: Firefox client behind NAT I've attached a pcap that was recorded on Freeswitch side. If you filter by "(sip || stun) && (ip.addr == 89.246.67.250 || ip.addr == 185.61.149.132)", you'll see the connection process. The issue is, that freeswitch does not auto change the stun port anymore. On source 89.246.67.250 is our firefox client. 10.240.0.130 is the IP where freeswitch resides. Though he receives the stun messages from 89.246.67.250:44953, he still sends the binding requests to 89.246.67.250:17212, which is the srvrflx candidate that he received via sdp. 89.246.67.250:17212 was determined by Firefox using Googles STUN Server (stun.l.google.com:19302). We omited the whole STUN-Process in earlier versions of our application, since Firefox is behind symmetric NAT and so it does not make sense to use a STUN server as the discovered port is not reachable from Freeswitch. It is blocked by our pfSense Firewall. Earlier versions of Freeswitch (e.g. 1.6.2) did learn the candidate, from which he received STUN CHECK messages and used it to send his check messages. But since your fix, he does not do this anymore. It is not a problem with chrome, since chrome browser sends a lot more check messages than firefox. Firefox only sends 4 messages and then considers the STUN Candidate check as failed, if he does not receive a check message on this candidate pair. Obviously, this does not seem to be enough for Freeswitch to change the UDP port. Has anyone had similar experiences, or can anyone help us solve the problem? Kind regards, Marko Seidenglanz -- Marko Seidenglanz Softwareentwicklung Telefon: +49 351-21324-261 E-Mail: marko.seidenglanz(a)modima.de modima GmbH Sitz der Gesellschaft: Altplauen 19, 01187 Dresden Amtsgericht Dresden HRB: 32806 Geschäftsführer: Wolfram Gürlich USt-IdNr: DE232950743

1 0

Does Verto support ICE trickling?
by Sowmya Venkat 05 Mar '19

05 Mar '19

Hi, I see a post back from 2017 saying Verto/FS does not support ICE trickling. Can you pls update if there have been any enhancements since then and if Verto/FS supports ICE trickling now? http://lists.freeswitch.org/pipermail/freeswitch-users/2017-May/125974.html Thanks Sowmya This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify so to the sender by e-mail and delete the original message. In such cases, please notify us immediately at info(a)infinite.com <mailto:info@infinite.com> . Further, you are not to copy, disclose, or distribute this e-mail or its contents to any unauthorized person(s). Any such actions are considered unlawful. This e-mail may contain viruses. Infinite has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachments. Infinite reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infinite e-mail system. ***INFINITE******** End of Disclaimer********INFINITE********

2 1

random source port
by FUX 04 Mar '19

04 Mar '19

Good morning. Is any way in freeswitch to force to use same source port for outbound calls to gateway? For example i have following gateway configuration : <gateway name="PRO"> <param name="proxy" value="10.10.10.44"/> <param name="username" value="not-used"/> <param name="password" value="not-used"/> <param name="context" value="from_PRO"/> <param name="register" value="false"/> <param name="register-transport" value="tcp"/> <variables> <variable name="verbose_sdp" value="true"/> <variable name="absolute_codec_string" value="PCMA,PCMU" direction="outbound"/> </variables> </gateway> When i send outbound calls to gw PRO. FS choose random source port for every attempt. Due to it Gateway PRO fail to authenticate it.

1 0

Call hold issue
by igor.potjevlesch＠gmail.com 04 Mar '19

04 Mar '19

Hello, I have a weird behaviour with a call hold scenario. When the customer on leg A is placing the call on-hold (by sending a RE INVITE with sendonly attribute in the SDP), Freeswitch is switching to hold: "Callstate Change ACTIVE -> HELD". But only on the leg A. The holding is not forwarded to the leg B. So, it causes the called party not to hear the Music On Hold generated by the calling party. Any idea of what could result in this behaviour? Regards, Igor.

2 3

About sched_hangup
by 王聡 01 Mar '19

01 Mar '19

Hey all, I made a prepaid call system and applied sched_hangup in dialplan to limit the call duration like(lua) : session:execute("sched_hangup", “+60") Recently I updated my system to allow user buy points during calling, but when I tried to recall sched_hangup like [sched_hangup +30 <uuid>] in fs_cli it still hangup at 60s (which hopes to hangup at 90s). Is there any mistake in my usage? Or any solutions for this? Regards. C.Wang

3 2