Hi, Please help. My FreeSWITCH has some mobile clients (Sipdroid and Nokia), keeps registration on the FS. See registration record samples: Call-ID: 571195090210@14.144.242.244 User: 1019@192.168.1.5 Contact: "user" <sip:1019@14.144.242.244:38592;transport=udp> Agent: Sipdroid/1.4.6 beta/T-Mobile G1 Status: Registered(UDP)(unknown) EXP(2010-05-19 16:38:41) Host: olegh.ath.cx IP: 208.54.35.47 Port: 30727 Auth-User: 1019 Auth-Realm: olegh.ath.cx MWI-Account: 1019@192.168.1.5 Call-ID: 30IpTq1FoIfJnxJC5ROP1HByEOig2n User: 1015@192.168.1.5 Contact: "user" <sip:1015@10.0.0.135;transport=TCP;fs_nat=yes;fs_path=sip%3A1015%4094.71.98.45%3A17476%3Btransport%3DTCP> Agent: Nokia RA-6 210.34.75 Status: Registered(TCP-NAT)(unknown) EXP(2010-05-19 15:57:27) Host: olegh.ath.cx IP: 94.71.98.45 Port: 17476 Auth-User: 1015 Auth-Realm: olegh.ath.cx MWI-Account: 1015@192.168.1.5 As you can see, for last samle (nokia) "Contact" contains line: sip:1015@10.0.0.135. In the real life, this phone NATed, and real IP (gateway's) is 94.71.98.45. Call from that phone is OK. But, when I try to call that phone from local, FS try to use wrong IP for connect: 2010-05-19 14:28:24.156706 [NOTICE] switch_channel.c:669 New Channel sofia/internal/sip:1015@10.0.0.135 [62b74c4f-7463-df11-ac63-005004c3cb7e] Of course, connection can not be established. Question: How to fix this problem? Or maybe, need to change FS, and always use REAL IP:PORT for establish outgoing call? Following - header of "sofia status profile internal": ================================================================================================= Name internal Domain Name N/A Auto-NAT true DBName sofia_reg_internal Pres Hosts Dialplan XML Context public Challenge Realm auto_from RTP-IP 192.168.1.5 Ext-RTP-IP 173.73.120.93 SIP-IP 192.168.1.5 Ext-SIP-IP 173.73.120.93 URL sip:mod_sofia@192.168.1.5:5060 BIND-URL sip:mod_sofia@192.168.1.5:5060 HOLD-MUSIC local_stream://moh OUTBOUND-PROXY N/A CODECS IN G7221@32000h,G7221@16000h,G722,PCMU,PCMA,GSM CODECS OUT G7221@32000h,G7221@16000h,G722,PCMU,PCMA,GSM TEL-EVENT 101 DTMF-MODE rfc2833 CNG 13 SESSION-TO 0 MAX-DIALOG 0 NOMEDIA false LATE-NEG false PROXY-MEDIA false AGGRESSIVENAT false STUN-ENABLED true STUN-AUTO-DISABLE false CALLS-IN 96 FAILED-CALLS-IN 15 CALLS-OUT 113 FAILED-CALLS-OUT 79 Registrations: =================================================================================================
On May 19, 2010, at 1:46 PM, Oleg Khovayko wrote:
Call from that phone is OK. But, when I try to call that phone from local, FS try to use wrong IP for connect:
No its not... you can't assume the channel name has anything to do with it... the fs_path is where its going. Have you bothered to look at the SIP traces? Also what SVN rev are you using? /b
2010-05-19 14:28:24.156706 [NOTICE] switch_channel.c:669 New Channel sofia/internal/sip:1015@10.0.0.135 [62b74c4f-7463-df11-ac63-005004c3cb7e]
Of course, connection can not be established.
Question: How to fix this problem? Or maybe, need to change FS, and always use REAL IP:PORT for establish outgoing call?
what SVN rev are you using?
I use latest official release 1.0.6, not SVN revision.
you can't assume the channel name has anything to do with it... I not assume, I see it. For Nokia record, FS PATH contains: ;fs_path=sip%3A1015%4094.71.98.45%3A17476%3Btransport%3DTCP But, call goes to sip:1015@10.0.0.135 - FS PATH is ignored.
the fs_path is where its going.
Also, you can see, for Sipdroid, no FS PATH in the Contact line: Contact: "user" <sip:1019@14.144.242.244:38592;transport=udp> Where if going from, when fs_path is missing?
Have you bothered to look at the SIP traces?
Excuse me, no. How can I do it? Brian West wrote:
On May 19, 2010, at 1:46 PM, Oleg Khovayko wrote:
Call from that phone is OK. But, when I try to call that phone from local, FS try to use wrong IP for connect:
No its not... you can't assume the channel name has anything to do with it... the fs_path is where its going. Have you bothered to look at the SIP traces? Also what SVN rev are you using?
/b
2010-05-19 14:28:24.156706 [NOTICE] switch_channel.c:669 New Channel sofia/internal/sip:1015@10.0.0.135 [62b74c4f-7463-df11-ac63-005004c3cb7e]
Of course, connection can not be established.
Question: How to fix this problem? Or maybe, need to change FS, and always use REAL IP:PORT for establish outgoing call?
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
On May 19, 2010, at 3:08 PM, Oleg Khovayko wrote:
what SVN rev are you using?
I use latest official release 1.0.6, not SVN revision.
you can't assume the channel name has anything to do with it... I not assume, I see it. For Nokia record, FS PATH contains: ;fs_path=sip%3A1015%4094.71.98.45%3A17476%3Btransport%3DTCP But, call goes to sip:1015@10.0.0.135 - FS PATH is ignored.
I really find that one hard to believe.
the fs_path is where its going.
Also, you can see, for Sipdroid, no FS PATH in the Contact line: Contact: "user" <sip:1019@14.144.242.244:38592;transport=udp> Where if going from, when fs_path is missing?
Because sipdroid does stun and is smart enough to figure out its own public IP and registers properly but the Nokia is stupid and doesn't know its public IP.
Have you bothered to look at the SIP traces?
Excuse me, no. How can I do it?
sofia profile xxx siptrace on I will be you its NOT ignoring the fs_path you just can't see the packet leaving and since its TCP the far side nat I suspect has closed the nat translation thus you'll need to register more often or enable keep alives on the device. /b
Brian West wrote:
I really find that one hard to believe.
Hard to believe, but this is true: I have made PURE experiment. My friend has registered SIP-phone behind NAT in Ukraine. His registration: Call-ID: 4a978b30@192.168.10.103 User: 1012@192.168.1.5 Contact: "user" <sip:1012@192.168.1.136:1024> Agent: AcctonVoIP/2.5 Status: Registered(UDP)(unknown) EXP(2010-05-23 14:27:20) Host: olegh.ath.cx IP: 91.207.244.1 Port: 1024 Auth-User: 1012 Auth-Realm: olegh.ath.cx MWI-Account: 1012@192.168.1.5 I tried call 1001 -> 1012, fs_cli prints: 2010-05-23 12:37:01.593320 [NOTICE] switch_channel.c:669 New Channel sofia/internal/sip:1012@192.168.1.136:1024 [2b79d969-8966-df11-ac63-005004c3cb7e] I sniffed network traffic, FS tries connect to his LAN address from "Contact", not his real address: olegh# tcpdump host'(192.168.1.136 or 91.207.244.1)' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on xl0, link-type EN10MB (Ethernet), capture size 96 bytes 12:40:55.044208 arp who-has 192.168.1.136 tell deskpro.khovayko.com 12:40:55.544711 arp who-has 192.168.1.136 tell deskpro.khovayko.com 12:40:56.545145 arp who-has 192.168.1.136 tell deskpro.khovayko.com 12:40:58.546827 arp who-has 192.168.1.136 tell deskpro.khovayko.com
sofia profile xxx siptrace on
I will be you its NOT ignoring the fs_path you just can't see the packet leaving and since its TCP the far side nat I suspect has closed the nat translation thus you'll need to register more often or enable keep alives on the device.
/b
I tried to do this -- results as same as with tcpdump. My local phone has number 1001, IP=192.168.1.130, try to call 1012 (behind NAT, see registration above): freeswitch@internal> freeswitch@internal> freeswitch@internal> recv 950 bytes from udp/[192.168.1.130]:5060 at 16:55:30.811681: ------------------------------------------------------------------------ INVITE sip:1012@192.168.1.5 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.130:5060;branch=z9hG4bKe2ba0d5f00302 From: 1001 Cabinet<sip:1001@192.168.1.5>;tag=4df567c4 To: 1012<sip:1012@192.168.1.5> Call-ID: 78fdee2b-17@192.168.1.130 CSeq: 1380166667 INVITE Max-Forwards: 70 Contact: 1001 Cabinet<sip:1001@192.168.1.130:5060> P-Preferred-Identity: 1001 Cabinet<sip:1001@192.168.1.5:5060> User-Agent: AcctonVoIP/2.5 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, REFER, NOTIFY, PRACK, UPDATE, MESSAGE, SERVICE, INFO, PING Allow-Events: refer Supported: 100rel, replaces Content-Length: 322 Content-Type: application/sdp v=0 o=- 608413784 756898537 IN IP4 192.168.1.130 s=Voice call e=you@yourcompany.com c=IN IP4 192.168.1.130 t=0 0 a=sendrecv m=audio 5000 RTP/AVP 0 8 18 100 a=ptime:20 a=maxptime:30 a=sendrecv a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:18 g729/8000 a=rtpmap:100 telephone-event/8000 a=fmtp:100 0-15 ------------------------------------------------------------------------ send 307 bytes to udp/[192.168.1.130]:5060 at 16:55:30.815843: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.1.130:5060;branch=z9hG4bKe2ba0d5f00302 From: 1001 Cabinet<sip:1001@192.168.1.5>;tag=4df567c4 To: 1012<sip:1012@192.168.1.5> Call-ID: 78fdee2b-17@192.168.1.130 CSeq: 1380166667 INVITE User-Agent: FreeSWITCH-mod_sofia/1.0.6-svn-exported Content-Length: 0 ------------------------------------------------------------------------ send 788 bytes to udp/[192.168.1.130]:5060 at 16:55:30.842061: ------------------------------------------------------------------------ SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP 192.168.1.130:5060;branch=z9hG4bKe2ba0d5f00302 From: 1001 Cabinet<sip:1001@192.168.1.5>;tag=4df567c4 To: 1012 <sip:1012@192.168.1.5>;tag=Za0U6NHjK7H6S Call-ID: 78fdee2b-17@192.168.1.130 CSeq: 1380166667 INVITE User-Agent: FreeSWITCH-mod_sofia/1.0.6-svn-exported Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, precondition, path, replaces Allow-Events: talk, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Proxy-Authenticate: Digest realm="192.168.1.5", nonce="4f2df2fe-8b66-df11-ac63-005004c3cb7e", algorithm=MD5, qop="auth" Content-Length: 0 ------------------------------------------------------------------------ recv 329 bytes from udp/[192.168.1.130]:5060 at 16:55:30.907144: ------------------------------------------------------------------------ ACK sip:1012@192.168.1.5 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.130:5060;branch=z9hG4bKe2ba0d5f00302 From: 1001 Cabinet<sip:1001@192.168.1.5>;tag=4df567c4 To: 1012<sip:1012@192.168.1.5>;tag=Za0U6NHjK7H6S Call-ID: 78fdee2b-17@192.168.1.130 CSeq: 1380166667 ACK Max-Forwards: 70 User-Agent: AcctonVoIP/2.5 Content-Length: 0 ------------------------------------------------------------------------ recv 1177 bytes from udp/[192.168.1.130]:5060 at 16:55:30.913127: ------------------------------------------------------------------------ INVITE sip:1012@192.168.1.5 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.130:5060;branch=z9hG4bK69429b9100303 From: 1001 Cabinet<sip:1001@192.168.1.5>;tag=4df567c4 To: 1012<sip:1012@192.168.1.5> Call-ID: 78fdee2b-17@192.168.1.130 CSeq: 1380166668 INVITE Max-Forwards: 70 Contact: 1001 Cabinet<sip:1001@192.168.1.130:5060> P-Preferred-Identity: 1001 Cabinet<sip:1001@192.168.1.5:5060> User-Agent: AcctonVoIP/2.5 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, SUBSCRIBE, REFER, NOTIFY, PRACK, UPDATE, MESSAGE, SERVICE, INFO, PING Allow-Events: refer Supported: 100rel, replaces Proxy-Authorization: Digest username="1001", realm="192.168.1.5", uri="sip:1012@192.168.1.5", nonce="4f2df2fe-8b66-df11-ac63-005004c3cb7e", qop=auth, cnonce="2f9b946d", nc=00000001, response="32cf7ea1d398bce1e1c8f53380a6bcea" Content-Length: 322 Content-Type: application/sdp v=0 o=- 608413784 756898537 IN IP4 192.168.1.130 s=Voice call e=you@yourcompany.com c=IN IP4 192.168.1.130 t=0 0 a=sendrecv m=audio 5000 RTP/AVP 0 8 18 100 a=ptime:20 a=maxptime:30 a=sendrecv a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:18 g729/8000 a=rtpmap:100 telephone-event/8000 a=fmtp:100 0-15 ------------------------------------------------------------------------ send 307 bytes to udp/[192.168.1.130]:5060 at 16:55:30.919399: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.1.130:5060;branch=z9hG4bK69429b9100303 From: 1001 Cabinet<sip:1001@192.168.1.5>;tag=4df567c4 To: 1012<sip:1012@192.168.1.5> Call-ID: 78fdee2b-17@192.168.1.130 CSeq: 1380166668 INVITE User-Agent: FreeSWITCH-mod_sofia/1.0.6-svn-exported Content-Length: 0 ------------------------------------------------------------------------ send 1302 bytes to udp/[192.168.1.136]:1024 at 16:55:31.703579: ------------------------------------------------------------------------ INVITE sip:1012@192.168.1.136:1024 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.5;rport;branch=z9hG4bK2ajD0jFj617vN Max-Forwards: 69 From: "Extension 1001" <sip:1001@192.168.1.5>;tag=1vjDacKSDSyBH To: <sip:1012@192.168.1.136:1024> Call-ID: d6d76003-e12e-122d-728c-2fb53066047d CSeq: 131198529 INVITE Contact: <sip:mod_sofia@192.168.1.5:5060> User-Agent: FreeSWITCH-mod_sofia/1.0.6-svn-exported Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, precondition, path, replaces Allow-Events: talk, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Privacy: none Content-Type: application/sdp Content-Disposition: session Content-Length: 425 X-FS-Support: update_display P-Asserted-Identity: "Extension 1001" <sip:1001@192.168.1.5> v=0 o=FreeSWITCH 1274609641 1274609642 IN IP4 192.168.1.5 s=FreeSWITCH c=IN IP4 192.168.1.5 t=0 0 m=audio 24090 RTP/AVP 0 115 107 9 8 3 101 13 a=rtpmap:0 PCMU/8000 a=rtpmap:115 G7221/32000 a=fmtp:115 bitrate=48000 a=rtpmap:107 G7221/16000 a=fmtp:107 bitrate=32000 a=rtpmap:9 G722/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 a=ptime:20 ------------------------------------------------------------------------
It's not ignoring the fs_path, it doesn't have one. Check your nat related settings in your sip profile, specifically your ext-sip-ip, nat-acl and localnet-acl settings. You would see the fspath in the contact and nat in the status if this was set correctly. Mike On May 23, 2010, at 1:01 PM, Oleg Khovayko wrote:
Brian West wrote:
I really find that one hard to believe.
Hard to believe, but this is true:
I have made PURE experiment. My friend has registered SIP-phone behind NAT in Ukraine. His registration:
Call-ID: 4a978b30@192.168.10.103 User: 1012@192.168.1.5 Contact: "user" <sip:1012@192.168.1.136:1024> Agent: AcctonVoIP/2.5 Status: Registered(UDP)(unknown) EXP(2010-05-23 14:27:20) Host: olegh.ath.cx IP: 91.207.244.1 Port: 1024 Auth-User: 1012 Auth-Realm: olegh.ath.cx MWI-Account: 1012@192.168.1.5
I tried call 1001 -> 1012, fs_cli prints:
2010-05-23 12:37:01.593320 [NOTICE] switch_channel.c:669 New Channel sofia/internal/sip:1012@192.168.1.136:1024 [2b79d969-8966-df11-ac63-005004c3cb7e]
I sniffed network traffic, FS tries connect to his LAN address from "Contact", not his real address:
olegh# tcpdump host'(192.168.1.136 or 91.207.244.1)' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on xl0, link-type EN10MB (Ethernet), capture size 96 bytes 12:40:55.044208 arp who-has 192.168.1.136 tell deskpro.khovayko.com 12:40:55.544711 arp who-has 192.168.1.136 tell deskpro.khovayko.com 12:40:56.545145 arp who-has 192.168.1.136 tell deskpro.khovayko.com 12:40:58.546827 arp who-has 192.168.1.136 tell deskpro.khovayko.com
sofia profile xxx siptrace on
I will be you its NOT ignoring the fs_path you just can't see the packet leaving and since its TCP the far side nat I suspect has closed the nat translation thus you'll need to register more often or enable keep alives on the device.
/b
I tried to do this -- results as same as with tcpdump. My local phone has number 1001, IP=192.168.1.130, try to call 1012 (behind NAT, see registration above):
Michael Jerris wrote:
It's not ignoring the fs_path, it doesn't have one. Check your nat related settings in your sip profile, specifically your ext-sip-ip, nat-acl and localnet-acl settings. You would see the fspath in the contact and nat in the status if this was set correctly. Everything exactly as same as in default configuration, everywhere is auto-nat:
[root@olegh /usr/local/freeswitch/conf/sip_profiles]# grep ext-sip-ip internal.xml <param name="ext-sip-ip" value="auto-nat"/> [root@olegh /usr/local/freeswitch/conf/sip_profiles]# grep t-acl internal.xml <param name="apply-nat-acl" value="nat.auto"/> and you see, no localnet-acl settings in there. //////////////////////////////////////////////////////////////////////////////// There is output of "sofia status profile internal", external Ext-RTP-IP/Ext-SIP-IP both correct: Name internal Domain Name N/A Auto-NAT true DBName sofia_reg_internal Pres Hosts Dialplan XML Context public Challenge Realm auto_from RTP-IP 192.168.1.5 Ext-RTP-IP 173.73.120.93 SIP-IP 192.168.1.5 Ext-SIP-IP 173.73.120.93 URL sip:mod_sofia@192.168.1.5:5060 BIND-URL sip:mod_sofia@192.168.1.5:5060 HOLD-MUSIC local_stream://moh OUTBOUND-PROXY N/A CODECS IN G7221@32000h,G7221@16000h,G722,PCMU,PCMA,GSM CODECS OUT G7221@32000h,G7221@16000h,G722,PCMU,PCMA,GSM TEL-EVENT 101 DTMF-MODE rfc2833 CNG 13 SESSION-TO 0 MAX-DIALOG 0 NOMEDIA false LATE-NEG false PROXY-MEDIA false AGGRESSIVENAT false STUN-ENABLED true STUN-AUTO-DISABLE false CALLS-IN 168 FAILED-CALLS-IN 32 CALLS-OUT 98 FAILED-CALLS-OUT 59 ///////////////////////////////////////////////// freeswitch@internal> sofia status internal profile sip:mod_sofia@192.168.1.5:5060 RUNNING (0) 192.168.1.5 alias internal ALIASED Really, with debug print, I see debug messages for Originarot's phone during call: 2010-05-23 18:55:57.399958 [DEBUG] sofia.c:5847 IP 192.168.1.130 Rejected by acl "domains". Falling back to Digest auth. 2010-05-23 18:55:57.501841 [DEBUG] sofia.c:5847 IP 192.168.1.130 Rejected by acl "domains". Falling back to Digest auth. But, it works OK no LAN, despite these messages. And, you right, after upgrade FS to 1.0.6, all fs_path-es gone. How to restore it? Thanks, Oleg
Mike
On May 23, 2010, at 1:01 PM, Oleg Khovayko wrote:
Brian West wrote:
I really find that one hard to believe.
Hard to believe, but this is true:
I have made PURE experiment. My friend has registered SIP-phone behind NAT in Ukraine. His registration:
Call-ID: 4a978b30@192.168.10.103 User: 1012@192.168.1.5 Contact: "user" <sip:1012@192.168.1.136:1024> Agent: AcctonVoIP/2.5 Status: Registered(UDP)(unknown) EXP(2010-05-23 14:27:20) Host: olegh.ath.cx IP: 91.207.244.1 Port: 1024 Auth-User: 1012 Auth-Realm: olegh.ath.cx MWI-Account: 1012@192.168.1.5
I tried call 1001 -> 1012, fs_cli prints:
2010-05-23 12:37:01.593320 [NOTICE] switch_channel.c:669 New Channel sofia/internal/sip:1012@192.168.1.136:1024 [2b79d969-8966-df11-ac63-005004c3cb7e]
I sniffed network traffic, FS tries connect to his LAN address from "Contact", not his real address:
olegh# tcpdump host'(192.168.1.136 or 91.207.244.1)' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on xl0, link-type EN10MB (Ethernet), capture size 96 bytes 12:40:55.044208 arp who-has 192.168.1.136 tell deskpro.khovayko.com <http://deskpro.khovayko.com> 12:40:55.544711 arp who-has 192.168.1.136 tell deskpro.khovayko.com <http://deskpro.khovayko.com> 12:40:56.545145 arp who-has 192.168.1.136 tell deskpro.khovayko.com <http://deskpro.khovayko.com> 12:40:58.546827 arp who-has 192.168.1.136 tell deskpro.khovayko.com <http://deskpro.khovayko.com>
sofia profile xxx siptrace on
I will be you its NOT ignoring the fs_path you just can't see the packet leaving and since its TCP the far side nat I suspect has closed the nat translation thus you'll need to register more often or enable keep alives on the device.
/b
I tried to do this -- results as same as with tcpdump. My local phone has number 1001, IP=192.168.1.130, try to call 1012 (behind NAT, see registration above):
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
On May 23, 2010, at 7:07 PM, Oleg Khovayko wrote:
Michael Jerris wrote:
It's not ignoring the fs_path, it doesn't have one. Check your nat related settings in your sip profile, specifically your ext-sip-ip, nat-acl and localnet-acl settings. You would see the fspath in the contact and nat in the status if this was set correctly.
Everything exactly as same as in default configuration, everywhere is auto-nat:
[root@olegh /usr/local/freeswitch/conf/sip_profiles]# grep ext-sip-ip internal.xml <param name="ext-sip-ip" value="auto-nat"/>
[root@olegh /usr/local/freeswitch/conf/sip_profiles]# grep t-acl internal.xml <param name="apply-nat-acl" value="nat.auto"/>
and you see, no localnet-acl settings in there.
So you removed the local-network-acl from the default config? Mike
Michael Jerris wrote:
On May 23, 2010, at 7:07 PM, Oleg Khovayko wrote:
Michael Jerris wrote:
It's not ignoring the fs_path, it doesn't have one. Check your nat related settings in your sip profile, specifically your ext-sip-ip, nat-acl and localnet-acl settings. You would see the fspath in the contact and nat in the status if this was set correctly.
Everything exactly as same as in default configuration, everywhere is auto-nat:
[root@olegh /usr/local/freeswitch/conf/sip_profiles]# grep ext-sip-ip internal.xml <param name="ext-sip-ip" value="auto-nat"/>
[root@olegh /usr/local/freeswitch/conf/sip_profiles]# grep t-acl internal.xml <param name="apply-nat-acl" value="nat.auto"/>
and you see, no localnet-acl settings in there.
So you removed the local-network-acl from the default config?
Mike No, I did not removed. See value:
[root@olegh /usr/local/freeswitch/conf/sip_profiles]# grep local-network-acl internal.xml <param name="local-network-acl" value="localnet.auto"/> [root@olegh /usr/local/freeswitch/conf/sip_profiles]# Just in the prev. message you asked about "localnet-acl", and I did not found exactly this tag in the config. Now, when you correctly wrote tag name, I have found it, and it has default value.
Hi, Michael After some personal investigation, I've found param aggressive-nat-detection, and uncommented it in the profile internal: ./sip_profiles/internal.xml: <param name="aggressive-nat-detection" value="true"/> After this step, I can see fs_path for remote sipdroid phone: Call-ID: 845794751536@14.18.161.240 User: 1019@192.168.1.5 Contact: "user" <sip:1019@14.18.161.240:43305;transport=udp;fs_nat=yes;fs_path=sip%3A1019%40208.54.45.78%3A16146%3Btransport%3Dudp> Agent: Sipdroid/1.4.6 beta/T-Mobile G1 Status: Registered(UDP-NAT)(unknown) EXP(2010-05-24 17:13:49) Host: olegh.ath.cx IP: 208.54.45.78 Port: 16146 Auth-User: 1019 Auth-Realm: olegh.ath.cx MWI-Account: 1019@192.168.1.5 Call goes OK, phone works! Thank you for help, Oleg
You shouldn't have to turn on aggressive nat detection. in the end your busted sipdroid should learn to overcome nat on its own. /b On May 24, 2010, at 2:20 PM, Oleg Khovayko wrote:
Hi, Michael
After some personal investigation, I've found param aggressive-nat-detection, and uncommented it in the profile internal:
./sip_profiles/internal.xml: <param name="aggressive-nat-detection" value="true"/>
After this step, I can see fs_path for remote sipdroid phone:
Call-ID: 845794751536@14.18.161.240 User: 1019@192.168.1.5 Contact: "user" <sip:1019@14.18.161.240:43305;transport=udp;fs_nat=yes;fs_path=sip%3A1019%40208.54.45.78%3A16146%3Btransport%3Dudp> Agent: Sipdroid/1.4.6 beta/T-Mobile G1 Status: Registered(UDP-NAT)(unknown) EXP(2010-05-24 17:13:49) Host: olegh.ath.cx IP: 208.54.45.78 Port: 16146 Auth-User: 1019 Auth-Realm: olegh.ath.cx MWI-Account: 1019@192.168.1.5
Call goes OK, phone works! Thank you for help,
Oleg
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
On May 24, 2010, at 12:32 PM, Brian West wrote:
in the end your busted sipdroid should learn to overcome nat on its own.
Ideally yes, everything will be proper in what it sends, however there is: The Robustness Principle: "Be liberal in what you accept, and conservative in what you send" is particularly important in the Internet layer, where one misbehaving host can deny Internet service to many other hosts. (from RFC1122 and this principle originated in RFC790 and is a Jon Postel founding principle). It is easy to just say that the other end should be fixed, there are enough software titles that do that already and end up not working well. I bring this up because I am chasing down the exposure of a bug in other VoIP software that used to not be present in a them->FS exchange but tightening of the FS code on what it accepts exposed the bug. So when it starts to get discussed that the other side should fix itself, I feel it important to bring this internet founding principle up. -- Trixter aka Bret McDanel http://www.0xdecafbad.com
It still doesn't negate the fact that agressive-nat shouldn't be used it breaks may may things. If it wasn't being detected properly then the local-network-acl or the inbound-nat-acl was wrong. /b On May 24, 2010, at 2:55 PM, Trixter aka Bret McDanel wrote:
It is easy to just say that the other end should be fixed, there are enough software titles that do that already and end up not working well. I bring this up because I am chasing down the exposure of a bug in other VoIP software that used to not be present in a them->FS exchange but tightening of the FS code on what it accepts exposed the bug. So when it starts to get discussed that the other side should fix itself, I feel it important to bring this internet founding principle up.
Brian West wrote:
You shouldn't have to turn on aggressive nat detection. in the end your busted sipdroid should learn to overcome nat on its own.
Maybe.. but, when I turn ON, I see fs_path-es for outer clients. If it is OFF, I never see fs_pathes. Can you suggest, how to enforce "fs_path-es without aggressive-nat-detection"? Also, I see another problem: My friend in the Ukraine, uses phone behind NAT, too (situation like to Sipdroid - he also behind NAT). There is his registration record: Call-ID: c4e76211@192.168.10.103 User: 1012@192.168.1.5 Contact: "user" <sip:1012@192.168.1.136:1024;fs_nat=yes;fs_path=sip%3A1012%4091.207.244.1%3A1024> Agent: AcctonVoIP/2.5 Status: Registered(UDP-NAT)(unknown) EXP(2010-05-24 17:49:15) Host: olegh.ath.cx IP: 91.207.244.1 Port: 1024 Auth-User: 1012 Auth-Realm: olegh.ath.cx MWI-Account: 1012@192.168.1.5 When he calls me, everything is OK, we can talk each to other. But, when I call him (from LAN), he receives RING signal, pick up handset -- and we both heard nothing. Can you suggest, where to search?
/b
On May 24, 2010, at 2:20 PM, Oleg Khovayko wrote:
Hi, Michael
After some personal investigation, I've found param aggressive-nat-detection, and uncommented it in the profile internal:
./sip_profiles/internal.xml:<param name="aggressive-nat-detection" value="true"/>
After this step, I can see fs_path for remote sipdroid phone:
Call-ID: 845794751536@14.18.161.240 User: 1019@192.168.1.5 Contact: "user" <sip:1019@14.18.161.240:43305;transport=udp;fs_nat=yes;fs_path=sip%3A1019%40208.54.45.78%3A16146%3Btransport%3Dudp> Agent: Sipdroid/1.4.6 beta/T-Mobile G1 Status: Registered(UDP-NAT)(unknown) EXP(2010-05-24 17:13:49) Host: olegh.ath.cx IP: 208.54.45.78 Port: 16146 Auth-User: 1019 Auth-Realm: olegh.ath.cx MWI-Account: 1019@192.168.1.5
Call goes OK, phone works! Thank you for help,
Oleg
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
Well I think you might have to compose your ACL's by hand and not use any of the auto ones.. Aggressive nat will break 302 processing along with transfers. Can you paste your profile into the email you have now and email it to the list please. /b On May 24, 2010, at 3:24 PM, Oleg Khovayko wrote:
Maybe.. but, when I turn ON, I see fs_path-es for outer clients. If it is OFF, I never see fs_pathes. Can you suggest, how to enforce "fs_path-es without aggressive-nat-detection"?
Also, I see another problem: My friend in the Ukraine, uses phone behind NAT, too (situation like to Sipdroid - he also behind NAT).
There is his registration record:
Call-ID: c4e76211@192.168.10.103 User: 1012@192.168.1.5 Contact: "user" <sip:1012@192.168.1.136:1024;fs_nat=yes;fs_path=sip%3A1012%4091.207.244.1%3A1024> Agent: AcctonVoIP/2.5 Status: Registered(UDP-NAT)(unknown) EXP(2010-05-24 17:49:15) Host: olegh.ath.cx IP: 91.207.244.1 Port: 1024 Auth-User: 1012 Auth-Realm: olegh.ath.cx MWI-Account: 1012@192.168.1.5
When he calls me, everything is OK, we can talk each to other. But, when I call him (from LAN), he receives RING signal, pick up handset -- and we both heard nothing.
Can you suggest, where to search?
participants (4)
-
Brian West
-
Michael Jerris
-
Oleg Khovayko
-
Trixter aka Bret McDanel