[Freeswitch-users] T.38 gateway and peer/self
Brian West
brian at freeswitch.org
Mon Feb 27 18:21:35 MSK 2017
http://lists.freeswitch.org/pipermail/freeswitch-users/2017-January/124459.html
On Mon, Feb 27, 2017 at 9:18 AM, Brian West <brian at freeswitch.org> wrote:
> Also there was a small logic bug in 1.6.14 that was fixed in FS-9943
> 6ff51458e25c2759e2e4d39965174604007a0cc7
>
> We would 488 the reinvite, and switch to udptl mode anyway. Thats fixed
> in 1.6.15. Or worked around in 1.6.14 by setting fax_enable_t38=true in
> vars.xml
>
> /b
>
>
> On Mon, Feb 27, 2017 at 9:15 AM, Brian West <brian at freeswitch.org> wrote:
>
>> I need to point out that there was a slight behavior change in fax
>> handling in 1.6.14+, It was related to 488 handling, We do not now by
>> default accept a t.38 re-invite, You must set fax_enable_t38=true, or we
>> will 488 the re-invite, and some devices do not handle this well. You can
>> restore the previous default behavior by setting fax_enable_t38=true in
>> vars.xml
>>
>> I had sent this out, the is the second time a behavior change notice has
>> gone out and very few have seen it.
>>
>> /b
>>
>>
>> On Mon, Feb 27, 2017 at 6:40 AM, Peter Steinbach <lists at telefaks.de>
>> wrote:
>>
>>> Hello Michael,
>>>
>>> I just updated a test machine with current Freeswitch from GIT. He I did
>>> not find any T.38 reinvite issue.
>>>
>>> Best regards
>>> Peter
>>>
>>>
>>>
>>> On 02/24/17 22:06, Michael Jerris wrote:
>>>
>>> If you have to switch to older free switch, that is a problem, we need
>>> to figure out exactly what is going on with current freeswitch or the issue
>>> will just never get fixed.
>>>
>>> Please lets look at what happens when its running on latest 1.6 release
>>> not older release and figure out how to get that working properly.
>>>
>>>
>>> On Feb 24, 2017, at 3:46 PM, Peter Steinbach <lists at telefaks.de> wrote:
>>>
>>> I finally found a solution, for those who are interested.
>>>
>>> - I switched back to old Freeswitch from Feb 2016, as new FS always
>>> answered with 488 on T.38 reinvite from the B-Leg
>>> - Then I implemented the following (coding outside of FS with
>>> XML-Curl)
>>> - When call is done with T.38 on boths legs, do not anything
>>> special, just use a minimum dialplan
>>> - if B-leg does not answer with T.38, this normally fails in my
>>> environment. I then store a Value NOT38 to the dialled number for 1/2 hour
>>> in a cache
>>> - when then the fax machine is retrying the same call, I lookup
>>> the cache and return another dialplan with T38 gateway (self) enabled
>>>
>>> That way, pure T.38 calls work nicely, and calls with T.39 on the B-leg
>>> work on the second try.
>>> Hope this helps. At last here in Germany, we have to find some
>>> workarounds, as fax implementation on some carrier's side (to say the
>>> positive) does not improve.
>>>
>>> Best regards
>>> Peter
>>>
>>>
>>> On 02/24/17 14:29, Peter Steinbach wrote:
>>>
>>> Hello Brian,
>>>
>>> I just updated to latest GIT. Dialplan ist still
>>>
>>> Dialplan: sofia/internalvpn2/492927aaaaaa at 10.7.0.1 Action
>>> set(fax_enable_t38=true)
>>> Dialplan: sofia/internalvpn2/492927aaaaaa at 10.7.0.1 Action
>>> set(fax_enable_t38_request=true)
>>> Dialplan: sofia/internalvpn2/492927aaaaaa at 10.7.0.1 Action
>>> set(execute_on_answer=t38_gateway self)
>>> Dialplan: sofia/internalvpn2/492927aaaaaa at 10.7.0.1 Action ring_ready()
>>> Dialplan: sofia/internalvpn2/492927aaaaaa at 10.7.0.1 Action
>>> bridge(sofia/gateway/sip.provider.com/4940bbbbbbbbbbbbbbb at si
>>> p.provider.com)
>>>
>>> However the behavour changed now
>>> 2017-02-24 13:50:18.913016 [NOTICE] switch_ivr_originate.c:3633 Channel [
>>> sofia/internalvpn2/492927aaaaaa at 10.7.0.1] has been answered
>>> 2017-02-24 13:50:18.913016 [DEBUG] sofia.c:7241 Channel
>>> sofia/internalvpn2/492927aaaaaa at 10.7.0.1 entering state [completed][200]
>>> *EXECUTE sofia/internalvpn2/492927aaaaaa at 10.7.0.1
>>> <sofia/internalvpn2/492927aaaaaa at 10.7.0.1> t38_gateway(peer)*
>>> 2017-02-24 13:50:18.913016 [DEBUG] switch_core_media_bug.c:841 Attaching
>>> BUG to sofia/internalvpn2/492927aaaaaa at 10.7.0.1
>>> 2017-02-24 13:50:18.913016 [DEBUG] switch_channel.c:3780 (
>>> sofia/internalvpn2/492927aaaaaa at 10.7.0.1) Callstate Change RINGING ->
>>> ACTIVE
>>> 2017-02-24 13:50:18.913016 [DEBUG] switch_ivr_originate.c:3691 Originate
>>> Resulted in Success: [sofia/external/4940bbbbbbbbbb
>>> bbbbb at sip.provider.com]
>>> 2017-02-24 13:50:18.913016 [DEBUG] switch_ivr_bridge.c:1696 (
>>> sofia/external/4940bbbbbbbbbbbbbbb at sip.provider.com) State Change
>>> CS_CONSUME_MEDIA -> CS_EXCHANGE_MEDIA
>>> 2017-02-24 13:50:18.913016 [DEBUG] switch_core_state_machine.c:584 (
>>> sofia/external/4940bbbbbbbbbbbbbbb at sip.provider.com) Running State
>>> Change CS_EXCHANGE_MEDIA (Cur 2 Tot 10)
>>> 2017-02-24 13:50:18.913016 [DEBUG] switch_core_state_machine.c:653 (
>>> sofia/external/4940bbbbbbbbbbbbbbb at sip.provider.com) State
>>> EXCHANGE_MEDIA
>>> 2017-02-24 13:50:18.913016 [DEBUG] mod_sofia.c:645 SOFIA EXCHANGE_MEDIA
>>> 2017-02-24 13:50:18.953025 [DEBUG] sofia.c:7241 Channel
>>> sofia/internalvpn2/492927aaaaaa at 10.7.0.1 entering state [ready][200]
>>> 2017-02-24 13:50:18.953025 [DEBUG] switch_rtp.c:7021 Correct audio
>>> ip/port confirmed.
>>> 2017-02-24 13:50:19.333126 [DEBUG] switch_rtp.c:7021 Correct audio
>>> ip/port confirmed.
>>> 2017-02-24 13:50:19.333126 [DEBUG] switch_core_io.c:448 Setting BUG
>>> Codec PCMA:8
>>> 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:7241 Channel
>>> sofia/external/4940bbbbbbbbbbbbbbb at sip.provider.com entering state
>>> [received][100]
>>> 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:7251 Remote SDP:
>>> v=0
>>> o=HuaweiSoftX3000 1487923856 1487923858 IN IP4 185.39.xx.yy
>>> s=HuaweiSoftX3000
>>> c=IN IP4 185.39.xx.yy
>>> t=0 0
>>> m=image 16762 udptl t38
>>> a=T38FaxVersion:0
>>> a=T38MaxBitRate:14400
>>> a=T38FaxRateManagement:transferredTCF
>>> a=T38FaxMaxBuffer:500
>>> a=T38FaxMaxDatagram:500
>>> a=T38FaxUdpEC:t38UDPRedundancy
>>>
>>> *2017-02-24 13:50:26.013047 [DEBUG] switch_core_media.c:4634
>>> sofia/external/4940bbbbbbbbbbbbbbb at sip.provider.com
>>> <sofia/external/4940bbbbbbbbbbbbbbb at sip.provider.com> T38 REFUSE on request*
>>> 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:8152 Reinvite resulted in
>>> codec negotiation failure.
>>> *2017-02-24 13:50:26.033201 [DEBUG] sofia.c:7234 Channel
>>> sofia/external/4940bbbbbbbbbbbbbbb at sip.provider.com
>>> <sofia/external/4940bbbbbbbbbbbbbbb at sip.provider.com> skipping state
>>> [ready][488]*
>>> *2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2212 Fax Tone
>>> Detected. [peer][]*
>>> *2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2080
>>> sofia/internalvpn2/492927aaaaaa at 10.7.0.1
>>> <sofia/internalvpn2/492927aaaaaa at 10.7.0.1> starting gateway mode to
>>> sofia/external/4940bbbbbbbbbbbbbbb at sip.provider.com
>>> <sofia/external/4940bbbbbbbbbbbbbbb at sip.provider.com>*
>>> 2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2098 (
>>> sofia/internalvpn2/492927aaaaaa at 10.7.0.1) State Change CS_EXECUTE ->
>>> CS_RESET
>>> 2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2101 (
>>> sofia/external/4940bbbbbbbbbbbbbbb at sip.provider.com) State Change
>>> CS_EXCHANGE_MEDIA -> CS_RESET
>>> 2017-02-24 13:50:31.993164 [DEBUG] switch_core_media_bug.c:1208 Removing
>>> BUG from sofia/internalvpn2/492927aaaaaa at 10.7.0.1
>>> 2017-02-24 13:50:31.993164 [DEBUG] switch_ivr_bridge.c:792
>>> sofia/external/4940bbbbbbbbbbbbbbb at sip.provider.com ending bridge by
>>> request from write function
>>>
>>> In this case the sip provider comes back with T.38 reinvite and
>>> Freeswitch refuses it.
>>>
>>> As you mentioned that there are further settings and variables (I see
>>> e.g. "fax_t38_tx_reinvite_packet_count" in the release notes), I am
>>> wondering how I will neeed to set this up in order to have in one single
>>> dialplan:
>>>
>>> - send fax to SIP Provider(b leg) and have T.38 Re-invite from SIP
>>> Provider and pass it to a-leg
>>> - send fax to SIP Provider(b leg), do NOT receive T.38 Re-invite
>>> from SIP Provider and then do T.38 Gateway in FS.
>>>
>>>
>>> Best regards Peter
>>>
>>>
>>> On 02/24/17 08:52, Peter Steinbach wrote:
>>>
>>> Hello Brian,
>>>
>>> this Version of Freeswitch is from 09-Feb-2016. So I think, we should
>>> update.
>>>
>>> We need to cover 2 scenarios
>>>
>>> - send fax to SIP Provider(b leg) and have T.38 Re-invite from SIP
>>> Provider and pass it to a-leg
>>> - send fax to SIP Provider(b leg), do NOT receive T.38 Re-invite
>>> from SIP Provider and then do T.38 Gateway in FS.
>>>
>>> And no: We cannot foresee, whether the SIp provider will do T.38 and
>>> not. Here in Germany, the main incumbant PSTN provider did not implement
>>> T.38, so it depends on the target number and actual route, if this will be
>>> T.38 or not. A call to a certain number can be T.38 today and tomorrow it
>>> will be T.30 only, as some peering partner changed the routes in the
>>> meantime.
>>>
>>> Best regards
>>> Peter
>>>
>>>
>>> On 02/23/17 20:38, Brian West wrote:
>>>
>>> What revision of FreeSWITCH are you on? These behaviors have been
>>> solidified in 1.6.15, Sadly MOST of the details of how it all works is
>>> locked up in my head, I've just not had the time to write it all down and
>>> update the documentation. Can you outline all the scenarios you need to
>>> cover and if you have the ability know ahead of time which one needs to
>>> apply?
>>>
>>> /b
>>>
>>>
>>> On Thu, Feb 23, 2017 at 8:23 AM, Peter Steinbach <lists at telefaks.de>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> we have the following screnario
>>>>
>>>> - The caller, a local fax machine (Fax, ATA and Freeswitch) with
>>>> T.38, is behind a slow line so therefore T.38 is needed here
>>>> - a central Freeswitch fax server serves as a central gateway to
>>>> the SIP provider
>>>> - the SIP provider sometimes reinvites T.38 and sometimes not.
>>>> - In case, the SIP provider does NOT answer with T.38, the central
>>>> Freeswitch fax server shall act as a T.38 gateway and transcode between
>>>> local fax (T.38) and SIP provider (T.30)
>>>> - In case, the SIP provider does answer with T.38, the central
>>>> Freeswitch fax server shall pass T.38 to the local fax ,machine (T.38)
>>>>
>>>> How we set this up
>>>>
>>>> - according to the wiki we have a dialplan as follows: (this is
>>>> what CLI shows)
>>>>
>>>> Dialplan: sofia/internalvpn2/49274xxxxx at 10.7.0.1 Action
>>>> set(fax_enable_t38=true)
>>>> Dialplan: sofia/internalvpn2/49274xxxxx at 10.7.0.1 Action
>>>> set(fax_enable_t38_request=true)
>>>> Dialplan: sofia/internalvpn2/49274xxxxx at 10.7.0.1 Action
>>>> set(execute_on_answer=t38_gateway self)
>>>> Dialplan: sofia/internalvpn2/49274xxxxx at 10.7.0.1 Action ring_ready()
>>>> Dialplan: sofia/internalvpn2/49274xxxxx at 10.7.0.1 Action bridge(
>>>> sofia/gateway/sip.provider.com/xxxxxxxxxxxxxxx at sip.provider.com)
>>>>
>>>> In all profiles, we have
>>>> <param name="t38-passthru" value="true"/>
>>>>
>>>> In case, the SIP provider does NOT answer with T.38, it works. The
>>>> caller's side is reinvited with T.38, the SIP provider side is T.30
>>>>
>>>> What the problem is: When the SIP provider' side IS answering with
>>>> T.38, then (sometimes, when I send it via cli from the local freeswitch
>>>> near the sending fax machine, it works)
>>>>
>>>> - caller initiates a call
>>>> - call is bridged to the SIP provider' side
>>>> - we receive a T.38 Reinvite from the SIP provider' side
>>>> - Freeswitch sends Trying back to the the SIP provider' side
>>>> - Freeswitch logs: set(execute_on_answer=t38_gateway self)
>>>> - Freeswitch sends a T.38 Reinvite to the caller, establishes T.38
>>>> on this side.
>>>> - But the T.38 Reinvite from the SIP provider' side is not
>>>> answerered
>>>> - So the SIP provider' sidehangs up after 10 sec of timeout.
>>>>
>>>> What are we doing wrong here? Is it possible to act as a t.38
>>>> passthrough router and a T.38 gateway in the same dialplan?
>>>>
>>>>
>>>>
>>>> --
>>>> With kind regards
>>>> Peter Steinbach
>>>>
>>>> Telefaks Services GmbHmailto:lists <lists> (att) telefaks.de
>>>> Internet: www.telefaks.de
>>>>
>>>>
>>>> ____________________________________________________________
>>>> _____________
>>>> Professional FreeSWITCH Consulting Services:
>>>> consulting at freeswitch.org
>>>> http://www.freeswitchsolutions.com
>>>>
>>>> Official FreeSWITCH Sites
>>>> http://www.freeswitch.org
>>>> http://confluence.freeswitch.org
>>>> http://www.cluecon.com
>>>>
>>>> FreeSWITCH-users mailing list
>>>> FreeSWITCH-users at lists.freeswitch.org
>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/free
>>>> switch-users
>>>> http://www.freeswitch.org
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> *Brian West*
>>> brian at freeswitch.org
>>>
>>> *Twitter: @FreeSWITCH , @briankwest*
>>>
>>> http://www.freeswitchbook.com
>>> http://www.freeswitchcookbook.com
>>>
>>> Allison prompts for FreeSWITCH:
>>>
>>> *https://www.gofundme.com/allison-prompts-for-freeswitch*
>>> <https://www.gofundme.com/allison-prompts-for-freeswitch>
>>>
>>> Wish to schedule a meeting?
>>>
>>> http://app.timebridge.com/#/meet/freeswitch
>>>
>>> Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit:
>>> /r/freeswitch <https://www.reddit.com/r/freeswitch>
>>>
>>> *T:*+19184209001 <(918)%20420-9001> | *F:*+19184209002
>>> <(918)%20420-9002> | *M:*+1918424WEST (9378)
>>> *Skype:*briankwest
>>>
>>>
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services: consulting at freeswitch.orghttp://www.freeswitchsolutions.com
>>>
>>> Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon.com
>>>
>>> FreeSWITCH-users mailing listFreeSWITCH-users at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.freeswitch.org
>>>
>>>
>>>
>>> --
>>> With kind regards
>>> Peter Steinbach
>>>
>>> Telefaks Services GmbHmailto:lists <lists> (att) telefaks.de
>>> Internet: www.telefaks.de
>>>
>>>
>>>
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services: consulting at freeswitch.orghttp://www.freeswitchsolutions.com
>>>
>>> Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon.com
>>>
>>> FreeSWITCH-users mailing listFreeSWITCH-users at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.freeswitch.org
>>>
>>>
>>>
>>> --
>>> With kind regards
>>> Peter Steinbach
>>>
>>> Telefaks Services GmbHmailto:lists <lists> (att) telefaks.de
>>> Internet: www.telefaks.de
>>>
>>>
>>>
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services: consulting at freeswitch.orghttp://www.freeswitchsolutions.com
>>>
>>> Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon.com
>>>
>>> FreeSWITCH-users mailing listFreeSWITCH-users at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.freeswitch.org
>>>
>>>
>>>
>>> --
>>> With kind regards
>>> Peter Steinbach
>>>
>>> Telefaks Services GmbHmailto:lists <lists> (att) telefaks.de
>>> Internet: www.telefaks.de
>>>
>>> ____________________________________________________________
>>> _____________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://confluence.freeswitch.org
>>> http://www.cluecon.com
>>>
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>>
>>>
>>>
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services: consulting at freeswitch.orghttp://www.freeswitchsolutions.com
>>>
>>> Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon.com
>>>
>>> FreeSWITCH-users mailing listFreeSWITCH-users at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.freeswitch.org
>>>
>>>
>>>
>>> --
>>> With kind regards
>>> Peter Steinbach
>>>
>>> Telefaks Services GmbHmailto:lists <lists> (att) telefaks.de
>>> Internet: www.telefaks.de
>>>
>>>
>>> ____________________________________________________________
>>> _____________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://confluence.freeswitch.org
>>> http://www.cluecon.com
>>>
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>
>>
>>
>> --
>>
>> *Brian West*
>> brian at freeswitch.org
>>
>> *Twitter: @FreeSWITCH , @briankwest*
>>
>> http://www.freeswitchbook.com
>> http://www.freeswitchcookbook.com
>>
>> Allison prompts for FreeSWITCH:
>>
>> *https://www.gofundme.com/allison-prompts-for-freeswitch*
>> <https://www.gofundme.com/allison-prompts-for-freeswitch>
>>
>> Wish to schedule a meeting?
>>
>> http://app.timebridge.com/#/meet/freeswitch
>>
>> Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit:
>> /r/freeswitch <https://www.reddit.com/r/freeswitch>
>>
>> *T:*+19184209001 <(918)%20420-9001> | *F:*+19184209002 <(918)%20420-9002>
>> | *M:*+1918424WEST (9378)
>> *Skype:*briankwest
>>
>
>
>
> --
>
> *Brian West*
> brian at freeswitch.org
>
> *Twitter: @FreeSWITCH , @briankwest*
>
> http://www.freeswitchbook.com
> http://www.freeswitchcookbook.com
>
> Allison prompts for FreeSWITCH:
>
> *https://www.gofundme.com/allison-prompts-for-freeswitch*
> <https://www.gofundme.com/allison-prompts-for-freeswitch>
>
> Wish to schedule a meeting?
>
> http://app.timebridge.com/#/meet/freeswitch
>
> Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit:
> /r/freeswitch <https://www.reddit.com/r/freeswitch>
>
> *T:*+19184209001 <(918)%20420-9001> | *F:*+19184209002 <(918)%20420-9002>
> | *M:*+1918424WEST (9378)
> *Skype:*briankwest
>
--
*Brian West*
brian at freeswitch.org
*Twitter: @FreeSWITCH , @briankwest*
http://www.freeswitchbook.com
http://www.freeswitchcookbook.com
Allison prompts for FreeSWITCH:
*https://www.gofundme.com/allison-prompts-for-freeswitch*
<https://www.gofundme.com/allison-prompts-for-freeswitch>
Wish to schedule a meeting?
http://app.timebridge.com/#/meet/freeswitch
Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit:
/r/freeswitch <https://www.reddit.com/r/freeswitch>
*T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378)
*Skype:*briankwest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20170227/e45a995c/attachment-0001.html
Join us at ClueCon 2016 Aug 8-12, 2016
More information about the FreeSWITCH-users
mailing list