July 2017 - FreeSWITCH-users - FreeSWITCH Mailing Lists

Freeswitch SIP call not work using a static public IP
by Jose David Jurado Alonso 24 Jul '17

24 Jul '17

I've installed *freeswitch into a local environment* and I perform SIP calls well using the server local IP. This server has connected to ADSL network with a *static public IP* but when I try to call using the public IP instead of the local IP the server receive the call not work... The clients can register well (or I think so). Others process like apache work well. I NAT forwarding in the firewall the next ports: 5060, 5080, 7443. *$ netstat -putan* Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 192.168.230.143:2855 0.0.0.0:* LISTEN 15894/freeswitch tcp 0 0 192.168.230.143:2856 0.0.0.0:* LISTEN 15894/freeswitch tcp 0 0 192.168.230.143:5066 0.0.0.0:* LISTEN 15894/freeswitch tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1166/nginx -g daemo tcp 0 0 192.168.230.143:7443 0.0.0.0:* LISTEN 15894/freeswitch tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1079/sshd tcp 0 0 192.168.230.143:5080 0.0.0.0:* LISTEN 15894/freeswitch tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 1166/nginx -g daemo tcp 0 0 192.168.230.143:5060 0.0.0.0:* LISTEN 15894/freeswitch tcp 0 0 192.168.230.143:22 192.168.230.167:60298 ESTABLISHED 14816/sshd: ubuntu tcp 0 0 192.168.230.143:22 192.168.230.167:60296 ESTABLISHED 14744/sshd: ubuntu tcp6 0 0 :::80 :::* LISTEN 1166/nginx -g daemo tcp6 0 0 :::8021 :::* LISTEN 15894/freeswitch tcp6 0 0 :::22 :::* LISTEN 1079/sshd tcp6 0 0 ::1:5080 :::* LISTEN 15894/freeswitch tcp6 0 0 :::443 :::* LISTEN 1166/nginx -g daemo tcp6 0 0 ::1:5060 :::* LISTEN 15894/freeswitch udp 0 0 192.168.230.143:5060 0.0.0.0:* 15894/freeswitch udp 0 0 192.168.230.143:5080 0.0.0.0:* 15894/freeswitch udp 0 0 0.0.0.0:68 0.0.0.0:* 1019/dhclient udp6 0 0 ::1:5060 :::* 15894/freeswitch udp6 0 0 ::1:5080 :::* 15894/freeswitch *$ fs_cli -x "sofia status"* Name Type Data State ================================================================================================= external-ipv6 profile sip:mod_sofia@[::1]:5080 RUNNING (0) 192.168.230.143 alias internal ALIASED external profile sip:mod_sofia@192.168.230.143:5080 RUNNING (0) external::example.com gateway sip:joeuser@example.com NOREG internal-ipv6 profile sip:mod_sofia@[::1]:5060 RUNNING (0) internal profile sip:mod_sofia@192.168.230.143:5060 RUNNING (0) ================================================================================================= *$ fs_cli -x "sofia status profile external"* ================================================================================================= Name external Domain Name N/A Auto-NAT false DBName sofia_reg_external Pres Hosts Dialplan XML Context public Challenge Realm auto_to RTP-IP 192.168.230.143 SIP-IP 192.168.230.143 URL sip:mod_sofia@192.168.230.143:5080 BIND-URL sip:mod_sofia@192.168.230.143:5080;transport=udp,tcp HOLD-MUSIC local_stream://moh OUTBOUND-PROXY N/A CODECS IN OPUS,G722,PCMU,PCMA,VP8,H264 CODECS OUT OPUS,G722,PCMU,PCMA,VP8,H264 TEL-EVENT 101 DTMF-MODE rfc2833 CNG 13 SESSION-TO 0 MAX-DIALOG 0 NOMEDIA false LATE-NEG true PROXY-MEDIA false ZRTP-PASSTHRU true AGGRESSIVENAT false CALLS-IN 0 FAILED-CALLS-IN 0 CALLS-OUT 0 FAILED-CALLS-OUT 0 REGISTRATIONS 0 *$ grep -r '"ext-' ** sip_profiles/external.xml: <param name="ext-rtp-ip" value="auto-nat"/> sip_profiles/external.xml: <param name="ext-rtp-ip" value="auto-nat"/> sip_profiles/internal.xml: <param name="ext-rtp-ip" value="auto-nat"/> sip_profiles/internal.xml: <param name="ext-sip-ip" value="auto-nat"/> When I perform a call the freeswitch.log file show: df895d9a-30f2-40b5-97bb-56e222c1c45f 2017-07-18 14:44:51.218939 [NOTICE] switch_channel.c:1104 New Channel sofia/internal/1009@192.168.230.143:5060 [df895d9a-30f2-40b5-97bb-56e222c1c45f] df895d9a-30f2-40b5-97bb-56e222c1c45f 2017-07-18 14:44:51.218939 [DEBUG] switch_core_state_machine.c:584 (sofia/internal/1009@192.168.230.143:5060) Running State Change CS_NEW (Cur 1 Tot 7) df895d9a-30f2-40b5-97bb-56e222c1c45f 2017-07-18 14:44:51.218939 [DEBUG] sofia.c:10067 sofia/internal/1009@192.168.230.143:5060 receiving invite from 88.33.111.22:57076 version: 1.9.0 -493-13f2f2a 64bit 2017-07-18 14:44:51.218939 [DEBUG] sofia.c:10238 IP 88.33.111.22 Rejected by acl "domains". Falling back to Digest auth. df895d9a-30f2-40b5-97bb-56e222c1c45f 2017-07-18 14:44:51.218939 [DEBUG] switch_core_state_machine.c:603 (sofia/internal/1009@192.168.230.143:5060) State NEW 2017-07-18 14:44:51.218939 [DEBUG] sofia.c:2405 detaching session df895d9a-30f2-40b5-97bb-56e222c1c45f and passed some seconds: df895d9a-30f2-40b5-97bb-56e222c1c45f 2017-07-18 14:45:01.258940 [WARNING] switch_core_state_machine.c:687 df895d9a-30f2-40b5-97bb-56e222c1c45f sofia/internal/1009@192.168.230.143:5060 Abandoned df895d9a-30f2-40b5-97bb-56e222c1c45f 2017-07-18 14:45:01.258940 [NOTICE] switch_core_state_machine.c:690 Hangup sofia/internal/1009@192.168.230.143:5060 [CS_NEW] [WRONG_CALL_STATE] df895d9a-30f2-40b5-97bb-56e222c1c45f 2017-07-18 14:45:01.258940 [DEBUG] switch_core_state_machine.c:584 (sofia/internal/1009@192.168.230.143:5060) Running State Change CS_HANGUP (Cur 1 Tot 7) df895d9a-30f2-40b5-97bb-56e222c1c45f 2017-07-18 14:45:01.258940 [DEBUG] switch_core_state_machine.c:850 (sofia/internal/1009@192.168.230.143:5060) Callstate Change DOWN -> HANGUP df895d9a-30f2-40b5-97bb-56e222c1c45f 2017-07-18 14:45:01.258940 [DEBUG] switch_core_state_machine.c:852 (sofia/internal/1009@192.168.230.143:5060) State HANGUP df895d9a-30f2-40b5-97bb-56e222c1c45f 2017-07-18 14:45:01.258940 [DEBUG] mod_sofia.c:449 Channel sofia/internal/1009@192.168.230.143:5060 hanging up, cause: WRONG_CALL_STATE df895d9a-30f2-40b5-97bb-56e222c1c45f 2017-07-18 14:45:01.258940 [DEBUG] switch_core_state_machine.c:60 sofia/internal/1009@192.168.230.143:5060 Standard HANGUP, cause: WRONG_CALL_STATE df895d9a-30f2-40b5-97bb-56e222c1c45f 2017-07-18 14:45:01.258940 [DEBUG] switch_core_state_machine.c:852 (sofia/internal/1009@192.168.230.143:5060) State HANGUP going to sleep df895d9a-30f2-40b5-97bb-56e222c1c45f 2017-07-18 14:45:01.258940 [DEBUG] switch_core_state_machine.c:619 (sofia/internal/1009@192.168.230.143:5060) State Change CS_HANGUP -> CS_REPORTING df895d9a-30f2-40b5-97bb-56e222c1c45f 2017-07-18 14:45:01.258940 [DEBUG] switch_core_state_machine.c:584 (sofia/internal/1009@192.168.230.143:5060) Running State Change CS_REPORTING (Cur 1 Tot 7) df895d9a-30f2-40b5-97bb-56e222c1c45f 2017-07-18 14:45:01.258940 [DEBUG] switch_core_state_machine.c:938 (sofia/internal/1009@192.168.230.143:5060) State REPORTING df895d9a-30f2-40b5-97bb-56e222c1c45f 2017-07-18 14:45:01.258940 [DEBUG] switch_core_state_machine.c:174 sofia/internal/1009@192.168.230.143:5060 Standard REPORTING, cause: WRONG_CALL_STATE df895d9a-30f2-40b5-97bb-56e222c1c45f 2017-07-18 14:45:01.258940 [DEBUG] switch_core_state_machine.c:938 (sofia/internal/1009@192.168.230.143:5060) State REPORTING going to sleep df895d9a-30f2-40b5-97bb-56e222c1c45f 2017-07-18 14:45:01.258940 [DEBUG] switch_core_state_machine.c:610 (sofia/internal/1009@192.168.230.143:5060) State Change CS_REPORTING -> CS_DESTROY df895d9a-30f2-40b5-97bb-56e222c1c45f 2017-07-18 14:45:01.258940 [DEBUG] switch_core_session.c:1713 Session 7 (sofia/internal/1009@192.168.230.143:5060) Locked, Waiting on external entities df895d9a-30f2-40b5-97bb-56e222c1c45f 2017-07-18 14:45:01.258940 [NOTICE] switch_core_session.c:1731 Session 7 (sofia/internal/1009@192.168.230.143:5060) Ended df895d9a-30f2-40b5-97bb-56e222c1c45f 2017-07-18 14:45:01.258940 [NOTICE] switch_core_session.c:1735 Close Channel sofia/internal/1009@192.168.230.143:5060 [CS_DESTROY] df895d9a-30f2-40b5-97bb-56e222c1c45f 2017-07-18 14:45:01.258940 [DEBUG] switch_core_state_machine.c:741 (sofia/internal/1009@192.168.230.143:5060) Running State Change CS_DESTROY (Cur 0 Tot 7) df895d9a-30f2-40b5-97bb-56e222c1c45f 2017-07-18 14:45:01.258940 [DEBUG] switch_core_state_machine.c:751 (sofia/internal/1009@192.168.230.143:5060) State DESTROY df895d9a-30f2-40b5-97bb-56e222c1c45f 2017-07-18 14:45:01.258940 [DEBUG] mod_sofia.c:354 sofia/internal/1009@192.168.230.143:5060 SOFIA DESTROY df895d9a-30f2-40b5-97bb-56e222c1c45f 2017-07-18 14:45:01.258940 [DEBUG] switch_core_state_machine.c:181 sofia/internal/1009@192.168.230.143:5060 Standard DESTROY df895d9a-30f2-40b5-97bb-56e222c1c45f 2017-07-18 14:45:01.258940 [DEBUG] switch_core_state_machine.c:751 (sofia/internal/1009@192.168.230.143:5060) State DESTROY going to sleep Can it be an ACL or sip_profile bad configuration?? Router firewall configuration maybe?

4 8

traffic and system monitoring
by robert mundkowsky 23 Jul '17

23 Jul '17

Is Homer the best free option for traffic and systemmonitoring GUI? Or isCACTI better option? Robert

5 8

Path header handling
by Iskren Hadzhinedev 23 Jul '17

23 Jul '17

Hi, I have a kamailio proxy in front of FreeSWITCH. When a user registers, kamailio adds a path header like so: Path: <sip:KAMAILIO_PUBLIC_IP;lr;received=sip:UAC_PUBLIC_IP:5063> However, when FreeSWITCH sends the initial invite, it sends a Route header like this: Route: <sip:KAMAILIO_PUBLIC_IP>;lr;received=sip:UAC_PUBLIC_IP:5063 Is it possible to instruct FreeSWITCH to add the lr;received parameters inside the angle brackets as a part of the URI and how? e.g. how to achieve Route: <sip:KAMAILIO_PUBLIC_IP;lr;received=sip:UAC_PUBLIC_IP:5063> Thank you! Kind regards, Iskren Hadzhinedev

2 1

Behaviour of blocking applications
by Oz Mortimer 22 Jul '17

22 Jul '17

Hi, I know I can work around this issue, but was wondering if the behaviour is expected… If I use an application that blocks, mod_http_cache for example and the web server is unavailable - the call will stay up until the connect-timeout is reached. Obviously I can set a lower connect-timeout, but this doesn’t really resolve the issue. So, say I set connect-timeout to 3 seconds and place a 1 second call via soft phone (caller hangup), the billable duration will be 3 seconds - should the billable duration not be 1 second to match the calling party? also, shouldn’t a hangup force any running applications to stop? Again, obviously I can avoid this by being a bit smarter with the usage of http_cache, etc - but was really wondering if a) thats expected behaviour and the callee should count the duration based on the ACK from the BYE (which I suspect non do), or b) maybe there is a duration variable that I’ve not yet seen that contains the call duration until we receive the BYE from caller?. I would have thought (and Im probably wrong), billable duration s/u/m should resemble the SIP durations, i.e. endtime = time BYE was received? The other byproduct of this symptom is that the channels will stack up until call-timeout is reached - if it was left to the default of 300 seconds - a dead web server could soon cause the switch to burn out. Again, easily resolvable by not using blocking applications, doing things in the background, etc but… Thoughts & postcards? Thanks Oz.

1 0

Re: [Freeswitch-users] Multiple endpoints bridge issue
by 'Yemi Obembe 22 Jul '17

22 Jul '17

I totally understand that it should cancel all others. If Call A comes in and rings across user/xxxxx1,user/xxxxx2,user/xxxxx3 and xxxxx1 picks, I know ~2 and ~3 should be dropped. What I'd assume is that if Call B comes in (as Call A is engaged to xxxxx1), xxxxx2 and xxxxx3 should also be able to pick as they are available. As it is now, Call B will ring on them, but once they pick, as long as an existing call (A) exists, Call B drops. In other words, there can't be concurrent calls on the system. (What I am trying to create is a call center system where multiple agents can be engaged with different calls at the same time). Bridge is not a conferencing app. Bridge is used, normally within a dial plan to link an incoming a-leg call to an outgoing b-leg which is created to the endpoint’s specified in the bridge command. So the behaviour your experiencing is correct when specifying multiple endpoints, as soon as an endpoint/user answers the call the bridge command cancels all others. On 21 Jul 2017, at 13:04, 'Yemi Obembe <fickledreams(a)yahoo.com> wrote: I am using bridge via mod_httapi to call multiple endpoints via an xml response like this: <document type="text/freeswitch-httapi"><work> <execute application="bridge" data="user/xxxxx1,user/xxxxx2,user/xxxxx3" /> </work></document> What I notice is that this works for one or two connected endpoints. But once there are three or four endpoints, other incoming calls drop. I changed to enterprise originate (i.e, :_:) and noticed that once a call is engaged, other calls don't come in till that one ends. Same if I separate users with pipe (user/xxxxx1|user/xxxxx2|user/xxxxx3). Even when I bridge just a user at time, <execute application="bridge" data="user/xxxxx1" /> the other calls drop once one is engaged. What am I missing?

1 0

Freeswitch call-ID configuration
by hemanth＠advaitamtech.com 21 Jul '17

21 Jul '17

Hello, I am using Freswitch as a media proxy and to handle SIP requests it is working as B2BUA, Here i am not able handle 407 response from server, Because Freeswitch is sending different Call-ID and From tag in the Invite carrying proxy-authorization header, Because of this behavior SIP server is sending 407 for Second Invite carrying Proxy-Authorization Header also, Can any one please help me to configure freeswitch, So that it sends Same Call-ID and from tag in Both the Invite requests Thanks & Regards Hemanth

3 3

Understanding a dial string returned by group_call
by Mark Melling 21 Jul '17

21 Jul '17

When I execute a group_call command I get responses like this [^^:sip_invite_domain=example.com:presence_id=1010@example.com ]sofia/external/sip:1010@192.168.56.1:59527 ;ob;fs_nat=yes;fs_path=sip%3A1010%40192.168.56.1%3A59527%3Bob Are there any decent resources that would help me understand this better? As I understand it the [...] at the beginning means, apply variables to the channel, but what does the ^^ mean? And what does the bit after the address do/mean? i.e. in this specific case the bit ;ob;fs_nat=yes;fs_path=sip%3A1010%40192.168.56.1%3A59527%3Bob Thanks Mark

1 0

Multiple endpoints bridge issue
by 'Yemi Obembe 21 Jul '17

21 Jul '17

I am using bridge via mod_httapi to call multiple endpoints via an xml response like this: <document type="text/freeswitch-httapi"><work><execute application="bridge" data="user/xxxxx1,user/xxxxx2,user/xxxxx3" /></work></document> What I notice is that this works for one or two connected endpoints. But once there are three or four endpoints, other incoming calls drop. I changed to enterprise originate (i.e, :_:) and noticed that once a call is engaged, other calls don't come in till that one ends. Same if I separate users with pipe (user/xxxxx1|user/xxxxx2|user/xxxxx3). Even when I bridge just a user at time, <execute application="bridge" data="user/xxxxx1" /> the other calls drop once one is engaged. What am I missing?

2 1

Call forward
by Karlheinz Knapp 20 Jul '17

20 Jul '17

i have extension which is forwarded to a mobile number If I call this extension from a neighbor extension it works. But if I call from a outside number to the extension I don't get the voice on both sides. I believe it is a issue with reinvite. How I can fix this issue ? -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

1 0

CDR - best practices
by robert mundkowsky 20 Jul '17

20 Jul '17

What are the best practice for writing Call DetailRecords (CDRs) to a database? We are using custom code to write CDR-like data to logfiles and then later loading logs into a database. We have very low usage right now, so Isuspect that we could just write directly to the database. But as we scale, is it a better idea to notwrite directly to the database? Note I am not sure if we need custom CDRs or if FS' CDRmodule might be leveraged. I have tolook into that. Robert

5 4