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:INCOMI NG:INFO:sipx1.callidus.local:SipClientTcp-31:7f1f8acf5700:SipRegistrar:"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: <mailto:sip:[email protected]:55243;rinstance=4782eca9743a1724;transport=TCP; x-sipX-nonat> <sip:[email protected]:55243;rinstance=4782eca9743a1724;transport=TCP;x-sipX- nonat>\r To: \"201\" <mailto:sip:[email protected]> <sip:[email protected]>\r From: \"201\" <mailto:sip:[email protected]> <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:OUTGOING :INFO:sipx2.callidus.local:SipUserAgent-0:7f03249c1700:SipXProxy:"SipUserAge nt::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-n onat 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~UgrmM4eHLTVEMlRgE` 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: <mailto:sip:[email protected]:1889;transport=TCP;x-sipX-nonat> <sip:[email protected]:1889;transport=TCP;x-sipX-nonat>\r To: <mailto:sip:[email protected]> <sip:[email protected]>\r From: \"200\" <mailto:sip:[email protected]> <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=\"0b61a318caca69024f6803b99f cd402a506bdff0\",uri=\ <mailto:sip:[email protected];transport=tcp%5C> "sip:[email protected];transport=tcp\",response=\"7717633a520ccd47215721a17f2 76e8e\",cnonce=\"aad9569089334a96274f1a7839d054d7\",nc=00000001,qop=auth,alg orithm=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:OUTGOING :INFO:sipx2.callidus.local:SipUserAgent-0:7f03249c1700:SipXProxy:"SipUserAge nt::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\" <mailto:sip:[email protected]> <sip:[email protected]>;tag=cd09f73c\r To: <mailto:sip:[email protected]> <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~UgrmM4eHLTVEMlRgE` 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 <mailto:[email protected]> <[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/
