November 2016 - FreeSWITCH-users - FreeSWITCH Mailing Lists

Conference URI
by Kiran Ravuri 08 Nov '16

08 Nov '16

Hi All, I could able to create a conference room and dial out from room to participants using ESL. Where can I find the sip URI of the conference room, which is dynamically created from ESL, so that I can give that to the pariticipants who want to dial in to the room ? BRs Kiran

2 1

Video call failed
by Agustí Ubalde 08 Nov '16

08 Nov '16

Hi all, I've just installed FS 1.6 and configured 2 extensions for make video calls. Is this scenario possible without conference the video call? The call failed with the following message: *67cc9edd-bc3a-4b25-bb1c-5dc475a409d6 2016-11-07 15:36:50.676944 [INFO] mod_dptools.c:3401 Originate Failed. Cause: INCOMPATIBLE_DESTINATION* Thanks! *PRESENCE TECHNOLOGY* *Agustí Ubalde Bellot* Chief Developer C/ Comte Urgell 240 3A Barcelona 08036 aubalde(a)presenceco.com Ph: +34 93 10 10 300 Fx: +34 93 10 10 333 *www.presenceco.com* <http://www.presenceco.com/> *Follow us on:* *[image: tw]* <http://twitter.com/presencetech>*[image: yt]* <http://www.youtube.com/PresenceTechnology>*[image: in]* <http://www.linkedin.com/groups?mostPopular=&gid=2898558>*[image: ss]* <http://www.slideshare.net/PresenceTech>*[image: fb]* <http://www.facebook.com/presencetech> For additional information, please visit our website *www.presenceco.com* <http://www.presenceco.com/> -- *Presence Technology - DisclaimerThis message, its content and any file attached thereto is for the intended recipient only and is confidential and /or privileged. If you have received this e-mail in error or had access to it, you should note that the information in it is private and any use thereof is unauthorized. In such an event please notify us by e-mail or by telephone (+ 34 93 10 10 300). Any reproduction of this e-mail by whatsoever means and any transmission or dissemination thereof to other persons is prohibited. It should be deleted immediately from your system. Presence Technology reserves the right to take legal action against any persons unlawfully gaining access to the content of any external message it has emitted.* *For additional information, please visit our website **www.presenceco.com <http://www.presenceco.com/>*

3 4

Re: [Freeswitch-users] 486 busy here adding Normal Clearing
by fs＠voice2net.ca 08 Nov '16

08 Nov '16

Can anyone tell me if it is possible to correct this issue. I am using a freeswitch as a gateway to sereval carriers for routing traffic. When I receive a 486 Busy Here without the Reason Element, when the freeswitch responds to the originator, it adds in a Reason, 16 Normal clearing. Our servers on the other end are deciphering this as the wrong cause, it would be great to either remove the Normal Clearing message or have it reflect 17, user busy. SIP/2.0 486 Busy Here Via: SIP/2.0/UDP xx.xx.xx.xx;received=xx.xx.xx.xx;branch=z9hG4bKSB2rZ17eQ3ryK;rport=5080 From: "temp" <sip:2222223333@xx.xx.xx.xx>;tag=N5aNrFte8N6SS To: <sip:14166359251@xx.xx.xx.xx:5060>;tag=SDhv1pb99-400a14cd+1+69160089+a381d68 0 Call-ID: d9d1f48b-1fd7-1235-a9ad-00002d3a2463 CSeq: 98941824 INVITE Server: DC-SIP/2.0 Content-Length: 0 Retry-After: 1 SIP/2.0 486 Busy Here Via: SIP/2.0/UDP xx.xx.xx.xx;rport=5060;branch=z9hG4bKypUUHeUU1gK7j Max-Forwards: 69 From: "temp" <sip:2222223333@xx.xx.xx.xx>;tag=Z5pjZ2QtN3KpQ To: <sip:14166359251@domain.com>;tag=SFZ9Bv2NpD7jK Call-ID: d9d097a2-1fd7-1235-038a-00163eef87f4 CSeq: 98941824 INVITE User-Agent: FreeSWITCH-mod_sofia/1.4.26+git~20160205T175853Z~ca9207aa32~64bit Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: timer, path, replaces Allow-Events: talk, hold, conference, refer Reason: Q.850;cause=16;text="NORMAL_CLEARING" Content-Length: 0 X-FS-Display-Name: 14166359251 X-FS-Display-Number: sip:14166359251@domain.com P-Asserted-Identity: "14166359251" <sip:14166359251@domain.com> Darcy Primrose octoberlogo3 http://www.voice2net.ca <http://www.voice2net.ca/> darcy(a)voice2net.ca 200 Prescott Street Kemptville, ON K0G 1J0 Contact <http://voice2net.ca/Contact.html> via Phone

2 2

Freeswitch WebRTC with Nginx
by Murugan Pandian 08 Nov '16

08 Nov '16

HI, I am using nginx for load balancing behind my freeswitch ,My WebRTC client SIPJS,i can able to register with my freeswitch and i can make outbound call successfully but when i cant able to receive any incoming call,if i register directly with freeswitch means without nginx i can make and receive call but when i register using nginx i am facing this issue(i cant able to receive call ).

2 1

Conference DID Testing help
by Kathleen King 08 Nov '16

08 Nov '16

Hello, We are doing some testing and want to make sure the DIDs to call into the public 888 conference are working. The team has been able to test the US number, but we need your help to test the international DIDs. Please take a moment and call to see if the DID for your region is working and reply to this email to let us know. Thank-you! Australia +61-7-3188-7519 Thanks to Jay Binks - NetSIP.com.au <http://www.netsip.com.au/> Canada +1-438-800-0531 Thanks to NG Communications <http://www.ngcommunications.com/> France +33-975-181-606 Thanks to NG Communications <http://www.ngcommunications.com/> Germany +49-228-9293-9009 Thanks to Yiftach at ChooChee Germany +49-2373-913-4009 Thanks to einfachVoIP.de <http://www.einfachvoip.de/> Ireland +353-1-687-9001 Thanks to Ziron <http://www.ziron.com/> Israel +972-2-372-0394 Thanks to Avi Marcus - BestFone.com <http://bestfone.com/?israel-wholesale> Netherlands +31-858-880-387 Thanks to NG Communications <http://www.ngcommunications.com/> New Zealand +64-4-887-1401 Thanks to Ziron <http://www.ziron.com/> Portugal +351-300505224 Thanks to Finesource <http://www.finesource.eu/en/> South Africa +27-87-8204656 Thanks to Othos Telecom <http://www.othos.co.za/> Spain +34-91-290-12-71 Thanks to SIPtize <http://www.siptize.com/> UK +44-330-320-0105 Thanks to Ziron <http://www.ziron.com/> UK +44-1904-201-313 Thanks to ukddi.com <http://www.ukddi.com/> (Routed by Steven Ayre) UK +44-203-298-5931 Thanks to ukddi.com <http://www.ukddi.com/> (Routed by Avi Marcus) USA +1-919-386-9900 Kathleen King FreeSWITCH Public Relations Office: +1-213-286-0400 Mobile: +1-703-859-3757 http://freeswitch.org

10 10

Re: [Freeswitch-users] Conference DID Testing help
by DanB 07 Nov '16

07 Nov '16

Kathleen, Germany numbers appear to be both down, first pointed towards some other IVR, second reporting not available. BR DanB Germany +49-228-9293-9009 Thanks to Yiftach at ChooChee Germany +49-2373-913-4009 Thanks to<http://www.einfachvoip.de/> einfachVoIP.de

1 0

Verso installation
by Sergey Safarov 07 Nov '16

07 Nov '16

I has installed verto commucator on my server and point to websocker of FreeSwith team conference server. All works as expected. Then I change websocker URL to my FreeSwith server. Server has trusted certificate. I dial 3000 number, then connects to conference, can send/accept audio/video but cannot see who is connected to conference. Also I cannot send chat messages. I cannot find related error in browser console, FS log also not contain errors. Could you advise what is required to fix?

2 3

Jitter during on-hold
by Miroslav Levanic 07 Nov '16

07 Nov '16

Hello, I'm trying to play from file when other party is set on-hold. reINVITE sent by FreeSwitch contains sendonly attribute which opens possibility that FreeSwitch can play something to other end although other party is on-hold. I've used modified switch_ivr_play_file() function which by default prevents sending rtp packets to other side when call is on-hold. I've encountered rtp stream issue causing distorted audio due to dropped packets on the caller end. Codec used is G.711 mulaw 8kHz and ptime is 20ms accepted on both side, FreeSwitch and softphone. Both endpoints are located in the local LAN. Wireshark rtp analysis shows that when call is not on-hold, packets comes in interval of 20ms as expected. But when the call is set on-hold, average delta time between packets is 21ms, causing dropping packet every second (1ms extra time multiplied by 50 packets per second) with jitter buffer set to 50ms in Wireshark. Setting "auto-jitterbuffer-msec" parameter in sofia did not help. Is there a serious reason why I cannot use switch_ivr_play_file() during on-hold and what could cause jitter only during on-hold period? When call is retrieved from hold, jitter disappears and audio is good again. Thanks, Miro

2 4

Enable H264 Video
by Jürgen Wendler 07 Nov '16

07 Nov '16

Hello everyone, i've found some amazaing articles about FS and so i thought i can give it a try. So I followed instructions in confluenca and got a simple running fs server with mod_verto which is capable of some basic webrtc. Really nice. Now I want to join this room (which is the basic 3500 room with the default video-mcu-profile) with some external h323 device. So I compiled ptlib and opalvoip and finally mod_opal and created a h323 listener. When I call the ip + room number with an external device (polycom, sony) via h323 I get voice only connections, log says the following: 2016-09-12 12:26:17.140849 [WARNING] mod_opal.cpp:750 {Opal Answer:12170,0000000000001} mod_opal Could not match FS codec H263-2000@90000 (pt=121) to an OPAL media format. 2016-09-12 12:26:17.140849 [WARNING] mod_opal.cpp:750 {Opal Answer:12170,0000000000001} mod_opal Could not match FS codec H263-1998@90000 (pt=115) to an OPAL media format. 2016-09-12 12:26:17.140849 [WARNING] mod_opal.cpp:750 {Opal Answer:12170,0000000000001} mod_opal Could not match FS codec VP8@90000 (pt=99) to an OPAL media format. 2016-09-12 12:26:17.140849 [WARNING] mod_opal.cpp:750 {Opal Answer:12170,0000000000001} mod_opal Could not match FS codec VP9@90000 (pt=99) to an OPAL media format. 2016-09-12 12:26:17.160836 [WARNING] mod_opal.cpp:750 {Opal Answer:12170,0000000000001} mod_opal Could not match FS codec H263@90000 (pt=34) to an OPAL media format. 2016-09-12 12:26:17.160836 [WARNING] mod_opal.cpp:750 {Opal Answer:12170,0000000000001} mod_opal Could not match FS codec LPC@8000 (pt=7) to an OPAL media format. 2016-09-12 12:26:17.160836 [WARNING] mod_opal.cpp:750 {Opal Answer:12170,0000000000001} mod_opal Could not match FS codec PROXY-VID@90000 (pt=31) to an OPAL media format. 2016-09-12 12:26:17.160836 [WARNING] mod_opal.cpp:750 {Opal Answer:12170,0000000000001} mod_opal Could not match FS codec H261@90000 (pt=31) to an OPAL media format. 2016-09-12 12:26:17.160836 [WARNING] mod_opal.cpp:750 {Opal Answer:12170,0000000000001} mod_opal Could not match FS codec H264@90000 (pt=97) to an OPAL media format. So I thought I should have a look about the compiled codecs. I activated mod_opal and mod_h26x in modules.conf but no succes. Log always says: 2016-09-12 12:26:17.160836 [INFO] h323.cxx:3996 {Opal Answer:12170,0000000000001} H323 SetLocalCapabilities: GSM-AMR,G.723.1,G.729,GSM-06.10,G.711-uLaw-64k,G.711-ALaw-64k,T.38,UserInput/hookflash,UserInput/basicString,UserInput/dtmf I've tried to change profile or the conference / dialplan, event set "absolute_codec_string" in dialplan/default.xml but I think I am missing something. Could anyone point me in the right direction where I can "enable" h263++ or h264 video capabilitys for an external h323 device / call via mod_opal? System is debian 8, FS and ptlib / mod_opal are checked out from git / cvs. Best regards, Juergen

6 11

Ignore RTP until Remote Address Confirmed
by Colin Morelli 06 Nov '16

06 Nov '16

Hello, I'm trying to fix some issues with communication on devices that are on NAT64 networks. In this case, I'm using ICE to generate candidates for the local device before sending an INVITE to FS; however, because the device is on (what it perceives to be) an IPv6-only network, and FS is on an IPv4-only network, the device simply can't generate create a candidate that would be accepted by FS. FS essentially rejects all IPv6 candidates and then rejects the call with a 488. However, if I add a random IPv4 address in the INVITE that is accepted by the apply-candidate-acl in FS, then once the device starts sending RTP data to Freeswitch, auto-adjust kicks in and everything is fine. In other words, the two devices *can* communicate with each other, but based on the ICE candidates provided by the local device, they don't think that they can. So, my question is, is there any "safe" bogus IP I can provide to FS that will essentially allow the call to start, knowing it will just blackhole any RTP data for that client until auto-adjust has found the proper destination? Any other suggestions to solve this? (Besides using STUN, which - even if used - is still only going to generate an IP address with almost certainly an invalid port) Best, Colin

1 0