- FreeSWITCH-users - FreeSWITCH Mailing Lists

g729 licenses usage
by Julien Chavanton 17 Aug '11

17 Aug '11

Hi, Before we purchase more g729 licenses we would like to confirm, how many licenses are used when you have two call leg (g.729) bridged with session recording ? I would expect 2 licenses, is this correct ? ------------------------------------------------------ I am sure I am not alone to hate this kind of licensing limitation, after all theses years do we still need g.729, if it did not exist it would be replaced by something just as good or better. I know this as nothing to do with FS, since the market abuse or takeover of g.729 is enforced everywhere in the network switches. <freeswitch-users(a)lists.freeswitch.org>

3 2

FreeSWITCH Conference Call Today
by Michael Collins 17 Aug '11

17 Aug '11

Hello all! We are going to have a conf call today and talk about a few things, like how awesome ClueCon was this year! http://wiki.freeswitch.org/wiki/FS_weekly_2011_08_17 Come join us and be part of the discussion. I think we might have a few first-timers involved also. Thanks, MC

1 0

DTMF when speaking
by Boris Kovalenko 17 Aug '11

17 Aug '11

Hello! Sometimes (very rarely) when I speaking I can hear DTMF signals. So the question is - may the FS (proxy_media=false, bypass_media=false) generate this DTMFs if no start_dtfm application is used? FS version is git-3c74f39 2011-07-22 23-06-06 +0200. Clients devices are different: Planet, Linksys, Audiocodes and even Cisco 5350. -- Regards, Boris

2 2

Re: [Freeswitch-users] Help with dual IP gateways
by chrisbware＠interfree.it 17 Aug '11

17 Aug '11

1 0

SIP/2.0 482 Request merged with Huawei-MC820/1.0.0
by Eugene Prokopiev 17 Aug '11

17 Aug '11

Hi, I've got SIP/2.0 482 Request merged on INVITE from successfully registered Huawei-MC820/1.0.0 UA. Conversation looks like: freeswitch@internal> recv 834 bytes from udp/[10.0.0.102]:5060 at 10:28:55.614664: ------------------------------------------------------------------------ INVITE sip:2101020@10.0.0.1 SIP/2.0 CSeq: 1 INVITE Call-ID: 75b760e11a9f9c7b4be7251c4f381d55(a)huawei.com Contact: <sip:102@10.0.0.102> Content-Length: 453 From: <sip:102@10.0.0.1>;tag=1728f3d7 To: <sip:2101020@10.0.0.1> Via: SIP/2.0/UDP 10.0.0.102;branch=z9hG4bK11fef50f3 User-Agent: Huawei-MC820/1.0.0 Supported: 100rel Content-Type: application/sdp Max-Forwards: 70 v=0 o=Huawei 1313566095 1313566095 IN IP4 10.0.0.102 s=Sip Call c=IN IP4 10.0.0.102 t=0 0 m=audio 10050 RTP/AVP 8 0 15 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:15 G728/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=sendrecv m=video 10052 RTP/AVP 117 34 b=AS:192 a=rtpmap:117 H264/90000 a=rtpmap:34 H263/90000 a=fmtp:117 profile-level-id=42080D; max-br=194 a=fmtp:34 CIF=1 QCIF=1 MaxBR=1940 a=sendrecv ------------------------------------------------------------------------ send 298 bytes to udp/[10.0.0.102]:5060 at 10:28:55.615140: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.0.0.102;branch=z9hG4bK11fef50f3 From: <sip:102@10.0.0.1>;tag=1728f3d7 To: <sip:2101020@10.0.0.1> Call-ID: 75b760e11a9f9c7b4be7251c4f381d55(a)huawei.com CSeq: 1 INVITE User-Agent: FreeSWITCH-mod_sofia/1.0.head-hacked-20110816T130734Z Content-Length: 0 ------------------------------------------------------------------------ send 653 bytes to udp/[10.0.0.102]:5060 at 10:28:55.615973: ------------------------------------------------------------------------ SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP 10.0.0.102;branch=z9hG4bK11fef50f3 From: <sip:102@10.0.0.1>;tag=1728f3d7 To: <sip:2101020@10.0.0.1>;tag=U9D95t1myaeNH Call-ID: 75b760e11a9f9c7b4be7251c4f381d55(a)huawei.com CSeq: 1 INVITE User-Agent: FreeSWITCH-mod_sofia/1.0.head-hacked-20110816T130734Z Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Allow-Events: talk, hold, refer Proxy-Authenticate: Digest realm="10.0.0.1", nonce="b5d47364-c8bb-11e0-9704-7d44b5f0bd2d", algorithm=MD5, qop="auth" Content-Length: 0 ------------------------------------------------------------------------ recv 260 bytes from udp/[10.0.0.102]:5060 at 10:28:55.687752: ------------------------------------------------------------------------ ACK sip:2101020@10.0.0.1 SIP/2.0 CSeq: 1 ACK Call-ID: 75b760e11a9f9c7b4be7251c4f381d55(a)huawei.com Content-Length: 0 From: <sip:102@10.0.0.1>;tag=1728f3d7 To: <sip:2101020@10.0.0.1>;tag=U9D95t1myaeNH Via: SIP/2.0/UDP 10.0.0.102;branch=z9hG4bK11fef50f3 ------------------------------------------------------------------------ recv 1072 bytes from udp/[10.0.0.102]:5060 at 10:28:55.706532: ------------------------------------------------------------------------ INVITE sip:2101020@10.0.0.1 SIP/2.0 CSeq: 1 INVITE Call-ID: 75b760e11a9f9c7b4be7251c4f381d55(a)huawei.com Contact: <sip:102@10.0.0.102> Content-Length: 453 From: <sip:102@10.0.0.1>;tag=1728f3d7 To: <sip:2101020@10.0.0.1> Via: SIP/2.0/UDP 10.0.0.102;branch=z9hG4bK11a279953 User-Agent: Huawei-MC820/1.0.0 Supported: 100rel Proxy-Authorization: Digest username="102",realm="10.0.0.1",nonce="b5d47364-c8bb-11e0-9704-7d44b5f0bd2d",uri="sip:2101020@10.0.0.1",response="199c0f493e04ab89c6b8ab2dcc1a4ae4",algorithm=MD5,cnonce="6c64988847d3f764",qop=auth,nc=00000001 Content-Type: application/sdp Max-Forwards: 70 v=0 o=Huawei 1313566095 1313566096 IN IP4 10.0.0.102 s=Sip Call c=IN IP4 10.0.0.102 t=0 0 m=audio 10050 RTP/AVP 8 0 15 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:15 G728/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=sendrecv m=video 10052 RTP/AVP 117 34 b=AS:192 a=rtpmap:117 H264/90000 a=rtpmap:34 H263/90000 a=fmtp:117 profile-level-id=42080D; max-br=194 a=fmtp:34 CIF=1 QCIF=1 MaxBR=1940 a=sendrecv ------------------------------------------------------------------------ send 257 bytes to udp/[10.0.0.102]:5060 at 10:28:55.706753: ------------------------------------------------------------------------ SIP/2.0 482 Request merged Via: SIP/2.0/UDP 10.0.0.102;branch=z9hG4bK11a279953 From: <sip:102@10.0.0.1>;tag=1728f3d7 To: <sip:2101020@10.0.0.1>;tag=U9D95t1myaeNH Call-ID: 75b760e11a9f9c7b4be7251c4f381d55(a)huawei.com CSeq: 1 INVITE Content-Length: 0 What is wrong? -- Thanks, Eugene Prokopiev

1 0

mod_event_socket Outbound connection in Java.
by Suresh M 17 Aug '11

17 Aug '11

Hi, I am trying mod_event_socket in FreeSwitch [outbound ] using Java and I am stuck: I tried the following C# sample successfully. ESLconnection eslConnection = new ESLconnection(sckClient.Handle.ToInt32()); I need to do the same in Java. But what should I pass to new ESLconnection constructor in Java in place of socket handle?! I know basically this is a Java question for which I tried a lot to find answer but in vain. Hope somebody out there would already have come across this and got a solution. Any help or clue or alternative method to achieve the same is greatly appreciated. Thanks in advance. Suresh

2 2

SIP proxy collect DTMF using FS
by Sam Govind 17 Aug '11

17 Aug '11

Hi guys, I'm looking to establish a scenario like this, any idea how to do it, if its possible. 1- SIP proxy send call to FS where DTMF will be collected. (I'm thinking of using PlayAndGetDigits) 2- DTMF collected be sent back to SIP proxy while FS ends the call 3- Call at SIP proxy end keeps running for some other processing. basically I just need FS to collect DTMF and send those back to SIP Proxy. Any ideas are welcome. Thanks.

3 3

DTMF bleed through in conference
by David Bolen 17 Aug '11

17 Aug '11

I'm encountering what I would probably best describe as some bleed through of inbound DTMF when in a conference, and I was wondering if anyone might have suggestions for likely causes or troubleshooting? DTMF detection itself seems fine, and appears to properly be using rfc2833 (the SDPs all show include "a=rtpmap:101 telephone-event/8000"). I get "RTP RECV DTMF" logs for each digit that is recognized. However, a reasonable percentage of the time, some small fraction of the DTMF appears to be heard by the conference as a whole. Never the whole thing, and sometimes it's a bit distorted (though that may just be due to it being so short). Almost as if a small portion of a sound sample makes it through. For testing, I'm using internal phones with direct SIP connections to the switch so no PSTN or gateways involved, though it also occurs with a PSTN caller coming in through multiple gateways. For the internal phones, I've tried both a physical phone through a PAP2T, as well as a PC soft phone. This is with git-868d823 from Jul 29, so a few weeks old but reviewing the more recent commits there weren't any seemingly related to DTMF or conferencing. Any suggestions on places to look or things to try would be most appreciated. -- David

5 7

FS performance using ESL
by Tihomir Culjaga 16 Aug '11

16 Aug '11

hello, im wondering how much performance do we loose when using ESL instead of running it via dialplan? without ESL with a fine tuned FS and a short dialplan ( answer, playback like 20 seconds file, hangup ) im able to service 75 CPS. On the same FS, when i use ESL to answer the call, playback the same file and hangup, im not able to run more than 2 CPS... this is a huge impact and i really can't believe it. I'm using event-socket outbound e.g.: <action application="socket" data="127.0.0.1:8088 async full"/> my extension looks like: <extension name="ESL_C"> <condition field="destination_number" expression="^(6666)$"> <action application="socket" data="127.0.0.1:8088 async full"/> <action application="sleep" data="1000"/> <action application="hangup"/> </condition> </extension> im using testserver from lib/esl/ and i just removed the conference command and added the playback one.... also i moved the esl_debug lvl to 0 anyhow, FS cannot run more than 2 CPS compared to 75 CPS when the playback is done from the dialplan. Please, can someone give me a clue on what is going on? Maybe im doing something wrong? how to get maximum FS performance using ESL ? Regards, Tihomir.

2 8

Building Freeswitch + FreeTDM + LibSng-ISDN RPMs
by Octavio Ruiz 16 Aug '11

16 Aug '11

I'm trying to build Freeswitch with full Sangoma's ( FreeTDM + LibSng-ISDN ) support from SRPMs for Centos 5, but there are two not satisfied dependencies for what looks like non existing RPMs, fact that raises many questions on my head, An extract from the freeswitch SPEC file: -- from freeswitch.spec Requires: libsng_isdn BuildRequires: wanpipe BuildRequires: libsng_isdn even if looks quite easy to bypass this and get it to compile satisfying those, either creating the missing libsng_isdn SPEC file needed for building the package (libsng_isdn is only a bunch of headers and an already-build shared object) and modifying the wanpipe.rpmspec in order to change the naming behavior which doesn't comply with the above (Wanpipe's resulting RPM is named 'wanpipe-<kernel-version>' which do not satisfy the solely string 'wanpipe') or either worst, in terms of cleanliness, creating dummy RPM packages or removing dependencies on the freeswitch.spec, I wonder what is supposed to be the correct environment and proper procedure for building Freeswitch and Wanrouter + SNG-ISDN following what the SPEC file states. -- from wanpipe.rpmspec %define KERNEL_VERSION %{?kern_ver} %define WANPIPE_VER wanpipe %define name %{WANPIPE_VER} Am I missing something? Has anyone tested this before? Someone else is packaging Sangoma's Wanrouter on RPM with other naming scheme? Are they on the SPEC file merely to denote upcoming work?

2 1