Any news on this problem? -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Douglas Hubler Sent: Wednesday, October 10, 2012 1:19 PM To: Discussion list for users of sipXecs software Subject: Re: [sipx-users] 4.6 Cluster
I reread your post, i totally misunderstood. I thought you were ready to make a concession for now until bria support for redundant, tls servers fix is committed. ezuce wants tls to work on redundant systems so we'd have a vested interest in getting this fixed in 4.6.0, it's only a matter of time and seems like an easy fix. Thanks for finding the issue, I don't think we tested HA and TLS together yet. On Tue, Oct 9, 2012 at 5:36 PM, darthzejdr <[email protected]> wrote: > Yes it does, but the problem is i need it to work with domain > registration and tls. Setting a proxy means i can't use failover, and > then i don't actualy need 2 servers. Also it doesn't actualy help with > comunication since if i register bria on 1 server, and another bria on > second, i'll still have the same tcp problem i'm having here. Atm the > only way i can use domain is using udp, and that's not really a good > solution for me since i really need the tls for security. > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Douglas > Hubler > Sent: Tuesday, October 09, 2012 10:22 PM > To: Discussion list for users of sipXecs software > Subject: Re: [sipx-users] 4.6 Cluster > > does bria allow you to set an outbound proxy? polycom has this. so > essentially it will allow you to register > > [email protected] > > at server > > server1.domain.com > > > On Tue, Oct 9, 2012 at 9:44 AM, darthzejdr <[email protected]> wrote: >> I haven't found a way to insert the path header. Did you manage to >> think of a way to fix it on your end? Or any other ideas on what i >> could try? Is there any way to forward calls to server1, so it >> initializes calls to bria instead of server 2? >> >> >> >> From: Joegen Baclor [mailto:[email protected]] >> Sent: Friday, October 05, 2012 9:18 AM >> >> >> To: Discussion list for users of sipXecs software >> Cc: darthzejdr >> Subject: Re: [sipx-users] 4.6 Cluster >> >> >> >> If you can make Bria insert a Path header in REGISTER, that should >> solve your issue. We are discussing a workable solution but there is >> nothing final yet. >> >> On 10/05/2012 02:57 PM, darthzejdr wrote: >> >> So, is there anything i can do to fix this? Or does it need to be >> fixed on a server level? I need to be able to use TLS and clustering, >> and from what i see here i won't have comunication between my sites >> if i use anything except UDP. >> >> >> >> From: Joegen Baclor [mailto:[email protected]] >> Sent: Thursday, October 04, 2012 4:39 PM >> To: Discussion list for users of sipXecs software >> Cc: darthzejdr >> Subject: Re: [sipx-users] 4.6 Cluster >> >> >> >> Finally I got the trace I need to provide you with an analysis >> >> ./Server1/sipregistrar.log-20121004:"2012-10-03T11:28:33.730099Z":367: >> INCOMING:INFO:sipx1.callidus.local:SipClientTcp-31:7f1f8acf5700:SipRe >> g >> istrar:"Read >> SIP message: >> ----Local Host:192.168.0.46---- Port: 5060---- ----Remote >> Host:192.168.0.46---- Port: 39985---- REGISTER >> sip:192.168.0.46;transport=tcp SIP/2.0\r >> Route: <sip:rr.sipx1.callidus.local;transport=tcp;lr>\r >> Via: SIP/2.0/TCP >> 192.168.0.46;branch=z9hG4bK-XX-0001JZfBODnCeQ5GLt01pwXDbw\r >> Via: SIP/2.0/TCP >> 192.168.0.66:36070;branch=z9hG4bK-d8754z-2110ba28537b1953-1---d8754z- >> ; >> rport=60123\r >> Max-Forwards: 20\r >> Contact: >> <sip:[email protected]:55243;rinstance=4782eca9743a1724;transport=TCP; >> x >> -sipX-nonat>\r >> To: \"201\"<sip:[email protected]>\r >> From: \"201\"<sip:[email protected]>;tag=1775733c\r >> Call-Id: NTQwOTE2OWIwYmQyN2JmNDdjN2FmZDhkNzE1YjkyZjk.\r >> Cseq: 1 REGISTER\r >> Expires: 3600\r >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, >> SUBSCRIBE, INFO\r >> User-Agent: Bria release 2.2 stamp 45414\r >> Content-Length: 0\r >> Date: Wed, 03 Oct 2012 11:28:33 GMT\r >> X-Sipx-Spiral: true\r >> \r >> ====================END==================== >> >> >> >> This is the register sent by Bria to your master server. You will see >> that the contact is towards an ephemeral port >> ([email protected]:55243). The problem with TCP is it is connection >> oriented. And if a phone registers TCP, it normally intends to >> receive incoming request via the same connection. Thus, since your >> Bria is registered to the master server, calls from secondary will >> not be able to connect to port 55243 since it is already in use to >> connect to the master. The INVITE from secondary towards the Bria is timed out. > See Sip messages below. >> >> >> >> ./Server2/sipXproxy.log-20121004:"2012-10-03T06:49:21.751101Z":4231:O >> U >> TGOING:INFO:sipx2.callidus.local:SipUserAgent-0:7f03249c1700:SipXProx >> y >> :"SipUserAgent::sendTcp >> TCP SIP User Agent sent message: >> ----Local Host:192.168.0.47---- Port: -1---- ----Remote >> Host:192.168.0.66---- Port: 55243---- INVITE >> sip:[email protected]:55243;transport=TCP;rinstance=77652402758671b3;x >> - >> sipX-nonat >> SIP/2.0\r >> Record-Route: >> <sip:192.168.0.47:5060;lr;sipXecs-CallDest=INT;sipXecs-rs=%2Aauth%7E. >> % 2Afrom%7EY2QwOWY3M2M%60%2195d58d323e0b74721490b5960f9aacdb>\r >> Via: SIP/2.0/TCP >> 192.168.0.47;branch=z9hG4bK-XX-007aGHD2233NJ37`o7R9ub11Sg\r >> Via: SIP/2.0/UDP >> 192.168.0.47;branch=z9hG4bK-XX-0073ek6_NOw9GHGEKiPxB1mC7Q~UgrmM4eHLTV >> E >> MlRgE`UzIA\r >> Via: SIP/2.0/TCP >> 192.168.0.55:49440;branch=z9hG4bK-d8754z-5f3c597876149a55-1---d8754z- >> ; >> rport=1889\r >> Max-Forwards: 18\r >> Contact: <sip:[email protected]:1889;transport=TCP;x-sipX-nonat>\r >> To: <sip:[email protected]>\r >> From: \"200\"<sip:[email protected]>;tag=cd09f73c\r >> Call-Id: NTkwMmY1MTExNWQxZmI0OTVkNDI0ZjFlNzE4ZTUyYTM.\r >> Cseq: 2 INVITE\r >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, >> SUBSCRIBE, INFO\r >> Content-Type: application/sdp\r >> Proxy-Authorization: Digest >> username=\"200\",realm=\"callidus.local\",nonce=\"0b61a318caca69024f6 >> 8 >> 03b99fcd402a506bdff0\",uri=\"sip:[email protected];transport=tcp\",res >> p >> onse=\"7717633a520ccd47215721a17f276e8e\",cnonce=\"aad9569089334a9627 >> 4 f1a7839d054d7\",nc=00000001,qop=auth,algorithm=MD5\r >> User-Agent: Bria release 2.2 stamp 45414\r >> Content-Length: 480\r >> Date: Wed, 03 Oct 2012 06:49:20 GMT\r >> Expires: 20\r >> \r >> v=0\r >> o=- 2 2 IN IP4 192.168.0.55\r >> s=CounterPath Bria\r >> c=IN IP4 192.168.0.55\r >> t=0 0\r >> m=audio 2592 RTP/AVP 107 119 100 106 0 98 8 18 101\r >> a=alt:1 1 : 8oh9Hd/J 65epFIay 192.168.0.55 2592\r >> a=fmtp:18 annexb=yes\r >> a=fmtp:101 0-15\r >> a=rtpmap:107 BV32/16000\r >> a=rtpmap:119 BV32-FEC/16000\r >> a=rtpmap:100 SPEEX/16000\r >> a=rtpmap:106 SPEEX-FEC/16000\r >> a=rtpmap:98 iLBC/8000\r >> a=rtpmap:18 G729/8000\r >> a=rtpmap:101 telephone-event/8000\r >> a=sendrecv\r >> a=x-rtp-session-id:E06731ED3F024F80A7328BCDEB36DFDB\r >> --------------------END-------------------- >> " >> ./Server2/sipXproxy.log-20121004:"2012-10-03T06:49:22.532219Z":4237:O >> U >> TGOING:INFO:sipx2.callidus.local:SipUserAgent-0:7f03249c1700:SipXProx >> y >> :"SipUserAgent::sendUdp >> UDP SIP User Agent sent message: >> ----Local Host:192.168.0.47---- Port: 5060---- ----Remote >> Host:192.168.0.47---- Port: 5060---- >> SIP/2.0 408 Request timeout\r >> From: \"200\"<sip:[email protected]>;tag=cd09f73c\r >> To: <sip:[email protected]>;tag=sps0im\r >> Call-Id: NTkwMmY1MTExNWQxZmI0OTVkNDI0ZjFlNzE4ZTUyYTM.\r >> Cseq: 2 INVITE\r >> Via: SIP/2.0/UDP >> 192.168.0.47;branch=z9hG4bK-XX-006fPVfBK8gIftTBiiPIQE9c4A~UgrmM4eHLTV >> E >> MlRgE`UzIA\r >> Via: SIP/2.0/TCP >> 192.168.0.55:49440;branch=z9hG4bK-d8754z-5f3c597876149a55-1---d8754z- >> ; >> rport=1889\r >> Record-Route: <sip:192.168.0.47:5060;lr>\r >> Server: sipXecs/4.6.0 sipXecs/sipXproxy (Linux)\r >> Content-Length: 0\r >> \r >> --------------------END-------------------- >> >> >> >> >> >> On 10/04/2012 10:16 PM, darthzejdr wrote: >> >> Server1: >> >> [root@sipx1 ~]# iptables -L -n >> >> Chain INPUT (policy DROP) >> >> target prot opt source destination >> >> ACCEPT all -- 192.168.0.46 0.0.0.0/0 >> >> ACCEPT all -- 192.168.0.47 0.0.0.0/0 >> >> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 >> >> state NEW,ESTABLISHED >> >> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 >> >> state NEW,ESTABLISHED >> >> ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53 >> >> state NEW,ESTABLISHED >> >> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21 >> >> state NEW,ESTABLISHED >> >> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:20 >> >> state NEW,ESTABLISHED >> >> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp >> >> dpts:50000:50050 state NEW,ESTABLISHED >> >> ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp >> >> dpts:30000:31000 state NEW,ESTABLISHED >> >> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:5060 >> >> state NEW,ESTABLISHED >> >> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:5061 >> >> state NEW,ESTABLISHED >> >> ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:5060 >> >> state NEW,ESTABLISHED >> >> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:5080 >> >> state NEW,ESTABLISHED >> >> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:5081 >> >> state NEW,ESTABLISHED >> >> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 >> >> state NEW,ESTABLISHED >> >> ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:69 >> >> state NEW,ESTABLISHED >> >> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state >> >> RELATED,ESTABLISHED >> >> ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 >> >> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 >> >> >> >> Chain FORWARD (policy DROP) >> >> target prot opt source destination >> >> >> >> Chain OUTPUT (policy ACCEPT) >> >> target prot opt source destination >> >> >> >> Chain syn-flood (0 references) >> >> target prot opt source destination >> >> >> >> >> >> Server2: >> >> [root@sipx2 ~]# iptables -L -n >> >> Chain INPUT (policy DROP) >> >> target prot opt source destination >> >> ACCEPT all -- 192.168.0.46 0.0.0.0/0 >> >> ACCEPT all -- 192.168.0.47 0.0.0.0/0 >> >> ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53 >> >> state NEW,ESTABLISHED >> >> ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp >> >> dpts:30000:31000 state NEW,ESTABLISHED >> >> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:5060 >> >> state NEW,ESTABLISHED >> >> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:5061 >> >> state NEW,ESTABLISHED >> >> ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:5060 >> >> state NEW,ESTABLISHED >> >> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 >> >> state NEW,ESTABLISHED >> >> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state >> >> RELATED,ESTABLISHED >> >> ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 >> >> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 >> >> >> >> Chain FORWARD (policy DROP) >> >> target prot opt source destination >> >> >> >> Chain OUTPUT (policy ACCEPT) >> >> target prot opt source destination >> >> >> >> Chain syn-flood (0 references) >> >> target prot opt source destination >> >> >> >> >> >> >> >> -----Original Message----- >> >> From: [email protected] >> >> [mailto:[email protected]] On Behalf Of George >> Niculae >> >> Sent: Thursday, October 04, 2012 3:27 PM >> >> To: Discussion list for users of sipXecs software >> >> Subject: Re: [sipx-users] 4.6 Cluster >> >> >> >> On Thu, Oct 4, 2012 at 4:05 PM, darthzejdr <[email protected]> wrote: >> >> So, we've discovered the problem(and a partial solution). It works as >> >> it should only if we're both using udp. >> >> >> >> 200(Server2, TCP) -> 201(Server1, TCP) doesn't work 201(Server1, TCP) >> >> -> 200(Server2, TCP) doesn't work >> >> >> >> 200(Server2, UDP) -> 201(Server1, TCP) works 201(Server1, TCP) -> >> >> 200(Server2, UDP) doesn't work >> >> >> >> 200(Server2, TCP) -> 201(Server1, UDP) doesn't work 201(Server1, UDP) >> >> -> 200(Server2, TCP) works >> >> >> >> 200(Server2, UDP) -> 201(Server1, UDP) works 201(Server1, UDP) -> >> >> 200(Server2, UDP) works >> >> >> >> >> >> We're looking at the logs, can you post output for iptables -L -n >> from both >> >> nodes meanwhile? >> >> >> >> George >> >> _______________________________________________ >> >> sipx-users mailing list >> >> [email protected] >> >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> >> >> >> _______________________________________________ >> >> sipx-users mailing list >> >> [email protected] >> >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> sipx-users mailing list >> >> [email protected] >> >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> >> >> >> >> _______________________________________________ >> sipx-users mailing list >> [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/ _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
