August 2010 - FreeSWITCH-users - FreeSWITCH Mailing Lists

Wrong hangup cause (NO_ANSWER) while answered session
by Durmuş Ali Öztürk 25 Aug '10

25 Aug '10

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

2 4

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

25 Aug '10

Brian, we are not bridging calls. FreeSWITCH (Leg A) as the caller can not be in a 'not answered' state. Also if I see 200 then it must be come from Leg B (the callee) which means that other party has answered the call. Also, both legs was active but FS had reported us the opposite. And this happened more than 40.000 times between 8 hours. I would like to know what you are expecting from the sip trace, because the log is detailed enough to be verified that FS has catched the 200 SIP - but it seems to be ignored (maybe hangup timer started or something else) therefor the session is closed with the wrong state. It is also clear for me, that FS is *over-challenged* to set the correct hangup cause in bulk calls over 200 cps. @Milena We must to re-call all numbers again to give you a SIP trace but this is to expensive for us :-) > > ---------- Weitergeleitete Nachricht ---------- > From: Milena <testeador01(a)gmail.com> > To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> > Date: Mon, 23 Aug 2010 10:17:37 -0500 > Subject: Re: [Freeswitch-users] Wrong hangup cause (NO_ANSWER) while > answered session > type "version" on the CLI > > If the "sip trace wasnt active" then activate it and pastebin it, that's > the only way you can get help with this, you know the developers are experts > not soothsayers :) > > > -Mile > > 2010/8/23 Durmuş Ali Öztürk <ali.stgt(a)gmail.com> > >> I have setup freeswitch by using git and followed the instructions on the >> wiki page. How can I retrieve the exact git version? >> > > > ---------- Weitergeleitete Nachricht ---------- > From: Brian West <brian(a)freeswitch.org> > To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> > Date: Mon, 23 Aug 2010 10:18:30 -0500 > Subject: Re: [Freeswitch-users] Wrong hangup cause (NO_ANSWER) while > answered session > Again without a SIP trace I can't say... You have to remember that > FreeSWITCH is a B2BUA and a call thru it results in TWO legs. If you were > to ANSWER the first but then bridge to the second then it didn't answer you > might still get a NO_ANSWER even thou you see the 200ok for the one leg of > the call. > > /b > > On Aug 23, 2010, at 10:08 AM, Durmuş Ali Öztürk wrote: > > > 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? > > > > > > ---------- Weitergeleitete Nachricht ---------- > From: Sergey Okhapkin <sos(a)sokhapkin.dyndns.org> > To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> > Date: Mon, 23 Aug 2010 11:22:37 -0400 > Subject: Re: [Freeswitch-users] Wrong hangup cause (NO_ANSWER) while > answered session > You're running concurrent calls, hangup cause NO_ANSWER and log line with > 200 > OK belong to different calls. > > On Monday 23 August 2010, Durmuş Ali Öztürk wrote: > > 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 > > > >

3 2

Account selection
by Ken Gillett 25 Aug '10

25 Aug '10

If one wishes to have use of several VOIP 'lines', but with no PBX, you need to register all those SIP accounts with the client (softphone etc). You should then be informed which account is receiving a call and can pick a particular account from which to make calls. Once a PBX is in use, you can register the client as a single extension of the PBX and direct calls as appropriate to that extension - I assume with the correct caller ID and incoming account information passed to the recipient so they know as much as in the 'no PBX' configuration. But what about outgoing calls. In this scenario, registered as a single extension, how would it be possible to pick the outgoing 'line' (i.e. account) to use? Would it have to be done by dialling a prefix or is there another way? Is it client dependent? Ken G i l l e t t _/_/_/_/_/_/_/_/

6 13

Predefined hangup cause possible for originate?
by Helmut Kuper 25 Aug '10

25 Aug '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, is it possible, to load originate command with a predefined hangup cause e.g. "completed_elsewhere" when originate-call-timeout occured? regards helmut -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFMc86L4tZeNddg3dwRAuWEAKCzxADKkpv6x/gc8Xkmgy8QaGhXUACfSr8R Gh+h7TEqV8KR7Xe+GdrS7wM= =pLvI -----END PGP SIGNATURE-----

2 2

ivr menu matching and execution problem
by Antonio 25 Aug '10

25 Aug '10

During the configuration of an ivr menu and test i just realized that if you have multiple actions with the same "digits" it executes the both actions. The execution of the multiple actions is normal? The normal behavior should executed only the action that is match first, reading the priority of the entries in the menu. I look at the code, and in the function, switch_ivr_menu_execute, looks like the loop that searches for the match/action should need a break after a success match, to avoid the continues search for other matches. Thanks, António /* configuration */ <menu name="ivr" greet-long="/home/system/telephony/sounds/buraka.mp3" exit-sound="/home/system/telephony/sounds/prompt/en/conf-invalid.gsm" timeout ="2000" inter-digit-timeout="2000" max-failures="10" digit-len="4" > <entry action="menu-exec-app" digits="/^(10[0-9])$/" param="transfer $1 XML local"/> <entry action="menu-exec-app" digits="9" param="transfer 9 XML ivr-[1]"/> <entry action="menu-exec-app" digits="9" param="transfer 8 XML ivr-[1]"/> </menu> /* some log from fs */ 2010-08-24 17:07:47.888057 [DEBUG] switch_ivr_menu.c:777 building menu 'ivr' 2010-08-24 17:07:47.888057 [DEBUG] switch_ivr_menu.c:838 binding menu action 'menu-exec-app' to '/^(10[0-9])$/' 2010-08-24 17:07:47.888057 [DEBUG] switch_ivr_menu.c:838 binding menu action 'menu-exec-app' to '9' 2010-08-24 17:07:47.888057 [DEBUG] switch_ivr_menu.c:838 binding menu action 'menu-exec-app' to '9' 2010-08-24 17:07:47.888057 [DEBUG] switch_ivr_menu.c:414 Executing IVR menu ivr 2010-08-24 17:07:52.616160 [DEBUG] switch_rtp.c:2892 RTP RECV DTMF 9:480 2010-08-24 17:07:52.617160 [DEBUG] switch_ivr_play_say.c:1468 done playing file 2010-08-24 17:07:52.617160 [DEBUG] switch_ivr_menu.c:329 waiting for 3/4 digits t/o 2000 2010-08-24 17:07:54.635190 [DEBUG] switch_ivr_menu.c:376 digits '9' 2010-08-24 17:07:54.635190 [DEBUG] switch_ivr_menu.c:488 IVR action on menu 'ivr' matched '9' param 'transfer 8 XML ivr-[1]' 2010-08-24 17:07:54.635190 [DEBUG] switch_ivr_menu.c:492 switch_ivr_menu_execute todo=[2] EXECUTE sofia/192.168.10.25/101(a)192.168.10.25 transfer(8 XML ivr-[1]) 2010-08-24 17:07:54.635190 [DEBUG] switch_ivr.c:1470 (sofia/192.168.10.25/101(a)192.168.10.25) State Change CS_EXECUTE -> CS_ROUTING 2010-08-24 17:07:54.635190 [DEBUG] switch_core_session.c:1039 Send signal sofia/192.168.10.25/101(a)192.168.10.25 [BREAK] 2010-08-24 17:07:54.635190 [DEBUG] switch_core_session.c:658 Send signal sofia/192.168.10.25/101(a)192.168.10.25 [BREAK] 2010-08-24 17:07:54.635190 [NOTICE] switch_ivr.c:1476 Transfer sofia/192.168.10.25/101(a)192.168.10.25 to XML[8@ivr-[1]] 2010-08-24 17:07:54.635190 [DEBUG] switch_ivr_menu.c:488 IVR action on menu 'ivr' matched '9' param 'transfer 9 XML ivr-[1]' 2010-08-24 17:07:54.635190 [DEBUG] switch_ivr_menu.c:492 switch_ivr_menu_execute todo=[2] EXECUTE sofia/192.168.10.25/101(a)192.168.10.25 transfer(9 XML ivr-[1]) 2010-08-24 17:07:54.635190 [DEBUG] switch_core_session.c:658 Send signal sofia/192.168.10.25/101(a)192.168.10.25 [BREAK] 2010-08-24 17:07:54.635190 [NOTICE] switch_ivr.c:1476 Transfer sofia/192.168.10.25/101(a)192.168.10.25 to XML[9@ivr-[1]] 2010-08-24 17:07:54.635190 [DEBUG] switch_ivr_menu.c:470 action regex [9] [/^(10[0-9])$/] [0] 2010-08-24 17:07:54.635190 [DEBUG] switch_ivr_menu.c:580 exit-sound '/home/system/telephony/sounds/prompt/en/conf-invalid.gsm' 2010-08-24 17:07:54.635190 [DEBUG] switch_core_state_machine.c:348 (sofia/192.168.10.25/101(a)192.168.10.25) State EXECUTE going to sleep 2010-08-24 17:07:54.635190 [DEBUG] switch_core_state_machine.c:314 (sofia/192.168.10.25/101(a)192.168.10.25) Running State Change CS_ROUTING 2010-08-24 17:07:54.635190 [DEBUG] switch_channel.c:1512 (sofia/192.168.10.25/101(a)192.168.10.25) Callstate Change ACTIVE -> RINGING 2010-08-24 17:07:54.635190 [DEBUG] switch_core_state_machine.c:341 (sofia/192.168.10.25/101(a)192.168.10.25) State ROUTING 2010-08-24 17:07:54.635190 [DEBUG] mod_sofia.c:142 sofia/192.168.10.25/101(a)192.168.10.25 SOFIA ROUTING 2010-08-24 17:07:54.635190 [DEBUG] switch_core_state_machine.c:77 sofia/192.168.10.25/101(a)192.168.10.25 Standard ROUTING 2010-08-24 17:07:54.635190 [INFO] mod_dialplan_xml.c:331 Processing 101->9 in context ivr-[1]

2 2

New Bounty (again): Improved Mod_voicemail Emulation
by Kristian Kielhofner 25 Aug '10

25 Aug '10

Hello everyone, While extensive tweaks to Mod_voicemail and phrases can get "pretty close" to emulating existing voicemail systems like Asterisk, "pretty close" doesn't cut it when you have many discerning users that have become accustomed to the behavior of a given system. I want to move to FreeSWITCH voicemail but I don't want to have to reprint quick reference cards and retrain users and support staff. I want to make FreeSWITCH mod_voicemail even better by expanding its already impressive customization. A few tweaks here, and few new features there and we should be able to do drop in replacements for Asterisk and presumably other voicemail systems. Official bounty here: http://jira.freeswitch.org/browse/BOUNTY-22 You'll notice I haven't included a dollar/euro/pound amount... Well it's because I'm not even sure of the scope of this work. I'm hoping to get some discussion going first (of course any work we pay for will be open source and given back). So, what are your thoughts? -- Kristian Kielhofner http://www.astlinux.org http://blog.krisk.org http://www.star2star.com http://www.submityoursip.com http://www.voalte.com

7 12

How to stop SPAM calls?
by Malay Thakershi 25 Aug '10

25 Aug '10

Hello, Since last few days my freeswitch server receives SPAM calls. 25 to 30 calls at the same time. It makes my mod_managed program crash. Unlike regular phone numbers in US, these seem to come from sip IP addresses. When I see location of these IP addresses, most of them seem to be from China. Sample from CDR: <caller_profile> <username>sip</username> <dialplan>XML</dialplan> <caller_id_name>sip</caller_id_name> <ani></ani> <aniii></aniii> <caller_id_number>sip</caller_id_number> <network_addr>113.105.152.220</network_addr> <rdnis>1442073479999</rdnis> <destination_number>1056</destination_number> <uuid>bef84579-d25a-ab4b-aa52-dbcf9d7509be</uuid> <source>mod_sofia</source> <context>default</context> <chan_name>sofia/sipinterface_1/sip(a)113.105.152.220</chan_name> </caller_profile> I am only expecting call from regular phone lines from USA. I use Vitelity and I have secured my Vitelity configuration (SOFIA) with secret code provided by them. How do I stop these anonymous SIP callers from crashing my system? Please help. Thank you.

6 16

mod_callcenter vs mod_fifo
by Juan Backson 25 Aug '10

25 Aug '10

Hi, I am doing an investigation of using freeswitch for a call center app. It seems like both mod_fifo and mod_callcenter can pretty much do the same thing. Can someone share a comparison analysis between the two? Which one is better in terms of functionality and efficiency? Thanks jb

1 0

incoming pots ring
by Brian May 25 Aug '10

25 Aug '10

Hello, Something that has been bugging me for a while is the behaviour when receiving an incoming ring from a pots connection. If the incoming connection stops ringing, it takes Freeswitch ages for it to realize. In fact, I have found even if the phone stops ringing after the first ring, Freeswitch doesn't realize until after it activates voicemail (IIRC 20 second delay). I can understand that Freeswitch can't work out the instant the phone has stopped ringing, but the delay seems to be excessively long - is it possible to tweak it? If so how? I am using freetdm with a TDM400 card. Thanks -- Brian May <brian(a)microcomaustralia.com.au>

3 3

Why not Ubuntu
by lloyd thomas 24 Aug '10

24 Aug '10

I have seen a few posts where it has been recommended not to use ubuntu to run freeswitch on. I'll admit I did not pay that much attention. Is there a really pressing reason not to or is it a preference of most users not to? I would prefer to use Ubuntu as that is what I am used to. Regards Lloydie T

2 1