December 2017 - FreeSWITCH-users - FreeSWITCH Mailing Lists

ACL: auth_calls + apply-inbound-acl/auth-acl
by Anatoli 06 Dec '17

06 Dec '17

Hi all, I'm trying to understand FreeSWITCH's ACL concepts, but I find the documentation not clear with respect to a combined effect of various *acl* params with auth-calls. Could you please provide your comments on the following? The documentation (https://freeswitch.org/confluence/display/FREESWITCH/ACL) says: /auth-calls: Can be set to true/false forcing users to authenticate or no on the profile. Only allow users from a specific cidr to register/make calls.// / First of all, it's not clear what's the default value of the auth-calls param. If it's not explicitly defined, is it true or false? (BTW, same happens with a lot of other params, i.e. no default value specified in the docs, and for some params I couldn't even find the default values in the sources.) Then, if auth-calls is set to true, will it ignore all *acl* params and always force auth? Or will it force auth only for those not specified in the *acl* params (e.g. IPs in apply-inbound-acl won't be forced to auth, all others will be). Similar doubt with the false value: will it always ignore auth or will it ignore auth for the IPs in the *acl* params and still require it for everything else? Then the documentation specifies: /apply-inbound-acl: Allow users to make calls from a particular cidr without authenticating. Phones having IPs within these ACLs will be able to perform calls (apply-inbound-acl) or register (apply-register-acl) without having to provide a password (i.e. without getting a "401 Unauthorized" challenge message).// / So if I understand it correctly, if I want a particular host (e.g. my SIP trunk provider) to make inbound calls without auth, but everyone else to be rejected with Unauthorized, I should specify in the corresponding sip profile: <param name="apply-inbound-acl" value="1.2.3.4/32"/> The documentation adds: /The ACL behavior is modified by auth-calls, accept-blind-reg, and accept-blind-auth./ So what should be the value for auth-calls in this case? How would it modify the behavior of apply-inbound-acl (i.e. apply-inbound-acl + auth-calls=false and apply-inbound-acl + auth-calls=true)? Then, the documentation says: /auth-calls: Users in the directory can have "auth-acl" parameters applied to them so as to restrict users access to a predefined ACL or a CIDR. Note: this will require "auth-calls" to be set to true in your sip (sofia) profile.// / So, if I want to restrict my internal users to be able to register (providing their passwords) only from a specific range and be rejected with Unauthorized for other IPs or if not providing auth, should I configure the profile this way? <param name="auth-calls" value="true"/> <param name="auth-acl" value="1.2.3.0/24"/> My doubt here is: would auth-acl add an additional level of restriction without altering the default behavior of auth-calls (that is to request auth from everyone) or would it somehow relax the default behavior for some cases? Thanks, Anatoli

2 5

Any update on 1.8 production release?
by Nathan Neulinger 06 Dec '17

06 Dec '17

Been in a holding pattern on deploying to our production environment until this is actually released. Any timeframe update? -- Nathan ------------------------------------------------------------ Nathan Neulinger nneul(a)mst.edu Missouri S&T Information Technology (573) 612-1412 System Administrator - Architect

1 0

fifo callers when > call limit until limit no longer exceeded
by Royce Mitchell III 06 Dec '17

06 Dec '17

I am currently using hash to limit the number of calls that can get through on a specific destination_number and giving any excess a USER_BUSY, something like this: <action application="limit" data="hash inbound ${destination_number} ${call_limit} !USER_BUSY"/> However, now they're asking me to queue those calls with a recording and let them through in order as the call_limit reduces back down and then send the call to a different destination if it stays in that queue for a minute. In other words, if call_limit is 5, the 6th call would get queued until one of those first 5 calls clears. If none of the 5 calls clears before a minute has elapsed, I want to transfer that 6th call to a different destination. If a 7th call enters the queue, the 6th call should be the next to get a channel because it has been in the queue longer. I'm digging through the documentation and I haven't been able to figure out a way to do this so far. It seems like maybe using fifo in combination with limit would be in order, but I can't think of how to make them work together to accomplish this. Royce Mitchell, IT Consultant ITAS Solutions royce3(a)itas-solutions.com

2 2

Header Duplicate same name
by Joaquin Peral 06 Dec '17

06 Dec '17

3 2

WSS Socket Disconnect
by Geoff Mina 06 Dec '17

06 Dec '17

I am having an issue where the WSS connection to Freeswitch is abruptly disconnecting under certain scenarios. When trying to send an INVITE to FreeSwitch, the socket disconnects. When accepting an INVITE from FreeSwitch everything works fine. I am running on CentOS 7 - 3.10.0-693.el7.x86_64. I installed Freeswitch 1.6.19 via yum. Here is what we are seeing from the browser side. Same symptom in Chrome and FireFox: sip-0.7.7.js:2900:3 Sat Dec 02 2017 15:34:52 GMT-0700 (MST) | sip.transaction.nist | Timer J expired for non-INVITE server transaction z9hG4bKZmZS5KUSecFee sip-0.7.7.js:2900:3 Sat Dec 02 2017 15:35:12 GMT-0700 (MST) | sip.invitecontext.mediahandler | acquiring local media sip-0.7.7.js:2900:3 onaddstream is deprecated! Use peerConnection.ontrack instead. sip-0.7.7.js:11498 navigator.mozGetUserMedia has been replaced by navigator.mediaDevices.getUserMedia sip-0.7.7.js:10554:8 Sat Dec 02 2017 15:35:12 GMT-0700 (MST) | sip.invitecontext.mediahandler | acquired local media streams sip-0.7.7.js:2900:3 Sat Dec 02 2017 15:35:12 GMT-0700 (MST) | sip.invitecontext.mediahandler | RTCIceGatheringState changed: gathering sip-0.7.7.js:2900:3 Sat Dec 02 2017 15:35:12 GMT-0700 (MST) | sip.invitecontext.mediahandler | ICE candidate received: candidate:0 1 UDP 2122252543 192.168.240.12 61028 typ host sip-0.7.7.js:2900:3 Sat Dec 02 2017 15:35:12 GMT-0700 (MST) | sip.invitecontext.mediahandler | ICE candidate received: candidate:2 1 UDP 2122187007 172.16.2.7 54757 typ host sip-0.7.7.js:2900:3 Sat Dec 02 2017 15:35:12 GMT-0700 (MST) | sip.invitecontext.mediahandler | ICE candidate received: candidate:4 1 TCP 2105524479 192.168.240.12 9 typ host tcptype active sip-0.7.7.js:2900:3 Sat Dec 02 2017 15:35:12 GMT-0700 (MST) | sip.invitecontext.mediahandler | ICE candidate received: candidate:5 1 TCP 2105458943 172.16.2.7 9 typ host tcptype active sip-0.7.7.js:2900:3 Sat Dec 02 2017 15:35:12 GMT-0700 (MST) | sip.invitecontext.mediahandler | ICE candidate received: candidate:0 2 UDP 2122252542 192.168.240.12 61218 typ host sip-0.7.7.js:2900:3 Sat Dec 02 2017 15:35:12 GMT-0700 (MST) | sip.invitecontext.mediahandler | ICE candidate received: candidate:2 2 UDP 2122187006 172.16.2.7 52542 typ host sip-0.7.7.js:2900:3 Sat Dec 02 2017 15:35:12 GMT-0700 (MST) | sip.invitecontext.mediahandler | ICE candidate received: candidate:4 2 TCP 2105524478 192.168.240.12 9 typ host tcptype active sip-0.7.7.js:2900:3 Sat Dec 02 2017 15:35:12 GMT-0700 (MST) | sip.invitecontext.mediahandler | ICE candidate received: candidate:5 2 TCP 2105458942 172.16.2.7 9 typ host tcptype active sip-0.7.7.js:2900:3 Sat Dec 02 2017 15:35:12 GMT-0700 (MST) | sip.invitecontext.mediahandler | ICE candidate received: candidate:3 1 UDP 1685987327 52.33.247.158 25669 typ srflx raddr 172.16.2.7 rport 54757 sip-0.7.7.js:2900:3 Sat Dec 02 2017 15:35:12 GMT-0700 (MST) | sip.invitecontext.mediahandler | ICE candidate received: candidate:3 2 UDP 1685987326 52.33.247.158 16597 typ srflx raddr 172.16.2.7 rport 52542 sip-0.7.7.js:2900:3 Sat Dec 02 2017 15:35:17 GMT-0700 (MST) | sip.invitecontext.mediahandler | RTCIceChecking Timeout Triggered after 5000 milliseconds sip-0.7.7.js:2900:3 Sat Dec 02 2017 15:35:17 GMT-0700 (MST) | sip.transport | sending WebSocket message: INVITE sip:*97@c01-aorgc-reg6.somehost.biz SIP/2.0 Via: SIP/2.0/WSS hqj7ffmo2koa.invalid;branch=z9hG4bK1975235 Max-Forwards: 70 To: <sip:*97@c01-aorgc-reg6.somehost.biz> From: "gmina" <sip:gmina@c01-aorgc-reg6.somehost.biz>;tag=efk4hqf1dc Call-ID: vitn3acs5ss3dikrn14a CSeq: 7808 INVITE Contact: <sip:7jm943k7@hqj7ffmo2koa.invalid;transport=ws;ob> Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER Supported: outbound User-Agent: SIP.js/0.7.7 BB\ Content-Type: application/sdp Content-Length: 1646 v=0 o=mozilla...THIS_IS_SDPARTA-57.0 335274293698172607 0 IN IP4 0.0.0.0 s=- t=0 0 a=sendrecv a=fingerprint:sha-256 BE:35:AD:35:14:DB:CB:2B:D9:A3:D5:A7:EB:7D:08:E4:29:5E:7E:25:A6:16:9F:34:EC:37:0B:7A:C7:E0:9F:5B a=group:BUNDLE sdparta_0 a=ice-options:trickle a=msid-semantic:WMS * m=audio 25669 UDP/TLS/RTP/SAVPF 109 9 0 8 101 c=IN IP4 52.33.247.158 a=candidate:0 1 UDP 2122252543 192.168.240.12 61028 typ host a=candidate:2 1 UDP 2122187007 172.16.2.7 54757 typ host a=candidate:4 1 TCP 2105524479 192.168.240.12 9 typ host tcptype active a=candidate:5 1 TCP 2105458943 172.16.2.7 9 typ host tcptype active a=candidate:0 2 UDP 2122252542 192.168.240.12 61218 typ host a=candidate:2 2 UDP 2122187006 172.16.2.7 52542 typ host a=candidate:4 2 TCP 2105524478 192.168.240.12 9 typ host tcptype active a=candidate:5 2 TCP 2105458942 172.16.2.7 9 typ host tcptype active a=candidate:3 1 UDP 1685987327 52.33.247.158 25669 typ srflx raddr 172.16.2.7 rport 54757 a=candidate:3 2 UDP 1685987326 52.33.247.158 16597 typ srflx raddr 172.16.2.7 rport 52542 a=sendrecv a=extmap:1/sendonly urn:ietf:params:rtp-hdrext:ssrc-audio-level a=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1 a=fmtp:101 0-15 a=ice-pwd:d45de180fdae3dc61f0e26238541045c a=ice-ufrag:50681d44 a=mid:sdparta_0 a=msid:{23ed6231-4501-1944-8577-ab85c6c721cb} {c98743c7-76d0-5c44-89a1-f702f7d8168d} a=rtcp:16597 IN IP4 52.33.247.158 a=rtcp-mux a=rtpmap:109 opus/48000/2 a=rtpmap:9 G722/8000/1 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=setup:actpass a=ssrc:3742140108 cname:{76ae6d79-b818-1e40-a9bc-4734a437b47a} sip-0.7.7.js:2900:3 Sat Dec 02 2017 15:35:17 GMT-0700 (MST) | sip.transport | WebSocket disconnected (code: 1006) sip-0.7.7.js:2900:3 Sat Dec 02 2017 15:35:17 GMT-0700 (MST) | sip.transport | WebSocket abrupt disconnection sip-0.7.7.js:2900:3 Sat Dec 02 2017 15:35:17 GMT-0700 (MST) | sip.ua | connection state set to 1 sip-0.7.7.js:2900:3 Sat Dec 02 2017 15:35:17 GMT-0700 (MST) | sip.transaction.ict | transport error occurred, deleting INVITE client transaction z9hG4bK1975235 sip-0.7.7.js:2900:3 Sat Dec 02 2017 15:35:17 GMT-0700 (MST) | sip.transport | Connection to WebSocket wss://c01-aorgc-reg6.somehost.biz:8089/freeswitch severed, attempting first reconnect sip-0.7.7.js:2900:3 Sat Dec 02 2017 15:35:17 GMT-0700 (MST) | sip.transport | connecting to WebSocket wss://c01-aorgc-reg6.somehost.biz:8089/freeswitch sip-0.7.7.js:2900:3 Sat Dec 02 2017 15:35:17 GMT-0700 (MST) | sip.transport | WebSocket wss:// c01-aorgc-reg6.somehost.biz:8089/freeswitch connected *And here is what we are seeing from the Freeswitch side.* tport.c:2773 tport_wakeup() tport_wakeup(0x7f4e580fc4d0): events IN tport.c:2864 tport_recv_event() tport_recv_event(0x7f4e580fc4d0) tport.c:2157 tport_shutdown0() tport_shutdown0(0x7f4e580fc4d0, 2) tport.c:2090 tport_close() tport_close(0x7f4e580fc4d0): wss/ 52.33.247.158:25656/sips nua_registrar.c:200 registrar_tport_error() tport error 0: Success tport.c:4222 tport_release() tport_release(0x7f4e580fc4d0): (nil) by 0x7f4e581361b0 with (nil) tport.c:2263 tport_set_secondary_timer() tport(0x7f4e580fc4d0): set timer at 0 ms because zap *nua_stack.c:271 nua_stack_event() nua(0x7f4e581361b0): event i_media_error 500 Transport error detected* nua_stack.c:359 nua_application_event() nua: nua_application_event: entering tport.c:2263 tport_set_secondary_timer() tport(0x7f4e580fc4d0): set timer at 0 ms because zap tport_type_ws.c:521 tport_ws_deinit_secondary() 0x7f4e580fc4d0 destroy wss transport 0x7f4e580fc6c0. nua.c:366 nua_handle_magic() nua: nua_handle_magic: entering nua.c:921 nua_handle_destroy() nua: nua_handle_destroy: entering nua_stack.c:529 nua_signal() nua(0x7f4e581361b0): sent signal r_destroy nua.c:921 nua_handle_destroy() nua: nua_handle_destroy: entering nua_stack.c:569 nua_stack_signal() nua(0x7f4e581361b0): recv signal r_destroy nua_dialog.c:397 nua_dialog_usage_remove_at() nua(0x7f4e581361b0): removing registrar usage nta.c:4470 nta_leg_destroy() nta_leg_destroy((nil)) soa.c:356 soa_destroy() soa_destroy(static::0x7f4e5803dea0) called tport.c:2749 tport_wakeup_pri() tport_wakeup_pri(0x7f4e58004f50): events IN tport.c:862 tport_alloc_secondary() tport_alloc_secondary(0x7f4e58004f50): new secondary tport 0x7f4e580fc4d0 tport.c:2292 tport_set_secondary_timer() tport(0x7f4e580fc4d0): set timer at 4998 ms because keepalive tport.c:2640 tport_accept() tport_accept(0x7f4e580fc4d0): new connection from wss/52.33.247.158:54385/sips tport.c:2773 tport_wakeup() tport_wakeup(0x7f4e580fc4d0): events IN tport.c:2864 tport_recv_event() tport_recv_event(0x7f4e580fc4d0) tport.c:2296 tport_set_secondary_timer() tport(0x7f4e580fc4d0): reset timer tport.c:2773 tport_wakeup() tport_wakeup(0x7f4e580fc4d0): events IN Any help in narrowing down the cause would be greatly appreciated. I am thinking maybe it's a max frame size on the websocket or something... but I couldn't find anything that would indicate there was a setting to tweak. Thanks, Geoff

1 1

call interruption after 5 minutes
by Philipp Zeitschel 05 Dec '17

05 Dec '17

Hi, i'm regged to a gateway, if I initiate a call to my mobile after 5 Minutes the call terminates but only on my mobile, my phone (connected to freeswitch) counts the time until I hang up to the time when the problem occurs I get following log entries: nta.c:7159 _nta_incoming_timer() nta: timer J fired, terminate 401 response nta.c:7188 _nta_incoming_timer() nta_incoming_timer: 0/0 resent, 0/0 tout, 1/2 term, 1/2 free nta.c:7159 _nta_incoming_timer() nta: timer J fired, terminate 200 response nta.c:7188 _nta_incoming_timer() nta_incoming_timer: 0/0 resent, 0/0 tout, 1/1 term, 1/1 free nta.c:9101 outgoing_timer_dk() nta: timer K fired, terminate OPTIONS (115912462) nta.c:8929 _nta_outgoing_timer() nta_outgoing_timer: 0/0 resent, 0/0 tout, 1/3 term, 1/3 free nta.c:9101 outgoing_timer_dk() nta: timer K fired, terminate OPTIONS (115912463) nta.c:8929 _nta_outgoing_timer() nta_outgoing_timer: 0/0 resent, 0/0 tout, 1/2 term, 1/2 free nta.c:9101 outgoing_timer_dk() nta: timer K fired, terminate OPTIONS (115912464) nta.c:8929 _nta_outgoing_timer() nta_outgoing_timer: 0/0 resent, 0/0 tout, 1/1 term, 1/1 free auth_digest.c:226 auth_digest_a1() auth_digest_a1() has A1 = MD5(+49xxx: mga.mnet-voip.de:xxx) = xxxx auth_digest.c:318 auth_digest_response() A2 = MD5(REGISTER:sip:mga.mnet-voip.de;transport=udp) auth_digest.c:348 auth_digest_response() auth_response: xxx = MD5(xxx) (qop=auth) nta.c:10720 outgoing_query_aaaa() nta: for "mga.mnet-voip.de" query "mga.mnet-voip.de" AAAA (cached) nta.c:10774 outgoing_answer_aaaa() nta(0x7fe3740563f0): mga.mnet-voip.de. IN AAAA 2001:a60:1:7::10 nta.c:8304 outgoing_send() nta: sent REGISTER (115912137) to udp/2001:a60:1:7::10:5060/sip nta.c:3299 agent_recv_response() nta: received 200 OK for REGISTER (115912137) nta.c:3366 agent_recv_response() nta: 200 OK is going to a transaction nua_stack.c:271 nua_stack_event() nua(0x7fe394014e10): event r_register 200 OK 2017-12-05 19:38:12.246833 [DEBUG] switch_rtp.c:1463 [ zrtp cache]: Storing ZRTP cache to </var/lib/freeswitch/db/zrtp.dat>... 2017-12-05 19:38:12.246833 [DEBUG] switch_rtp.c:1324 Saving ZRTP cache: OK nta.c:9101 outgoing_timer_dk() nta: timer K fired, terminate REGISTER (115912137) nta.c:8929 _nta_outgoing_timer() nta_outgoing_timer: 0/0 resent, 0/0 tout, 1/1 term, 1/1 free nua_stack.c:569 nua_stack_signal() nua(0x7fe394083af0): recv signal r_options nta.c:10720 outgoing_query_aaaa() nta: for "mga.mnet-voip.de" query "mga.mnet-voip.de" AAAA (cached) nta.c:10774 outgoing_answer_aaaa() nta(0x7fe3740398f0): mga.mnet-voip.de. IN AAAA 2001:a60:1:7::10 nta.c:8304 outgoing_send() nta: sent OPTIONS (115912465) to udp/2001:a60:1:7::10:5060 nta.c:3299 agent_recv_response() nta: received 403 Forbidden for OPTIONS (115912465) nta.c:3366 agent_recv_response() nta: 403 Forbidden is going to a transaction nua_stack.c:271 nua_stack_event() nua(0x7fe394083af0): event r_options 403 Forbidden nua_stack.c:569 nua_stack_signal() nua(0x7fe394083af0): recv signal r_destroy nua_stack.c:569 nua_stack_signal() nua(0x7fe394083b80): recv signal r_options nta.c:10720 outgoing_query_aaaa() nta: for "mga.mnet-voip.de" query "mga.mnet-voip.de" AAAA (cached) nta.c:10774 outgoing_answer_aaaa() nta(0x7fe37402c980): mga.mnet-voip.de. IN AAAA 2001:a60:1:7::10 nta.c:8304 outgoing_send() nta: sent OPTIONS (115912466) to udp/2001:a60:1:7::10:5060 nta.c:3299 agent_recv_response() nta: received 403 Forbidden for OPTIONS (115912466) nta.c:3366 agent_recv_response() nta: 403 Forbidden is going to a transaction nua_stack.c:271 nua_stack_event() nua(0x7fe394083b80): event r_options 403 Forbidden nua_stack.c:569 nua_stack_signal() nua(0x7fe394083b80): recv signal r_destroy nua_stack.c:569 nua_stack_signal() nua(0x7fe39407d2d0): recv signal r_options nta.c:10720 outgoing_query_aaaa() nta: for "mga.mnet-voip.de" query "mga.mnet-voip.de" AAAA (cached) nta.c:10774 outgoing_answer_aaaa() nta(0x7fe37405b8f0): mga.mnet-voip.de. IN AAAA 2001:a60:1:7::10 nta.c:8304 outgoing_send() nta: sent OPTIONS (115912467) to udp/2001:a60:1:7::10:5060 nta.c:3299 agent_recv_response() nta: received 403 Forbidden for OPTIONS (115912467) nta.c:3366 agent_recv_response() nta: 403 Forbidden is going to a transaction nua_stack.c:271 nua_stack_event() nua(0x7fe39407d2d0): event r_options 403 Forbidden nua_stack.c:569 nua_stack_signal() nua(0x7fe39407d2d0): recv signal r_destroy nta.c:9101 outgoing_timer_dk() nta: timer K fired, terminate OPTIONS (115912465) nta.c:8929 _nta_outgoing_timer() nta_outgoing_timer: 0/0 resent, 0/0 tout, 1/3 term, 1/3 free nta.c:9101 outgoing_timer_dk() nta: timer K fired, terminate OPTIONS (115912466) nta.c:8929 _nta_outgoing_timer() nta_outgoing_timer: 0/0 resent, 0/0 tout, 1/2 term, 1/2 free nta.c:9101 outgoing_timer_dk() nta: timer K fired, terminate OPTIONS (115912467) nta.c:8929 _nta_outgoing_timer() nta_outgoing_timer: 0/0 resent, 0/0 tout, 1/1 term, 1/1 free it seems like the registration is the problem but I have no glue why. My Provider won't help cause he tries to bend me to a router he provides. Incoming calls are no problem at all. Any ideas? Anything else I can provide? Thanks in advance Regards Philipp

1 0

Turning off ring back
by Jerry Chinn 05 Dec '17

05 Dec '17

Good Day. FreeSwitch is presenting ring back to calling party by default. Is there a way to shut that feature off? Jerry Chinn Telecom VoIP Specialist NAVIS More Performance. More Profit. tel 541-330-3562 www.TheNavisWay.com<http://www.thenavisway.com/> Facebook<https://www.facebook.com/theNAVISway/> | Twitter<https://twitter.com/NAVISway> | LinkedIn<https://www.linkedin.com/company/navisway> | Blog<https://www.thenavisway.com/blog>

2 1

G729 and windows
by Gregor Nanger 05 Dec '17

05 Dec '17

Hi, I'm using Fs on Windows and would like to buy licenses for g729 transoding. But is this possible to use this functionality on Windows? Best regards, Gregor -- Gregor Nanger *CTO* t./f.: 00386 (0) 7 6000 308/309 • m:. 00386 (0)41 756485 • Infomedia d.o.o. • Jerebova 3, Novo mesto, Slovenia • www.infomedia.si

6 8

WebSocket behind NGINX
by Anton 04 Dec '17

04 Dec '17

Hello All, I have to proxy all websocket requests though a nginx server. Right now I am using next configuration: map $http_upgrade $connection_upgrade { default upgrade; '' close; } server { listen 443; server_name wss.somedomain.com.ua; ssl on; ssl_certificate /etc/nginx/cert.pem; ssl_certificate_key /etc/nginx/private.key; location / { proxy_pass http://127.0.0.1:5066; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; proxy_read_timeout 86400s; } access_log /var/log/nginx/wss_access; error_log /var/log/nginx/wss_error debug; } I dumped traffic from nginx and found out that "switching protocol" phrase was successful but INVITE message from my browser in pending state. Maybe FreeSWITCH wants real IP not loopback? Who have faced with similar problem? BR, Anton

4 5

Issues with T.38 on outgoing fax (sofia T38 invite failed)
by Kevin Olbrich 04 Dec '17

04 Dec '17

Hi! Our carrier supports T.38 for outgoing faxes. I am trying to send faxes like this: originate > {origination_caller_id_name='kevin',origination_caller_id_number='+49123456789',ignore_early_media=true,absolute_codec_string='PCMA,PCMU',fax_use_ecm=true,fax_enable_t38=true,fax_enable_t38_request=true}sofia/gateway/carrier_1/+4912121212 > &txfax(/opt/faxout.tif) Log: 668fd128-f2f5-4af5-9536-6780762c2efa 2017-12-01 21:38:57.513164 [DEBUG] > sofia_glue.c:1295 sofia/external/+4912121212 sending invite version: 1.6.19 > -36-7a77e0b 64bit > 668fd128-f2f5-4af5-9536-6780762c2efa Local SDP: > 668fd128-f2f5-4af5-9536-6780762c2efa v=0 > 668fd128-f2f5-4af5-9536-6780762c2efa o=FreeSWITCH 1512130268 1512130270 IN > IP4 123.123.123.123 > 668fd128-f2f5-4af5-9536-6780762c2efa s=FreeSWITCH > 668fd128-f2f5-4af5-9536-6780762c2efa c=IN IP4 123.123.123.123 > 668fd128-f2f5-4af5-9536-6780762c2efa t=0 0 > 668fd128-f2f5-4af5-9536-6780762c2efa m=image 30466 udptl t38 > 668fd128-f2f5-4af5-9536-6780762c2efa a=T38FaxVersion:0 > 668fd128-f2f5-4af5-9536-6780762c2efa a=T38MaxBitRate:14400 > 668fd128-f2f5-4af5-9536-6780762c2efa a=T38FaxFillBitRemoval > 668fd128-f2f5-4af5-9536-6780762c2efa a=T38FaxRateManagement:transferredTCF > 668fd128-f2f5-4af5-9536-6780762c2efa a=T38FaxMaxBuffer:2000 > 668fd128-f2f5-4af5-9536-6780762c2efa a=T38FaxMaxDatagram:400 > 668fd128-f2f5-4af5-9536-6780762c2efa a=T38FaxUdpEC:t38UDPRedundancy > 668fd128-f2f5-4af5-9536-6780762c2efa > 668fd128-f2f5-4af5-9536-6780762c2efa 2017-12-01 21:38:57.533158 [DEBUG] > sofia.c:7084 Channel sofia/external/+4912121212 entering state [calling][0] > 668fd128-f2f5-4af5-9536-6780762c2efa 2017-12-01 21:38:57.673120 [DEBUG] > sofia.c:6294 sofia/external/+4912121212 T38 invite failed > 668fd128-f2f5-4af5-9536-6780762c2efa 2017-12-01 21:38:57.673120 [DEBUG] > sofia.c:7077 Channel sofia/external/+4912121212 skipping state [ready][488] Carrier confirmed that T.38 is possible... What could be the cause for this? How can I enforce T.38 instead of falling back to g711a (hangup on failed invite)? Thanks. Kind regards, Kevin

3 5