Hi all, I'm running FS 1.4.9 on a CentOS 6.5 machine with a single NIC. The machine is behind NAT, and I have a working VPN so that internal calls work. The local IP of the machine is 192.168.196.101, and the remote VPN subnet (no NAT - clear routing) is 192.168.41.0/24. I am using port 5080 for internal calls (auth-calls=true) and port 5060 for incoming calls from a SIP provider. The machine has an internal IP and port-forwarding handles public IP -> private IP. When I dial from a mobile phone to a number on the external SIP provider, I do get activity on the console: 2014-10-10 10:52:20.655471 [NOTICE] switch_channel.c:1055 New Channel sofia/external/07951357XXX@87.238.73.181 [78cc73d0-e9d1-4d7d-9f22-f7adac8ba0c0] 2014-10-10 10:52:21.259045 [NOTICE] switch_ivr.c:1844 Transfer sofia/external/07951357xxx@87.238.73.181 to XML[106@default] 2014-10-10 10:52:21.259045 [WARNING] mod_dptools.c:1628 incoming call from [07951357XXX] to [106] 2014-10-10 10:52:21.259045 [NOTICE] mod_sofia.c:2237 Pre-Answer sofia/external/07951357XXX@87.238.73.181! 2014-10-10 10:52:21.259045 [NOTICE] switch_channel.c:1055 New Channel sofia/internal/sip:106@192.168.41.198:5060 [a7aaa63b-fd85-4b1f-8855-180a218a388e] At this point there is a pause and a timeout after 30 seconds. There is a phone registered to extension '106' listening at that IP address on port 5060: freeswitch@internal> sofia status profile internal reg Registrations: ================================================================================================= Call-ID: 1572302163@192.168.41.198 User: 106@freeswitch.bashton.eu Contact: "" <sip:106@192.168.41.198:5060> Agent: qutecom/rev-g-trunk Status: Registered(UDP)(unknown) EXP(2014-10-10 10:32:04) EXPSECS(2796) Host: freeswitch IP: 192.168.41.198 Port: 5060 Auth-User: 106 Auth-Realm: freeswitch.bashton.eu MWI-Account: 106@freeswitch.bashton.eu Total items returned: 1 ================================================================================================= freeswitch@internal> 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.196.101 SIP-IP 192.168.196.101 URL sip:mod_sofia@192.168.196.101:5060 BIND-URL sip:mod_sofia@192.168.196.101:5060;transport=udp,tcp HOLD-MUSIC N/A OUTBOUND-PROXY N/A CODECS IN PCMU,PCMA CODECS OUT TEL-EVENT 101 DTMF-MODE rfc2833 CNG 13 SESSION-TO 0 MAX-DIALOG 0 NOMEDIA false LATE-NEG false PROXY-MEDIA false ZRTP-PASSTHRU false AGGRESSIVENAT false CALLS-IN 2 FAILED-CALLS-IN 1 CALLS-OUT 0 FAILED-CALLS-OUT 0 REGISTRATIONS 0 freeswitch@internal> sofia status profile internal ================================================================================================= Name internal Domain Name N/A Auto-NAT false DBName sofia_reg_internal Pres Hosts Dialplan XML Context default Challenge Realm auto_to RTP-IP 192.168.196.101 Ext-RTP-IP 192.168.196.101 SIP-IP 192.168.196.101 Ext-SIP-IP 192.168.196.101 URL sip:mod_sofia@192.168.196.101:5080 BIND-URL sip:mod_sofia@192.168.196.101:5080 ;maddr=192.168.196.101;transport=udp HOLD-MUSIC N/A OUTBOUND-PROXY N/A CODECS IN PCMU,PCMA CODECS OUT PCMU,PCMA TEL-EVENT 101 DTMF-MODE rfc2833 CNG 13 SESSION-TO 0 MAX-DIALOG 0 NOMEDIA false LATE-NEG false PROXY-MEDIA false ZRTP-PASSTHRU false AGGRESSIVENAT false CALLS-IN 0 FAILED-CALLS-IN 0 CALLS-OUT 2 FAILED-CALLS-OUT 2 REGISTRATIONS 1 freeswitch@internal> sofia status Name Type Data State ================================================================================================= external profile sip:mod_sofia@192.168.196.101:5060 RUNNING (0) external::magrathea gateway sip:bashton@sipgw.magrathea.net REGED internal profile sip:mod_sofia@192.168.196.101:5080 RUNNING (0) ================================================================================================= 2 profiles 0 aliases The SIP client is definitely listening: gdh@gdh-e7440:~$ netstat -anp | grep 5060 tcp 0 0 192.168.41.198:5060 0.0.0.0:* LISTEN 17566/qutecom udp 0 0 192.168.41.198:5060 0.0.0.0:* 17566/qutecom And I can see that when the call comes in, there is traffic received by the SIP client (tcpdump + wireshark): INVITE sip:106@192.168.41.198:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.196.101:5080;rport;branch=z9hG4bKX71j6K414rQNa Max-Forwards: 67 From: "None " <sip:07951357XXX@freeswitch.bashton.eu>;tag=rBeB1Nv1Bampm To: <sip:106@192.168.41.198:5060> Call-ID: f850b9a6-cb05-1232-7693-02b891c191f6 CSeq: 66131306 INVITE Contact: <sip:mod_sofia@192.168.196.101:5080> User-Agent: FreeSWITCH-mod_sofia/1.4.9~64bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: timer, path, replaces Allow-Events: talk, hold, conference, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 253 X-CALLINFO: cdr=5437AC53=94F6B14; X-FS-Support: update_display,send_info Remote-Party-ID: "None " <sip:07951357XXX@freeswitch.bashton.eu
;party=calling;screen=yes;privacy=off
The incoming call is handled in the public context with: <action application="transfer" data="106 XML default"/> and in extension 106 in the default context, there's this: <action application="bridge" data="user/$1"/> I have tried both qutecom and linphone with the same behaviour. Any ideas? Cheers, Gavin.
Hi Gavin, Could this be a firewall issue on the client side (is 5060 open)? When doing tcpdump, do you see any provisional reply from the client? No packet filtering could help. Do you see any log on the client side? (if no, then the INVITE might not reach the application layer, if yes, it could help to investigate) Florent 2014-10-10 12:11 GMT+02:00 Gavin Hamill <gavin@bashton.com>:
Hi all,
I'm running FS 1.4.9 on a CentOS 6.5 machine with a single NIC. The machine is behind NAT, and I have a working VPN so that internal calls work. The local IP of the machine is 192.168.196.101, and the remote VPN subnet (no NAT - clear routing) is 192.168.41.0/24.
I am using port 5080 for internal calls (auth-calls=true) and port 5060 for incoming calls from a SIP provider. The machine has an internal IP and port-forwarding handles public IP -> private IP.
When I dial from a mobile phone to a number on the external SIP provider, I do get activity on the console:
2014-10-10 10:52:20.655471 [NOTICE] switch_channel.c:1055 New Channel sofia/external/07951357XXX@87.238.73.181 [78cc73d0-e9d1-4d7d-9f22-f7adac8ba0c0] 2014-10-10 10:52:21.259045 [NOTICE] switch_ivr.c:1844 Transfer sofia/external/07951357xxx@87.238.73.181 to XML[106@default] 2014-10-10 10:52:21.259045 [WARNING] mod_dptools.c:1628 incoming call from [07951357XXX] to [106] 2014-10-10 10:52:21.259045 [NOTICE] mod_sofia.c:2237 Pre-Answer sofia/external/07951357XXX@87.238.73.181! 2014-10-10 10:52:21.259045 [NOTICE] switch_channel.c:1055 New Channel sofia/internal/sip:106@192.168.41.198:5060 [a7aaa63b-fd85-4b1f-8855-180a218a388e]
At this point there is a pause and a timeout after 30 seconds. There is a phone registered to extension '106' listening at that IP address on port 5060:
freeswitch@internal> sofia status profile internal reg
Registrations:
================================================================================================= Call-ID: 1572302163@192.168.41.198 User: 106@freeswitch.bashton.eu Contact: "" <sip:106@192.168.41.198:5060> Agent: qutecom/rev-g-trunk Status: Registered(UDP)(unknown) EXP(2014-10-10 10:32:04) EXPSECS(2796) Host: freeswitch IP: 192.168.41.198 Port: 5060 Auth-User: 106 Auth-Realm: freeswitch.bashton.eu MWI-Account: 106@freeswitch.bashton.eu
Total items returned: 1
=================================================================================================
freeswitch@internal> 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.196.101 SIP-IP 192.168.196.101 URL sip:mod_sofia@192.168.196.101:5060 BIND-URL sip:mod_sofia@192.168.196.101:5060;transport=udp,tcp HOLD-MUSIC N/A OUTBOUND-PROXY N/A CODECS IN PCMU,PCMA CODECS OUT TEL-EVENT 101 DTMF-MODE rfc2833 CNG 13 SESSION-TO 0 MAX-DIALOG 0 NOMEDIA false LATE-NEG false PROXY-MEDIA false ZRTP-PASSTHRU false AGGRESSIVENAT false CALLS-IN 2 FAILED-CALLS-IN 1 CALLS-OUT 0 FAILED-CALLS-OUT 0 REGISTRATIONS 0
freeswitch@internal> sofia status profile internal
================================================================================================= Name internal Domain Name N/A Auto-NAT false DBName sofia_reg_internal Pres Hosts Dialplan XML Context default Challenge Realm auto_to RTP-IP 192.168.196.101 Ext-RTP-IP 192.168.196.101 SIP-IP 192.168.196.101 Ext-SIP-IP 192.168.196.101 URL sip:mod_sofia@192.168.196.101:5080 BIND-URL sip:mod_sofia@192.168.196.101:5080 ;maddr=192.168.196.101;transport=udp HOLD-MUSIC N/A OUTBOUND-PROXY N/A CODECS IN PCMU,PCMA CODECS OUT PCMU,PCMA TEL-EVENT 101 DTMF-MODE rfc2833 CNG 13 SESSION-TO 0 MAX-DIALOG 0 NOMEDIA false LATE-NEG false PROXY-MEDIA false ZRTP-PASSTHRU false AGGRESSIVENAT false CALLS-IN 0 FAILED-CALLS-IN 0 CALLS-OUT 2 FAILED-CALLS-OUT 2 REGISTRATIONS 1
freeswitch@internal> sofia status Name Type Data State
================================================================================================= external profile sip:mod_sofia@192.168.196.101:5060 RUNNING (0) external::magrathea gateway sip:bashton@sipgw.magrathea.net REGED internal profile sip:mod_sofia@192.168.196.101:5080 RUNNING (0)
================================================================================================= 2 profiles 0 aliases
The SIP client is definitely listening:
gdh@gdh-e7440:~$ netstat -anp | grep 5060 tcp 0 0 192.168.41.198:5060 0.0.0.0:* LISTEN 17566/qutecom udp 0 0 192.168.41.198:5060 0.0.0.0:* 17566/qutecom
And I can see that when the call comes in, there is traffic received by the SIP client (tcpdump + wireshark):
INVITE sip:106@192.168.41.198:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.196.101:5080;rport;branch=z9hG4bKX71j6K414rQNa Max-Forwards: 67 From: "None " <sip:07951357XXX@freeswitch.bashton.eu>;tag=rBeB1Nv1Bampm To: <sip:106@192.168.41.198:5060> Call-ID: f850b9a6-cb05-1232-7693-02b891c191f6 CSeq: 66131306 INVITE Contact: <sip:mod_sofia@192.168.196.101:5080> User-Agent: FreeSWITCH-mod_sofia/1.4.9~64bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: timer, path, replaces Allow-Events: talk, hold, conference, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 253 X-CALLINFO: cdr=5437AC53=94F6B14; X-FS-Support: update_display,send_info Remote-Party-ID: "None " <sip:07951357XXX@freeswitch.bashton.eu
;party=calling;screen=yes;privacy=off
The incoming call is handled in the public context with:
<action application="transfer" data="106 XML default"/>
and in extension 106 in the default context, there's this:
<action application="bridge" data="user/$1"/>
I have tried both qutecom and linphone with the same behaviour. Any ideas?
Cheers, Gavin.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Florent, Many thanks for the reply - I have now solved this issue thanks to your suggestions. The plot thickened with client logging for QuteCom. This occurs every time an INVITE is received (error) 14:04:04 [PhApi] : osip: /build/qutecom-u8vPAW/qutecom-2.2.1+dfsg1/wifo/libosip2/src/osipparser2/osip_message_parse.c:414: Could not set header: "from" "None (error) 14:04:04 [PhApi] : osip: /build/qutecom-u8vPAW/qutecom-2.2.1+dfsg1/wifo/libosip2/src/osipparser2/osip_message_parse.c:695: End of header Not found (error) 14:04:04 [PhApi] : osip: /build/qutecom-u8vPAW/qutecom-2.2.1+dfsg1/wifo/libosip2/src/osipparser2/osip_message_parse.c:932: error in msg_headers_parse() (error) 14:04:04 [PhApi] : osip: /build/qutecom-u8vPAW/qutecom-2.2.1+dfsg1/wifo/libosip2/src/osip2/osip_event.c:79: could not parse message (error) 14:04:04 [PhApi] : osip: /build/qutecom-u8vPAW/qutecom-2.2.1+dfsg1/wifo/eXosip/src/udp.c:2569: Could not parse SIP message Looking at the first few lines of the INVITE, I see this: INVITE sip:106@192.168.41.198:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.196.101:5080;rport;branch=z9hG4bK0DN82p3e63jZm Max-Forwards: 67 From: "None " <sip:07951357XXX@freeswitch.bashton.eu>;tag=7ZjyU00tv7mFr That makes sense now since the "None" is split over two lines causing the parse error. I then went back to the dialplan and remembered that I set up <action application="set" data="effective_caller_id_name=${cidlookup(${caller_id_number})}"/> where the cidlookup service was a small Python CGI script running on localhost. As it turned out, the output from this service included a line-feed after the caller name, and this was directly fed into the INVITE headers, confusing the SIP client. Cheers, Gavin.
That makes sense ;). I'm glad it helped. Florent 2014-10-10 15:45 GMT+02:00 Gavin Hamill <gavin@bashton.com>:
Florent,
Many thanks for the reply - I have now solved this issue thanks to your suggestions.
The plot thickened with client logging for QuteCom. This occurs every time an INVITE is received
(error) 14:04:04 [PhApi] : osip: /build/qutecom-u8vPAW/qutecom-2.2.1+dfsg1/wifo/libosip2/src/osipparser2/osip_message_parse.c:414: Could not set header: "from" "None (error) 14:04:04 [PhApi] : osip: /build/qutecom-u8vPAW/qutecom-2.2.1+dfsg1/wifo/libosip2/src/osipparser2/osip_message_parse.c:695: End of header Not found (error) 14:04:04 [PhApi] : osip: /build/qutecom-u8vPAW/qutecom-2.2.1+dfsg1/wifo/libosip2/src/osipparser2/osip_message_parse.c:932: error in msg_headers_parse() (error) 14:04:04 [PhApi] : osip: /build/qutecom-u8vPAW/qutecom-2.2.1+dfsg1/wifo/libosip2/src/osip2/osip_event.c:79: could not parse message (error) 14:04:04 [PhApi] : osip: /build/qutecom-u8vPAW/qutecom-2.2.1+dfsg1/wifo/eXosip/src/udp.c:2569: Could not parse SIP message
Looking at the first few lines of the INVITE, I see this:
INVITE sip:106@192.168.41.198:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.196.101:5080;rport;branch=z9hG4bK0DN82p3e63jZm Max-Forwards: 67 From: "None " <sip:07951357XXX@freeswitch.bashton.eu>;tag=7ZjyU00tv7mFr
That makes sense now since the "None" is split over two lines causing the parse error. I then went back to the dialplan and remembered that I set up
<action application="set" data="effective_caller_id_name=${cidlookup(${caller_id_number})}"/>
where the cidlookup service was a small Python CGI script running on localhost. As it turned out, the output from this service included a line-feed after the caller name, and this was directly fed into the INVITE headers, confusing the SIP client.
Cheers, Gavin.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (2)
-
Florent Krieg
-
Gavin Hamill