November 2016 - FreeSWITCH-users - FreeSWITCH Mailing Lists

DESTINATION_OUT_OF_ORDER calls to mobile and fixed line not working
by vidhya sagar dixit 05 Nov '16

05 Nov '16

Hi Guys, I am using FreeSWITCH (Version 1.6.12 64bit) I am able to register sip softphone and able to make peer to peer calls without any problem. But I am not able to dial any mobile or fixed line number. External gateway is showing registered. Any help will be highly appreciated. Following is the log i get in cli : 2016-11-03 05:56:54.995540 [DEBUG] switch_core_codec.c:111 sofia/internal/ 3000@5.250.179.173:5090 Original read codec set to GSM:3 2016-11-03 05:56:54.995540 [DEBUG] switch_core_media.c:4572 Set telephone-event payload to 101@8000 2016-11-03 05:56:54.995540 [DEBUG] switch_core_media.c:4631 sofia/internal/ 3000@5.250.179.173:5090 Set 2833 dtmf send payload to 101 recv payload to 101 2016-11-03 05:56:54.995540 [DEBUG] sofia.c:7364 (sofia/internal/ 3000@5.250.179.173:5090) State Change CS_NEW -> CS_INIT 2016-11-03 05:56:54.995540 [DEBUG] switch_core_state_machine.c:584 (sofia/internal/3000@5.250.179.173:5090) Running State Change CS_INIT 2016-11-03 05:56:54.995540 [DEBUG] switch_core_state_machine.c:627 (sofia/internal/3000@5.250.179.173:5090) State INIT 2016-11-03 05:56:54.995540 [DEBUG] mod_sofia.c:90 sofia/internal/ 3000@5.250.179.173:5090 SOFIA INIT 2016-11-03 05:56:54.995540 [DEBUG] switch_core_state_machine.c:40 sofia/internal/3000@5.250.179.173:5090 Standard INIT 2016-11-03 05:56:54.995540 [DEBUG] switch_core_state_machine.c:48 (sofia/internal/3000@5.250.179.173:5090) State Change CS_INIT -> CS_ROUTING 2016-11-03 05:56:54.995540 [DEBUG] switch_core_state_machine.c:627 (sofia/internal/3000@5.250.179.173:5090) State INIT going to sleep 2016-11-03 05:56:54.995540 [DEBUG] switch_core_state_machine.c:584 (sofia/internal/3000@5.250.179.173:5090) Running State Change CS_ROUTING 2016-11-03 05:56:54.995540 [DEBUG] switch_channel.c:2249 (sofia/internal/ 3000@5.250.179.173:5090) Callstate Change DOWN -> RINGING 2016-11-03 05:56:54.995540 [DEBUG] switch_core_state_machine.c:643 (sofia/internal/3000@5.250.179.173:5090) State ROUTING 2016-11-03 05:56:54.995540 [DEBUG] mod_sofia.c:143 sofia/internal/ 3000@5.250.179.173:5090 SOFIA ROUTING 2016-11-03 05:56:54.995540 [DEBUG] switch_core_state_machine.c:236 sofia/internal/3000@5.250.179.173:5090 Standard ROUTING 2016-11-03 05:56:54.995540 [INFO] mod_dialplan_xml.c:637 Processing 3000 <3000>->00919971931166 in context 5.250.179.173 2016-11-03 05:56:55.015522 [DEBUG] freeswitch_lua.cpp:365 DBH handle 0x7f0cc4041120 Connected. 2016-11-03 05:56:55.255553 [DEBUG] freeswitch_lua.cpp:382 DBH handle 0x7f0cc4041120 released. Dialplan: sofia/internal/3000@5.250.179.173:5090 parsing [5.250.179.173->gateway1.00d1220] continue=false Dialplan: sofia/internal/3000@5.250.179.173:5090 Regex (FAIL) [gateway1.00d1220] destination_number(00919971931166) =~ /00^(\d{12,20})$/ break=on-false Dialplan: sofia/internal/3000@5.250.179.173:5090 parsing [5.250.179.173->gateway1.00d1220] continue=false Dialplan: sofia/internal/3000@5.250.179.173:5090 Regex (PASS) [gateway1.00d1220] destination_number(00919971931166) =~ /^(\d{12,20})$/ break=on-false Dialplan: sofia/internal/3000@5.250.179.173:5090 Action () Dialplan: sofia/internal/3000@5.250.179.173:5090 Action set(sip_h_X-accountcode=${accountcode}) Dialplan: sofia/internal/3000@5.250.179.173:5090 Action set(call_direction=outbound) Dialplan: sofia/internal/3000@5.250.179.173:5090 Action set(hangup_after_bridge=true) Dialplan: sofia/internal/3000@5.250.179.173:5090 Action set(effective_caller_id_name=${outbound_caller_id_name}) 2016-11-03 05:56:55.275562 [DEBUG] switch_core_state_machine.c:286 (sofia/internal/3000@5.250.179.173:5090) State Change CS_ROUTING -> CS_EXECUTE 2016-11-03 05:56:55.275562 [DEBUG] switch_core_state_machine.c:643 (sofia/internal/3000@5.250.179.173:5090) State ROUTING going to sleep 2016-11-03 05:56:55.275562 [DEBUG] switch_core_state_machine.c:584 (sofia/internal/3000@5.250.179.173:5090) Running State Change CS_EXECUTE 2016-11-03 05:56:55.275562 [DEBUG] switch_core_state_machine.c:650 (sofia/internal/3000@5.250.179.173:5090) State EXECUTE 2016-11-03 05:56:55.275562 [DEBUG] mod_sofia.c:198 sofia/internal/ 3000@5.250.179.173:5090 SOFIA EXECUTE 2016-11-03 05:56:55.275562 [DEBUG] switch_core_state_machine.c:328 sofia/internal/3000@5.250.179.173:5090 Standard EXECUTE 2016-11-03 05:56:55.275562 [ERR] switch_core_session.c:2604 Invalid Application 2016-11-03 05:56:55.275562 [NOTICE] switch_core_session.c:2605 Hangup sofia/internal/3000@5.250.179.173:5090 [CS_EXECUTE] [DESTINATION_OUT_OF_ORDER] 2016-11-03 05:56:55.275562 [DEBUG] switch_core_state_machine.c:650 (sofia/internal/3000@5.250.179.173:5090) State EXECUTE going to sleep 2016-11-03 05:56:55.275562 [DEBUG] switch_core_state_machine.c:584 (sofia/internal/3000@5.250.179.173:5090) Running State Change CS_HANGUP 2016-11-03 05:56:55.275562 [DEBUG] switch_core_state_machine.c:850 (sofia/internal/3000@5.250.179.173:5090) Callstate Change RINGING -> HANGUP 2016-11-03 05:56:55.275562 [DEBUG] switch_core_state_machine.c:852 (sofia/internal/3000@5.250.179.173:5090) State HANGUP 2016-11-03 05:56:55.275562 [DEBUG] mod_sofia.c:438 Channel sofia/internal/ 3000@5.250.179.173:5090 hanging up, cause: DESTINATION_OUT_OF_ORDER 2016-11-03 05:56:55.275562 [DEBUG] mod_sofia.c:577 Responding to INVITE with: 502 2016-11-03 05:56:55.275562 [DEBUG] switch_core_state_machine.c:60 sofia/internal/3000@5.250.179.173:5090 Standard HANGUP, cause: DESTINATION_OUT_OF_ORDER 2016-11-03 05:56:55.275562 [DEBUG] switch_core_state_machine.c:852 (sofia/internal/3000@5.250.179.173:5090) State HANGUP going to sleep 2016-11-03 05:56:55.275562 [DEBUG] switch_core_state_machine.c:619 (sofia/internal/3000@5.250.179.173:5090) State Change CS_HANGUP -> CS_REPORTING 2016-11-03 05:56:55.275562 [DEBUG] switch_core_state_machine.c:584 (sofia/internal/3000@5.250.179.173:5090) Running State Change CS_REPORTING 2016-11-03 05:56:55.275562 [DEBUG] switch_core_state_machine.c:938 (sofia/internal/3000@5.250.179.173:5090) State REPORTING 2016-11-03 05:56:55.355544 [DEBUG] switch_core_state_machine.c:174 sofia/internal/3000@5.250.179.173:5090 Standard REPORTING, cause: DESTINATION_OUT_OF_ORDER 2016-11-03 05:56:55.355544 [DEBUG] switch_core_state_machine.c:938 (sofia/internal/3000@5.250.179.173:5090) State REPORTING going to sleep 2016-11-03 05:56:55.355544 [DEBUG] switch_core_state_machine.c:610 (sofia/internal/3000@5.250.179.173:5090) State Change CS_REPORTING -> CS_DESTROY 2016-11-03 05:56:55.355544 [DEBUG] switch_core_session.c:1647 Session 8023 (sofia/internal/3000@5.250.179.173:5090) Locked, Waiting on external entities 2016-11-03 05:56:55.355544 [NOTICE] switch_core_session.c:1665 Session 8023 (sofia/internal/3000@5.250.179.173:5090) Ended 2016-11-03 05:56:55.355544 [NOTICE] switch_core_session.c:1669 Close Channel sofia/internal/3000@5.250.179.173:5090 [CS_DESTROY] 2016-11-03 05:56:55.355544 [DEBUG] switch_core_state_machine.c:741 (sofia/internal/3000@5.250.179.173:5090) Running State Change CS_DESTROY 2016-11-03 05:56:55.355544 [DEBUG] switch_core_state_machine.c:751 (sofia/internal/3000@5.250.179.173:5090) State DESTROY 2016-11-03 05:56:55.355544 [DEBUG] mod_sofia.c:343 sofia/internal/ 3000@5.250.179.173:5090 SOFIA DESTROY 2016-11-03 05:56:55.355544 [DEBUG] switch_core_state_machine.c:181 sofia/internal/3000@5.250.179.173:5090 Standard DESTROY 2016-11-03 05:56:55.355544 [DEBUG] switch_core_state_machine.c:751 (sofia/internal/3000@5.250.179.173:5090) State DESTROY going to sleep Thanks and Regards Vidhya Sagar Dixit

3 3

Re: [Freeswitch-users] SRTP support
by Tom Chen 04 Nov '16

04 Nov '16

Hi Brian, Thank you! Should I just add this line to vars.xml to "Accept/Offer SAVP/AVP with SAVP preferred"? <X-PRE-PROCESS cmd="set" data="rtp_secure_media=optional"/> Tom >Read the very long description on SRTP in the vars.xml file, It has some >extensive documentation on this topic. (Hint: were not a proxy.) On Wed, Oct 26, 2016 at 11:42 AM, Tom Chen <chentom60 at hotmail.com<http://lists.freeswitch.org/mailman/listinfo/freeswitch-users>> wrote: > Hello, > > > By default, Freeswitch seems always translates incoming SRTP packets to > outbound RTP only packets as the INVITE SIP message to Receiver from FS > contains only RTP/AVP audio media in SDP section even if the Caller's > INVITE has RTP/SAVP audio media only. > > > Caller to FS > > Session Initiation Protocol (INVITE) > > . . . . > > Session Description Protocol > > Session Description Protocol Version (v): 0 > > Owner/Creator, Session Id (o): 1001 625 1382 IN IP4 10.113.49.31 > > Session Attribute (a): rtcp-xr:rcvr-rtt=all:10000 > stat-summary=loss,dup,jitt,TTL voip-metrics > > Media Description, name and address (m): audio 7078 *RTP/SAVP* 96 97 98 > 99 0 8 101 100 102 > > > FS to Receiver > > Session Description Protocol > > Session Description Protocol Version (v): 0 > Owner/Creator, Session Id (o): FreeSWITCH 1477472443 1477472444 IN IP4 > 172.17.10.23 > > Media Description, name and address (m): audio 25206 *RTP/AVP* 0 8 101 > 13 > > > Is there a way to let FS send SRTP packets to receiver as the receiver can > accept SRTP media only? > > > Tom > > > ______

3 4

SIP MESSAGE messages
by Tom Fielding 04 Nov '16

04 Nov '16

Hi all, I was wondering if I needed to do anything special to route SIP MESSAGE messages from one endpoint to another via Freeswitch. Calls are able to be made between the endpoints but when a SIP MESSAGE is sent, the second leg incorrectly loops back to Freeswitch instead of being sent out to the recipient. Is there any special configuration that needs to be done to send a MESSAGE from one endpoint to another the way an INVITE is routed? Thanks!

2 2

unrelayed BYE
by David Villasmil 04 Nov '16

04 Nov '16

Hello guys, I have this situation where the whole call goes well, except the BYE. Freeswitch receives the BYE, but doesn't relay it, and I can't figure out why, here's a trace: recv 489 bytes from udp/[196.207.243.108]:5080 at 07:22:05.626643: ------------------------------------------------------------------------ BYE sip:gw+gw_108@196.207.243.245:5080;transport=udp;gw=gw_108 SIP/2.0 Via: SIP/2.0/UDP 196.207.243.108:5080;branch=z9hG4bK2e5f9502;rport Max-Forwards: 70 From: <sip:774720380@196.207.243.108:5080>;tag=as6c7e3a9d To: "721102372" <sip:721102372@196.207.243.245>;tag=a9B2UttKm9Nyg Call-ID: 16336d2d-1d02-1235-8693-0026b955dc81 CSeq: 102 BYE User-Agent: Asterisk PBX 11.23.0 X-Asterisk-HangupCause: Unallocated (unassigned) number X-Asterisk-HangupCauseCode: 1 Content-Length: 0 ------------------------------------------------------------------------ tport.c:3023 tport_deliver() tport_deliver(0x7f5a04004540): msg 0x7f5a04007eb0 (489 bytes) from udp/196.207.243.108:5080/sip next=(nil) nta.c:2880 agent_recv_request() nta: received BYE sip:gw+gw_108@196.207.243.245:5080;transport=udp;gw=gw_108 SIP/2.0 (CSeq 102) nta.c:3248 agent_aliases() nta: canonizing sip:gw+gw_108@196.207.243.245:5080 with contact nta.c:3060 agent_recv_request() nta: BYE (102) going to existing leg nua_server.c:102 nua_stack_process_request() nua: nua_stack_process_request: entering nua_stack.c:359 nua_application_event() nua: nua_application_event: entering nua.c:366 nua_handle_magic() nua: nua_handle_magic: entering nua.c:879 nua_respond() nua: nua_respond: entering nua_stack.c:529 nua_signal() nua(0x7f599c000d40): sent signal r_respond nua.c:342 nua_handle_bind() nua: nua_handle_bind: entering nua.c:921 nua_handle_destroy() nua: nua_handle_destroy: entering nua_stack.c:529 nua_signal() nua(0x7f599c000d40): sent signal r_destroy nua_params.c:480 nua_stack_set_params() nua: nua_stack_set_params: entering soa.c:403 soa_set_params() soa_set_params(static::0x7f5a04014610, ...) called tport.c:3257 tport_tsend() tport_tsend(0x7f5a04004540) tpn = UDP/ 196.207.243.108:5080 tport.c:4046 tport_resolve() tport_resolve addrinfo = 196.207.243.108:5080 tport.c:4680 tport_by_addrinfo() tport_by_addrinfo(0x7f5a04004540): not found by name UDP/196.207.243.108:5080 Any ideas? Thanks ᐧ

2 1

JSAPI in Verto
by Donny Hardyanto 04 Nov '16

04 Nov '16

Hi all, Is it possible to run JSAPI via verto? Is it as powerfull as Event Socket? Is there any way to secure it? I like to deploy the verto webrtc to website, but dont want any one can abuse and control my FS box via JSAPi/verto. Thanks, Donny

2 4

Re: [Freeswitch-users] FreeSwitch and CDR-Stats
by tarik＠pasifiktelekom.com.tr 03 Nov '16

03 Nov '16

1 0

How to figure out mod_sofia.c:4391 Gateway 'vgaccount' is down!
by Muhammad Naseer Bhatti 03 Nov '16

03 Nov '16

I am trying to diagnose a gateway down issue, 2016-11-02 17:59:41.304402 [ERR] mod_sofia.c:4391 Gateway 'vgaccount' is down! (Yes it’s a little old version but need to figure out the root cause) I have the gigantic sip trace and the log files but not able to figure out why I am seeing this message. Though at the same time I am able to ping the gateway fine from the same machine. What sort of symptoms should I look for in the log files? I am already looking into network connectivity and other system log files but nothing as of now. Thanks. via Newton Mail [https://cloudmagic.com/k/d/mailapp?ct=dx&cv=9.1.25&pv=10.12.1&source=email_…]

5 12

mod_event_socket with Dialplan Interaction
by Dimitry Nagorny 03 Nov '16

03 Nov '16

3 3

Windows build v1.6
by Gregor Nanger 03 Nov '16

03 Nov '16

Need some help. Pulled latest -v16 version and on windows build I get error: Error C2220 warning treated as error - no 'object' file generated FreeSwitchCoreLib D:\freeswitch\src\switch_rtp.c 38 It is in line 38 of file switch_rtp.c Any hints?

3 6

Re: [Freeswitch-users] FreeSwitch and CDR-Stats
by Mikhail Demekhov 03 Nov '16

03 Nov '16

Hi, > Thanks for the help! Cdr-pusher operates. But the CDR accumulates in the table cdr_import and I do not see CDR in Dashboard. djcelery_error.log: [2016-11-03 15:56:42,241: INFO/MainProcess] Connected to redis://localhost:6379/0 [2016-11-03 15:56:42,280: WARNING/MainProcess] celery@freesw ready. [2016-11-03 15:56:42,292: INFO/MainProcess] Received task: cdr.tasks.run_cdr_import[d85838e5-53b2-42c2-9966-efb9c10dcccd] [2016-11-03 15:56:42,295: INFO/MainProcess] Received task: cdr.tasks.refresh_materialized_views[4e2b2b34-ecf6-404d-add3-fb259142cdd9] [2016-11-03 15:56:42,297: INFO/Worker-11] cdr.tasks.refresh_materialized_views[4e2b2b34-ecf6-404d-add3-fb259142cdd9]: TASK :: refresh_materialized_views [2016-11-03 15:56:42,300: INFO/MainProcess] Received task: cdr.tasks.run_cdr_import[5e08cbbd-b6f5-40cb-9a57-a88a08a08efd] [2016-11-03 15:56:42,301: INFO/Worker-14] cdr.tasks.run_cdr_import[d85838e5-53b2-42c2-9966-efb9c10dcccd]: TASK :: run_cdr_import [2016-11-03 15:56:42,302: INFO/Worker-14] cdr.tasks.run_cdr_import[d85838e5-53b2-42c2-9966-efb9c10dcccd]: in func import_cdr... [2016-11-03 15:56:42,307: INFO/MainProcess] Received task: cdr.tasks.run_cdr_import[3a800491-a4e4-42ff-9da2-b98d0fa1f623] [2016-11-03 15:56:42,312: INFO/MainProcess] Received task: cdr.tasks.run_cdr_import[0a29e731-8692-420d-a05a-951ac7b0981f] [2016-11-03 15:56:42,317: INFO/MainProcess] Received task: cdr.tasks.run_cdr_import[623a625d-be2d-4345-8bd6-cca1d51fbf1b] [2016-11-03 15:56:42,318: INFO/MainProcess] Task cdr.tasks.run_cdr_import[5e08cbbd-b6f5-40cb-9a57-a88a08a08efd] succeeded in 0.00933933118358s: None [2016-11-03 15:56:42,319: INFO/MainProcess] Task cdr.tasks.run_cdr_import[3a800491-a4e4-42ff-9da2-b98d0fa1f623] succeeded in 0.00994342006743s: None [2016-11-03 15:56:42,323: INFO/MainProcess] Received task: cdr.tasks.run_cdr_import[0d430eb2-1e74-404b-a5e7-7d7cb0203445] [2016-11-03 15:56:42,328: INFO/MainProcess] Received task: cdr.tasks.run_cdr_import[ee738776-1c16-41ad-85f1-08ab5a358eaa] Regards, Mikhail Demekhov

1 0