tcp call misses sip message
Hello everyone! I'v got strange problem with incomplete call via tcp transport. When I perform bridged call from one ua (no matter what transport udp or tcp) through FS this call's leg b message sequence (over tcp) lacks finishing SIP message what in it's turn cause the call to be disconnected by the client by timeout. Everything works fine with local calls, so I guess the problem is somewhere between UA and FS. There is no NAT and calls via udp are being established correctly. The problem is with tcp and tls as well. This is the sender's ua SIP trace: TX 1049 bytes Request msg INVITE/cseq=11615 (tdta0486C000) to UDP : RX 348 bytes Response msg 100/INVITE/cseq=11615 (rdata0482806C) from UDP : RX 813 bytes Response msg 407/INVITE/cseq=11615 (rdata0482806C) from UDP : TX 346 bytes Request msg ACK/cseq=11615 (tdta0486EFD0) to UDP : TX 1324 bytes Request msg INVITE/cseq=11616 (tdta0486C000) to UDP : RX 348 bytes Response msg 100/INVITE/cseq=11616 (rdata0482806C) from UDP : RX 1083 bytes Response msg 200/INVITE/cseq=11616 (rdata0482806C) from UDP : TX 360 bytes Request msg ACK/cseq=11616 (tdta04874E38) to UDP : And this is the reciever's SIP trace: RX 1167 bytes Request msg INVITE/cseq=122911315 (rdata04864E10) from tcp : TX 298 bytes Response msg 100/INVITE/cseq=122911315 (tdta0486D010) to tcp : TX 801 bytes Response msg 200/INVITE/cseq=122911315 (tdta0486D010) to tcp : ------ I guess this is where ACK is supposed to arrive Retransmiting Response msg 200/INVITE/cseq=122911315 (tdta0486D010), count=0, restart?=1 TX 801 bytes Response msg 200/INVITE/cseq=122911315 (tdta0486D010) to tcp : Retransmiting Response msg 200/INVITE/cseq=122911315 (tdta0486D010), count=0, restart?=2 TX 801 bytes Response msg 200/INVITE/cseq=122911315 (tdta0486D010) to tcp : Retransmiting Response msg 200/INVITE/cseq=122911315 (tdta0486D010), count=0, restart?=3 TX 801 bytes Response msg 200/INVITE/cseq=122911315 (tdta0486D010) to tcp : .... Sofia profile config: <param name="debug" value="8"/> <param name="sip-trace" value="yes"/> <param name="rfc2833-pt" value="101"/> <param name="sip-port" value="$${external_call_sip_port}"/> <param name="dialplan" value="XML"/> <param name="context" value="public"/> <param name="dtmf-duration" value="100"/> <param name="codec-prefs" value="$${global_codec_prefs}"/> <param name="hold-music" value="$${hold_music}"/> <param name="use-rtp-timer" value="true"/> <param name="rtp-timer-name" value="soft"/> <param name="session-timeout" value="172800"/> <param name="enable-timer" value="false"/> <param name="minimum-session-expires" value="172800"/> <param name="pass-callee-id" value="false"/> <param name="manage-presence" value="true"/> <param name="challenge-realm" value="auto_from"/> <param name="force-register-domain" value="$${domain}"/> <param name="send-message-query-on-register" value="false"/> <param name="aggressive-nat-detection" value="true"/> <param name="inbound-proxy-media" value="true"/> <param name="inbound-bypass-media" value="false"/> <param name="inbound-late-negotiation" value="true"/> <param name="inbound-codec-negotiation" value="generous"/> <param name="nonce-ttl" value="60"/> <param name="auth-calls" value="true"/> <param name="rtp-timeout-sec" value="1800"/> <param name="accept-blind-auth" value="false"/> <param name="rtp-ip" value="$${local_ip_v4}"/> <param name="sip-ip" value="$${local_ip_v4}"/> <param name="rtp-timeout-sec" value="300"/> <param name="rtp-hold-timeout-sec" value="1800"/> <param name="tls" value="$${external_ssl_enable}"/> <param name="tls-bind-params" value="transport=tls"/> <param name="tls-sip-port" value="$${external_call_tls_port}"/> <param name="tls-cert-dir" value="$${external_ssl_dir}"/> <param name="tls-version" value="$${sip_tls_version}"/> and super-smart dialplan <extension name="one2one"> <condition field="destination_number" expression="(.*)"> <action application="bridge" data="sofia/external_call/$1%${domain_name}"/> </condition> </extension> FS 1.0.5pre5 is running on Windows Server 2007SP1 64bit.This issue first occured with 1.0.4 release. Best regards, Robert
but FS does use tcp for that call leg -> RX 1167 bytes ... from *tcp* ...: And after all there can be other SIP transports combinations FS should interconnect...
I've tried to add ;transport=tcp in dialplan bridge application and it has ended up with error on FS with message "can't find registered extension * called_extension*%external_call;transport=tcp" whereas this extension is registered in FS via tcp. Also I tried to reproduce the same scenario with public SIP server and everything worked fine from what I can draw that problem is with my FS configuration or maybe with some FS host's network configuration. Any help will be appretiated. Best regards, Robert.
How exactly are you doing this? /b On Nov 18, 2009, at 7:07 AM, RobertT wrote:
I've tried to add ;transport=tcp in dialplan bridge application and it has ended up with error on FS with message "can't find registered extension called_extension%external_call;transport=tcp" whereas this extension is registered in FS via tcp. Also I tried to reproduce the same scenario with public SIP server and everything worked fine from what I can draw that problem is with my FS configuration or maybe with some FS host's network configuration. Any help will be appretiated.
Well, I start 2 user agents. Each of them successfully registers as 1000 & 1001 extensions via tcp SIP transport. Then I issue a call, say from 1000 to 1001, and watch it being disconnected in several seconds by recieving client due to abovementioned conditions (no completing answer from FS). Why is it happening???
Well depends are you using x-lite 4 beta? you didn't include ANY logs... I know TCP to TCP works fine I use that daily. can you include some debug logs or join #freeswitch on irc.freenode.net? /b On Nov 20, 2009, at 6:30 AM, RobertT wrote:
Well, I start 2 user agents. Each of them successfully registers as 1000 & 1001 extensions via tcp SIP transport. Then I issue a call, say from 1000 to 1001, and watch it being disconnected in several seconds by recieving client due to abovementioned conditions (no completing answer from FS). Why is it happening??? _______________________________________________ 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
No, I don't use Xlite. I use my own .Net wrapper around pjsip ua lib. Foreseeing uncertaincies about it's quality I may say that pjsua reference implementation yields the same results in this scenario. Actually I have no doubt that FS is working nicely with tcp and tls as well because I had it working till some moment. And I don't know what the hell happened. =( In order to check if it is something related to my config I switched it back to default and conducted the same test with (urghhh) no luck as well. So now I wonder what could cause this very-very strange behavior? Some issues with network? But why the UDP works then? All traces (FS SIP, FS console, SIP caller and callee's) are here: http://pastebin.com/m2008de4e Regards, Robert.
Attached is graphical representation of SIP message flow. You can see that for some reason FS doesn't resend to callee an ACK message recieved from caller. Regards, RobertT
Well since we aren't a proxy we wouldn't resend the one we receive... what svn rev and are you using proxy media? /b On Nov 21, 2009, at 7:28 AM, RobertT wrote:
Attached is graphical representation of SIP message flow. You can see that for some reason FS doesn't resend to callee an ACK message recieved from caller.
Regards, RobertT
Yep, I use proxy media. First it started with 1.0.4 release, then I've updated a week or two ago with the latest svn trunk, not sure what was the rev number.
This looks like a nat issue to me, please re-test this against latest svn trunk and if its still not working pastebin a full sip trace and report the link back here. Mike On Nov 21, 2009, at 6:23 PM, RobertT wrote:
Yep, I use proxy media. First it started with 1.0.4 release, then I've updated a week or two ago with the latest svn trunk, not sure what was the rev number. _______________________________________________ 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
OK, this is what I've got. First, I've updated FreeSwitch from trunk to version 15630 and deployed it to my server. Performed a tets and again no magic happened. The link to SIP trace is below. Then I've installed 1.0.4 version to another server (virtual hosting), and performed tha same. And everything went OK. This server's log is below as well. Not working - http://pastebin.com/m2e97985d Working - http://pastebin.com/m3c1e6bfe Also in both cases there is a strange detail - clients' SIP ports are configured to be 5060 and 5061, but what can be seen in trace differs from these values whereas stun resolution shows that there is no NAT (clients connect with ADSL modem). Regards, Robert
You know what, guys? I've just made it working be opening ALL tcp trafic in and out from server by adding two match-all ip filters into local security policy. I can't say I like this solution... Why did this problem appeared with policy matching exact (sofia profiles) ports? Regards, Robert.
participants (3)
-
Brian West
-
Michael Jerris
-
RobertT