Re: [OpenSIPS-Users] Call sequence in serial forking
Hi John Did you try changing the Call-ID of every INVITE? "Merged Request" should be generated with requests that have same From tag, Call-ID, and CSeq https://tools.ietf.org/html/rfc3261#section-8.2.2.2 Regards, On Mon, Jan 12, 2015 at 2:09 AM, John Nash wrote: > I am testing one setup where opensips drouting module sends call to > "Freeswitch" and I encountered one situation ... > > UA sends Invite to opensips, opensips uses drouting module and sends > Invite to Freeswitch , callee rejects the call and opensips sends ACK to > freeswitch and sends second invite (from failure route). This second invite > (which has same call id but different branch in via) is not treated as > another transaction by freeswitch and it sends back SIP 482 Request merged > response. > > I had the same setup tested using SEMS as SBC some times back > successfully. I am not sure which side this issue should be taken care of > (opensips or freeswitch) > > I looked in some freeswitch mail archives and in one post I can see > someone suggesting that from opensips side we should increase Cseq in case > of second invite. I think this can be done using script but I am not sure > if i should do or not. > This is the post > > http://lists.freeswitch.org/pipermail/freeswitch-users/2013-February/092600.html > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- NguyenVD ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] TLS Error
Hi Gary The "TLS connection to 107.199.61.85:56437 read failed" error occurs when the device (Android & iOS) kills the application. -- NguyenVD ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] opensips tcp state
Hi all, After running opensips for a while (one or two days), I got this log message: *INFO:core:send2child: no free tcp receiver, connection passed to the least busy one (46)* *INFO:core:probe_max_sock_buff: using snd buffer of 509 kb* Then I checked the number of tcp connections: #*opensipsctl fifo list_tcp_conns* It displayed about 145 connections, but it's impossible since this is the testing server only. Here are all the output: - Connection:: ID=1203 Type=tls State=18446744073709551615 Source= 67.21.5.36:12497 Destination=sip_test_ip:5061 Timeout=2014-12-02 01:33:26 Pending lifetime=135250 Connection:: ID=1206 Type=tcp State=3 Source=162.236.129.149:62237 Destination=sip_test_ip:5060 Timeout=2014-12-03 14:10:18 Pending lifetime=0 Connection:: ID=1214 Type=tcp State=3 Source=162.236.129.149:62272 Destination=sip_test_ip:5060 Timeout=2014-12-03 14:24:18 Pending lifetime=0 Connection:: ID=1221 Type=tls State=0 Source=67.21.5.36:61790 Destination=sip_test_ip:5061 Timeout=2014-12-03 15:38:27 Pending lifetime=137101 Connection:: ID=1222 Type=tcp State=3 Source=172.56.38.226:46235 Destination=sip_test_ip:5060 Timeout=2014-12-03 14:41:55 Pending lifetime=0 Connection:: ID=1223 Type=tcp State=3 Source=172.56.38.226:27013 Destination=sip_test_ip:5060 Timeout=2014-12-03 14:43:36 Pending lifetime=0 Connection:: ID=1224 Type=tcp State=3 Source=162.236.129.149:62314 Destination=sip_test_ip:5060 Timeout=2014-12-03 14:45:10 Pending lifetime=0 Connection:: ID=1225 Type=tcp State=3 Source=162.236.129.149:62327 Destination=sip_test_ip:5060 Timeout=2014-12-03 14:48:55 Pending lifetime=0 Connection:: ID=1226 Type=tcp State=3 Source=162.236.129.149:62344 Destination=sip_test_ip:5060 Timeout=2014-12-03 14:59:33 Pending lifetime=0 Connection:: ID=1227 Type=tcp State=3 Source=162.236.129.149:62352 Destination=sip_test_ip:5060 Timeout=2014-12-03 15:04:56 Pending lifetime=0 Connection:: ID=1228 Type=tcp State=3 Source=162.236.129.149:62366 Destination=sip_test_ip:5060 Timeout=2014-12-03 15:15:34 Pending lifetime=0 Connection:: ID=1229 Type=tls State=3 Source=67.21.5.36:26619 Destination=sip_test_ip:5061 Timeout=2014-12-03 15:16:41 Pending lifetime=0 Connection:: ID=1230 Type=tls State=3 Source=67.21.5.36:22292 Destination=sip_test_ip:5061 Timeout=2014-12-03 15:19:29 Pending lifetime=0 [...] - According to netstat, the server had lots of CLOSE_WAIT sockets: - tcp 361 0 sip_test_ip:5061 67.21.5.36:32969 CLOSE_WAIT tcp 361 0 sip_test_ip:5061 67.21.5.36:36210 CLOSE_WAIT tcp 361 0 sip_test_ip:5061 67.21.5.36:17264 CLOSE_WAIT tcp 361 0 sip_test_ip:5061 67.21.5.36:10884 CLOSE_WAIT tcp 464 0 sip_test_ip:5060 172.56.38.226:65288 ESTABLISHED tcp 361 0 sip_test_ip:5061 67.21.5.36:56345 CLOSE_WAIT tcp 361 0 sip_test_ip:5061 67.21.5.36:46915 CLOSE_WAIT tcp 361 0 sip_test_ip:5061 67.21.5.36:62188 CLOSE_WAIT tcp 361 0 sip_test_ip:5061 67.21.5.36:28660 CLOSE_WAIT tcp 361 0 sip_test_ip:5061 67.21.5.36:62848 CLOSE_WAIT tcp 361 0 sip_test_ip:5061 67.21.5.36:16914 CLOSE_WAIT tcp 361 0 sip_test_ip:5061 67.21.5.36:37157 CLOSE_WAIT tcp 361 0 sip_test_ip:5061 67.21.5.36:27378 CLOSE_WAIT --- I think something happened with the first TCP connection because it had "strange" State = 18446744073709551615 So what is "State" mean? -- NguyenVD ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
