August 2010 - FreeSWITCH-users - FreeSWITCH Mailing Lists

INVALID_NUMBER_FORMAT
by Cliff Wells 23 Aug '10

23 Aug '10

I have two servers, both seemingly configured identically. One can make outbound calls via the gateway, the other cannot. Here's the error: EXECUTE FreeTDM/1:25/7771112222 bridge(sofia/gateway/outbound/18001231234) 2010-08-23 08:52:05.918700 [ERR] mod_sofia.c:3668 Invalid Gateway 2010-08-23 08:52:05.918700 [NOTICE] mod_sofia.c:3984 Close Channel N/A [CS_NEW] 2010-08-23 08:52:05.918700 [DEBUG] switch_core_state_machine.c:430 () Running State Change CS_DESTROY 2010-08-23 08:52:05.918700 [DEBUG] switch_core_state_machine.c:440 (N/A) State DESTROY 2010-08-23 08:52:05.918700 [DEBUG] mod_sofia.c:358 N/A SOFIA DESTROY 2010-08-23 08:52:05.918700 [DEBUG] switch_core_state_machine.c:440 (N/A) State DESTROY going to sleep 2010-08-23 08:52:05.918700 [ERR] switch_ivr_originate.c:2600 Cannot create outgoing channel of type [sofia] cause: [INVALID_NUMBER_FORMAT] 2010-08-23 08:52:05.918700 [DEBUG] switch_ivr_originate.c:3408 Originate Resulted in Error Cause: 28 [INVALID_NUMBER_FORMAT] 2010-08-23 08:52:05.918700 [INFO] mod_dptools.c:2393 Originate Failed. Cause: INVALID_NUMBER_FORMAT 2010-08-23 08:52:05.918700 [DEBUG] switch_channel.c:2261 (FreeTDM/1:25/7017120999) Callstate Change RINGING -> HANGUP 2010-08-23 08:52:05.918700 [NOTICE] mod_dptools.c:2456 Hangup FreeTDM/1:25/7017120999 [CS_EXECUTE] [INVALID_NUMBER_FORMAT] 2010-08-23 08:52:05.918700 [DEBUG] switch_channel.c:2277 Send signal FreeTDM/1:25/7771112222 [KILL] Dialplan is via mod_xml_curl (both servers get the same info from the same http server) and looks like: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <document type="freeswitch/xml"> <section name="dialplan" description="freeswitch dialplan for 7771112222"> <context name="public"> <extension name="xml-curl-bridge"> <condition field="destination_number" expression=".*"> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="call_timeout=30"/> <action application="set" data="effective_caller_id_number=7771112222"/> <action application="bridge" data="sofia/gateway/outbound/18001231234"/> </condition> </extension> </context> </section> </document> The gateway (identical on both systems): <include> <gateway name="outbound"> <param name="username" value="4442221111"/> <param name="auth-username" value="4444444"/> <param name="password" value="somesecret"/> <param name="proxy" value="sip.myprovider.com"/> <param name="expire-seconds" value="600"/> <param name="register" value="true"/> <param name="retry-seconds" value="30"/> <param name="ping" value="25"/> </gateway> </include> Again, this setup works on one system but not the other and I'm at a loss since I can't be sure what number FS is complaining about (I assume the outbound). Thanks in advance, Cliff --

3 4

FreeSwitch - Skypopen cant make call
by Shamun toha md 23 Aug '10

23 Aug '10

Hi, When i am calling from another skypeID to FreeSwitch->Mod Skypopen account. I get this following details, No call is able to establish between Server and Regular skype caller?: freeswitch@example> sk list sk console is: |||interface1||| F ID Name IB (F/T) OB (F/T) State CallFlw UUID = ==== ======== ======= ======= ====== ============ ====== 1 [interface1] 0/0 0/0 IDLE CALL_IDLE Total Interfaces: 1 IB Calls(Failed/Total): 0/0 OB Calls(Failed/Total): 0/0 freeswitch@example> sk MESSAGE test1 hi there sk console is: |||interface1||| freeswitch@example> 2010-08-22 11:36:52.675088 [NOTICE] switch_channel.c:669 New Channel skypopen/interface1 [cbb3b872-add0-11df-a4c6-75d067ab3b3d] 2010-08-22 11:36:52.675088 [NOTICE] mod_skypopen.c:1944 Channel [skypopen/interface1] has been answered 2010-08-22 11:36:52.677551 [INFO] mod_dialplan_xml.c:418 Processing alu malu->5000 in context default 2010-08-22 11:36:52.687099 [NOTICE] mod_skypopen.c:1171 Hangup skypopen/interface1 [CS_EXECUTE] [NORMAL_CLEARING] 2010-08-22 11:36:52.750656 [NOTICE] switch_core_session.c:1182 Session 1 (skypopen/interface1) Ended 2010-08-22 11:36:52.750656 [NOTICE] switch_core_session.c:1184 Close Channel skypopen/interface1 [CS_DESTROY] 2010-08-22 11:36:52.987482 [ERR] skypopen_protocol.c:233 rev [(nil)|37 ][ERRORA 233 ][interface1][-1, 0, 0] Skype got ERROR: |||ERROR 589 ALTER CALL: unable to alter input/output||| 2010-08-22 11:36:52.987482 [ERR] skypopen_protocol.c:235 rev [(nil)|37 ][ERRORA 235 ][interface1][-1, 0,16] skype_call now is DOWN 2010-08-22 11:37:18.045973 [NOTICE] switch_channel.c:669 New Channel skypopen/interface1 [dad30380-add0-11df-a4c7-75d067ab3b3d] 2010-08-22 11:37:18.047140 [NOTICE] mod_skypopen.c:1944 Channel [skypopen/interface1] has been answered 2010-08-22 11:37:18.048145 [INFO] mod_dialplan_xml.c:418 Processing alu malu->5000 in context default 2010-08-22 11:37:18.058690 [NOTICE] mod_skypopen.c:1171 Hangup skypopen/interface1 [CS_EXECUTE] [NORMAL_CLEARING] 2010-08-22 11:37:18.072829 [NOTICE] switch_core_session.c:1182 Session 2 (skypopen/interface1) Ended 2010-08-22 11:37:18.072829 [NOTICE] switch_core_session.c:1184 Close Channel skypopen/interface1 [CS_DESTROY] 2010-08-22 11:37:18.359355 [ERR] skypopen_protocol.c:233 rev [(nil)|37 ][ERRORA 233 ][interface1][-1, 0, 0] Skype got ERROR: |||ERROR 589 ALTER CALL: unable to alter input/output||| 2010-08-22 11:37:18.359355 [ERR] skypopen_protocol.c:235 rev [(nil)|37 ][ERRORA 235 ][interface1][-1, 0,16] skype_call now is DOWN

2 3

french language implementation
by Tim St. Pierre 23 Aug '10

23 Aug '10

Hello, I would like to make a proper bilingual PBX implementation here in Canada, and it looks like there isn't a stock set of Canadian French sound files. I talked to GM Voices, and they have some voice talent available to do this job. Our company is willing to pay for it (they gave us a pretty good deal), and we will contribute the prompt set back to the project once it's done. Being that it's a different language, and some numbers and phrases are said in a different format, what do I need to change to make all this work? I imagine I have to modify some phrase macros somewhere. Does anyone have some instructions, or is there someone fluent in French willing to take this on? I see references to fr in modules.conf, but I can't find the audio files. Is it possible that someone has already done this work, and all we have to do is record the prompts? Any help is appreciated. -Tim

2 1

FS with Red5 Streaming-Server (RTMP-Stream)
by Dennis 23 Aug '10

23 Aug '10

hi, we are currently playing with streaming calls. with fs and icecast (over mod_shout) it works quite well. the problem is, that http-streaming to a website in conjuction with a flashplayer, a lot of overhead is produced. therefore this is no optimal solution. the best for streaming to a flashplayer embedded in a website are rtmp-streams (which are also used by webradios). red5 is an open source streaming server (written in java), which supports rtmp-streams and mp3. the problem seems to be, that fs "only" supports icecast and shoutcast. we can not get fs to work with red5. does someone have experiences with fs and red5 and can tell me, if there might be a way to get it working? or are there any technical issues, why this can't work? thanks and kind regards dennis

11 23

freeswitch CPU usage
by Woody Dickson 23 Aug '10

23 Aug '10

Hi, I am doing some experiments with Freeswitch by torturing it to see how the machine's CPU response to heavy loaded situation. The test is done on a 16 core 5550 dual quad core server running fedora 2.6.30.10-105.2.23.fc11.x86_64 OS. What I found so strange was that while CPU usage remains pretty low and distributed among all cores at 190 - 200 calls per second. Then, after added a few more calls per second, all CPU becomes fully utilized. Is this due to some wrong setting? Any idea how I can tweak the configuration and continue my test? Thanks, Woody

13 58

Re: [Freeswitch-users] Wrong hangup cause (NO_ANSWER) while answered session
by Durmuş Ali Öztürk 23 Aug '10

23 Aug '10

I have setup freeswitch by using git and followed the instructions on the wiki page. How can I retrieve the exact git version? There is no override of the hangup cause in our code. The algorithm is very simple; we call the originate function with the playback action and use a wav file as argument. Hangup is done automatically by FreeSWITCH, after eof of the wav file is reached. Or the other part hangs up before the file ends. We dont traced the communication but in other hand, the sip codes are traced out into the log file (183-->180-->200=call established). This show to me, that there is no problem with the SIP transactions. Please assume, that SIP messages are OK. What else could be happen? 2010-08-17 22:40:51.087402 [DEBUG] switch_ivr_originate.c:1979 variable string 0 = [sip_from_uri=sip:xxxx@xxxxx] 2010-08-17 22:40:51.087402 [DEBUG] switch_ivr_originate.c:1979 variable string 1 = [ignore_early_media=true] 2010-08-17 22:40:51.087402 [DEBUG] switch_ivr_originate.c:1979 variable string 2 = [sip_cid_type=none] 2010-08-17 22:40:51.087402 [DEBUG] switch_ivr_originate.c:1979 variable string 3 = [originate_timeout=40] 2010-08-17 22:41:09.904378 [NOTICE] switch_channel.c:779 New Channel sofia/internal/9055599XXXXX [9e4b396e-3d99-445f-a2e8- 227e99f3f0ef] 2010-08-17 22:41:12.641362 [DEBUG] mod_sofia.c:3892 (sofia/internal/9055599XXXXX) State Change CS_NEW -> CS_INIT 2010-08-17 22:41:12.641362 [DEBUG] switch_core_session.c:1039 Send signal sofia/internal/9055599XXXXX [BREAK] 2010-08-17 22:41:12.641362 [DEBUG] switch_core_session.c:454 sofia/internal/9055599XXXXX set UUID=9dc8a739-f439-4815-981a-347b7a90a1a8 2010-08-17 22:41:12.642441 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/9055599XXXXX) Running State Change CS_INIT 2010-08-17 22:41:12.642441 [DEBUG] switch_core_state_machine.c:338 (sofia/internal/9055599XXXXX) State INIT 2010-08-17 22:41:12.642441 [DEBUG] mod_sofia.c:83 sofia/internal/9055599XXXXX SOFIA INIT 2010-08-17 22:41:12.643399 [DEBUG] mod_sofia.c:119 (sofia/internal/9055599XXXXX) State Change CS_INIT -> CS_ROUTING 2010-08-17 22:41:12.643399 [DEBUG] switch_core_session.c:1039 Send signal sofia/internal/9055599XXXXX [BREAK] 2010-08-17 22:41:12.643399 [DEBUG] switch_core_state_machine.c:338 (sofia/internal/9055599XXXXX) State INIT going to sleep 2010-08-17 22:41:12.643399 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/9055599XXXXX) Running State Change CS_ROUTING 2010-08-17 22:41:12.644456 [DEBUG] switch_channel.c:1512 (sofia/internal/9055599XXXXX) Callstate Change DOWN -> RINGING 2010-08-17 22:41:12.644456 [DEBUG] switch_core_state_machine.c:341 (sofia/internal/9055599XXXXX) State ROUTING 2010-08-17 22:41:12.644456 [DEBUG] mod_sofia.c:142 sofia/internal/9055599XXXXX SOFIA ROUTING 2010-08-17 22:41:12.644456 [DEBUG] switch_ivr_originate.c:66 (sofia/internal/9055599XXXXX) State Change CS_ROUTING -> CS_CONSUME_MEDIA 2010-08-17 22:41:12.644456 [DEBUG] switch_core_session.c:1039 Send signal sofia/internal/9055599XXXXX [BREAK] 2010-08-17 22:41:12.644456 [DEBUG] switch_core_state_machine.c:341 (sofia/internal/9055599XXXXX) State ROUTING going to sleep 2010-08-17 22:41:12.644456 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/9055599XXXXX) Running State Change CS_CONSUME_MEDIA 2010-08-17 22:41:12.644456 [DEBUG] switch_core_state_machine.c:360 (sofia/internal/9055599XXXXX) State CONSUME_MEDIA 2010-08-17 22:41:12.645373 [DEBUG] switch_core_state_machine.c:360 (sofia/internal/9055599XXXXX) State CONSUME_MEDIA going to sleep 2010-08-17 22:41:42.806367 [DEBUG] sofia.c:4318 Channel sofia/internal/9055599XXXXX entering state [calling][0] 2010-08-17 22:41:42.890442 [INFO] sofia.c:662 sofia/internal/9055599XXXXX Update Callee ID to "9055599XXXXX" <9055599XXXXX> 2010-08-17 22:41:42.894355 [DEBUG] sofia.c:4318 Channel sofia/internal/9055599XXXXX entering state [proceeding][183] 2010-08-17 22:41:42.894355 [NOTICE] sofia.c:4390 Ring-Ready sofia/internal/9055599XXXXX! 2010-08-17 22:41:42.895440 [DEBUG] sofia.c:4318 Channel sofia/internal/9055599XXXXX entering state [proceeding][183] 2010-08-17 22:41:42.895440 [DEBUG] sofia.c:4329 Remote SDP: 2010-08-17 22:41:42.895440 [DEBUG] sofia_glue.c:2444 Set Codec sofia/internal/9055599XXXXX PCMA/8000 20 ms 160 samples 2010-08-17 22:41:42.896357 [DEBUG] sofia_glue.c:3937 Set 2833 dtmf send payload to 101 2010-08-17 22:41:42.896357 [DEBUG] sofia_glue.c:2684 AUDIO RTP [sofia/internal/9055599XXXXX] 10.100.224.10 port 31416 -> 10.100.199.19 port 18620 codec: 8 ms: 20 2010-08-17 22:41:42.896357 [DEBUG] switch_rtp.c:1413 Starting timer [soft] 160 bytes per 20ms 2010-08-17 22:41:42.897431 [DEBUG] sofia_glue.c:2894 Set 2833 dtmf send payload to 101 2010-08-17 22:41:42.897431 [DEBUG] sofia_glue.c:2899 Set 2833 dtmf receive payload to 101 2010-08-17 22:41:42.897431 [NOTICE] sofia_glue.c:3292 Pre-Answer sofia/internal/9055599XXXXX! 2010-08-17 22:41:42.897431 [DEBUG] switch_channel.c:2397 (sofia/internal/9055599XXXXX) Callstate Change RINGING -> EARLY 2010-08-17 22:41:42.916461 [DEBUG] sofia.c:4313 Channel sofia/internal/9055599XXXXX skipping state [proceeding][180] 2010-08-17 22:41:43.434412 [DEBUG] sofia.c:4318 Channel sofia/internal/9055599XXXXX entering state [completing][200] 2010-08-17 22:41:43.434412 [DEBUG] sofia.c:4326 Duplicate SDP 2010-08-17 22:41:52.000488 [DEBUG] switch_channel.c:2309 (sofia/internal/9055599XXXXX) Callstate Change EARLY -> HANGUP 2010-08-17 22:41:52.000488 [NOTICE] switch_ivr_originate.c:3282 Hangup sofia/internal/9055599XXXXX [CS_CONSUME_MEDIA] [NO_ANSWER] 2010-08-17 22:41:52.000488 [DEBUG] switch_channel.c:2325 Send signal sofia/internal/9055599XXXXX [KILL] 2010-08-17 22:41:52.000488 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/9055599XXXXX) Running State Change CS_HANGUP 2010-08-17 22:41:52.000488 [DEBUG] switch_core_state_machine.c:535 (sofia/internal/9055599XXXXX) State HANGUP 2010-08-17 22:41:52.000488 [DEBUG] mod_sofia.c:453 Channel sofia/internal/9055599XXXXX hanging up, cause: NO_ANSWER 2010-08-17 22:41:52.000488 [DEBUG] switch_core_session.c:1039 Send signal sofia/internal/9055599XXXXX [BREAK] 2010-08-17 22:41:55.204396 [DEBUG] mod_sofia.c:506 Sending CANCEL to sofia/internal/9055599XXXXX 2010-08-17 22:41:55.204396 [DEBUG] switch_core_state_machine.c:46 sofia/internal/9055599XXXXX Standard HANGUP, cause: NO_ANSWER 2010-08-17 22:41:55.204396 [DEBUG] switch_core_state_machine.c:535 (sofia/internal/9055599XXXXX) State HANGUP going to sleep 2010-08-17 22:41:55.204396 [DEBUG] switch_core_state_machine.c:333 (sofia/internal/9055599XXXXX) State Change CS_HANGUP -> CS_REPORTING 2010-08-17 22:41:55.204396 [DEBUG] switch_core_session.c:1039 Send signal sofia/internal/9055599XXXXX [BREAK] 2010-08-17 22:41:55.204396 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/9055599XXXXX) Running State Change CS_REPORTING 2010-08-17 22:41:55.205401 [DEBUG] switch_core_state_machine.c:595 (sofia/internal/9055599XXXXX) State REPORTING 2010-08-17 22:41:55.205401 [DEBUG] switch_core_state_machine.c:53 sofia/internal/9055599XXXXX Standard REPORTING, cause: NO_ANSWER 2010-08-17 22:41:55.205401 [DEBUG] switch_core_state_machine.c:595 (sofia/internal/9055599XXXXX) State REPORTING going to sleep 2010-08-17 22:41:55.206428 [DEBUG] switch_core_state_machine.c:327 (sofia/internal/9055599XXXXX) State Change CS_REPORTING -> CS_DESTROY 2010-08-17 22:41:55.206428 [DEBUG] switch_core_session.c:1039 Send signal sofia/internal/9055599XXXXX [BREAK] 2010-08-17 22:41:55.206428 [DEBUG] switch_core_session.c:1202 Session 18770 (sofia/internal/9055599XXXXX) Locked, Waiting on external entities 2010-08-17 22:41:55.206428 [NOTICE] switch_core_session.c:1220 Session 18770 (sofia/internal/9055599XXXXX) Ended 2010-08-17 22:41:55.206428 [NOTICE] switch_core_session.c:1222 Close Channel sofia/internal/9055599XXXXX [CS_DESTROY] 2010-08-17 22:41:55.207463 [DEBUG] switch_core_state_machine.c:427 (sofia/internal/9055599XXXXX) Callstate Change HANGUP -> DOWN 2010-08-17 22:41:55.207463 [DEBUG] switch_core_state_machine.c:430 (sofia/internal/9055599XXXXX) Running State Change CS_DESTROY 2010-08-17 22:41:55.207463 [DEBUG] switch_core_state_machine.c:440 (sofia/internal/9055599XXXXX) State DESTROY 2010-08-17 22:41:55.207463 [DEBUG] mod_sofia.c:358 sofia/internal/9055599XXXXX SOFIA DESTROY 2010-08-17 22:41:55.207463 [DEBUG] switch_core_state_machine.c:60 sofia/internal/9055599XXXXX Standard DESTROY 2010-08-17 22:41:55.207463 [DEBUG] switch_core_state_machine.c:440 (sofia/internal/9055599XXXXX) State DESTROY going to sleep ---------- Weitergeleitete Nachricht ---------- > From: Brian West <brian(a)freeswitch.org> > To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> > Date: Mon, 23 Aug 2010 09:29:32 -0500 > Subject: Re: [Freeswitch-users] Wrong hangup cause (NO_ANSWER) while > answered session > Without that we can't help. You also need to make sure you're on the very > latest code. The one thing I'm sure we get right are the hangup causes > unless you're doing something to override them. > > /b > > On Aug 23, 2010, at 9:24 AM, Durmuş Ali Öztürk wrote: > > > I'm afraid, sip trace wasnt active. > > ---------- Weitergeleitete Nachricht ---------- > From: Steven Ayre <steveayre(a)gmail.com> > To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> > Date: Mon, 23 Aug 2010 11:53:33 +0100 > Subject: Re: [Freeswitch-users] Wrong hangup cause (NO_ANSWER) while > answered session > Do you have a sip trace for those calls? > > > On 23 August 2010 11:36, Durmuş Ali Öztürk <ali.stgt(a)gmail.com> wrote: > Hello, > > we had some trouble while executing a bulk call process with originating a > parallel call of 200. Because in many cases, FreeSWITCH has notified hangups > (SWITCH_EVENT_CHANNEL_HANGUP_COMPLETE) with the wrong hangup-cause. Instead > of notifying the successful state, we got the NO_ANSWER hangup cause. BUSY > and NO_ANSWER states are candidates for retries, therefor many numbers are > called/payed twice. See log below. > > Some other questions: > > B) Is the originate_timeout value an overall timer or a timer for the > ringing (starts if SIP code 180 incomes?) stage. > > C) We are originating each number in a separate thread and listen to the > channel events for updating the call result. Should we change this > implementation or is this a good scenario/standard way. Related to the call > result, if it is busy or not answered, the call is retried after 30 min. > What are the recommends on this side to be ensured, the correct hangup case > be got and the number is not called twice.. > > D) What do I have to bear in mind for bulk calls with parallel calls over > 200. > > Thanks for your answer in advance. > > Ali

4 3

Re: [Freeswitch-users] Wrong hangup cause (NO_ANSWER) while answered session
by Durmuş Ali Öztürk 23 Aug '10

23 Aug '10

I'm afraid, sip trace wasnt active. ---------- Weitergeleitete Nachricht ---------- > From: Steven Ayre <steveayre(a)gmail.com> > To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> > Date: Mon, 23 Aug 2010 11:53:33 +0100 > Subject: Re: [Freeswitch-users] Wrong hangup cause (NO_ANSWER) while > answered session > Do you have a sip trace for those calls? > > > On 23 August 2010 11:36, Durmuş Ali Öztürk <ali.stgt(a)gmail.com> wrote: > >> Hello, >> >> we had some trouble while executing a bulk call process with originating a >> parallel call of 200. Because in many cases, FreeSWITCH has notified hangups >> (SWITCH_EVENT_CHANNEL_HANGUP_COMPLETE) with the wrong hangup-cause. Instead >> of notifying the successful state, we got the NO_ANSWER hangup cause. BUSY >> and NO_ANSWER states are candidates for retries, therefor many numbers are >> called/payed twice. See log below. >> >> Some other questions: >> >> B) Is the originate_timeout value an overall timer or a timer for the >> ringing (starts if SIP code 180 incomes?) stage. >> >> C) We are originating each number in a separate thread and listen to the >> channel events for updating the call result. Should we change this >> implementation or is this a good scenario/standard way. Related to the call >> result, if it is busy or not answered, the call is retried after 30 min. >> What are the recommends on this side to be ensured, the correct hangup case >> be got and the number is not called twice.. >> >> D) What do I have to bear in mind for bulk calls with parallel calls over >> 200. >> >> Thanks for your answer in advance. >> >> Ali >> >> >> An extraction of the log (regard to the first issue): >> >> 2010-08-17 22:40:51.087402 [DEBUG] switch_ivr_originate.c:1979 variable >> string 0 = [sip_from_uri=sip:xxxx@xxxxx] >> 2010-08-17 22:40:51.087402 [DEBUG] switch_ivr_originate.c:1979 variable >> string 1 = [ignore_early_media=true] >> 2010-08-17 22:40:51.087402 [DEBUG] switch_ivr_originate.c:1979 variable >> string 2 = [sip_cid_type=none] >> 2010-08-17 22:40:51.087402 [DEBUG] switch_ivr_originate.c:1979 variable >> string 3 = [originate_timeout=40] >> 2010-08-17 22:41:09.904378 [NOTICE] switch_channel.c:779 New Channel >> sofia/internal/9055599XXXXX [9e4b396e-3d99-445f-a2e8-227e99f3f0ef] >> 2010-08-17 22:41:12.641362 [DEBUG] mod_sofia.c:3892 >> (sofia/internal/9055599XXXXX) State Change CS_NEW -> CS_INIT >> 2010-08-17 22:41:12.641362 [DEBUG] switch_core_session.c:1039 Send signal >> sofia/internal/9055599XXXXX [BREAK] >> 2010-08-17 22:41:12.641362 [DEBUG] switch_core_session.c:454 >> sofia/internal/9055599XXXXX set UUID=9dc8a739-f439-4815-981a-347b7a90a1a8 >> 2010-08-17 22:41:12.642441 [DEBUG] switch_core_state_machine.c:314 >> (sofia/internal/9055599XXXXX) Running State Change CS_INIT >> 2010-08-17 22:41:12.642441 [DEBUG] switch_core_state_machine.c:338 >> (sofia/internal/9055599XXXXX) State INIT >> 2010-08-17 22:41:12.642441 [DEBUG] mod_sofia.c:83 >> sofia/internal/9055599XXXXX SOFIA INIT >> 2010-08-17 22:41:12.643399 [DEBUG] mod_sofia.c:119 >> (sofia/internal/9055599XXXXX) State Change CS_INIT -> CS_ROUTING >> 2010-08-17 22:41:12.643399 [DEBUG] switch_core_session.c:1039 Send signal >> sofia/internal/9055599XXXXX [BREAK] >> 2010-08-17 22:41:12.643399 [DEBUG] switch_core_state_machine.c:338 >> (sofia/internal/9055599XXXXX) State INIT going to sleep >> 2010-08-17 22:41:12.643399 [DEBUG] switch_core_state_machine.c:314 >> (sofia/internal/9055599XXXXX) Running State Change CS_ROUTING >> 2010-08-17 22:41:12.644456 [DEBUG] switch_channel.c:1512 >> (sofia/internal/9055599XXXXX) Callstate Change DOWN -> RINGING >> 2010-08-17 22:41:12.644456 [DEBUG] switch_core_state_machine.c:341 >> (sofia/internal/9055599XXXXX) State ROUTING >> 2010-08-17 22:41:12.644456 [DEBUG] mod_sofia.c:142 >> sofia/internal/9055599XXXXX SOFIA ROUTING >> 2010-08-17 22:41:12.644456 [DEBUG] switch_ivr_originate.c:66 >> (sofia/internal/9055599XXXXX) State Change CS_ROUTING -> CS_CONSUME_MEDIA >> 2010-08-17 22:41:12.644456 [DEBUG] switch_core_session.c:1039 Send signal >> sofia/internal/9055599XXXXX [BREAK] >> 2010-08-17 22:41:12.644456 [DEBUG] switch_core_state_machine.c:341 >> (sofia/internal/9055599XXXXX) State ROUTING going to sleep >> 2010-08-17 22:41:12.644456 [DEBUG] switch_core_state_machine.c:314 >> (sofia/internal/9055599XXXXX) Running State Change CS_CONSUME_MEDIA >> 2010-08-17 22:41:12.644456 [DEBUG] switch_core_state_machine.c:360 >> (sofia/internal/9055599XXXXX) State CONSUME_MEDIA >> 2010-08-17 22:41:12.645373 [DEBUG] switch_core_state_machine.c:360 >> (sofia/internal/9055599XXXXX) State CONSUME_MEDIA going to sleep >> 2010-08-17 22:41:42.806367 [DEBUG] sofia.c:4318 Channel >> sofia/internal/9055599XXXXX entering state [calling][0] >> 2010-08-17 22:41:42.890442 [INFO] sofia.c:662 sofia/internal/9055599XXXXX >> Update Callee ID to "9055599XXXXX" <9055599XXXXX> >> 2010-08-17 22:41:42.894355 [DEBUG] sofia.c:4318 Channel >> sofia/internal/9055599XXXXX entering state [proceeding][183] >> 2010-08-17 22:41:42.894355 [NOTICE] sofia.c:4390 Ring-Ready >> sofia/internal/9055599XXXXX! >> 2010-08-17 22:41:42.895440 [DEBUG] sofia.c:4318 Channel >> sofia/internal/9055599XXXXX entering state [proceeding][183] >> 2010-08-17 22:41:42.895440 [DEBUG] sofia.c:4329 Remote SDP: >> 2010-08-17 22:41:42.895440 [DEBUG] sofia_glue.c:2444 Set Codec >> sofia/internal/9055599XXXXX PCMA/8000 20 ms 160 samples >> 2010-08-17 22:41:42.896357 [DEBUG] sofia_glue.c:3937 Set 2833 dtmf send >> payload to 101 >> 2010-08-17 22:41:42.896357 [DEBUG] sofia_glue.c:2684 AUDIO RTP >> [sofia/internal/9055599XXXXX] 10.100.224.10 port 31416 -> 10.100.199.19 port >> 18620 codec: 8 ms: 20 >> 2010-08-17 22:41:42.896357 [DEBUG] switch_rtp.c:1413 Starting timer [soft] >> 160 bytes per 20ms >> 2010-08-17 22:41:42.897431 [DEBUG] sofia_glue.c:2894 Set 2833 dtmf send >> payload to 101 >> 2010-08-17 22:41:42.897431 [DEBUG] sofia_glue.c:2899 Set 2833 dtmf receive >> payload to 101 >> 2010-08-17 22:41:42.897431 [NOTICE] sofia_glue.c:3292 Pre-Answer >> sofia/internal/9055599XXXXX! >> 2010-08-17 22:41:42.897431 [DEBUG] switch_channel.c:2397 >> (sofia/internal/9055599XXXXX) Callstate Change RINGING -> EARLY >> 2010-08-17 22:41:42.916461 [DEBUG] sofia.c:4313 Channel >> sofia/internal/9055599XXXXX skipping state [proceeding][180] >> 2010-08-17 22:41:43.434412 [DEBUG] sofia.c:4318 Channel >> sofia/internal/9055599XXXXX entering state [completing][200] >> 2010-08-17 22:41:43.434412 [DEBUG] sofia.c:4326 Duplicate SDP >> 2010-08-17 22:41:52.000488 [DEBUG] switch_channel.c:2309 >> (sofia/internal/9055599XXXXX) Callstate Change EARLY -> HANGUP >> 2010-08-17 22:41:52.000488 [NOTICE] switch_ivr_originate.c:3282 Hangup >> sofia/internal/9055599XXXXX [CS_CONSUME_MEDIA] [NO_ANSWER] >> 2010-08-17 22:41:52.000488 [DEBUG] switch_channel.c:2325 Send signal >> sofia/internal/9055599XXXXX [KILL] >> 2010-08-17 22:41:52.000488 [DEBUG] switch_core_state_machine.c:314 >> (sofia/internal/9055599XXXXX) Running State Change CS_HANGUP >> 2010-08-17 22:41:52.000488 [DEBUG] switch_core_state_machine.c:535 >> (sofia/internal/9055599XXXXX) State HANGUP >> 2010-08-17 22:41:52.000488 [DEBUG] mod_sofia.c:453 Channel >> sofia/internal/9055599XXXXX hanging up, cause: NO_ANSWER >> 2010-08-17 22:41:52.000488 [DEBUG] switch_core_session.c:1039 Send signal >> sofia/internal/9055599XXXXX [BREAK] >> 2010-08-17 22:41:55.204396 [DEBUG] mod_sofia.c:506 Sending CANCEL to >> sofia/internal/9055599XXXXX >> 2010-08-17 22:41:55.204396 [DEBUG] switch_core_state_machine.c:46 >> sofia/internal/9055599XXXXX Standard HANGUP, cause: NO_ANSWER >> 2010-08-17 22:41:55.204396 [DEBUG] switch_core_state_machine.c:535 >> (sofia/internal/9055599XXXXX) State HANGUP going to sleep >> 2010-08-17 22:41:55.204396 [DEBUG] switch_core_state_machine.c:333 >> (sofia/internal/9055599XXXXX) State Change CS_HANGUP -> CS_REPORTING >> 2010-08-17 22:41:55.204396 [DEBUG] switch_core_session.c:1039 Send signal >> sofia/internal/9055599XXXXX [BREAK] >> 2010-08-17 22:41:55.204396 [DEBUG] switch_core_state_machine.c:314 >> (sofia/internal/9055599XXXXX) Running State Change CS_REPORTING >> 2010-08-17 22:41:55.205401 [DEBUG] switch_core_state_machine.c:595 >> (sofia/internal/9055599XXXXX) State REPORTING >> 2010-08-17 22:41:55.205401 [DEBUG] switch_core_state_machine.c:53 >> sofia/internal/9055599XXXXX Standard REPORTING, cause: NO_ANSWER >> 2010-08-17 22:41:55.205401 [DEBUG] switch_core_state_machine.c:595 >> (sofia/internal/9055599XXXXX) State REPORTING going to sleep >> 2010-08-17 22:41:55.206428 [DEBUG] switch_core_state_machine.c:327 >> (sofia/internal/9055599XXXXX) State Change CS_REPORTING -> CS_DESTROY >> 2010-08-17 22:41:55.206428 [DEBUG] switch_core_session.c:1039 Send signal >> sofia/internal/9055599XXXXX [BREAK] >> 2010-08-17 22:41:55.206428 [DEBUG] switch_core_session.c:1202 Session >> 18770 (sofia/internal/9055599XXXXX) Locked, Waiting on external entities >> 2010-08-17 22:41:55.206428 [NOTICE] switch_core_session.c:1220 Session >> 18770 (sofia/internal/9055599XXXXX) Ended >> 2010-08-17 22:41:55.206428 [NOTICE] switch_core_session.c:1222 Close >> Channel sofia/internal/9055599XXXXX [CS_DESTROY] >> 2010-08-17 22:41:55.207463 [DEBUG] switch_core_state_machine.c:427 >> (sofia/internal/9055599XXXXX) Callstate Change HANGUP -> DOWN >> 2010-08-17 22:41:55.207463 [DEBUG] switch_core_state_machine.c:430 >> (sofia/internal/9055599XXXXX) Running State Change CS_DESTROY >> 2010-08-17 22:41:55.207463 [DEBUG] switch_core_state_machine.c:440 >> (sofia/internal/9055599XXXXX) State DESTROY >> 2010-08-17 22:41:55.207463 [DEBUG] mod_sofia.c:358 >> sofia/internal/9055599XXXXX SOFIA DESTROY >> 2010-08-17 22:41:55.207463 [DEBUG] switch_core_state_machine.c:60 >> sofia/internal/9055599XXXXX Standard DESTROY >> 2010-08-17 22:41:55.207463 [DEBUG] switch_core_state_machine.c:440 >> (sofia/internal/9055599XXXXX) State DESTROY going to sleep >> >> >> >> _______________________________________________ >> FreeSWITCH-users mailing list >> FreeSWITCH-users(a)lists.freeswitch.org >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >> http://www.freeswitch.org >> >

2 1

repeat a submenu in ivr?
by Seven Du 23 Aug '10

23 Aug '10

Hi, >From http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_ivr , it can repeat a main menu by menu-top, <entry action="menu-top" digits="9"/>  But, how to repeat a submenu? -- Blog: http://www.dujinfang.com Proj: http://www.freeswitch.org.cn

2 2

Re: [Freeswitch-users] freeswitch CPU usage
by Kristian Kielhofner 23 Aug '10

23 Aug '10

Is this implementation open source? -- Kristian Kielhofner http://blog.krisk.org ----- Original Message ----- From: freeswitch-users-bounces(a)lists.freeswitch.org <freeswitch-users-bounces(a)lists.freeswitch.org> To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> Sent: Mon Aug 23 09:44:04 2010 Subject: Re: [Freeswitch-users] freeswitch CPU usage Based on my experiment, that is still the case with CentOS. After using my own UDP, I was able to get 70K pps on 1 ethernet card on a Intel 5550. The limitation is that I don't have enough machine power to fire off enough calls to max it out. On Mon, Aug 23, 2010 at 8:25 PM, Nyamul Hassan <mnhassan(a)usa.net> wrote: > Is this also the case for the recommended CentOS / RHEL? Do you still > have > to resort to having your own UDP implementation to max out Eth Card > limitation? > In the past, I have found a limitation on Linux, that the eth driver is > single-threaded. So, I couldn't push beyond 50K pps on a Intel Quad E5504 > HP machine through 1 ethernet card. > Regards > HASSAN > > On Mon, Aug 23, 2010 at 09:34, Woody Dickson <woodydickson(a)gmail.com> > wrote: >> >> Hi Vince, >> >> I have played with running Freeswitch on BSD too but the result is not >> great. The reason seems to be because BSD's threading is not as >> efficient as the one in Linux or there may be some other ways to tune >> it. BSD does give a better pure UDP throughput performance by the >> way. >> >> So what I ended up doing is developing my own UDP implementation which >> enable media to move through the ethernet at raw wire speed. I am >> able to max out the ethernet card limitation on Linux platform as a >> result of that. >> >> Woody >> >> >> On Mon, Aug 23, 2010 at 1:53 AM, Vincent Stemen >> <vince.freeswitch(a)hightek.org> wrote: >> > On Fri, Aug 20, 2010 at 05:29:31PM +0800, Woody Dickson wrote: >> >> Hi, >> >> >> >> I am doing some experiments with Freeswitch by torturing it to see how >> >> the machine's CPU response to heavy loaded situation. >> >> The test is done on a 16 core 5550 dual quad core server running >> >> fedora 2.6.30.10-105.2.23.fc11.x86_64 OS. >> >> >> >> What I found so strange was that while CPU usage remains pretty low >> >> and distributed among all cores at 190 - 200 calls per second. Then, >> >> after added a few more calls per second, all CPU becomes fully >> >> utilized. >> >> >> >> Is this due to some wrong setting? Any idea how I can tweak the >> >> configuration and continue my test? >> >> >> >> Thanks, >> >> Woody >> > >> > Hi Woody. >> > >> > I would hazard to guess that this could be a Linux resource management >> > issue. I don't have any experience with SMP on Linux, but Linux has >> > a long history of memory management (among other) problems. We ran >> > Linux exclusively on all our servers and workstations for over 10 years >> > before finally switching to BSD several years ago. We had continuous >> > problems ranging from minor strange unexplained behaviours, as you >> > describe, to what appeared to be bugs in applications, to outright >> > crashes and freezes of the whole OS every day. When we switched to BSD >> > nearly all the problems went away. Even some of the (what appeared to >> > be) bugs in Linux binary applications went way, going from Linux to BSD >> > running under Linux emulation (without re-compiling), using the same >> > Linux libraries on the same hardware. >> > >> > An interesting test would be to try the same load test with BSD on the >> > same machine and see if you get a similar result. >> > >> > Regards, >> > Vince >> > >> > >> > _______________________________________________ >> > FreeSWITCH-users mailing list >> > FreeSWITCH-users(a)lists.freeswitch.org >> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >> > http://www.freeswitch.org >> > >> >> _______________________________________________ >> FreeSWITCH-users mailing list >> FreeSWITCH-users(a)lists.freeswitch.org >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >> http://www.freeswitch.org > > > _______________________________________________ > FreeSWITCH-users mailing list > FreeSWITCH-users(a)lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org > > _______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users(a)lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

1 0

Custom SIP Notify via proxy
by Neil Burgess 23 Aug '10

23 Aug '10

Hello, Sent this post a couple of weeks back. Still trying to find a solution, so trying again and see if anyone has any thoughts! I am trying to send CUSTOM NOTIFY events to devices, using the ESL interface with a PHP script of the following form. I am having partial success, but coming up against problems when using with an outbound SIP proxy:- $e = new ESLevent("NOTIFY"); $e->addHeader("profile", "internal"); $e->addHeader("from", "1020"); $e->addHeader("to-uri", "sip:1019@192.168.2.3:5063;fs_path=sip:82.24.214.226:5063"); $e->addHeader("from-uri", "sip:1020@pbx.rm.com"); $e->addHeader("host", "pbx.rm.com"); $e->addHeader("event-string", "check-sync"); $e->addHeader("content-type", "application/simple-message-summary"); $e->addBody("ok"); $res = $sockFSServerCommand->sendEvent($e); In our setup, we have several FreeSwitch boxes sitting behind two OpenSIPS load balancers. These Load Balancers handle registrations, etc. When we originate calls from FreeSwitch, we use an originate URL of the form (sofia/internal/1001@sip.redmatter.com;fs_path=sip:84.45.30.2<mailto:sofia/internal/1001@sip.redmatter.com;fs_path=sip:84.45.30.2>), and use fs_path to push the sip call out via the right load balancer/ proxy. This works perfectly. So, with the custom NOTIFY's I also need to make them follow the same path. As mentioned, we already have the contact string in our hand from the OpenSIPS registration server, but can't see how I can use that plus force the outbound path for the Notify. Was thinking I could use fs_path in the uri (as above) but doesn't seem to work, i.e. the wrong IP is used, and NOTIFY is messed up somewhat (see example below)! Maybe another combination I am missing! ------------------------ NOTIFY sip:1019@192.168.2.3:5063;fs_path=sip:82.24.214.22:5063 SIP/2.0 Via: SIP/2.0/UDP 212.85.24.245;rport;branch=z9hG4bKv268QHcy539yc Max-Forwards: 70 From: <sip:1020@pbx.rm.com>;tag=0rer8BS2etmmc To: <sip:1019@192.168.2.3:5063>;fs_path=sip:82.24.214.22:5063 Call-ID: 5a08d5c6-1a8e-122e-3885-0024e86c401a CSeq: 134921 NOTIFY Contact: <sip:mod_sofia@212.85.24.245:5060> User-Agent: FreeSWITCH-mod_sofia/1.0.5-20100211-0400-16602 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: precondition, path, replaces Event: check-sync Allow-Events: talk, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Subscription-State: terminated;reason=timeout Content-Type: application/simple-message-summary Content-Length: 2 ok ------------------ Any thoughts gratefully appreciated. Rgds, Neil

1 0