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: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: <sip:201@192.168.0.66:55243;rinstance=4782eca9743a1724;transport=TCP;x-sipX-nonat> <mailto:sip:201@192.168.0.66:55243;rinstance=4782eca9743a1724;transport=TCP;x-sipX-nonat>\r
To: \"201\"<sip:201@192.168.0.46> <mailto:sip:201@192.168.0.46>\r
From: \"201\"<sip:201@192.168.0.46> <mailto: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 <mailto: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:OUTGOING: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 <mailto: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~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: <sip:200@192.168.0.55:1889;transport=TCP;x-sipX-nonat> <mailto:sip:200@192.168.0.55:1889;transport=TCP;x-sipX-nonat>\r
To: <sip:201@192.168.0.47> <mailto:sip:201@192.168.0.47>\r
From: \"200\"<sip:200@192.168.0.47> <mailto: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=\"0b61a318caca69024f6803b99fcd402a506bdff0\",uri=\"sip:201@192.168.0.47;transport=tcp\" <mailto:sip:201@192.168.0.47;transport=tcp%5C>,response=\"7717633a520ccd47215721a17f276e8e\",cnonce=\"aad9569089334a96274f1a7839d054d7\",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:OUTGOING: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> <mailto:sip:200@192.168.0.47>;tag=cd09f73c\r
To: <sip:201@192.168.0.47> <mailto: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~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:sipx-users-boun...@list.sipfoundry.org  
<mailto: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>  
<mailto: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  <mailto:sipx-users@list.sipfoundry.org>

    List Archive:http://list.sipfoundry.org/archive/sipx-users/

    _______________________________________________

    sipx-users mailing list

    sipx-users@list.sipfoundry.org  <mailto: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/

Reply via email to