Jump to content

Problem registering PBXnSIP servers to eachother


jlumby
 Share

Recommended Posts

I have a situation where I have 2 PBXnSIP servers registering their trunks to a third PBXnSIP server as different extensions. The problem I am having is even though the accounts are different, one server unregisters the other one. The registrations bounce back and forth based on the last one to register. The servers are directly connected to eachother on the same subnet, so there cannot be any nat issues. Below are the emails I constantly get:

 

 

Source address for "12182604488" <sip:12182604488@10.0.0.4>;tag=17066

has changed from udp:10.0.0.2:5060 to udp:10.0.0.3:5060

 

REGISTER sip:10.0.0.4 SIP/2.0

Via: SIP/2.0/UDP

10.0.0.3:5060;branch=z9hG4bK-30ebe24cc32d1422b18c9521081dba63;rport

From: "12182604488" <sip:12182604488@10.0.0.4>;tag=17066

To: "12182604488" <sip:12182604488@10.0.0.4>

Call-ID: d2zvps87@pbx

CSeq: 9598 REGISTER

Max-Forwards: 70

Contact:

<sip:12182604488@10.0.0.3:5060;transport=udp;line=d3d94468>;+sip.instance="<urn:uuid:39b32d12-074d-4dc8-a443-66bb428b26a6>"

User-Agent: pbxnsip-PBX/3.2.0.3144

Expires: 3600

Content-Length: 0

 

Source address for "19522531500" <sip:19522531500@10.0.0.4>;tag=17066

has changed from udp:10.0.0.3:5060 to udp:10.0.0.2:5060

 

REGISTER sip:10.0.0.4 SIP/2.0

Via: SIP/2.0/UDP

10.0.0.2:5060;branch=z9hG4bK-369244384ef1e7d8c8b824385ac8c662;rport

From: "19522531500" <sip:19522531500@10.0.0.4>;tag=17066

To: "19522531500" <sip:19522531500@10.0.0.4>

Call-ID: d2zvps87@pbx

CSeq: 14494 REGISTER

Max-Forwards: 70

Contact:

<sip:19522531500@10.0.0.2:5060;transport=udp;line=45c48cce>;+sip.instance="<urn:uuid:00294823-18be-4784-8ae1-3d6c2cd672ae>"

User-Agent: pbxnsip-PBX/3.2.0.3144

Expires: 3600

Content-Length: 0

 

Source address for "12182604488" <sip:12182604488@10.0.0.4>;tag=17066

has changed from udp:10.0.0.2:5060 to udp:10.0.0.3:5060

 

REGISTER sip:10.0.0.4 SIP/2.0

Via: SIP/2.0/UDP

10.0.0.3:5060;branch=z9hG4bK-0563a06f02bfcd037dc9916022766536;rport

From: "12182604488" <sip:12182604488@10.0.0.4>;tag=17066

To: "12182604488" <sip:12182604488@10.0.0.4>

Call-ID: d2zvps87@pbx

CSeq: 9596 REGISTER

Max-Forwards: 70

Contact:

<sip:12182604488@10.0.0.3:5060;transport=udp;line=d3d94468>;+sip.instance="<urn:uuid:39b32d12-074d-4dc8-a443-66bb428b26a6>"

User-Agent: pbxnsip-PBX/3.2.0.3144

Expires: 3600

Content-Length: 0

 

Source address for "19522531500" <sip:19522531500@10.0.0.4>;tag=17066

has changed from udp:10.0.0.3:5060 to udp:10.0.0.2:5060

 

REGISTER sip:10.0.0.4 SIP/2.0

Via: SIP/2.0/UDP

10.0.0.2:5060;branch=z9hG4bK-af2c5abca0e1ecd5a0813da65f04532b;rport

From: "19522531500" <sip:19522531500@10.0.0.4>;tag=17066

To: "19522531500" <sip:19522531500@10.0.0.4>

Call-ID: d2zvps87@pbx

CSeq: 14489 REGISTER

Max-Forwards: 70

Contact:

<sip:19522531500@10.0.0.2:5060;transport=udp;line=45c48cce>;+sip.instance="<urn:uuid:00294823-18be-4784-8ae1-3d6c2cd672ae>"

User-Agent: pbxnsip-PBX/3.2.0.3144

Expires: 3600

Content-Length: 0

 

The trunk 12182604488 is only on 10.0.0.3 and registers to 10.0.0.4

 

 

The trunk 19522531500 is only on 10.0.0.2 and registers to 10.0.0.4

 

I noticed that the SIP Tag on both is the same, could 10.0.0.4 be confused by getting the same Tag from 2 different servers? Not really sure what the Tag value is/means.

Link to comment
Share on other sites

Windows (one is 2000 server the other one is XP Pro)

 

As a side note, when I originally created the trunk, the problem did not exist. It was not until the first reboot after the trunk was created that the problem popped up.

 

It is strange that they share the same call-ID. That looks like there is a problem with the initialization of the random number generator.

Link to comment
Share on other sites

Is there anything i can try?

 

Well, we need to get the initial seed for the random number generator sorted out. Depending on your operating system the answer will differ. For example in Linux, usually the OS will inject some randomness (e.g. by measuring the interrupt time). Maybe we also need to do something like taking some configuration-based data to add more randomness to the system; but first lets try to find out what exactly is causing this surprising non-randomness.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...