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: sipx-users-boun...@list.sipfoundry.org [mailto:sipx-users-boun...@list.sipfoundry.org] 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 j...@domain.com at server server1.domain.com On Tue, Oct 9, 2012 at 9:44 AM, darthzejdr <darthze...@gmail.com> 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:jbac...@ezuce.com] > 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:jbac...@ezuce.com] > 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:SipReg > 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:201@192.168.0.66:55243;rinstance=4782eca9743a1724;transport=TCP;x > -sipX-nonat>\r > To: \"201\"<sip:201@192.168.0.46>\r > From: \"201\"<sip:201@192.168.0.46>;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 > (201@192.168.0.66: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:OU > TGOING:INFO:sipx2.callidus.local:SipUserAgent-0:7f03249c1700:SipXProxy > :"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:201@192.168.0.66: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~UgrmM4eHLTVE > 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:200@192.168.0.55:1889;transport=TCP;x-sipX-nonat>\r > To: <sip:201@192.168.0.47>\r > From: \"200\"<sip:200@192.168.0.47>;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=\"0b61a318caca69024f68 > 03b99fcd402a506bdff0\",uri=\"sip:201@192.168.0.47;transport=tcp\",resp > onse=\"7717633a520ccd47215721a17f276e8e\",cnonce=\"aad9569089334a96274 > 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:OU > TGOING:INFO:sipx2.callidus.local:SipUserAgent-0:7f03249c1700:SipXProxy > :"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:200@192.168.0.47>;tag=cd09f73c\r > To: <sip:201@192.168.0.47>;tag=sps0im\r > Call-Id: NTkwMmY1MTExNWQxZmI0OTVkNDI0ZjFlNzE4ZTUyYTM.\r > Cseq: 2 INVITE\r > Via: SIP/2.0/UDP > 192.168.0.47;branch=z9hG4bK-XX-006fPVfBK8gIftTBiiPIQE9c4A~UgrmM4eHLTVE > 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: sipx-users-boun...@list.sipfoundry.org > > [mailto:sipx-users-boun...@list.sipfoundry.org] 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 <darthze...@gmail.com> 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 > > sipx-users@list.sipfoundry.org > > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > > > _______________________________________________ > > sipx-users mailing list > > sipx-users@list.sipfoundry.org > > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > > > > > > > > _______________________________________________ > > sipx-users mailing list > > sipx-users@list.sipfoundry.org > > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > > > > _______________________________________________ > sipx-users mailing list > sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users/ _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/ _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/