Discussion:
4.6 Cluster
darthzejdr
2012-09-27 14:07:35 UTC
Permalink
I'm trying to get clustering to work, but i have some problems. Some calls
work, while others don't. I think that the ones that work are people
registered on main server. I thinkDoes anyone have any idea what might the
problem be, and how to fix it? I have sip registrar and dns working on both
servers, and they can ping eachther by name.



I also tried disabling the firewall, and i get accept all, but on secondary
server it's still running. Tried send profiles, rebooting server, and
restarting iptables. Didn't help.



>From what i managed to pull out, i'm loosing registrations on secondary
server, and the server is not forwarding invites to server 1.
Gerald Drouillard
2012-09-27 14:24:59 UTC
Permalink
On 9/27/2012 10:07 AM, darthzejdr wrote:
>
> I'm trying to get clustering to work, but i have some problems. Some
> calls work, while others don't. I think that the ones that work are
> people registered on main server. I thinkDoes anyone have any idea
> what might the problem be, and how to fix it? I have sip registrar and
> dns working on both servers, and they can ping eachther by name.
>
> I also tried disabling the firewall, and i get accept all, but on
> secondary server it's still running. Tried send profiles, rebooting
> server, and restarting iptables. Didn't help.
>
> From what i managed to pull out, i'm loosing registrations on
> secondary server, and the server is not forwarding invites to server 1.
>
>
Without a log or a packet capture we can only guess. My guess is that
there are a few bugs in the registration in 4.4 and 4.6 at the moment
that they are working on.

--
Regards
--------------------------------------
Gerald Drouillard
Technology Architect
Drouillard & Associates, Inc.
http://www.Drouillard.biz
George Niculae
2012-09-27 14:36:07 UTC
Permalink
On Thu, Sep 27, 2012 at 5:24 PM, Gerald Drouillard
<***@drouillard.ca> wrote:
> On 9/27/2012 10:07 AM, darthzejdr wrote:
>
> I'm trying to get clustering to work, but i have some problems. Some calls
> work, while others don't. I think that the ones that work are people
> registered on main server. I thinkDoes anyone have any idea what might the
> problem be, and how to fix it? I have sip registrar and dns working on both
> servers, and they can ping eachther by name.
>
>
>
> I also tried disabling the firewall, and i get accept all, but on secondary
> server it's still running. Tried send profiles, rebooting server, and
> restarting iptables. Didn't help.
>
>
>
> From what i managed to pull out, i'm loosing registrations on secondary
> server, and the server is not forwarding invites to server 1.
>
>
>
>
> Without a log or a packet capture we can only guess. My guess is that there
> are a few bugs in the registration in 4.4 and 4.6 at the moment that they
> are working on.

Right, please provide snapshot. Also, could you do a

service sipxsupervisor restart

on secondary and see if iptables rules applied after?

George
darthzejdr
2012-09-28 08:01:52 UTC
Permalink
https://www.dropbox.com/s/hf9trlr06dhjrbh/configuration.tar.gz
https://www.dropbox.com/s/beachijue7gaxkf/homer.tar.gz

is this what you mean? I don't understand sip logs(homer), and i started the
service yesterday, so not really sure what's in there. If you want me to
test something specific just say and i'll do it and upload new logs. service
sipxsupervisor restart didn't help with ipconfig on second server.


-----Original Message-----
From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of George Niculae
Sent: Thursday, September 27, 2012 4:36 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] 4.6 Cluster

On Thu, Sep 27, 2012 at 5:24 PM, Gerald Drouillard <***@drouillard.ca>
wrote:
> On 9/27/2012 10:07 AM, darthzejdr wrote:
>
> I'm trying to get clustering to work, but i have some problems. Some
> calls work, while others don't. I think that the ones that work are
> people registered on main server. I thinkDoes anyone have any idea
> what might the problem be, and how to fix it? I have sip registrar and
> dns working on both servers, and they can ping eachther by name.
>
>
>
> I also tried disabling the firewall, and i get accept all, but on
> secondary server it's still running. Tried send profiles, rebooting
> server, and restarting iptables. Didn't help.
>
>
>
> From what i managed to pull out, i'm loosing registrations on
> secondary server, and the server is not forwarding invites to server 1.
>
>
>
>
> Without a log or a packet capture we can only guess. My guess is that
> there are a few bugs in the registration in 4.4 and 4.6 at the moment
> that they are working on.

Right, please provide snapshot. Also, could you do a

service sipxsupervisor restart

on secondary and see if iptables rules applied after?

George
George Niculae
2012-09-28 08:04:36 UTC
Permalink
On Fri, Sep 28, 2012 at 11:01 AM, darthzejdr <***@gmail.com> wrote:
> https://www.dropbox.com/s/hf9trlr06dhjrbh/configuration.tar.gz
> https://www.dropbox.com/s/beachijue7gaxkf/homer.tar.gz
>
> is this what you mean? I don't understand sip logs(homer), and i started the
> service yesterday, so not really sure what's in there. If you want me to
> test something specific just say and i'll do it and upload new logs. service
> sipxsupervisor restart didn't help with ipconfig on second server.
>

Go to Diagnostics > Snapshot and click apply, it will generate an
tar.gz containing relevant logs (do this after you recreate the
problem)

George
darthzejdr
2012-09-28 10:19:18 UTC
Permalink
1st call 201->202 works, both on main server

2nd call 201->200 works, both on main server

Reregistered extensions 200 and 202

3rd call 201->202 doesn't work, 202 on secondary server

4th call 202->201 doesn't work 202 on secondary server

5th call 201->202 works, both on secondary server



Snapshot and homer:

https://www.dropbox.com/s/e5xax7o857xagfj/sipx-snapshot-sipx1.callidus.local
.tar.gz

https://www.dropbox.com/s/mnrk4apapz72mux/sipx-snapshot-sipx2.callidus.local
.tar.gz

https://www.dropbox.com/s/beachijue7gaxkf/homer.tar.gz







-----Original Message-----

From: sipx-users-***@list.sipfoundry.org

[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of George Niculae

Sent: Friday, September 28, 2012 10:05 AM

To: Discussion list for users of sipXecs software

Subject: Re: [sipx-users] 4.6 Cluster



On Fri, Sep 28, 2012 at 11:01 AM, darthzejdr <***@gmail.com> wrote:

> https://www.dropbox.com/s/hf9trlr06dhjrbh/configuration.tar.gz

> https://www.dropbox.com/s/beachijue7gaxkf/homer.tar.gz

>

> is this what you mean? I don't understand sip logs(homer), and i

> started the service yesterday, so not really sure what's in there. If

> you want me to test something specific just say and i'll do it and

> upload new logs. service sipxsupervisor restart didn't help with ipconfig

on second server.

>



Go to Diagnostics > Snapshot and click apply, it will generate an tar.gz

containing relevant logs (do this after you recreate the

problem)



George

_______________________________________________

sipx-users mailing list

sipx-***@list.sipfoundry.org

List Archive: http://list.sipfoundry.org/archive/sipx-users/
George Niculae
2012-09-28 10:52:29 UTC
Permalink
On Fri, Sep 28, 2012 at 1:19 PM, darthzejdr <***@gmail.com> wrote:
> 1st call 201->202 works, both on main server
>
> 2nd call 201->200 works, both on main server
>
> Reregistered extensions 200 and 202
>
> 3rd call 201->202 doesn't work, 202 on secondary server
>
> 4th call 202->201 doesn't work 202 on secondary server
>
> 5th call 201->202 works, both on secondary server
>

Can you make sure you're not registering TLS and do another test?
Looks like something wrong with DNS & TLS

"2012-09-28T09:56:13.958386Z":2138:SIP:ERR:sipx2.callidus.local:SipRouter-12:7fce6c34b700:SipXProxy:"SipTransaction::recurseDnsSrvChildren
TLS is not set for host "
"2012-09-28T09:57:35.812516Z":2139:SIP:ERR:sipx2.callidus.local:SipRouter-12:7fce6c34b700:SipXProxy:"SipTransaction::recurseDnsSrvChildren
TLS is not set for host "

George
darthzejdr
2012-09-28 11:31:29 UTC
Permalink
I checked and we didn't use tls. We used bria set on automatic(wireshark
says its on tcp) for this 5 calls. Calls before that were done using tls.

-----Original Message-----
From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of George Niculae
Sent: Friday, September 28, 2012 12:52 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] 4.6 Cluster

On Fri, Sep 28, 2012 at 1:19 PM, darthzejdr <***@gmail.com> wrote:
> 1st call 201->202 works, both on main server
>
> 2nd call 201->200 works, both on main server
>
> Reregistered extensions 200 and 202
>
> 3rd call 201->202 doesn't work, 202 on secondary server
>
> 4th call 202->201 doesn't work 202 on secondary server
>
> 5th call 201->202 works, both on secondary server
>

Can you make sure you're not registering TLS and do another test?
Looks like something wrong with DNS & TLS

"2012-09-28T09:56:13.958386Z":2138:SIP:ERR:sipx2.callidus.local:SipRouter-12
:7fce6c34b700:SipXProxy:"SipTransaction::recurseDnsSrvChildren
TLS is not set for host "
"2012-09-28T09:57:35.812516Z":2139:SIP:ERR:sipx2.callidus.local:SipRouter-12
:7fce6c34b700:SipXProxy:"SipTransaction::recurseDnsSrvChildren
TLS is not set for host "

George
George Niculae
2012-09-28 11:40:58 UTC
Permalink
On Fri, Sep 28, 2012 at 2:31 PM, darthzejdr <***@gmail.com> wrote:
> I checked and we didn't use tls. We used bria set on automatic(wireshark
> says its on tcp) for this 5 calls. Calls before that were done using tls.
>

Can you post also the zone file from both machines?

George
Michael Picher
2012-09-28 11:57:01 UTC
Permalink
set bria to tcp or udp specifically...

On Fri, Sep 28, 2012 at 7:40 AM, George Niculae <***@ezuce.com> wrote:

> On Fri, Sep 28, 2012 at 2:31 PM, darthzejdr <***@gmail.com> wrote:
> > I checked and we didn't use tls. We used bria set on automatic(wireshark
> > says its on tcp) for this 5 calls. Calls before that were done using tls.
> >
>
> Can you post also the zone file from both machines?
>
> George
> _______________________________________________
> sipx-users mailing list
> sipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>



--
Michael Picher, Director of Technical Services
eZuce, Inc.

300 Brickstone Square****

Suite 201****

Andover, MA. 01810
O.978-296-1005 X2015
M.207-956-0262
@mpicher <http://twitter.com/mpicher>
linkedin <http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro>
www.ezuce.com

------------------------------------------------------------------------------------------------------------
There are 10 kinds of people in the world, those who understand binary and
those who don't.
George Niculae
2012-09-28 11:57:43 UTC
Permalink
On Fri, Sep 28, 2012 at 2:40 PM, George Niculae <***@ezuce.com> wrote:
> On Fri, Sep 28, 2012 at 2:31 PM, darthzejdr <***@gmail.com> wrote:
>> I checked and we didn't use tls. We used bria set on automatic(wireshark
>> says its on tcp) for this 5 calls. Calls before that were done using tls.
>>
>
> Can you post also the zone file from both machines?
>

Hm, it doesn't look like you're running DNS on second node

INSERT INTO feature_local (feature_id, location_id) VALUES ('apache', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('ftp', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('tftp', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('sipxdns', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('mongo', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('sipxdns', 2);
INSERT INTO feature_local (feature_id, location_id) VALUES ('redis', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('homer_web', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('registrar', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('proxy', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('sipxsqa', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('homer_capture', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('mysql', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('redis', 2);
INSERT INTO feature_local (feature_id, location_id) VALUES ('registrar', 2);
INSERT INTO feature_local (feature_id, location_id) VALUES ('proxy', 2);
darthzejdr
2012-09-28 12:02:00 UTC
Permalink
Zone files attached, they are both the same. I have selected dns on both
servers.

Will create new logs using tcp and post once it's tested

-----Original Message-----
From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of George Niculae
Sent: Friday, September 28, 2012 1:58 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] 4.6 Cluster

On Fri, Sep 28, 2012 at 2:40 PM, George Niculae <***@ezuce.com> wrote:
> On Fri, Sep 28, 2012 at 2:31 PM, darthzejdr <***@gmail.com> wrote:
>> I checked and we didn't use tls. We used bria set on
>> automatic(wireshark says its on tcp) for this 5 calls. Calls before that
were done using tls.
>>
>
> Can you post also the zone file from both machines?
>

Hm, it doesn't look like you're running DNS on second node

INSERT INTO feature_local (feature_id, location_id) VALUES ('apache', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('ftp', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('tftp', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('sipxdns', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('mongo', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('sipxdns', 2);
INSERT INTO feature_local (feature_id, location_id) VALUES ('redis', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('homer_web', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('registrar', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('proxy', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('sipxsqa', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('homer_capture',
1); INSERT INTO feature_local (feature_id, location_id) VALUES ('mysql', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('redis', 2);
INSERT INTO feature_local (feature_id, location_id) VALUES ('registrar', 2);
INSERT INTO feature_local (feature_id, location_id) VALUES ('proxy', 2);
darthzejdr
2012-09-28 12:14:14 UTC
Permalink
Using bria set to tcp:
201 -> 200 doesn't work, different servers (201 - secondary server, 200 -
primary server)
201 -> 202 works (both secondary server)

https://www.dropbox.com/s/n1qtbkkawl7arip/homer.tar.gz
https://www.dropbox.com/s/eonvleyi3is6nkf/sipx-snapshot-sipx1.callidus.local
.tar.gz
https://www.dropbox.com/s/hrgxivsz033m4tz/sipx-snapshot-sipx2.callidus.local
.tar.gz


-----Original Message-----
From: darthzejdr [mailto:***@gmail.com]
Sent: Friday, September 28, 2012 2:02 PM
To: 'Discussion list for users of sipXecs software'
Subject: RE: [sipx-users] 4.6 Cluster

Zone files attached, they are both the same. I have selected dns on both
servers.

Will create new logs using tcp and post once it's tested

-----Original Message-----
From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of George Niculae
Sent: Friday, September 28, 2012 1:58 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] 4.6 Cluster

On Fri, Sep 28, 2012 at 2:40 PM, George Niculae <***@ezuce.com> wrote:
> On Fri, Sep 28, 2012 at 2:31 PM, darthzejdr <***@gmail.com> wrote:
>> I checked and we didn't use tls. We used bria set on
>> automatic(wireshark says its on tcp) for this 5 calls. Calls before
>> that
were done using tls.
>>
>
> Can you post also the zone file from both machines?
>

Hm, it doesn't look like you're running DNS on second node

INSERT INTO feature_local (feature_id, location_id) VALUES ('apache', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('ftp', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('tftp', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('sipxdns', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('mongo', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('sipxdns', 2);
INSERT INTO feature_local (feature_id, location_id) VALUES ('redis', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('homer_web', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('registrar', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('proxy', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('sipxsqa', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('homer_capture',
1); INSERT INTO feature_local (feature_id, location_id) VALUES ('mysql', 1);
INSERT INTO feature_local (feature_id, location_id) VALUES ('redis', 2);
INSERT INTO feature_local (feature_id, location_id) VALUES ('registrar', 2);
INSERT INTO feature_local (feature_id, location_id) VALUES ('proxy', 2);
George Niculae
2012-09-28 12:36:15 UTC
Permalink
On Fri, Sep 28, 2012 at 3:14 PM, darthzejdr <***@gmail.com> wrote:
> Using bria set to tcp:
> 201 -> 200 doesn't work, different servers (201 - secondary server, 200 -
> primary server)
> 201 -> 202 works (both secondary server)
>
> https://www.dropbox.com/s/n1qtbkkawl7arip/homer.tar.gz
> https://www.dropbox.com/s/eonvleyi3is6nkf/sipx-snapshot-sipx1.callidus.local
> .tar.gz
> https://www.dropbox.com/s/hrgxivsz033m4tz/sipx-snapshot-sipx2.callidus.local
> .tar.gz
>

Put secondary IP address and fqdn as domain alias (System > Domain)
and try again the scenario

George
darthzejdr
2012-09-28 13:35:07 UTC
Permalink
Didnt help. Everything the same. If i try to call extension on second server
i get The user is temporarily unavailable (404 )

-----Original Message-----
From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of George Niculae
Sent: Friday, September 28, 2012 2:36 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] 4.6 Cluster

On Fri, Sep 28, 2012 at 3:14 PM, darthzejdr <***@gmail.com> wrote:
> Using bria set to tcp:
> 201 -> 200 doesn't work, different servers (201 - secondary server,
> 200 - primary server)
> 201 -> 202 works (both secondary server)
>
> https://www.dropbox.com/s/n1qtbkkawl7arip/homer.tar.gz
> https://www.dropbox.com/s/eonvleyi3is6nkf/sipx-snapshot-sipx1.callidus
> .local
> .tar.gz
> https://www.dropbox.com/s/hrgxivsz033m4tz/sipx-snapshot-sipx2.callidus
> .local
> .tar.gz
>

Put secondary IP address and fqdn as domain alias (System > Domain) and try
again the scenario

George
George Niculae
2012-09-28 15:46:41 UTC
Permalink
On Fri, Sep 28, 2012 at 4:35 PM, darthzejdr <***@gmail.com> wrote:
> Didnt help. Everything the same. If i try to call extension on second server
> i get The user is temporarily unavailable (404 )
>

That's what I did, let me know if testing scenario different:
- setup cluster with 2 nodes, both running DNS, Proxy and Registrar
- configured secondary IP and fqdn as domain aliases, then sent
profiles to servers
- registered account 200 Bria on first node (giving 1st node IP as domain)
- registered account 201, another phone on 2nd node (giving 2nd node
IP as domain)
- calls 200 to 200 established just fine

George
darthzejdr
2012-10-02 08:49:01 UTC
Permalink
I reinstalled my sipx according to your setup.

201 is registered on primary server(with ip address in domain, 92.168.0.46)

200 is registered on secondary server(with ip address in domain,
192.168.0.47)



201 to 200 works normaly

200 to 201 gives error "user is temporarily unavailable(404)"

200 to ***@192.168.0.46(primary server ip address) works



https://www.dropbox.com/s/cn9vqmt25zurm2z/sipx-snapshot-sipx1.callidus.local
.tar.gz

https://www.dropbox.com/s/loqjb4v0x74kktm/sipx-snapshot-sipx2.callidus.local
.tar.gz



-----Original Message-----

From: sipx-users-***@list.sipfoundry.org

[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of George Niculae

Sent: Friday, September 28, 2012 5:47 PM

To: Discussion list for users of sipXecs software

Subject: Re: [sipx-users] 4.6 Cluster



On Fri, Sep 28, 2012 at 4:35 PM, darthzejdr <***@gmail.com> wrote:

> Didnt help. Everything the same. If i try to call extension on second

> server i get The user is temporarily unavailable (404 )

>



That's what I did, let me know if testing scenario different:

- setup cluster with 2 nodes, both running DNS, Proxy and Registrar

- configured secondary IP and fqdn as domain aliases, then sent profiles to

servers

- registered account 200 Bria on first node (giving 1st node IP as domain)

- registered account 201, another phone on 2nd node (giving 2nd node IP as

domain)

- calls 200 to 200 established just fine



George

_______________________________________________

sipx-users mailing list

sipx-***@list.sipfoundry.org

List Archive: http://list.sipfoundry.org/archive/sipx-users/
darthzejdr
2012-10-02 11:08:18 UTC
Permalink
I've done a few more tests(extensions registered with normal
domain(callidus.local) but using proxy field with ip adress) but again the
same problem. II can make calls from primary server to sacondary, but the
only way to make a call from secondary server is to use ***@192.168.0.46 as
the number i am calling. For some reason secondary server can't reach
extensions on primary.



From: darthzejdr [mailto:***@gmail.com]
Sent: Tuesday, October 02, 2012 10:49 AM
To: 'Discussion list for users of sipXecs software'
Subject: RE: [sipx-users] 4.6 Cluster



I reinstalled my sipx according to your setup.

201 is registered on primary server(with ip address in domain, 92.168.0.46)

200 is registered on secondary server(with ip address in domain,
192.168.0.47)



201 to 200 works normaly

200 to 201 gives error "user is temporarily unavailable(404)"

200 to ***@192.168.0.46(primary server ip address) works



https://www.dropbox.com/s/cn9vqmt25zurm2z/sipx-snapshot-sipx1.callidus.local
.tar.gz

https://www.dropbox.com/s/loqjb4v0x74kktm/sipx-snapshot-sipx2.callidus.local
.tar.gz



-----Original Message-----

From: sipx-users-***@list.sipfoundry.org

[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of George Niculae

Sent: Friday, September 28, 2012 5:47 PM

To: Discussion list for users of sipXecs software

Subject: Re: [sipx-users] 4.6 Cluster



On Fri, Sep 28, 2012 at 4:35 PM, darthzejdr <***@gmail.com> wrote:

> Didnt help. Everything the same. If i try to call extension on second

> server i get The user is temporarily unavailable (404 )

>



That's what I did, let me know if testing scenario different:

- setup cluster with 2 nodes, both running DNS, Proxy and Registrar

- configured secondary IP and fqdn as domain aliases, then sent profiles to

servers

- registered account 200 Bria on first node (giving 1st node IP as domain)

- registered account 201, another phone on 2nd node (giving 2nd node IP as

domain)

- calls 200 to 200 established just fine



George

_______________________________________________

sipx-users mailing list

sipx-***@list.sipfoundry.org

List Archive: http://list.sipfoundry.org/archive/sipx-users/
Joegen Baclor
2012-10-02 11:22:13 UTC
Permalink
Please send snapshots with both proxy and registrar in debug level.

On 10/02/2012 07:08 PM, darthzejdr wrote:
>
> I've done a few more tests(extensions registered with normal
> domain(callidus.local) but using proxy field with ip adress) but again
> the same problem. II can make calls from primary server to sacondary,
> but the only way to make a call from secondary server is to use
> ***@192.168.0.46 <mailto:***@192.168.0.46> as the number i am calling.
> For some reason secondary server can't reach extensions on primary.
>
> *From:*darthzejdr [mailto:***@gmail.com]
> *Sent:* Tuesday, October 02, 2012 10:49 AM
> *To:* 'Discussion list for users of sipXecs software'
> *Subject:* RE: [sipx-users] 4.6 Cluster
>
> I reinstalled my sipx according to your setup.
>
> 201 is registered on primary server(with ip address in domain,
> 92.168.0.46)
>
> 200 is registered on secondary server(with ip address in domain,
> 192.168.0.47)
>
> 201 to 200 works normaly
>
> 200 to 201 gives error "user is temporarily unavailable(404)"
>
> 200 to ***@192.168.0.46(primary <mailto:***@192.168.0.46%28primary>
> server ip address) works
>
> https://www.dropbox.com/s/cn9vqmt25zurm2z/sipx-snapshot-sipx1.callidus.local.tar.gz
>
> https://www.dropbox.com/s/loqjb4v0x74kktm/sipx-snapshot-sipx2.callidus.local.tar.gz
>
> -----Original Message-----
>
> From: sipx-users-***@list.sipfoundry.org
> <mailto:sipx-users-***@list.sipfoundry.org>
>
> [mailto:sipx-users-***@list.sipfoundry.org]
> <mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of
> George Niculae
>
> Sent: Friday, September 28, 2012 5:47 PM
>
> To: Discussion list for users of sipXecs software
>
> Subject: Re: [sipx-users] 4.6 Cluster
>
> On Fri, Sep 28, 2012 at 4:35 PM, darthzejdr <***@gmail.com
> <mailto:***@gmail.com>> wrote:
>
> > Didnt help. Everything the same. If i try to call extension on second
>
> > server i get The user is temporarily unavailable (404 )
>
> >
>
> That's what I did, let me know if testing scenario different:
>
> - setup cluster with 2 nodes, both running DNS, Proxy and Registrar
>
> - configured secondary IP and fqdn as domain aliases, then sent
> profiles to
>
> servers
>
> - registered account 200 Bria on first node (giving 1st node IP as domain)
>
> - registered account 201, another phone on 2nd node (giving 2nd node IP as
>
> domain)
>
> - calls 200 to 200 established just fine
>
> George
>
> _______________________________________________
>
> sipx-users mailing list
>
> sipx-***@list.sipfoundry.org <mailto:sipx-***@list.sipfoundry.org>
>
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
>
>
> _______________________________________________
> sipx-users mailing list
> sipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
darthzejdr
2012-10-02 11:56:37 UTC
Permalink
https://www.dropbox.com/s/iwiatrnvkf7fh9a/sipx-snapshot-sipx1.callidus.local
.tar.gz

https://www.dropbox.com/s/xwjq7q2px45b4sn/sipx-snapshot-sipx2.callidus.local
.tar.gz



calls are:

201 -> 200 works

200 -> 201 doesn't work

200 -> ***@192.168.0.46 works



From: Joegen Baclor [mailto:***@ezuce.com]
Sent: Tuesday, October 02, 2012 1:22 PM
To: Discussion list for users of sipXecs software
Cc: darthzejdr
Subject: Re: [sipx-users] 4.6 Cluster



Please send snapshots with both proxy and registrar in debug level.

On 10/02/2012 07:08 PM, darthzejdr wrote:

I've done a few more tests(extensions registered with normal
domain(callidus.local) but using proxy field with ip adress) but again the
same problem. II can make calls from primary server to sacondary, but the
only way to make a call from secondary server is to use ***@192.168.0.46 as
the number i am calling. For some reason secondary server can't reach
extensions on primary.



From: darthzejdr [mailto:***@gmail.com]
Sent: Tuesday, October 02, 2012 10:49 AM
To: 'Discussion list for users of sipXecs software'
Subject: RE: [sipx-users] 4.6 Cluster



I reinstalled my sipx according to your setup.

201 is registered on primary server(with ip address in domain, 92.168.0.46)

200 is registered on secondary server(with ip address in domain,
192.168.0.47)



201 to 200 works normaly

200 to 201 gives error "user is temporarily unavailable(404)"

200 to ***@192.168.0.46(primary <mailto:***@192.168.0.46%28primary> server
ip address) works



https://www.dropbox.com/s/cn9vqmt25zurm2z/sipx-snapshot-sipx1.callidus.local
.tar.gz

https://www.dropbox.com/s/loqjb4v0x74kktm/sipx-snapshot-sipx2.callidus.local
.tar.gz



-----Original Message-----

From: sipx-users-***@list.sipfoundry.org

[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of George Niculae

Sent: Friday, September 28, 2012 5:47 PM

To: Discussion list for users of sipXecs software

Subject: Re: [sipx-users] 4.6 Cluster



On Fri, Sep 28, 2012 at 4:35 PM, darthzejdr <***@gmail.com> wrote:

> Didnt help. Everything the same. If i try to call extension on second

> server i get The user is temporarily unavailable (404 )

>



That's what I did, let me know if testing scenario different:

- setup cluster with 2 nodes, both running DNS, Proxy and Registrar

- configured secondary IP and fqdn as domain aliases, then sent profiles to

servers

- registered account 200 Bria on first node (giving 1st node IP as domain)

- registered account 201, another phone on 2nd node (giving 2nd node IP as

domain)

- calls 200 to 200 established just fine



George

_______________________________________________

sipx-users mailing list

sipx-***@list.sipfoundry.org

List Archive: http://list.sipfoundry.org/archive/sipx-users/
George Niculae
2012-10-02 11:59:47 UTC
Permalink
On Tue, Oct 2, 2012 at 2:56 PM, darthzejdr <***@gmail.com> wrote:
> https://www.dropbox.com/s/iwiatrnvkf7fh9a/sipx-snapshot-sipx1.callidus.local.tar.gz
>
> https://www.dropbox.com/s/xwjq7q2px45b4sn/sipx-snapshot-sipx2.callidus.local.tar.gz
>
>
>
> calls are:
>
> 201 -> 200 works
>
> 200 -> 201 doesn't work
>
> 200 -> ***@192.168.0.46 works
>

Until Joegen checks snapshot, can you try change from Use stun to Use
Public Ip in System > NAT Traversal and try again the scenario?

George
darthzejdr
2012-10-02 12:09:30 UTC
Permalink
I'm not behind nat, i am in the same subnet as my servers. Also what should
i put in public ip address? Each servers own address, primary server
address, or something else?

-----Original Message-----
From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of George Niculae
Sent: Tuesday, October 02, 2012 2:00 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] 4.6 Cluster

On Tue, Oct 2, 2012 at 2:56 PM, darthzejdr <***@gmail.com> wrote:
> https://www.dropbox.com/s/iwiatrnvkf7fh9a/sipx-snapshot-sipx1.callidus
> .local.tar.gz
>
> https://www.dropbox.com/s/xwjq7q2px45b4sn/sipx-snapshot-sipx2.callidus
> .local.tar.gz
>
>
>
> calls are:
>
> 201 -> 200 works
>
> 200 -> 201 doesn't work
>
> 200 -> ***@192.168.0.46 works
>

Until Joegen checks snapshot, can you try change from Use stun to Use Public
Ip in System > NAT Traversal and try again the scenario?

George
George Niculae
2012-10-02 12:10:32 UTC
Permalink
On Tue, Oct 2, 2012 at 3:09 PM, darthzejdr <***@gmail.com> wrote:
> I'm not behind nat, i am in the same subnet as my servers. Also what should
> i put in public ip address? Each servers own address, primary server
> address, or something else?
>

You should put each server own address.

George
darthzejdr
2012-10-02 12:16:50 UTC
Permalink
Changed to ip address, everything is still the same

-----Original Message-----
From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of George Niculae
Sent: Tuesday, October 02, 2012 2:11 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] 4.6 Cluster

On Tue, Oct 2, 2012 at 3:09 PM, darthzejdr <***@gmail.com> wrote:
> I'm not behind nat, i am in the same subnet as my servers. Also what
> should i put in public ip address? Each servers own address, primary
> server address, or something else?
>

You should put each server own address.

George
George Niculae
2012-10-02 12:41:32 UTC
Permalink
On Tue, Oct 2, 2012 at 3:16 PM, darthzejdr <***@gmail.com> wrote:
> Changed to ip address, everything is still the same
>

IMO it really looks like the domain alias issue we seen in latest 4.4
build, will need Joegen's call to be sure

2012-10-02T11:51:25.797451Z":11702:SIP:DEBUG:sipx2.callidus.local:SipClientUdp-10:7fb0afa0b700:SipXProxy:"SipTransaction::handleChildIncoming
0x7fb0a801af80 relationship PROVISIONAL parent (nil)"
"2012-10-02T11:51:25.797655Z":11703:ODBC:DEBUG:sipx2.callidus.local:SipRouter-12:7fb0ad9c0700:SipXProxy:"***@192.168.0.47
is NOT present in namespace imdb.entity"
"2012-10-02T11:51:25.797678Z":11704:ODBC:INFO:sipx2.callidus.local:SipRouter-12:7fb0ad9c0700:SipXProxy:"EntityDB::findByIdentity
- Unable to find entity record for ***@192.168.0.47 from namespace
imdb.entity"
"2012-10-02T11:51:25.797702Z":11705:ODBC:INFO:sipx2.callidus.local:SipRouter-12:7fb0ad9c0700:SipXProxy:"EntityDB::findByIdentity
- Finding entity record for callidus.local from namespace imdb.entity"
"2012-10-02T11:51:25.797808Z":11706:SIP:DEBUG:sipx2.callidus.local:SipClientUdp-10:7fb0afa0b700:SipXProxy:"SipUserAgent::dispatch
resentWithAuth 0"
"2012-10-02T11:51:25.798772Z":11707:ODBC:DEBUG:sipx2.callidus.local:SipRouter-12:7fb0ad9c0700:SipXProxy:"callidus.local
is NOT present in namespace imdb.entity"
"2012-10-02T11:51:25.798799Z":11708:ODBC:INFO:sipx2.callidus.local:SipRouter-12:7fb0ad9c0700:SipXProxy:"EntityDB::findByIdentity
- Unable to find entity record for callidus.local from namespace
imdb.entity"
"2012-10-02T11:51:25.798823Z":11709:SIP:WARNING:sipx2.callidus.local:SipRouter-12:7fb0ad9c0700:SipXProxy:"CallerAlias::getCallerAlias
- No caller alias configured for identity=***@192.168.0.47

George
Joegen Baclor
2012-10-03 03:49:17 UTC
Permalink
George, the log below is for determining caller-id and has nothing to do
with user or domain alias. For the meantime, can you make something out
of this log. Registrar is unable to route to the user mailbox.

"2012-10-02T11:51:25.801279Z":1352:SIP:DEBUG:sipx2.callidus.local:SipClientTcp-31:7f01aaded700:SipRegistrar:"SipTransaction::handleChildIncoming
0x7f01b000e4d0 relationship REQUEST parent (nil)"
"2012-10-02T11:51:25.801426Z":1353:SIP:DEBUG:sipx2.callidus.local:SipClientTcp-32:7f01aacec700:SipRegistrar:"SipClient[SipClientTcp-32]::run
resPoll= 1 revents: fd[0]= 1 fd[1]= 0"
"2012-10-02T11:51:25.801446Z":1354:SIP:DEBUG:sipx2.callidus.local:SipClientTcp-32:7f01aacec700:SipRegistrar:"SipClient[SipClientTcp-32]::run
got pipe-select Number of Messages waiting: 1"
"2012-10-02T11:51:25.801462Z":1355:SIP:DEBUG:sipx2.callidus.local:SipClientTcp-32:7f01aacec700:SipRegistrar:"SipClient[SipClientTcp-32]::run
got pipe-select mbTcpOnErrWaitForSend-0 waitingToReportErr-0
mbTcpOnErrWaitForSend-0 repeatedEOFs-0"
"2012-10-02T11:51:25.801543Z":1356:SIP:DEBUG:sipx2.callidus.local:SipRegistrar:7f01caa74700:SipRegistrar:"SipRegistrar::handleMessage()
Start processing SIP message"
"2012-10-02T11:51:25.801925Z":1357:SIP:DEBUG:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"SipRedirectServer::processRedirect
Starting to process request URI 'sip:~~vm~***@callidus.local'"
"2012-10-02T11:51:25.801948Z":1358:SIP:DEBUG:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"[090-USERPARAM]
SipRedirectorUserParam::lookUp disabled by configuration"
"2012-10-02T11:51:25.801978Z":1359:SIP:DEBUG:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"[110-ALIAS]
SipRedirectorAliasDB::lookUp identity: ~~vm~***@callidus.local domain:
callidus.local local-domain: callidus.local isHostAlias: 0"
"2012-10-02T11:51:25.803212Z":1360:ODBC:INFO:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"EntityDB::findByAliasUserId
- Finding entity record for alias ~~vm~201 from namespace imdb.entity"
"2012-10-02T11:51:25.803459Z":1361:ODBC:INFO:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"EntityDB::findByAliasUserId
- Unable to find entity record for alias ~~vm~201 from namespace
imdb.entity"
"2012-10-02T11:51:25.804692Z":1362:SIP:DEBUG:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"[120-REG]
SipRedirectorRegDB::lookUp got 0 unexpired contacts"
"2012-10-02T11:51:25.804732Z":1363:ODBC:INFO:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"EntityDB::findByIdentity
- Finding entity record for ~~vm~***@callidus.local from namespace
imdb.entity"
"2012-10-02T11:51:25.805953Z":1364:ODBC:DEBUG:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"~~vm~***@callidus.local
is NOT present in namespace imdb.entity"
"2012-10-02T11:51:25.805975Z":1365:ODBC:INFO:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"EntityDB::findByIdentity
- Unable to find entity record for ~~vm~***@callidus.local from
namespace imdb.entity"
"2012-10-02T11:51:25.806084Z":1366:SIP:DEBUG:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"UrlMapping::doTransform
adding '<sip:~~vm~~~vm~***@callidus.local>;q=0.1'"
"2012-10-02T11:51:25.806114Z":1367:SIP:DEBUG:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"[130-MAPPING]
SipRedirectorMapping::lookUp got 1 UrlMapping Permission requirements
for 1 contacts"
"2012-10-02T11:51:25.806135Z":1368:ODBC:INFO:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"EntityDB::findByIdentity
- Finding entity record for ~~vm~***@callidus.local from namespace
imdb.entity"
"2012-10-02T11:51:25.807215Z":1369:ODBC:DEBUG:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"~~vm~***@callidus.local
is NOT present in namespace imdb.entity"
"2012-10-02T11:51:25.807242Z":1370:ODBC:INFO:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"EntityDB::findByIdentity
- Unable to find entity record for ~~vm~***@callidus.local from
namespace imdb.entity"
"2012-10-02T11:51:25.808309Z":1371:ODBC:INFO:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"EntityDB::findByAliasUserId
- Finding entity record for alias ~~vm~201 from namespace imdb.entity"
"2012-10-02T11:51:25.808335Z":1372:ODBC:INFO:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"EntityDB::findByAliasUserId
- Unable to find entity record for alias ~~vm~201 from namespace
imdb.entity"
"2012-10-02T11:51:25.808364Z":1373:SIP:DEBUG:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"[130-MAPPING]
SipRedirectorMapping::lookUp checking permissions DB for
urlMappingPermissions[0] = 'Voicemail'"
"2012-10-02T11:51:25.808404Z":1374:SIP:DEBUG:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"[130-MAPPING]
SipRedirectorMapping::lookUp 0 permissions configured for request URI
'sip:~~vm~***@callidus.local'. Checking: "
"2012-10-02T11:51:25.808430Z":1375:SIP:DEBUG:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"SipRedirectorFallback::
unbound entities allowing: FALSE"
"2012-10-02T11:51:25.808483Z":1376:SIP:DEBUG:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"SipXauthIdentity::decode
parse
'\"200\"<sip:***@callidus.local;signature=506AD53C%3A7d6e8fa3dc3cfcc6a62df203b12d9d35>'"
"2012-10-02T11:51:25.808540Z":1377:SIP:DEBUG:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"SipXauthIdentity::decode:
found P-Asserted-Identity '***@callidus.local' in request to
'sip:~~vm~***@callidus.local'"
"2012-10-02T11:51:25.808592Z":1378:SIP:DEBUG:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"[140-FALLBACK]
SipRedirectorFallback::lookUp got 0 UrlMapping Contacts for
sip:~~vm~***@callidus.local @ location ''"
"2012-10-02T11:51:25.808615Z":1379:ODBC:INFO:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"EntityDB::findByIdentity
- Finding entity record for ~~vm~***@callidus.local from namespace
imdb.entity"
"2012-10-02T11:51:25.809687Z":1380:ODBC:DEBUG:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"~~vm~***@callidus.local
is NOT present in namespace imdb.entity"
"2012-10-02T11:51:25.809714Z":1381:ODBC:INFO:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"EntityDB::findByIdentity
- Unable to find entity record for ~~vm~***@callidus.local from
namespace imdb.entity"
"2012-10-02T11:51:25.809741Z":1382:SIP:DEBUG:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"[997-SUBSCRIBE]
SipRedirectorSubscribe::lookUp uri 'sip:~~vm~***@callidus.local'"
"2012-10-02T11:51:25.809766Z":1383:SIP:DEBUG:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"[998-TIMEOFDAY]
SipRedirectorTimeOfDay::processContactList 0 contacts found"
"2012-10-02T11:51:25.809783Z":1384:SIP:DEBUG:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"[999-AUTHROUTER]
SipRedirectorAuthRouter::lookUp 'INVITE' request is neither an INVITE or
SUBSCRIBE or ContactList has no contacts (0) - ignored."
"2012-10-02T11:51:25.809802Z":1385:SIP:DEBUG:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"SipRedirectServer::processRedirect
No contacts added, sending 404 response"
"2012-10-02T11:51:25.809900Z":1386:SIP:DEBUG:sipx2.callidus.local:SipRedirectServer-10:7f01ab4f4700:SipRegistrar:"BranchId::equals(UtlString
'z9hG4bK-XX-0030tMqwaKbhff4odHjumUtstA')
'z9hG4bK-XX-0030tMqwaKbhff4odHjumUtstA'"



This is the content of indetity db




{ "_id" : "Group4", "uid" : "administrators", "dscr" : "Users with
superadmin privileges", "grprsc" : "user", "ent" : "group" }
{ "_id" : "User10", "ident" : "***@callidus.local", "uid" :
"superadmin", "cnt" : "sip:***@callidus.local", "lastUpdated" :
1349178254857, "gr" : [ "administrators" ], "vld" : true, "ent" :
"user", "moh" : "FILES_SRC", "bsyprmpt" : "true", "vcmltui" : "stdui",
"hshpstk" : "6a1f826e099d46d49a0c09192eb52460", "pntk" : "callidus_2",
"imenbld" : false, "imid" : "superadmin", "imdn" : "superadmin",
"cnfentry" : "1", "cnfexit" : "1", "lvmsgbeg" : "0", "lvmsgend" : "0",
"call" : "0", "callfrAny" : "0", "vmondnd" : false, "onphnmsg" : "On the
phone", "advcllsts" : true, "clldttls" : false, "defvmopt" : true, "pa"
: { "lng" : "en" }, "actvgr" : "standard", "rlm" : "callidus.local",
"pstk" : "hZyiVEnKkpJ1", "authtp" : "DIGEST", "als" : [], "prm" : [
"FreeswitchVoicemailServer", "InternationalDialing", "LocalDialing",
"LongDistanceDialing", "Mobile", "TollFree", "Voicemail",
"music-on-hold", "personal-auto-attendant", "subscribe-to-presence",
"superadmin" ], "cfwdtm" : 20 }
{ "_id" : "User11", "ident" : "***@callidus.local", "uid" : "200", "cnt"
: "sip:***@callidus.local", "lastUpdated" : 1349178255004, "gr" : [ ""
], "vld" : true, "ent" : "user", "moh" : "FILES_SRC", "bsyprmpt" :
"true", "vcmltui" : "stdui", "hshpstk" :
"80859c6eb77b573088770c69207f2cce", "pntk" : "password", "imenbld" :
false, "imid" : "200", "imdn" : "200", "cnfentry" : "1", "cnfexit" :
"1", "lvmsgbeg" : "0", "lvmsgend" : "0", "call" : "0", "callfrAny" :
"0", "vmondnd" : false, "onphnmsg" : "On the phone", "advcllsts" : true,
"clldttls" : false, "defvmopt" : true, "pa" : { "lng" : "en" }, "actvgr"
: "standard", "rlm" : "callidus.local", "pstk" : "password", "authtp" :
"DIGEST", "vpntk" : "731ecf0bf2df8034c756e49a255f7651", "als" : [],
"prm" : [ "FreeswitchVoicemailServer", "InternationalDialing",
"LocalDialing", "LongDistanceDialing", "Mobile", "TollFree",
"Voicemail", "music-on-hold", "personal-auto-attendant",
"subscribe-to-presence", "tui-change-pin" ], "cfwdtm" : 20 }
{ "_id" : "User12", "ident" : "***@callidus.local", "uid" : "201", "cnt"
: "sip:***@callidus.local", "lastUpdated" : 1349178255087, "gr" : [ ""
], "vld" : true, "ent" : "user", "moh" : "FILES_SRC", "bsyprmpt" :
"true", "vcmltui" : "stdui", "hshpstk" :
"910cb8a6ea2797c30bc0282278024720", "pntk" : "password", "imenbld" :
false, "imid" : "201", "imdn" : "201", "cnfentry" : "1", "cnfexit" :
"1", "lvmsgbeg" : "0", "lvmsgend" : "0", "call" : "0", "callfrAny" :
"0", "vmondnd" : false, "onphnmsg" : "On the phone", "advcllsts" : true,
"clldttls" : false, "defvmopt" : true, "pa" : { "lng" : "en" }, "actvgr"
: "standard", "rlm" : "callidus.local", "pstk" : "password", "authtp" :
"DIGEST", "vpntk" : "fa62938caba8d89e34814838e77c6655", "als" : [],
"prm" : [ "FreeswitchVoicemailServer", "InternationalDialing",
"LocalDialing", "LongDistanceDialing", "Mobile", "TollFree",
"Voicemail", "music-on-hold", "personal-auto-attendant",
"subscribe-to-presence", "tui-change-pin" ], "cfwdtm" : 20 }
{ "_id" : "extAls", "vld" : true, "ent" : "externalalias", "als" : [] }
{ "_id" : "~~id~acd", "ident" : "~~id~***@callidus.local", "uid" :
"~~id~acd", "ent" : "specialuser", "rlm" : "callidus.local", "pstk" :
"j7ahQcJoH9", "authtp" : "DIGEST", "prm" : [ "InternationalDialing",
"LocalDialing", "LongDistanceDialing", "Mobile", "TollFree" ] }
{ "_id" : "~~id~config", "ident" : "~~id~***@callidus.local", "uid" :
"~~id~config", "ent" : "specialuser", "rlm" : "callidus.local", "pstk" :
"xUKNFEoCmp", "authtp" : "DIGEST", "prm" : [ "InternationalDialing",
"LocalDialing", "LongDistanceDialing", "Mobile", "TollFree" ] }
{ "_id" : "~~id~media", "ident" : "~~id~***@callidus.local", "uid" :
"~~id~media", "ent" : "specialuser", "rlm" : "callidus.local", "pstk" :
"ytnKCLXZi4", "authtp" : "DIGEST", "prm" : [ "InternationalDialing",
"LocalDialing", "LongDistanceDialing", "Mobile", "TollFree" ] }
{ "_id" : "~~id~park", "ident" : "~~id~***@callidus.local", "uid" :
"~~id~park", "ent" : "specialuser", "rlm" : "callidus.local", "pstk" :
"cobgqpNP7E", "authtp" : "DIGEST", "prm" : [ "InternationalDialing",
"LocalDialing", "LongDistanceDialing", "Mobile", "TollFree" ] }
{ "_id" : "~~id~registrar", "ident" : "~~id~***@callidus.local",
"uid" : "~~id~registrar", "ent" : "specialuser", "rlm" :
"callidus.local", "pstk" : "cPFVo6zTY2", "authtp" : "DIGEST", "prm" : [
"InternationalDialing", "LocalDialing", "LongDistanceDialing", "Mobile",
"TollFree" ] }
{ "_id" : "~~id~sipXprovision", "ident" :
"~~id~***@callidus.local", "uid" : "~~id~sipXprovision", "ent"
: "specialuser", "rlm" : "callidus.local", "pstk" : "YOWT6JvHMd",
"authtp" : "DIGEST" }
{ "_id" : "~~id~sipXrls", "ident" : "~~id~***@callidus.local", "uid"
: "~~id~sipXrls", "ent" : "specialuser", "rlm" : "callidus.local",
"pstk" : "I8OR59vQXH", "authtp" : "DIGEST", "prm" : [
"InternationalDialing", "LocalDialing", "LongDistanceDialing", "Mobile",
"TollFree" ] }
{ "_id" : "~~id~sipXsaa", "ident" : "~~id~***@callidus.local", "uid"
: "~~id~sipXsaa", "ent" : "specialuser", "rlm" : "callidus.local",
"pstk" : "eT8C4ecUDR", "authtp" : "DIGEST", "prm" : [
"InternationalDialing", "LocalDialing", "LongDistanceDialing", "Mobile",
"TollFree" ] }
{ "_id" : "~~id~xmpprlsclient", "ident" :
"~~id~***@callidus.local", "uid" : "~~id~xmpprlsclient", "ent"
: "specialuser", "rlm" : "callidus.local", "pstk" : "tk2Li2iAYh",
"authtp" : "DIGEST", "prm" : [ "InternationalDialing", "LocalDialing",
"LongDistanceDialing", "Mobile", "TollFree" ] }



On 10/02/2012 08:41 PM, George Niculae wrote:
> On Tue, Oct 2, 2012 at 3:16 PM, darthzejdr <***@gmail.com> wrote:
>> Changed to ip address, everything is still the same
>>
> IMO it really looks like the domain alias issue we seen in latest 4.4
> build, will need Joegen's call to be sure
>
> 2012-10-02T11:51:25.797451Z":11702:SIP:DEBUG:sipx2.callidus.local:SipClientUdp-10:7fb0afa0b700:SipXProxy:"SipTransaction::handleChildIncoming
> 0x7fb0a801af80 relationship PROVISIONAL parent (nil)"
> "2012-10-02T11:51:25.797655Z":11703:ODBC:DEBUG:sipx2.callidus.local:SipRouter-12:7fb0ad9c0700:SipXProxy:"***@192.168.0.47
> is NOT present in namespace imdb.entity"
> "2012-10-02T11:51:25.797678Z":11704:ODBC:INFO:sipx2.callidus.local:SipRouter-12:7fb0ad9c0700:SipXProxy:"EntityDB::findByIdentity
> - Unable to find entity record for ***@192.168.0.47 from namespace
> imdb.entity"
> "2012-10-02T11:51:25.797702Z":11705:ODBC:INFO:sipx2.callidus.local:SipRouter-12:7fb0ad9c0700:SipXProxy:"EntityDB::findByIdentity
> - Finding entity record for callidus.local from namespace imdb.entity"
> "2012-10-02T11:51:25.797808Z":11706:SIP:DEBUG:sipx2.callidus.local:SipClientUdp-10:7fb0afa0b700:SipXProxy:"SipUserAgent::dispatch
> resentWithAuth 0"
> "2012-10-02T11:51:25.798772Z":11707:ODBC:DEBUG:sipx2.callidus.local:SipRouter-12:7fb0ad9c0700:SipXProxy:"callidus.local
> is NOT present in namespace imdb.entity"
> "2012-10-02T11:51:25.798799Z":11708:ODBC:INFO:sipx2.callidus.local:SipRouter-12:7fb0ad9c0700:SipXProxy:"EntityDB::findByIdentity
> - Unable to find entity record for callidus.local from namespace
> imdb.entity"
> "2012-10-02T11:51:25.798823Z":11709:SIP:WARNING:sipx2.callidus.local:SipRouter-12:7fb0ad9c0700:SipXProxy:"CallerAlias::getCallerAlias
> - No caller alias configured for identity=***@192.168.0.47
>
> George
> _______________________________________________
> sipx-users mailing list
> sipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
Joegen Baclor
2012-10-03 03:54:00 UTC
Permalink
Hi,

Thanks for the snapshots. Based on the logs that was available in the
registrar of the secondary node, it was able to redirect properly to the
phone

SIP/2.0 302 Moved Temporarily\r
From: \"200\"<sip:***@192.168.0.47>;tag=ab5d6542\r
To: <sip:***@192.168.0.47>;tag=AbhEaS\r
Call-Id: MjdiMGE4YWE4MGY4ODU3NDgzM2E1YzU1ZTBjYmU0NTk.\r
Cseq: 2 INVITE\r
Via: SIP/2.0/TCP 192.168.0.47;branch=z9hG4bK-XX-001aeUrpcbmu7vBf`_c61fH_Yw\r
Via: SIP/2.0/UDP
192.168.0.55:15810;branch=z9hG4bK-d8754z-983553228a49011f-1---d8754z-;rport=15810\r
Record-Route: <sip:192.168.0.47:5060;lr>\r
Contact:
<sip:***@192.168.0.66:62697;transport=TCP;rinstance=4ce1d9be058b9429;x-sipX-nonat;sipXecs-CallDest=INT?expires=20&ROUTE=%3Csip%3Acallidus.local%3Blr%3E>\r
Contact:
<sip:***@192.168.0.66:62945;transport=TCP;rinstance=276e8dd6bd8063e0;x-sipX-nonat;sipXecs-CallDest=INT?expires=20&ROUTE=%3Csip%3Acallidus.local%3Blr%3E>\r
Contact:
<sip:~~vm~***@callidus.local;sipXecs-CallDest=VMR?ROUTE=%3Csip%3Acallidus.local%3Blr%3E>;q=0.1\r
User-Agent: sipXecs/4.6.0 sipXecs/registry (Linux)\r
Date: Tue, 02 Oct 2012 11:51:24 GMT\r
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, REGISTER, SUBSCRIBE\r
Accept-Language: en\r
Supported: gruu, path\r
Content-Length: 0\r




However, looking at the proxy log and grepping for the INVITEs I wasn't
able to see the sip messages for the earlier transaction. Log is
incomplete. If possible, since there seems to be not much traffic in
this box yet, that you get actual TCP dumps of the call. You may do
this using homer.

Joegen


On 10/02/2012 07:56 PM, darthzejdr wrote:
>
> https://www.dropbox.com/s/iwiatrnvkf7fh9a/sipx-snapshot-sipx1.callidus.local.tar.gz
>
> https://www.dropbox.com/s/xwjq7q2px45b4sn/sipx-snapshot-sipx2.callidus.local.tar.gz
>
> calls are:
>
> 201 -> 200 works
>
> 200 -> 201 doesn't work
>
> 200 -> ***@192.168.0.46 <mailto:***@192.168.0.46> works
>
> *From:*Joegen Baclor [mailto:***@ezuce.com]
> *Sent:* Tuesday, October 02, 2012 1:22 PM
> *To:* Discussion list for users of sipXecs software
> *Cc:* darthzejdr
> *Subject:* Re: [sipx-users] 4.6 Cluster
>
> Please send snapshots with both proxy and registrar in debug level.
>
> On 10/02/2012 07:08 PM, darthzejdr wrote:
>
> I've done a few more tests(extensions registered with normal
> domain(callidus.local) but using proxy field with ip adress) but
> again the same problem. II can make calls from primary server to
> sacondary, but the only way to make a call from secondary server
> is to use ***@192.168.0.46 <mailto:***@192.168.0.46> as the number
> i am calling. For some reason secondary server can't reach
> extensions on primary.
>
> *From:*darthzejdr [mailto:***@gmail.com]
> *Sent:* Tuesday, October 02, 2012 10:49 AM
> *To:* 'Discussion list for users of sipXecs software'
> *Subject:* RE: [sipx-users] 4.6 Cluster
>
> I reinstalled my sipx according to your setup.
>
> 201 is registered on primary server(with ip address in domain,
> 92.168.0.46)
>
> 200 is registered on secondary server(with ip address in domain,
> 192.168.0.47)
>
> 201 to 200 works normaly
>
> 200 to 201 gives error "user is temporarily unavailable(404)"
>
> 200 to ***@192.168.0.46(primary
> <mailto:***@192.168.0.46%28primary> server ip address) works
>
> https://www.dropbox.com/s/cn9vqmt25zurm2z/sipx-snapshot-sipx1.callidus.local.tar.gz
>
> https://www.dropbox.com/s/loqjb4v0x74kktm/sipx-snapshot-sipx2.callidus.local.tar.gz
>
> -----Original Message-----
>
> From: sipx-users-***@list.sipfoundry.org
> <mailto:sipx-users-***@list.sipfoundry.org>
>
> [mailto:sipx-users-***@list.sipfoundry.org]
> <mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf
> Of George Niculae
>
> Sent: Friday, September 28, 2012 5:47 PM
>
> To: Discussion list for users of sipXecs software
>
> Subject: Re: [sipx-users] 4.6 Cluster
>
> On Fri, Sep 28, 2012 at 4:35 PM, darthzejdr <***@gmail.com
> <mailto:***@gmail.com>> wrote:
>
> > Didnt help. Everything the same. If i try to call extension on
> second
>
> > server i get The user is temporarily unavailable (404 )
>
> >
>
> That's what I did, let me know if testing scenario different:
>
> - setup cluster with 2 nodes, both running DNS, Proxy and Registrar
>
> - configured secondary IP and fqdn as domain aliases, then sent
> profiles to
>
> servers
>
> - registered account 200 Bria on first node (giving 1st node IP as
> domain)
>
> - registered account 201, another phone on 2nd node (giving 2nd
> node IP as
>
> domain)
>
> - calls 200 to 200 established just fine
>
> George
>
> _______________________________________________
>
> sipx-users mailing list
>
> sipx-***@list.sipfoundry.org <mailto:sipx-***@list.sipfoundry.org>
>
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
>
>
>
> _______________________________________________
>
> sipx-users mailing list
>
> sipx-***@list.sipfoundry.org <mailto:sipx-***@list.sipfoundry.org>
>
> List Archive:http://list.sipfoundry.org/archive/sipx-users/
>
>
>
> _______________________________________________
> sipx-users mailing list
> sipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
darthzejdr
2012-10-03 06:59:22 UTC
Permalink
Slightly different situation today(the only change i did was to send
profiles and turn on capture database)



First call was from 201(primary server) to 200(secondary server), didn't
work. Thats probably ***@192.168.0.46 to ***@192.168.0.46 in the logs. This
worked yesterday.

Second call from 201 to ***@192.168.0.47 (manualy gave ip address in call to
field). That one works

Third was 200 to 201, probably ***@192.168.0.47 to ***@192.168.0.47 in the
logs

Fourth was 200 to ***@192.168.0.46 (manualy gave ip address). That one works
as well.



https://www.dropbox.com/s/olw1nyxj57gadsc/configuration.tar.gz

https://www.dropbox.com/s/6j1bzcgtbf1qdxh/homer.tar.gz

https://www.dropbox.com/s/7r3a9d8eg1qxvhw/sipx-snapshot-sipx1.callidus.local
.tar.gz

https://www.dropbox.com/s/bq5yras7hyb0zyn/sipx-snapshot-sipx2.callidus.local
.tar.gz







From: Joegen Baclor [mailto:***@ezuce.com]
Sent: Wednesday, October 03, 2012 5:54 AM
To: Discussion list for users of sipXecs software
Cc: darthzejdr
Subject: Re: [sipx-users] 4.6 Cluster



Hi,

Thanks for the snapshots. Based on the logs that was available in the
registrar of the secondary node, it was able to redirect properly to the
phone

SIP/2.0 302 Moved Temporarily\r
From: \"200\" <mailto:sip:***@192.168.0.47>
<sip:***@192.168.0.47>;tag=ab5d6542\r
To: <mailto:sip:***@192.168.0.47> <sip:***@192.168.0.47>;tag=AbhEaS\r
Call-Id: MjdiMGE4YWE4MGY4ODU3NDgzM2E1YzU1ZTBjYmU0NTk.\r
Cseq: 2 INVITE\r
Via: SIP/2.0/TCP 192.168.0.47;branch=z9hG4bK-XX-001aeUrpcbmu7vBf`_c61fH_Yw\r
Via: SIP/2.0/UDP
192.168.0.55:15810;branch=z9hG4bK-d8754z-983553228a49011f-1---d8754z-;rport=
15810\r
Record-Route: <sip:192.168.0.47:5060;lr>\r
Contact:
<mailto:sip:***@192.168.0.66:62697;transport=TCP;rinstance=4ce1d9be058b9429;
x-sipX-nonat;sipXecs-CallDest=INT?expires=20&ROUTE=%3Csip%3Acallidus.local%3
Blr%3E>
<sip:***@192.168.0.66:62697;transport=TCP;rinstance=4ce1d9be058b9429;x-sipX-
nonat;sipXecs-CallDest=INT?expires=20&ROUTE=%3Csip%3Acallidus.local%3Blr%3E>
\r
Contact:
<mailto:sip:***@192.168.0.66:62945;transport=TCP;rinstance=276e8dd6bd8063e0;
x-sipX-nonat;sipXecs-CallDest=INT?expires=20&ROUTE=%3Csip%3Acallidus.local%3
Blr%3E>
<sip:***@192.168.0.66:62945;transport=TCP;rinstance=276e8dd6bd8063e0;x-sipX-
nonat;sipXecs-CallDest=INT?expires=20&ROUTE=%3Csip%3Acallidus.local%3Blr%3E>
\r
Contact:
<mailto:sip:~~vm~***@callidus.local;sipXecs-CallDest=VMR?ROUTE=%3Csip%3Acall
idus.local%3Blr%3E>
<sip:~~vm~***@callidus.local;sipXecs-CallDest=VMR?ROUTE=%3Csip%3Acallidus.lo
cal%3Blr%3E>;q=0.1\r
User-Agent: sipXecs/4.6.0 sipXecs/registry (Linux)\r
Date: Tue, 02 Oct 2012 11:51:24 GMT\r
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, REGISTER, SUBSCRIBE\r
Accept-Language: en\r
Supported: gruu, path\r
Content-Length: 0\r




However, looking at the proxy log and grepping for the INVITEs I wasn't able
to see the sip messages for the earlier transaction. Log is incomplete. If
possible, since there seems to be not much traffic in this box yet, that you
get actual TCP dumps of the call. You may do this using homer.

Joegen


On 10/02/2012 07:56 PM, darthzejdr wrote:

https://www.dropbox.com/s/iwiatrnvkf7fh9a/sipx-snapshot-sipx1.callidus.local
.tar.gz

https://www.dropbox.com/s/xwjq7q2px45b4sn/sipx-snapshot-sipx2.callidus.local
.tar.gz



calls are:

201 -> 200 works

200 -> 201 doesn't work

200 -> ***@192.168.0.46 works



From: Joegen Baclor [mailto:***@ezuce.com]
Sent: Tuesday, October 02, 2012 1:22 PM
To: Discussion list for users of sipXecs software
Cc: darthzejdr
Subject: Re: [sipx-users] 4.6 Cluster



Please send snapshots with both proxy and registrar in debug level.

On 10/02/2012 07:08 PM, darthzejdr wrote:

I've done a few more tests(extensions registered with normal
domain(callidus.local) but using proxy field with ip adress) but again the
same problem. II can make calls from primary server to sacondary, but the
only way to make a call from secondary server is to use ***@192.168.0.46 as
the number i am calling. For some reason secondary server can't reach
extensions on primary.



From: darthzejdr [mailto:***@gmail.com]
Sent: Tuesday, October 02, 2012 10:49 AM
To: 'Discussion list for users of sipXecs software'
Subject: RE: [sipx-users] 4.6 Cluster



I reinstalled my sipx according to your setup.

201 is registered on primary server(with ip address in domain, 92.168.0.46)

200 is registered on secondary server(with ip address in domain,
192.168.0.47)



201 to 200 works normaly

200 to 201 gives error "user is temporarily unavailable(404)"

200 to ***@192.168.0.46(primary <mailto:***@192.168.0.46%28primary> server
ip address) works



https://www.dropbox.com/s/cn9vqmt25zurm2z/sipx-snapshot-sipx1.callidus.local
.tar.gz

https://www.dropbox.com/s/loqjb4v0x74kktm/sipx-snapshot-sipx2.callidus.local
.tar.gz



-----Original Message-----

From: sipx-users-***@list.sipfoundry.org

[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of George Niculae

Sent: Friday, September 28, 2012 5:47 PM

To: Discussion list for users of sipXecs software

Subject: Re: [sipx-users] 4.6 Cluster



On Fri, Sep 28, 2012 at 4:35 PM, darthzejdr <***@gmail.com> wrote:

> Didnt help. Everything the same. If i try to call extension on second

> server i get The user is temporarily unavailable (404 )

>



That's what I did, let me know if testing scenario different:

- setup cluster with 2 nodes, both running DNS, Proxy and Registrar

- configured secondary IP and fqdn as domain aliases, then sent profiles to

servers

- registered account 200 Bria on first node (giving 1st node IP as domain)

- registered account 201, another phone on 2nd node (giving 2nd node IP as

domain)

- calls 200 to 200 established just fine



George

_______________________________________________

sipx-users mailing list

sipx-***@list.sipfoundry.org

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







_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/
darthzejdr
2012-10-04 11:20:04 UTC
Permalink
Unfortunately i don't understand those logs. Is there something wrong with
my configuration? Or any ideas what to try next? I am doing yum update now
so will do another try then and see if anything changed.

-----Original Message-----
From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Joegen Baclor
Sent: Thursday, October 04, 2012 1:06 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] 4.6 Cluster

Here's what happened to the bad call. Unforutenately, there is not enough
information in the proxy what happened to the call prior to hitting IVR.

On 10/04/2012 04:53 PM, George Niculae wrote:
> On Thu, Oct 4, 2012 at 11:47 AM, darthzejdr <***@gmail.com> wrote:
>> "201"<sip:***@callidus.local>
>> <sip:***@192.168.0.66:56053;transport=TCP;rinstance=fbf9694cbf1534fc;
>> x-sipX-
>> nonat> 2472
>> "200"<sip:***@callidus.local>
>> <sip:***@192.168.0.55:36150;rinstance=25d8170036270c5a;x-sipX-nonat>
3407
>>
>> This are the current registrations, but i'm not 100% sure it was the
>> same since we're constantly testing and changing.
>>
> Could you please yum update, there are some changes we done lately in
> this area. If still see the issue, try to register 201 as UDP too so
> we could isolate the problem
>
> Thanks
> George
> _______________________________________________
> sipx-users mailing list
> sipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
George Niculae
2012-10-04 12:05:36 UTC
Permalink
On Thu, Oct 4, 2012 at 2:20 PM, darthzejdr <***@gmail.com> wrote:
> Unfortunately i don't understand those logs. Is there something wrong with
> my configuration? Or any ideas what to try next? I am doing yum update now
> so will do another try then and see if anything changed.
>

There is a problem with snapshot right now we're working on, could you
please attach the entire sipXproxy.log file and sipregistrar.log form
both nodes when this is reproduced

George
darthzejdr
2012-10-04 13:05:26 UTC
Permalink
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

TLS not tested now, but had the same results as tcp

Logs:

https://www.dropbox.com/s/1athqwizv0tv75q/SipX.rar


-----Original Message-----
From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of George Niculae
Sent: Thursday, October 04, 2012 2:06 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] 4.6 Cluster

On Thu, Oct 4, 2012 at 2:20 PM, darthzejdr <***@gmail.com> wrote:
> Unfortunately i don't understand those logs. Is there something wrong
> with my configuration? Or any ideas what to try next? I am doing yum
> update now so will do another try then and see if anything changed.
>

There is a problem with snapshot right now we're working on, could you
please attach the entire sipXproxy.log file and sipregistrar.log form both
nodes when this is reproduced

George
darthzejdr
2012-10-04 14:16:47 UTC
Permalink
Server1:
[***@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:
[***@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-***@list.sipfoundry.org
[mailto:sipx-users-***@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 <***@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
George Niculae
2012-10-04 13:26:48 UTC
Permalink
On Thu, Oct 4, 2012 at 4:05 PM, darthzejdr <***@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
darthzejdr
2012-10-04 08:47:45 UTC
Permalink
"201"<sip:***@callidus.local>
<sip:***@192.168.0.66:56053;transport=TCP;rinstance=fbf9694cbf1534fc;x-sipX-
nonat> 2472
"200"<sip:***@callidus.local>
<sip:***@192.168.0.55:36150;rinstance=25d8170036270c5a;x-sipX-nonat> 3407

This are the current registrations, but i'm not 100% sure it was the same
since we're constantly testing and changing.

-----Original Message-----
From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of George Niculae
Sent: Thursday, October 04, 2012 9:30 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] 4.6 Cluster

On Wed, Oct 3, 2012 at 9:59 AM, darthzejdr <***@gmail.com> wrote:
> Slightly different situation today(the only change i did was to send
> profiles and turn on capture database)
>
>
>
> First call was from 201(primary server) to 200(secondary server),
> didn't work. Thats probably ***@192.168.0.46 to ***@192.168.0.46 in
> the logs. This worked yesterday.
>
> Second call from 201 to ***@192.168.0.47 (manualy gave ip address in
> call to field). That one works
>
> Third was 200 to 201, probably ***@192.168.0.47 to ***@192.168.0.47 in
> the logs
>
> Fourth was 200 to ***@192.168.0.46 (manualy gave ip address). That one
> works as well.
>
>

Can you also copy / paste the registrations for these phones taken from
Diagnostics > Registration page?

George
Joegen Baclor
2012-10-04 11:05:47 UTC
Permalink
Here's what happened to the bad call. Unforutenately, there is not
enough information in the proxy what happened to the call prior to
hitting IVR.

On 10/04/2012 04:53 PM, George Niculae wrote:
> On Thu, Oct 4, 2012 at 11:47 AM, darthzejdr <***@gmail.com> wrote:
>> "201"<sip:***@callidus.local>
>> <sip:***@192.168.0.66:56053;transport=TCP;rinstance=fbf9694cbf1534fc;x-sipX-
>> nonat> 2472
>> "200"<sip:***@callidus.local>
>> <sip:***@192.168.0.55:36150;rinstance=25d8170036270c5a;x-sipX-nonat> 3407
>>
>> This are the current registrations, but i'm not 100% sure it was the same
>> since we're constantly testing and changing.
>>
> Could you please yum update, there are some changes we done lately in
> this area. If still see the issue, try to register 201 as UDP too so
> we could isolate the problem
>
> Thanks
> George
> _______________________________________________
> sipx-users mailing list
> sipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
Joegen Baclor
2012-10-04 14:39:05 UTC
Permalink
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:***@192.168.0.66:55243;rinstance=4782eca9743a1724;transport=TCP;x-sipX-nonat>\r
To: \"201\"<sip:***@192.168.0.46>\r
From: \"201\"<sip:***@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
(***@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:***@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:***@192.168.0.55:1889;transport=TCP;x-sipX-nonat>\r
To: <sip:***@192.168.0.47>\r
From: \"200\"<sip:***@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:***@192.168.0.47;transport=tcp\",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:***@192.168.0.47>;tag=cd09f73c\r
To: <sip:***@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:
> [***@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:
> [***@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-***@list.sipfoundry.org
> [mailto:sipx-users-***@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 <***@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-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
> _______________________________________________
> sipx-users mailing list
> sipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
darthzejdr
2012-10-05 06:57:58 UTC
Permalink
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:***@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: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:***@192.168.0.66:55243;rinstance=4782eca9743a1724;transport=TCP;
x-sipX-nonat>
<sip:***@192.168.0.66:55243;rinstance=4782eca9743a1724;transport=TCP;x-sipX-
nonat>\r
To: \"201\" <mailto:sip:***@192.168.0.46> <sip:***@192.168.0.46>\r
From: \"201\" <mailto:sip:***@192.168.0.46>
<sip:***@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 (***@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:"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:***@192.168.0.66: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:***@192.168.0.55:1889;transport=TCP;x-sipX-nonat>
<sip:***@192.168.0.55:1889;transport=TCP;x-sipX-nonat>\r
To: <mailto:sip:***@192.168.0.47> <sip:***@192.168.0.47>\r
From: \"200\" <mailto:sip:***@192.168.0.47>
<sip:***@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=\"0b61a318caca69024f6803b99f
cd402a506bdff0\",uri=\ <mailto:sip:***@192.168.0.47;transport=tcp\>
"sip:***@192.168.0.47;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:***@192.168.0.47>
<sip:***@192.168.0.47>;tag=cd09f73c\r
To: <mailto:sip:***@192.168.0.47> <sip:***@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:
[***@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:
[***@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-***@list.sipfoundry.org
[mailto:sipx-users-***@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 <mailto:***@gmail.com>
<***@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-***@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/
Joegen Baclor
2012-10-05 07:18:15 UTC
Permalink
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:***@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:***@192.168.0.66:55243;rinstance=4782eca9743a1724;transport=TCP;x-sipX-nonat>
> <mailto:sip:***@192.168.0.66:55243;rinstance=4782eca9743a1724;transport=TCP;x-sipX-nonat>\r
> To: \"201\"<sip:***@192.168.0.46> <mailto:sip:***@192.168.0.46>\r
> From: \"201\"<sip:***@192.168.0.46>
> <mailto:sip:***@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 (***@192.168.0.66
> <mailto:***@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:***@192.168.0.66
> <mailto:sip:***@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:***@192.168.0.55:1889;transport=TCP;x-sipX-nonat>
> <mailto:sip:***@192.168.0.55:1889;transport=TCP;x-sipX-nonat>\r
> To: <sip:***@192.168.0.47> <mailto:sip:***@192.168.0.47>\r
> From: \"200\"<sip:***@192.168.0.47>
> <mailto:sip:***@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:***@192.168.0.47;transport=tcp\"
> <mailto:sip:***@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:***@192.168.0.47>
> <mailto:sip:***@192.168.0.47>;tag=cd09f73c\r
> To: <sip:***@192.168.0.47> <mailto:sip:***@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:
>
> [***@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:
>
> [***@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-***@list.sipfoundry.org <mailto:sipx-users-***@list.sipfoundry.org>
>
> [mailto:sipx-users-***@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<***@gmail.com> <mailto:***@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-***@list.sipfoundry.org <mailto:sipx-***@list.sipfoundry.org>
>
> List Archive:http://list.sipfoundry.org/archive/sipx-users/
>
>
>
> _______________________________________________
>
> sipx-users mailing list
>
> sipx-***@list.sipfoundry.org <mailto:sipx-***@list.sipfoundry.org>
>
> List Archive:http://list.sipfoundry.org/archive/sipx-users/
>
>
>
>
>
> _______________________________________________
> sipx-users mailing list
> sipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
darthzejdr
2012-10-09 13:44:26 UTC
Permalink
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:***@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:***@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: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:***@192.168.0.66:55243;rinstance=4782eca9743a1724;transport=TCP;
x-sipX-nonat>
<sip:***@192.168.0.66:55243;rinstance=4782eca9743a1724;transport=TCP;x-sipX-
nonat>\r
To: \"201\" <mailto:sip:***@192.168.0.46> <sip:***@192.168.0.46>\r
From: \"201\" <mailto:sip:***@192.168.0.46>
<sip:***@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 (***@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:"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:***@192.168.0.66: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:***@192.168.0.55:1889;transport=TCP;x-sipX-nonat>
<sip:***@192.168.0.55:1889;transport=TCP;x-sipX-nonat>\r
To: <mailto:sip:***@192.168.0.47> <sip:***@192.168.0.47>\r
From: \"200\" <mailto:sip:***@192.168.0.47>
<sip:***@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=\"0b61a318caca69024f6803b99f
cd402a506bdff0\",uri=\ <mailto:sip:***@192.168.0.47;transport=tcp%5C>
"sip:***@192.168.0.47;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:***@192.168.0.47>
<sip:***@192.168.0.47>;tag=cd09f73c\r
To: <mailto:sip:***@192.168.0.47> <sip:***@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:
[***@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:
[***@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-***@list.sipfoundry.org
[mailto:sipx-users-***@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 <mailto:***@gmail.com>
<***@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-***@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/
Douglas Hubler
2012-10-09 20:21:33 UTC
Permalink
does bria allow you to set an outbound proxy? polycom has this. so
essentially it will allow you to register

***@domain.com

at server

server1.domain.com


On Tue, Oct 9, 2012 at 9:44 AM, darthzejdr <***@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:***@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:***@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:***@192.168.0.66:55243;rinstance=4782eca9743a1724;transport=TCP;x-sipX-nonat>\r
> To: \"201\"<sip:***@192.168.0.46>\r
> From: \"201\"<sip:***@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 (***@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:***@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:***@192.168.0.55:1889;transport=TCP;x-sipX-nonat>\r
> To: <sip:***@192.168.0.47>\r
> From: \"200\"<sip:***@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:***@192.168.0.47;transport=tcp\",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:***@192.168.0.47>;tag=cd09f73c\r
> To: <sip:***@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:
>
> [***@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:
>
> [***@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-***@list.sipfoundry.org
>
> [mailto:sipx-users-***@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 <***@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-***@list.sipfoundry.org
>
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
>
>
> _______________________________________________
>
> sipx-users mailing list
>
> sipx-***@list.sipfoundry.org
>
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
>
>
>
>
>
>
>
> _______________________________________________
>
> sipx-users mailing list
>
> sipx-***@list.sipfoundry.org
>
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
>
>
>
> _______________________________________________
> sipx-users mailing list
> sipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
darthzejdr
2012-10-09 21:36:54 UTC
Permalink
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-***@list.sipfoundry.org
[mailto:sipx-users-***@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

***@domain.com

at server

server1.domain.com


On Tue, Oct 9, 2012 at 9:44 AM, darthzejdr <***@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:***@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:***@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:***@192.168.0.66:55243;rinstance=4782eca9743a1724;transport=TCP;x
> -sipX-nonat>\r
> To: \"201\"<sip:***@192.168.0.46>\r
> From: \"201\"<sip:***@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
> (***@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:***@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:***@192.168.0.55:1889;transport=TCP;x-sipX-nonat>\r
> To: <sip:***@192.168.0.47>\r
> From: \"200\"<sip:***@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:***@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:***@192.168.0.47>;tag=cd09f73c\r
> To: <sip:***@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:
>
> [***@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:
>
> [***@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-***@list.sipfoundry.org
>
> [mailto:sipx-users-***@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 <***@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-***@list.sipfoundry.org
>
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
>
>
> _______________________________________________
>
> sipx-users mailing list
>
> sipx-***@list.sipfoundry.org
>
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
>
>
>
>
>
>
>
> _______________________________________________
>
> sipx-users mailing list
>
> sipx-***@list.sipfoundry.org
>
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
>
>
>
> _______________________________________________
> sipx-users mailing list
> sipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
Douglas Hubler
2012-10-10 11:18:58 UTC
Permalink
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 <***@gmail.com> 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: sipx-users-***@list.sipfoundry.org
> [mailto:sipx-users-***@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
>
> ***@domain.com
>
> at server
>
> server1.domain.com
>
>
> On Tue, Oct 9, 2012 at 9:44 AM, darthzejdr <***@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:***@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:***@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:***@192.168.0.66:55243;rinstance=4782eca9743a1724;transport=TCP;x
>> -sipX-nonat>\r
>> To: \"201\"<sip:***@192.168.0.46>\r
>> From: \"201\"<sip:***@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
>> (***@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:***@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:***@192.168.0.55:1889;transport=TCP;x-sipX-nonat>\r
>> To: <sip:***@192.168.0.47>\r
>> From: \"200\"<sip:***@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:***@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:***@192.168.0.47>;tag=cd09f73c\r
>> To: <sip:***@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:
>>
>> [***@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:
>>
>> [***@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-***@list.sipfoundry.org
>>
>> [mailto:sipx-users-***@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 <***@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-***@list.sipfoundry.org
>>
>> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>>
>>
>>
>> _______________________________________________
>>
>> sipx-users mailing list
>>
>> sipx-***@list.sipfoundry.org
>>
>> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> sipx-users mailing list
>>
>> sipx-***@list.sipfoundry.org
>>
>> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>>
>>
>>
>>
>> _______________________________________________
>> sipx-users mailing list
>> sipx-***@list.sipfoundry.org
>> List Archive: http://list.sipfoundry.org/archive/sipx-users/
> _______________________________________________
> sipx-users mailing list
> sipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
> _______________________________________________
> sipx-users mailing list
> sipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
darthzejdr
2012-10-22 10:59:15 UTC
Permalink
Any news on this problem?

-----Original Message-----
From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] 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 <***@gmail.com> 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: sipx-users-***@list.sipfoundry.org
> [mailto:sipx-users-***@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
>
> ***@domain.com
>
> at server
>
> server1.domain.com
>
>
> On Tue, Oct 9, 2012 at 9:44 AM, darthzejdr <***@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:***@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:***@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: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:***@192.168.0.66:55243;rinstance=4782eca9743a1724;transport=TCP;
>> x
>> -sipX-nonat>\r
>> To: \"201\"<sip:***@192.168.0.46>\r
>> From: \"201\"<sip:***@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
>> (***@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: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:***@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~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:***@192.168.0.55:1889;transport=TCP;x-sipX-nonat>\r
>> To: <sip:***@192.168.0.47>\r
>> From: \"200\"<sip:***@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=\"0b61a318caca69024f6
>> 8
>> 03b99fcd402a506bdff0\",uri=\"sip:***@192.168.0.47;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:***@192.168.0.47>;tag=cd09f73c\r
>> To: <sip:***@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~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:
>>
>> [***@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:
>>
>> [***@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-***@list.sipfoundry.org
>>
>> [mailto:sipx-users-***@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 <***@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-***@list.sipfoundry.org
>>
>> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>>
>>
>>
>> _______________________________________________
>>
>> sipx-users mailing list
>>
>> sipx-***@list.sipfoundry.org
>>
>> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> sipx-users mailing list
>>
>> sipx-***@list.sipfoundry.org
>>
>> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>>
>>
>>
>>
>> _______________________________________________
>> sipx-users mailing list
>> sipx-***@list.sipfoundry.org
>> List Archive: http://list.sipfoundry.org/archive/sipx-users/
> _______________________________________________
> sipx-users mailing list
> sipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
> _______________________________________________
> sipx-users mailing list
> sipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
George Niculae
2012-10-04 08:53:40 UTC
Permalink
On Thu, Oct 4, 2012 at 11:47 AM, darthzejdr <***@gmail.com> wrote:
> "201"<sip:***@callidus.local>
> <sip:***@192.168.0.66:56053;transport=TCP;rinstance=fbf9694cbf1534fc;x-sipX-
> nonat> 2472
> "200"<sip:***@callidus.local>
> <sip:***@192.168.0.55:36150;rinstance=25d8170036270c5a;x-sipX-nonat> 3407
>
> This are the current registrations, but i'm not 100% sure it was the same
> since we're constantly testing and changing.
>

Could you please yum update, there are some changes we done lately in
this area. If still see the issue, try to register 201 as UDP too so
we could isolate the problem

Thanks
George
George Niculae
2012-10-04 07:29:56 UTC
Permalink
On Wed, Oct 3, 2012 at 9:59 AM, darthzejdr <***@gmail.com> wrote:
> Slightly different situation today(the only change i did was to send
> profiles and turn on capture database)
>
>
>
> First call was from 201(primary server) to 200(secondary server), didn't
> work. Thats probably ***@192.168.0.46 to ***@192.168.0.46 in the logs. This
> worked yesterday.
>
> Second call from 201 to ***@192.168.0.47 (manualy gave ip address in call to
> field). That one works
>
> Third was 200 to 201, probably ***@192.168.0.47 to ***@192.168.0.47 in the
> logs
>
> Fourth was 200 to ***@192.168.0.46 (manualy gave ip address). That one works
> as well.
>
>

Can you also copy / paste the registrations for these phones taken
from Diagnostics > Registration page?

George
Loading...