March 2011 - FreeSWITCH-users - FreeSWITCH Mailing Lists

Gateway with dynamic IP address
by Juan Wajnerman 14 Apr '11

14 Apr '11

I asked this question yesterday in the IRC but I couldn't get a solution. I'd like to have a gateway configured in FreeSwitch without specifying the static IP address. I have this configuration: <user id="gw"> <gateways> <gateway name="gw"> <param name="username" value="gw"/> <param name="password" value="password"/> <param name="register" value="false"/> <param name="extension" value="2"/> </gateway> </gateways> <params> <param name="password" value="password"/> </params> <variables> <variable name="user_context" value="default" /> </variables> </user> and the SIP device is registering properly, but I cannot dial with addresses like: "sofia/gateway/gw/123456789". Note that this works if the gateway name is the IP address or host name, or if I add a "proxy" setting with the IP address. I have a similar configuration in asterisk, where the sip.conf contains: [gw] type=friend secret=password context=default host=dynamic And once the gateway is registered in asterisk, I can dial with "SIP/gw/123456789". Is there any way to make a similar configuration in FreeSwitch? Thanks! - Juan

8 12

Re: [Freeswitch-users] CALL_REJECT on freeswitch
by Gourav Vohra 13 Apr '11

13 Apr '11

I have two freeswitch servers. First one is installed using the official release and the second is from a snapshot from mar 15. Call reject on the official release works without any problem. It doesn't work on the snapshot release. I am also having some trouble with SLA and barge on the snapshot release whereas the official release works without any problems. I am assuming the Official release should be used in production and snapshot releases are only for testing. Please correct me if I am wrong. Thanks.

3 8

Full username in caller_profile->username
by Serge S. Yuriev 12 Apr '11

12 Apr '11

Hello, caller_profile->channel_name shows sofia/internal/user@domain but caller_profile->username shows only user w/o domain part. How i can set username to include domain name in caller_profile->username? -- wbr, Serge

2 3

FS HA
by Tihomir Culjaga 12 Apr '11

12 Apr '11

hello guys, i configured FS HA and looks like its trying to recover the call .. but the re-INVITE fails due to "wrong/missed" codec capability. freeswitch@internal> freeswitch@internal> sofia profile external siptrace on Enabled sip debugging on external freeswitch@internal> sofia profile internal siptrace on Enabled sip debugging on internal freeswitch@internal> freeswitch@internal> freeswitch@internal> freeswitch@internal> sofia recover Recovered 1 call(s) 2011-01-24 21:32:31.667404 [CRIT] switch_odbc.c:205 The sql server is not responding for DSN COREFSdrv [STATE: HY000 CODE 7 ERROR: [unixODBC]Unknown error; FATAL: terminating connection due to administrator command ][176] freeswitch@internal> 2011-01-24 21:32:31.667404 [INFO] switch_odbc.c:210 The connection has been re-established 2011-01-24 21:32:32.726402 [NOTICE] switch_channel.c:669 New Channel sofia/external/385914392122(a)195.88.212.39[808b0a98-8928-4ca2-a320-8e026ba94018] *2011-01-24 21:32:32.726402 [DEBUG] sofia_glue.c:2354 Set Codec sofia/external/385914392122(a)195.88.212.39 PCMA/8000 20 ms 160 samples* 2011-01-24 21:32:32.726402 [DEBUG] sofia_glue.c:2594 AUDIO RTP [sofia/external/385914392122(a)195.88.212.39] 195.88.212.30 port 20092 -> 195.88.212.39 port 17750 codec: 8 ms: 20 2011-01-24 21:32:32.726402 [DEBUG] switch_rtp.c:1182 Starting timer [soft] 160 bytes per 20ms 2011-01-24 21:32:32.728288 [DEBUG] sofia_glue.c:2774 Set 2833 dtmf send payload to 101 2011-01-24 21:32:32.728288 [DEBUG] sofia_glue.c:2779 Set 2833 dtmf receive payload to 101 2011-01-24 21:32:32.728288 [DEBUG] sofia_glue.c:2790 Set comfort noise payload to 13 2011-01-24 21:32:32.779414 [DEBUG] sofia_glue.c:4246 (sofia/external/ 385914392122(a)195.88.212.39) State Change CS_NEW -> CS_INIT 2011-01-24 21:32:32.779414 [DEBUG] switch_core_session.c:1021 Send signal sofia/external/385914392122(a)195.88.212.39 [BREAK] 2011-01-24 21:32:32.779414 [NOTICE] sofia_glue.c:4249 Resurrecting fallen channel sofia/external/385914392122(a)195.88.212.39 2011-01-24 21:32:32.780381 [DEBUG] switch_core_state_machine.c:314 (sofia/external/385914392122(a)195.88.212.39) Running State Change CS_INIT 2011-01-24 21:32:32.780381 [DEBUG] switch_core_state_machine.c:338 (sofia/external/385914392122(a)195.88.212.39) State INIT 2011-01-24 21:32:32.780381 [DEBUG] mod_sofia.c:83 sofia/external/ 385914392122(a)195.88.212.39 SOFIA INIT 2011-01-24 21:32:32.780381 [DEBUG] mod_sofia.c:114 (sofia/external/ 385914392122(a)195.88.212.39) State Change CS_INIT -> CS_EXECUTE 2011-01-24 21:32:32.780381 [DEBUG] switch_core_session.c:1021 Send signal sofia/external/385914392122(a)195.88.212.39 [BREAK] 2011-01-24 21:32:32.780381 [DEBUG] switch_core_state_machine.c:338 (sofia/external/385914392122(a)195.88.212.39) State INIT going to sleep 2011-01-24 21:32:32.780381 [DEBUG] switch_core_state_machine.c:314 (sofia/external/385914392122(a)195.88.212.39) Running State Change CS_EXECUTE 2011-01-24 21:32:32.780381 [DEBUG] switch_core_state_machine.c:348 (sofia/external/385914392122(a)195.88.212.39) State EXECUTE 2011-01-24 21:32:32.780381 [DEBUG] mod_sofia.c:226 sofia/external/ 385914392122(a)195.88.212.39 SOFIA EXECUTE 2011-01-24 21:32:32.780381 [DEBUG] switch_core_state_machine.c:157 sofia/external/385914392122(a)195.88.212.39 Standard EXECUTE EXECUTE sofia/external/385914392122(a)195.88.212.39 set(playback_delimiter=!) send 1029 bytes to udp/[195.88.212.39]:62342 at 20:32:32.781241: ------------------------------------------------------------------------ INVITE sip:385914392122@195.88.212.39 <sip%3A385914392122(a)195.88.212.39>SIP/2.0 Via: SIP/2.0/UDP 195.88.212.30:5080;rport;branch=z9hG4bKKDX31Z2Q71B3j Route: <sip:385914392122@195.88.212.39:62342;lr> Max-Forwards: 69 From: <sip:38518880050@195.88.212.30 <sip%3A38518880050(a)195.88.212.30> >;tag=DFejDg1B59y9r To: <sip:385914392122@195.88.212.39 <sip%3A385914392122(a)195.88.212.39> >;tag=C4B0BE6C-1B8 Call-ID: 1785B58B-272611E0-8909D88B-B59C2BD1(a)195.88.212.39 CSeq: 7614512 INVITE Contact: <sip:385914392122@195.88.212.30:5080> User-Agent: FreeSWITCH-mod_sofia/1.0.6-svn-exported Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Allow-Events: talk, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 168 X-FS-Support: update_display Remote-Party-ID: "38518880050" <sip:38518880050@195.88.212.30<sip%3A38518880050(a)195.88.212.30> >;party=calling;screen=yes;privacy=off v=0 o=FreeSWITCH 1295881060 1295881062 IN IP4 195.88.212.30 s=FreeSWITCH c=IN IP4 195.88.212.30 t=0 0* m=audio 20092 RTP/AVP 0 13* * a=rtpmap:13 CN/8000* a=ptime:20 ------------------------------------------------------------------------ 2011-01-24 21:32:32.781430 [DEBUG] sofia.c:4153 Channel sofia/external/ 385914392122(a)195.88.212.39 entering state [calling][0] recv 496 bytes from udp/[195.88.212.39]:5060 at 20:32:32.784077: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 195.88.212.30:5080;rport;branch=z9hG4bKKDX31Z2Q71B3j From: <sip:38518880050@195.88.212.30 <sip%3A38518880050(a)195.88.212.30> >;tag=DFejDg1B59y9r To: <sip:385914392122@195.88.212.39 <sip%3A385914392122(a)195.88.212.39> >;tag=C4B0BE6C-1B8 Date: Mon, 24 Jan 2011 19:22:34 GMT Call-ID: 1785B58B-272611E0-8909D88B-B59C2BD1(a)195.88.212.39 Server: Cisco-SIPGateway/IOS-12.x CSeq: 7614512 INVITE Allow-Events: telephone-event Remote-Party-ID: <sip:385914392122@195.88.212.39<sip%3A385914392122(a)195.88.212.39> >;party=called;screen=yes;privacy=off Content-Length: 0 ------------------------------------------------------------------------ recv 376 bytes from udp/[195.88.212.39]:5060 at 20:32:32.784195: ------------------------------------------------------------------------ SIP/2.0 488 Not Acceptable Media Via: SIP/2.0/UDP 195.88.212.30:5080;rport;branch=z9hG4bKKDX31Z2Q71B3j From: <sip:38518880050@195.88.212.30 <sip%3A38518880050(a)195.88.212.30> >;tag=DFejDg1B59y9r To: <sip:385914392122@195.88.212.39 <sip%3A385914392122(a)195.88.212.39> >;tag=C4B0BE6C-1B8 Call-ID: 1785B58B-272611E0-8909D88B-B59C2BD1(a)195.88.212.39 Warning: 304 195.88.212.39 "Media Type(s) Unavailable" CSeq: 7614512 INVITE Content-Length: 0 ------------------------------------------------------------------------ send 395 bytes to udp/[195.88.212.39]:62342 at 20:32:32.784303: ------------------------------------------------------------------------ ACK sip:385914392122@195.88.212.39 <sip%3A385914392122(a)195.88.212.39>SIP/2.0 Via: SIP/2.0/UDP 195.88.212.30:5080;rport;branch=z9hG4bKKDX31Z2Q71B3j Route: <sip:385914392122@195.88.212.39:62342;lr> Max-Forwards: 69 From: <sip:38518880050@195.88.212.30 <sip%3A38518880050(a)195.88.212.30> >;tag=DFejDg1B59y9r To: <sip:385914392122@195.88.212.39 <sip%3A385914392122(a)195.88.212.39> >;tag=C4B0BE6C-1B8 Call-ID: 1785B58B-272611E0-8909D88B-B59C2BD1(a)195.88.212.39 CSeq: 7614512 ACK Content-Length: 0 ------------------------------------------------------------------------ 2011-01-24 21:32:32.784397 [DEBUG] sofia.c:4153 Channel sofia/external/ 385914392122(a)195.88.212.39 entering state [terminated][488] 2011-01-24 21:32:32.784397 [NOTICE] sofia.c:4789 Hangup sofia/external/ 385914392122(a)195.88.212.39 [CS_EXECUTE] [INCOMPATIBLE_DESTINATION] 2011-01-24 21:32:32.784397 [DEBUG] switch_channel.c:2102 Send signal sofia/external/385914392122(a)195.88.212.39 [KILL] 2011-01-24 21:32:32.784397 [DEBUG] switch_core_session.c:1021 Send signal sofia/external/385914392122(a)195.88.212.39 [BREAK] 2011-01-24 21:32:32.852411 [DEBUG] mod_dptools.c:816 sofia/external/ 385914392122(a)195.88.212.39 SET [playback_delimiter]=[!] 2011-01-24 21:32:32.853505 [DEBUG] switch_core_state_machine.c:348 (sofia/external/385914392122(a)195.88.212.39) State EXECUTE going to sleep 2011-01-24 21:32:32.853505 [DEBUG] switch_core_state_machine.c:314 (sofia/external/385914392122(a)195.88.212.39) Running State Change CS_HANGUP 2011-01-24 21:32:32.853505 [DEBUG] switch_core_state_machine.c:499 (sofia/external/385914392122(a)195.88.212.39) State HANGUP 2011-01-24 21:32:32.861414 [DEBUG] mod_sofia.c:408 sofia/external/ 385914392122(a)195.88.212.39 Overriding SIP cause 488 with 488 from the other leg 2011-01-24 21:32:32.861414 [DEBUG] mod_sofia.c:414 Channel sofia/external/ 385914392122(a)195.88.212.39 hanging up, cause: INCOMPATIBLE_DESTINATION 2011-01-24 21:32:32.863454 [DEBUG] switch_core_state_machine.c:46 sofia/external/385914392122(a)195.88.212.39 Standard HANGUP, cause: INCOMPATIBLE_DESTINATION 2011-01-24 21:32:32.863454 [DEBUG] switch_core_state_machine.c:499 (sofia/external/385914392122(a)195.88.212.39) State HANGUP going to sleep 2011-01-24 21:32:32.863454 [DEBUG] switch_core_state_machine.c:333 (sofia/external/385914392122(a)195.88.212.39) State Change CS_HANGUP -> CS_REPORTING 2011-01-24 21:32:32.863454 [DEBUG] switch_core_session.c:1021 Send signal sofia/external/385914392122(a)195.88.212.39 [BREAK] 2011-01-24 21:32:32.863454 [DEBUG] switch_core_state_machine.c:314 (sofia/external/385914392122(a)195.88.212.39) Running State Change CS_REPORTING 2011-01-24 21:32:32.863454 [DEBUG] switch_core_state_machine.c:590 (sofia/external/385914392122(a)195.88.212.39) State REPORTING 2011-01-24 21:32:32.864328 [DEBUG] switch_core_state_machine.c:53 sofia/external/385914392122(a)195.88.212.39 Standard REPORTING, cause: INCOMPATIBLE_DESTINATION 2011-01-24 21:32:32.864328 [DEBUG] switch_core_state_machine.c:590 (sofia/external/385914392122(a)195.88.212.39) State REPORTING going to sleep 2011-01-24 21:32:32.864328 [DEBUG] switch_core_state_machine.c:327 (sofia/external/385914392122(a)195.88.212.39) State Change CS_REPORTING -> CS_DESTROY 2011-01-24 21:32:32.864328 [DEBUG] switch_core_session.c:1021 Send signal sofia/external/385914392122(a)195.88.212.39 [BREAK] 2011-01-24 21:32:32.864328 [DEBUG] switch_core_session.c:1164 Session 1 (sofia/external/385914392122(a)195.88.212.39) Locked, Waiting on external entities 2011-01-24 21:32:32.864328 [NOTICE] switch_core_session.c:1182 Session 1 (sofia/external/385914392122(a)195.88.212.39) Ended 2011-01-24 21:32:32.864328 [NOTICE] switch_core_session.c:1184 Close Channel sofia/external/385914392122(a)195.88.212.39 [CS_DESTROY] 2011-01-24 21:32:32.864328 [DEBUG] switch_core_state_machine.c:428 (sofia/external/385914392122(a)195.88.212.39) Running State Change CS_DESTROY 2011-01-24 21:32:32.864328 [DEBUG] switch_core_state_machine.c:439 (sofia/external/385914392122(a)195.88.212.39) State DESTROY 2011-01-24 21:32:32.864328 [DEBUG] mod_sofia.c:341 sofia/external/ 385914392122(a)195.88.212.39 SOFIA DESTROY 2011-01-24 21:32:32.864328 [DEBUG] switch_core_state_machine.c:60 sofia/external/385914392122(a)195.88.212.39 Standard DESTROY 2011-01-24 21:32:32.864328 [DEBUG] switch_core_state_machine.c:439 (sofia/external/385914392122(a)195.88.212.39) State DESTROY going to sleep freeswitch@internal> freeswitch@internal> freeswitch@internal> 2011-01-24 21:32:51.813359 [CRIT] switch_odbc.c:205 The sql server is not responding for DSN COREFSdrv [STATE: HY000 CODE 7 ERROR: [unixODBC]Unknown error; FATAL: terminating connection due to administrator command ][176] 2011-01-24 21:32:51.813359 [INFO] switch_odbc.c:210 The connection has been re-established 2011-01-24 21:32:52.810408 [CRIT] switch_odbc.c:205 The sql server is not responding for DSN COREFSdrv [STATE: HY000 CODE 7 ERROR: [unixODBC]Unknown error; FATAL: terminating connection due to administrator command ][176] 2011-01-24 21:32:52.810408 [INFO] switch_odbc.c:210 The connection has been re-established 2011-01-24 21:32:53.817405 [CRIT] switch_odbc.c:205 The sql server is not responding for DSN COREFSdrv [STATE: HY000 CODE 7 ERROR: [unixODBC]Unknown error; FATAL: terminating connection due to administrator command ][176] 2011-01-24 21:32:53.817405 [INFO] switch_odbc.c:210 The connection has been re-established recv 432 bytes from udp/[195.88.212.39]:62342 at 20:33:06.045642: ------------------------------------------------------------------------ BYE sip:385914392122@195.88.212.30:5080 SIP/2.0 Via: SIP/2.0/UDP 195.88.212.39:5060;branch=z9hG4bK240FA From: <sip:385914392122@195.88.212.39 <sip%3A385914392122(a)195.88.212.39> >;tag=C4B0BE6C-1B8 To: <sip:38518880050@195.88.212.30 <sip%3A38518880050(a)195.88.212.30> >;tag=DFejDg1B59y9r Date: Mon, 24 Jan 2011 19:22:34 GMT Call-ID: 1785B58B-272611E0-8909D88B-B59C2BD1(a)195.88.212.39 User-Agent: Cisco-SIPGateway/IOS-12.x Max-Forwards: 70 Timestamp: 1295896987 CSeq: 102 BYE Content-Length: 0 ------------------------------------------------------------------------ send 522 bytes to udp/[195.88.212.39]:5060 at 20:33:06.045858: ------------------------------------------------------------------------ SIP/2.0 481 Call Does Not Exist Via: SIP/2.0/UDP 195.88.212.39:5060;branch=z9hG4bK240FA From: <sip:385914392122@195.88.212.39 <sip%3A385914392122(a)195.88.212.39> >;tag=C4B0BE6C-1B8 To: <sip:38518880050@195.88.212.30 <sip%3A38518880050(a)195.88.212.30> >;tag=DFejDg1B59y9r Call-ID: 1785B58B-272611E0-8909D88B-B59C2BD1(a)195.88.212.39 CSeq: 102 BYE Timestamp: 1295896987 0.000191 User-Agent: FreeSWITCH-mod_sofia/1.0.6-svn-exported Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Content-Length: 0 ------------------------------------------------------------------------ freeswitch@internal> freeswitch@internal> my codec settings in vars.conf <X-PRE-PROCESS cmd="set" data="global_codec_prefs=PCMA,GSM"/> <X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=PCMA,GSM"/> my codec settings in sip_profiles/* <param name="inbound-codec-prefs" value="$${global_codec_prefs}"/> <param name="outbound-codec-prefs" value="$${global_codec_prefs}"/> now, where the is FS picking up the codec list for the re-INVITE after "sofia recover" from the debug: 2011-01-24 21:32:32.726402 [DEBUG] sofia_glue.c:2354 Set Codec sofia/external/385914392122(a)195.88.212.39 PCMA/8000 20 ms 160 samples i can see sofia knows what codec is being used, but somehow its not sending it in re-INVITE. BTW: yea, i know, i know .. the version is a bit outdated but we can still make it working .. :)

7 19

Mod_fifo outbound strategy enterprise
by Marc de Corny 11 Apr '11

11 Apr '11

Hi all, I am getting the hang of the fifo now and it is proving very stable which is what we all need. Got one question however regarding mod_fifo and the outbound strategies. >From looking at the outbput of the fifo list commands I can see that that parameter is always set to "ringall". which is fine, but I can also see many stats on that number of calls and the last call that the members have taken. Is there also a way of sending the calls to the longest idle or something of that nature? Is that done by setting the outbound_strategy to "enterprise" or is there another way to achieve that. Is there also a command to change that value without editing the XML as I am trying to make everything dynamic. any input is very much appreciated. thanks Marc

3 3

time_test on Centos 5.5
by Louis Huppenbauer 09 Apr '11

09 Apr '11

Hi, I am testing FreeSWITCH on a Centos 5.5. The hardware is a 32 bit AMD Opteron 275. On the system I recognize a avg of 2000 if I run the time_test 1000 application. Currently I have no audio problems but I want to make sure that the system works well. There are 4 possible options: - Try to update the kernel to a newer one - Try to use debian. - Try to use the kernel-rt (realtime kernel from Centos) - Set some nice kernel options. Which? What do you think is the better solution? Thanks in advance. Kind regards, Louis

12 18

New FreeSWITCH IVR coming, but need HELP!
by Zac Wolfe 08 Apr '11

08 Apr '11

Hi guys, First some good news: we're finally close to releasing our free IVR Development platform SafiServer/SafiWorkshop (www.safisystems.com) with FreeSWITCH support! It's happening much later than we originally anticipated as we've been unexpectedly busy with contracting opportunities but I think it will be worth the wait. Currently everything is working fine with one minor exception: if the user-created script (we call them Saflets) doesn't explicitly hang up the call, the call will remain parked until the caller hangs up. Some details: In Asterisk we invoke our server-side scripting applications via the extensions.conf using the following syntax: exten = 1111,1,Agi(agi:// 192.168.0.10:3573/safletEngine.agi?saflet=project1/callflow1) Here '192.168.0.10' is the IP address of the SafiServer and project1/callflow1 identifies the Saflet to be executed. Asterisk creates a socket connection to the SafiServer and, once the socket is disconnected, the call proceeds to the next entry in the dialplan (typically 'hangup'). For FreeSWITCH, the process is slightly different. Currently, rather than create a separate socket connection for each incoming call, we're invoking an event that informs the SafiServer that there is a new incoming call. The event contains the contextual information including the Saflet name. For example: <extension name="9194"> <condition field="destination_number" expression="9194$"> <action inline="true" application="set" data="saficall=true"/> <action application="event" data="Event-Subclass=saficall::incoming,Event-Name=CUSTOM,saflet_project=test,saflet=flow1,new_saficall=true"/>  <action application="park" /> </condition> </extension> So once the event is fired, the call is parked to prevent further execution within the dialplan. From there on, SafiServer is controlling the call via Inbound Mod event socket. So this works perfectly, except that if the invoked Saflet doesn't explicitly hang-up the call it will remain parked until the caller hangs up. My question is, is there a better way to do this? Is there some better alternative to park in this case? Ideally I'd like to initiate a 'session' of some kind when the SafiServer is "controlling" the call and then exit that session as soon as the Saflet is complete, at which point the call would continue on to the next entry in the dialplan. I understand I could use Outbound sockets to achieve this but, as I mentioned, I'd like to avoid the overhead of a separate socket connection for each incoming call. I actually have a mod_saficall.c app that does basically the the same thing as I described in the dialplan entry. Perhaps there's something more I could do in code that would allow me to be notified when the session is complete. Here's the relevant code I have so far: switch_channel_t *channel = NULL; switch_event_t *event; const char *safiCallFlag = NULL; channel = switch_core_session_get_channel(session); safiCallFlag = switch_channel_get_variable(channel, "saficall"); if (!safiCallFlag) switch_channel_set_variable(channel, "saficall", "true"); if (switch_event_create_subclass(&event, SWITCH_EVENT_CUSTOM, "saficall::incoming") == SWITCH_STATUS_SUCCESS) { switch_event_add_header_string(event, SWITCH_STACK_BOTTOM, "new_saficall", safiCallFlag ? "false" : "true"); switch_channel_event_set_data(channel, event); switch_event_fire(&event); switch_ivr_park(session, NULL); } Any ideas you might have on this are welcome. Thanks, Zac Wolfe Safi Systems LLC www.safisystems.com

3 3

video problem in conference with H264
by Seven Du 05 Apr '11

05 Apr '11

I tested with default 3000 conference and it just OK. But I have problem on H264. I tested with one Bria 3.1 on Mac and two XTP8886 hardware phones. http://www.gvscusa.com/xtp8886.html Bria 1003 XTP 1011/1012 call from 1003 to 1011 and from 1011 to 1003 both ok with videos. http://pastebin.freeswitch.org/15910 http://pastebin.freeswitch.org/15911 When 3 phones calling into 3000(conference), Everyone call see Bria(1003), but no one can say 1011 and 1012. Even when I muted 1003. http://pastebin.freeswitch.org/15913 As I said there's no problem with similar test with h263. Can anyone help take a look, thanks. -- About: http://about.me/dujinfang Blog: http://www.dujinfang.com Proj: http://www.freeswitch.org.cn Sent with Sparrow

2 3

Recommended SIP IP Wifi Handsets?
by Michael Kennedy 05 Apr '11

05 Apr '11

Hello, Newbie here, and newbie on FS - but been lurking for a few YEARS!... I'm hoping to roll out FS where some areas in a building are wired, and other areas are on WiFi, and to deploy some SIP phones in both areas. I expected that many phone suppliers would have handsets with EITHER RJ45 or WiFi connectivity to the LAN, or even both! I've found only a single device, a Cisco SPA525G2! Furthermore, searching the FS site, and various VoIP sites, and running general searches, I've found no other SIP WiFi phones that look like standard desktop handsets. I'd appreciate any pointers to WiFi devices that are recommended with FS. Preferably "standard-looking" desktop units, and better still, if they had wired "sisters" - in appearance and functionality! Or... maybe best to invest in a few rolls of Cat-6 cable!! Thank you - and many thanks again to some of the regulars here for off-list guidance. - Mike

9 19

Dingaling and sasl authentication failed
by Peter Steinbach 04 Apr '11

04 Apr '11

Hello, I installed mod_dingaling and having problems with the registration freeswitch@internal> dingaling status --DingaLing status-- login | connected my.account(a)googlemail.com/talk | UNCONNECTED 2011-03-29 02:02:48.756832 [DEBUG] libdingaling.c:1289 sasl authentication failed 2011-03-29 02:02:48.756832 [DEBUG] libdingaling.c:1607 io error 2 7 retry in 47 second(s) Searching the mailing list led me to look at libgnutls26. But libgnutls26 libgnutls-dev are both installed, and both the are newest version, and both were installed long before I configured and compiled mod_dingaling. And TLs for SIP is working sucessfully since a while. Anybody has a hint where to look further? -- With kind regards Peter Steinbach Telefaks Services GmbH mailto:lists (att) telefaks.de Internet: www.telefaks.de

3 4