- FreeSWITCH-users - FreeSWITCH Mailing Lists

Changing loglevel / enable sip trace on sip profiles
by mbo 13 Apr '15

13 Apr '15

Hello, I just changed (decreased) the loglevel and disabled sip trace in a sip profile config on FS 1.4.15 and performed sofia profile <profilename> rescan, but the loglevel dis not change and the sip trace is still active. When I start and stop the profile the changes are active. Why is „rescan“ not sufficient for those changes, or is it a bug? Thanks and Regards Markus

2 1

FreeSWITCH Week in Review (Master Branch) April 4th-10th
by Ken Rice 13 Apr '15

13 Apr '15

New Post on freeswitch.org from Kathleen check it out at http://freeswitch.org/freeswitch-week-in-review-master-branch-april-4th-10t… FreeSWITCH Week in Review (Master Branch) April 4th-10th Hello, again. This passed week in the FreeSWITCH master branch we had 6 commits. More feature commits went in toward mod_amqp this week. The accuracy of the logging was tweaked and improved, the command configuration was expanded, and the command binding key configuration was added. Join us on Wednesdays at 12:00 CT for some more FreeSWITCH fun! And head over to freeswitch.com to learn more about FreeSWITCH support. New features that were added: FS-7430 Add variable expansion to mod_xml_ldap FS-7060 Improve the accuracy of logging and handling of producer reconnect attempt interval for mod_amqp, expand configuration for amqp command configuration, and add configuration of the amqp command binding key Improvements in build system, cross platform support, and packaging: FS-7426 Fix the debian packaging for wheezy when the newer librabbitmq1 package isn’t installed

3 2

Auto answer for FreeTDM analog_em
by DAVIS, JONATHAN P. (KSC-ITD10) 13 Apr '15

13 Apr '15

Hey all, I am creating a WebRTC interface for work that interfaces to our legacy intercom system. I have set up my span in FreeTDM as analog_em and have green lights all around for signaling. I need to be able to originate the DS0 into a conference, but attempting to do so causes the extension to ring for about 30 sec before finally going from DIALING to BUSY. I believe the endpoint isn't being answered. I had this working successfully in Asterisk by setting immediate=yes in chan_dahdi.conf. I found sip_auto_answer, and immediate_accept in the open_r2 module, but nothing for analog_em. I have nothing that would let me configure this on my conferencing switch, but believe there must be a way to configure it from my side as Asterisk could do it. Any help is greatly appreciated. Thanks, JD Some info: Freetdm.conf: [span zt OIS] trunk_type => EM em-channel => 1-24 freetdm.conf.xml: <analog_em_spans> <span name="OIS"> <param name="dialplan" value="XML"/> <param name="context" value="basic"/> </span> </analog_em_spans> Dialplan: <context name="basic"> <extension name="conf1"> <condition field="destination_number" expression="^200$"> <app name="answer"/> <action application="conference" data="conf1"/> </condition> </extension> </context> freeswitch@internal> ftdm list +OK span: 1 (OIS) type: analog_em physical_status: ok signaling_status: UP chan_count: 24 dialplan: XML context: basic dial_regex: fail_dial_regex: hold_music: analog_options: none freeswitch@internal> ftdm dump 1 1 span_id: 1 chan_id: 1 physical_span_id: 1 physical_chan_id: 1 physical_status: ok physical_status_red: 0 physical_status_yellow: 0 physical_status_rai: 0 physical_status_blue: 0 physical_status_ais: 0 physical_status_general: 0 signaling_status: UP type: EM state: DOWN last_state: DOWN txgain: 0.00 rxgain: 0.00 cid_date: cid_name: cid_num: ani: aniII: dnis: rdnis: cause: NONE session: (none) -- No state history - freeswitch@internal> bgapi originate freetdm/1/1 200 +OK Job-UUID: 603fb938-e214-11e4-97e6-43b5b7de6600 freeswitch@internal> 2015-04-13 15:36:26.979819 [DEBUG] switch_ivr_originate.c:2100 Parsing global variables 2015-04-13 15:36:26.979819 [INFO] ftmod_zt.c:671 Setting echo cancel to 64 taps for 1:1 2015-04-13 15:36:26.979819 [DEBUG] mod_freetdm.c:403 Set codec PCMU 20ms 2015-04-13 15:36:26.979819 [DEBUG] mod_freetdm.c:1251 Connect outbound channel FreeTDM/1:1/ 2015-04-13 15:36:26.979819 [NOTICE] switch_channel.c:1055 New Channel FreeTDM/1:1/ [603fc6f8-e214-11e4-97e8-43b5b7de6600] 2015-04-13 15:36:26.979819 [DEBUG] mod_freetdm.c:1260 (FreeTDM/1:1/) State Change CS_NEW -> CS_INIT 2015-04-13 15:36:26.979819 [DEBUG] switch_core_session.c:1396 Send signal FreeTDM/1:1/ [BREAK] 2015-04-13 15:36:26.979819 [DEBUG] mod_freetdm.c:1279 Attached session 603fc6f8-e214-11e4-97e8-43b5b7de6600 to channel 1:1 2015-04-13 15:36:26.979819 [DEBUG] ftmod_zt.c:754 [s1c1][1:1] Channel is now offhook 2015-04-13 15:36:26.979819 [DEBUG] ftmod_analog_em.c:168 [s1c1][1:1] Changed state from DOWN to DIALING 2015-04-13 15:36:26.979819 [DEBUG] ftmod_analog_em.c:528 ANALOG EM CHANNEL thread starting. 2015-04-13 15:36:26.979819 [INFO] ftmod_zt.c:671 Setting echo cancel to 64 taps for 1:1 2015-04-13 15:36:26.999821 [DEBUG] ftdm_io.c:3395 [s1c1][1:1] Enabled software DTMF detector 2015-04-13 15:36:26.999821 [DEBUG] ftmod_analog_em.c:565 [s1c1][1:1] IO Interval: 20 2015-04-13 15:36:26.999821 [DEBUG] ftmod_analog_em.c:708 [s1c1][1:1] Completed state change from DOWN to DIALING in 1 ms 2015-04-13 15:36:26.999821 [DEBUG] ftmod_analog_em.c:712 Executing state handler on 1:1 for DIALING 2015-04-13 15:36:27.479818 [DEBUG] switch_core_state_machine.c:472 (FreeTDM/1:1/) Running State Change CS_INIT 2015-04-13 15:36:27.479818 [DEBUG] switch_core_state_machine.c:512 (FreeTDM/1:1/) State INIT 2015-04-13 15:36:27.479818 [DEBUG] mod_freetdm.c:430 (FreeTDM/1:1/) State Change CS_INIT -> CS_ROUTING 2015-04-13 15:36:27.479818 [DEBUG] switch_core_session.c:1396 Send signal FreeTDM/1:1/ [BREAK] 2015-04-13 15:36:27.479818 [DEBUG] switch_core_state_machine.c:512 (FreeTDM/1:1/) State INIT going to sleep 2015-04-13 15:36:27.479818 [DEBUG] switch_core_state_machine.c:472 (FreeTDM/1:1/) Running State Change CS_ROUTING 2015-04-13 15:36:27.479818 [DEBUG] switch_core_state_machine.c:528 (FreeTDM/1:1/) State ROUTING 2015-04-13 15:36:27.479818 [DEBUG] mod_freetdm.c:453 FreeTDM/1:1/ CHANNEL ROUTING 2015-04-13 15:36:27.479818 [DEBUG] switch_ivr_originate.c:67 (FreeTDM/1:1/) State Change CS_ROUTING -> CS_CONSUME_MEDIA 2015-04-13 15:36:27.479818 [DEBUG] switch_core_session.c:1396 Send signal FreeTDM/1:1/ [BREAK] 2015-04-13 15:36:27.479818 [DEBUG] switch_core_state_machine.c:528 (FreeTDM/1:1/) State ROUTING going to sleep 2015-04-13 15:36:27.479818 [DEBUG] switch_core_state_machine.c:472 (FreeTDM/1:1/) Running State Change CS_CONSUME_MEDIA 2015-04-13 15:36:27.479818 [DEBUG] switch_core_state_machine.c:547 (FreeTDM/1:1/) State CONSUME_MEDIA 2015-04-13 15:36:27.479818 [DEBUG] switch_core_state_machine.c:547 (FreeTDM/1:1/) State CONSUME_MEDIA going to sleep 2015-04-13 15:36:27.979820 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:28.979821 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:29.979820 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:30.979820 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:31.979820 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:32.979818 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:33.979821 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:34.979821 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:35.979821 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:36.979821 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:37.979820 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:38.979821 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:39.979819 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:40.979819 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:41.979819 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:42.979819 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:43.979820 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:44.979820 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:45.979820 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:46.979820 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:47.979820 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:48.979819 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:49.979818 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:50.979820 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:51.979819 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:52.979820 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:53.979819 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:54.979820 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:55.979820 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:56.979820 [DEBUG] ftmod_analog_em.c:628 [s1c1][1:1] CAS bits: 0x0 2015-04-13 15:36:56.999820 [DEBUG] ftmod_analog_em.c:620 [s1c1][1:1] Changed state from DIALING to BUSY 2015-04-13 15:36:57.019820 [DEBUG] ftmod_analog_em.c:708 [s1c1][1:1] Completed state change from DIALING to BUSY in 20 ms 2015-04-13 15:36:57.019820 [DEBUG] ftmod_analog_em.c:712 Executing state handler on 1:1 for BUSY 2015-04-13 15:36:57.019820 [DEBUG] ftmod_analog_em.c:789 [s1c1][1:1] Changed state from BUSY to DOWN 2015-04-13 15:36:57.039820 [DEBUG] ftmod_analog_em.c:708 [s1c1][1:1] Completed state change from BUSY to DOWN in 20 ms 2015-04-13 15:36:57.039820 [DEBUG] ftmod_analog_em.c:712 Executing state handler on 1:1 for DOWN 2015-04-13 15:36:57.039820 [DEBUG] mod_freetdm.c:2262 got FXO sig 1:1 [STOP] 2015-04-13 15:36:57.039820 [NOTICE] mod_freetdm.c:2282 Hangup FreeTDM/1:1/ [CS_CONSUME_MEDIA] [NORMAL_CIRCUIT_CONGESTION] 2015-04-13 15:36:57.039820 [DEBUG] switch_channel.c:3222 Send signal FreeTDM/1:1/ [KILL] 2015-04-13 15:36:57.039820 [DEBUG] switch_core_session.c:1396 Send signal FreeTDM/1:1/ [BREAK] 2015-04-13 15:36:57.039820 [DEBUG] ftmod_zt.c:765 [s1c1][1:1] Channel is now onhook 2015-04-13 15:36:57.039820 [DEBUG] switch_core_state_machine.c:472 (FreeTDM/1:1/) Running State Change CS_HANGUP 2015-04-13 15:36:57.039820 [DEBUG] ftdm_io.c:3194 [s1c1][1:1] DTMF debug is already disabled 2015-04-13 15:36:57.039820 [DEBUG] ftdm_io.c:3226 [s1c1][1:1] No need to disable input dump 2015-04-13 15:36:57.039820 [DEBUG] ftdm_io.c:3257 [s1c1][1:1] No need to disable output dump 2015-04-13 15:36:57.039820 [DEBUG] ftdm_io.c:6873 Cleared call with id 2 2015-04-13 15:36:57.039820 [DEBUG] ftdm_io.c:2999 [s1c1][1:1] channel done 2015-04-13 15:36:57.039820 [DEBUG] ftmod_analog_em.c:993 ANALOG EM CHANNEL thread ended. 2015-04-13 15:36:57.039820 [DEBUG] switch_core_state_machine.c:735 (FreeTDM/1:1/) Callstate Change DOWN -> HANGUP 2015-04-13 15:36:57.039820 [DEBUG] switch_core_state_machine.c:737 (FreeTDM/1:1/) State HANGUP 2015-04-13 15:36:57.039820 [DEBUG] mod_freetdm.c:544 [1:1] FreeTDM/1:1/ CHANNEL HANGUP ENTER 2015-04-13 15:36:57.039820 [DEBUG] mod_freetdm.c:569 Device [1:1] is no longer attached to FreeTDM/1:1/ 2015-04-13 15:36:57.039820 [DEBUG] mod_freetdm.c:643 [1:1] FreeTDM/1:1/ CHANNEL HANGUP EXIT 2015-04-13 15:36:57.039820 [DEBUG] switch_core_state_machine.c:60 FreeTDM/1:1/ Standard HANGUP, cause: NORMAL_CIRCUIT_CONGESTION 2015-04-13 15:36:57.039820 [DEBUG] switch_core_state_machine.c:737 (FreeTDM/1:1/) State HANGUP going to sleep 2015-04-13 15:36:57.039820 [DEBUG] switch_core_state_machine.c:504 (FreeTDM/1:1/) State Change CS_HANGUP -> CS_REPORTING 2015-04-13 15:36:57.039820 [DEBUG] switch_core_session.c:1396 Send signal FreeTDM/1:1/ [BREAK] 2015-04-13 15:36:57.039820 [DEBUG] switch_core_state_machine.c:472 (FreeTDM/1:1/) Running State Change CS_REPORTING 2015-04-13 15:36:57.039820 [DEBUG] switch_core_state_machine.c:823 (FreeTDM/1:1/) State REPORTING 2015-04-13 15:36:57.039820 [DEBUG] switch_core_state_machine.c:104 FreeTDM/1:1/ Standard REPORTING, cause: NORMAL_CIRCUIT_CONGESTION 2015-04-13 15:36:57.039820 [DEBUG] switch_core_state_machine.c:823 (FreeTDM/1:1/) State REPORTING going to sleep 2015-04-13 15:36:57.039820 [DEBUG] switch_core_state_machine.c:498 (FreeTDM/1:1/) State Change CS_REPORTING -> CS_DESTROY 2015-04-13 15:36:57.039820 [DEBUG] switch_core_session.c:1396 Send signal FreeTDM/1:1/ [BREAK] 2015-04-13 15:36:57.039820 [DEBUG] switch_core_session.c:1623 Session 2 (FreeTDM/1:1/) Locked, Waiting on external entities 2015-04-13 15:36:57.059821 [DEBUG] switch_ivr_originate.c:3720 Originate Resulted in Error Cause: 34 [NORMAL_CIRCUIT_CONGESTION] 2015-04-13 15:36:57.059821 [NOTICE] switch_core_session.c:1641 Session 2 (FreeTDM/1:1/) Ended 2015-04-13 15:36:57.059821 [NOTICE] switch_core_session.c:1645 Close Channel FreeTDM/1:1/ [CS_DESTROY] 2015-04-13 15:36:57.059821 [DEBUG] switch_core_state_machine.c:626 (FreeTDM/1:1/) Running State Change CS_DESTROY 2015-04-13 15:36:57.059821 [DEBUG] switch_core_state_machine.c:636 (FreeTDM/1:1/) State DESTROY 2015-04-13 15:36:57.059821 [DEBUG] switch_core_state_machine.c:111 FreeTDM/1:1/ Standard DESTROY 2015-04-13 15:36:57.059821 [DEBUG] switch_core_state_machine.c:636 (FreeTDM/1:1/) State DESTROY going to sleep

1 0

ClueCon – Registration and Call for Speakers NOW OPEN!
by Ken Rice 13 Apr '15

13 Apr '15

New Post on freeswitch.org from anthm check it out at http://freeswitch.org/cluecon-registration-and-call-for-speakers-now-open/ ClueCon – Registration and Call for Speakers NOW OPEN! ClueCon Call for Speakers and Registration are both NOW OPEN. Visit our site and click the call for speakers link at the top of the page to reserve a spot now!

1 0

KVM vs. XEN virtualization
by Stanislav Sinyagin 13 Apr '15

13 Apr '15

hi, Here are some test results which might be interesting: I've set up a test FreeSWITCH server at digitalocean (they use KVM), and originated test calls to some ITSP accounts. Each call played a test sound file (voice samples from ITU: http://www.itu.int/net/itu-t/sigdb/genaudio/AudioForm-g.aspx?val=1000050 ), and on the receiving end another FreeSWITCH server was recording the received session. The receiving server was on a XEN VM. Both servers talked G711 to their corresponding ITSP accounts. Then I compared the source audio and received audio in Audacity editor. The tests showed that the received voice wave shifts 20ms from the original sound every few seconds, randomly back and forward. This skewing was always present, regardless of ITSP and time of day. Then I moved the sending server to a XEN VM, and the waves appeared almost perfectly synchronized (there was a 5ms skew in one test, and I guess it's related to transcoding buffer, as the sound was obviously transcoded). The effect was always visible with a 30-second sample, and I also made additional tests with 2-minute samples. It would also be interesting to test this from a VmWare VM. If someone wants to run such a test, feel free to contact me directly. cheers, stan

15 58

Freeswitch / FusionPBX T.38 Fax
by Bill Ross 13 Apr '15

13 Apr '15

Hi; I am attempting to get T38 Fax working between two FS/FusionPBX installations using mod_spandsp. I am unable to get into T.38 mode, T.30 used, successful fax. Note that zrtp is disabled for fax calls, due to T38 udpl (not rtp media) incompatibility Thanks Brian West!: "T.38 Fax takes place over UDPTL, There for it can NOT be encrypted as there was never really a standard for doing so." Details (both FS's): SIP Provider: freephoneline.ca (claims T38 capable) freeswitch - 1.4.18 x86_64 Topology: FS#1: rossco.org, using FusionPBX web GUI to send fax FS#2:rossco.duckdns.org, using spandsp extension to receive fax (spandsp txfax, x1020)FS#1 -> cloud -> FS#2(spandsp rxfax, x9000) Key variables for fax sender (FS#1), during call: $domain= rossco.org Spandsp Fax extension: 1020 t38_passthru = false zrtp_secure_media = false fax_enable_t38 = true fax_enable_t38_request = true fax_use_ecm = off inbound-late-negotiation = true ignore_early_media = false Key variables for fax receiver (FS#2), during call: $domain= rossco.duckdns.org Spandsp Fax extension: 9000 t38_passthru = false zrtp_secure_media = false fax_enable_t38 = true fax_enable_t38_request = true fax_use_ecm = off inbound-late-negotiation = true ignore_early_media = false Full Logs w/siptrace: Sender(rossco.org): https://pastebin.freeswitch.org/24115 Receiver(rossco.duckdns.org): https://pastebin.freeswitch.org/24116 Note that the SDP's are correct for T38: 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 v=0 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 o=FreeSWITCH 1428750600 1428750602 IN IP4 198.48.238.130 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 s=FreeSWITCH 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 c=IN IP4 198.48.238.130 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 t=0 0 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 m=image 16448 udptl t38 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxVersion:0 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38MaxBitRate:14400 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxFillBitRemoval 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxRateManagement:transferredTCF 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxMaxBuffer:2000 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxMaxDatagram:400 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxUdpEC:t38UDPRedundancy Questions: 1 - According to my interpretation of logs, T38 is not negotiated, despite T38 SDP's 2 - What am I missing? Thanks; Bill Ross

2 4

FEC feature in mod_opus
by Kamil Nigmatullin 13 Apr '15

13 Apr '15

Hello. Anybody from developers could please clarify if FreeSWITCH uses Forward Error Correction feature in opus codec? We actually are not a specialists in C and cannot fully understand how decode function works in 414 line. According to opus documentation decode function is called with special flag if previous packet is lost in order to call fec feature. In mod_opus it is hard to say for me as i don't see i or i+1 packets. Thanks

1 0

Bounty
by Andre DeMattia 13 Apr '15

13 Apr '15

How do I create a bounty for a bug in FS? Thanks

3 2

Freeswitch video conference (broadcast)
by Adam Ben-Ayoun 13 Apr '15

13 Apr '15

Hi guys, I have a conference configured with conference-flags and member-flags set to video-bridge and I am using SIPjs as a WebRTC client to test the setup. My goal is to broadcast from one client to all the rest. This seems to work fine with 2 clients, meaning, one client gets video from the other client, now, when I am adding a 3rd client, it doesn't get video (verified with chrome://webrtc-internals). Any idea? Am I missing something? Thanks! Adam

2 1

Freeswitch basic VP8 passthrough
by Adam Ben-Ayoun 13 Apr '15

13 Apr '15

Hi guys, I am trying to setup a simple WebRTC video conference using VP8 with mod_conference, while audio conferencing works fine, I am not able to setup a video conference using clients like SIPjs, basically, I am opening 2 clients and expect to see video streaming to each side. I did the following: 1. Added the following config to my conference profile in conference.conf.xml: <param name="conference-flags" value="video-bridge"/> <param name="member-flags" value="video-bridge"/> 2. Added VP8 to vars.xml: <X-PRE-PROCESS cmd="set" data="global_codec_prefs=iSAC@16000h ,VP8,OPUS,G722,PCMU,PCMA,GSM"/> Any idea? P.S The client seem to pass the video params correctly in the SDP, but Freeswitch still responses with the following SDP: v=0 o=FreeSWITCH 1428032845 1428032846 IN IP4 X.X.X.X s=FreeSWITCH c=IN IP4 52.1.148.244 t=0 0 a=msid-semantic: WMS QyrjMP4wDDWQeK1hU3mBsJvovhMMWjKD m=audio 23118 UDP/TLS/RTP/SAVPF 111 126 106 a=rtpmap:111 opus/48000/2 a=fmtp:111 useinbandfec=1; minptime=10 a=rtpmap:126 telephone-event/8000 a=rtpmap:106 CN/8000 a=ptime:20 a=fingerprint:sha-256 83:F4:57:6D:F9:40:C7:E8:28:6D:59:AE:5F:08:23:3E:9E:17:1E:2F:D8:A9:D5:E7:DB:13:92:B5:DE:4A:66:CA a=rtcp-mux a=rtcp:23118 IN IP4 X.X.X.X a=ssrc:3173617819 cname:I1MkHHGaasQf3InN a=ssrc:3173617819 msid:QyrjMP4wDDWQeK1hU3mBsJvovhMMWjKD a0 a=ssrc:3173617819 mslabel:QyrjMP4wDDWQeK1hU3mBsJvovhMMWjKD a=ssrc:3173617819 label:QyrjMP4wDDWQeK1hU3mBsJvovhMMWjKDa0 a=ice-ufrag:CzeU8A9uHL6uVHXu a=ice-pwd:zzF67b78uOeomr1PR6zQwzb4 a=candidate:8368394426 1 udp 659136 X.X.X.X 23118 typ host generation 0 m=video 0 UDP/TLS/RTP/SAVPF 19 Thanks! Adam

2 3