Jump to content

Trunks not connecting on the second day


grabit

Recommended Posts

Hi,

 

I am configuring a Snom ONE blue on a Mac mini.

 

Yesterday, I configured 2 trunks with my ITSP (weepeetelecom.eu), they worked almost fine except some 408 errors.

 

Since yesterday evening, when I restarted the PBX, no more connections to the trunks, no error message or status on the trunk list.

 

Even if I click on connect nothing happens.

 

Here is the log:

 

[1] 2011/01/18 09:50:08:	Starting up version 2011-4.2.0.3958
[1] 2011/01/18 09:50:09:	Working Directory is /usr/Applications/snomone
[5] 2011/01/18 09:50:09:	Starting threads
[1] 2011/01/18 09:50:09:	UDP: TOS could not be set
[5] 2011/01/18 09:50:09:	Set scheduling priority to 15
[5] 2011/01/18 09:50:17:	Table cdrt: Finished reading 46 rows
[5] 2011/01/18 09:50:17:	Table cdre: Finished reading 28 rows
[5] 2011/01/18 09:50:17:	Table cdri: Finished reading 62 rows
[4] 2011/01/18 09:50:46:	Could not find packet with number 1
[4] 2011/01/18 09:50:48:	Could not find packet with number 2

 

Any suggestions

Link to comment
Share on other sites

Hi,

 

I am configuring a Snom ONE blue on a Mac mini.

 

Yesterday, I configured 2 trunks with my ITSP (weepeetelecom.eu), they worked almost fine except some 408 errors.

 

Since yesterday evening, when I restarted the PBX, no more connections to the trunks, no error message or status on the trunk list.

 

Even if I click on connect nothing happens.

 

Here is the log:

 

[1] 2011/01/18 09:50:08:	Starting up version 2011-4.2.0.3958
[1] 2011/01/18 09:50:09:	Working Directory is /usr/Applications/snomone
[5] 2011/01/18 09:50:09:	Starting threads
[1] 2011/01/18 09:50:09:	UDP: TOS could not be set
[5] 2011/01/18 09:50:09:	Set scheduling priority to 15
[5] 2011/01/18 09:50:17:	Table cdrt: Finished reading 46 rows
[5] 2011/01/18 09:50:17:	Table cdre: Finished reading 28 rows
[5] 2011/01/18 09:50:17:	Table cdri: Finished reading 62 rows
[4] 2011/01/18 09:50:46:	Could not find packet with number 1
[4] 2011/01/18 09:50:48:	Could not find packet with number 2

 

Any suggestions

 

 

 

Can you check the access list? perhaps the the ITSP IP has been blocked?

Link to comment
Share on other sites

the outbound proxi is ssw3.brussels.weepee.org for the first and ssw4.bruges.weepee.org for the second one.

 

Where can I find the SIP logging except in the log from the web interface?

 

My concern is those 2 lines in the log:

[4] 2011/01/18 09:50:46:        Could not find packet with number 1
[4] 2011/01/18 09:50:48:        Could not find packet with number 2

 

They appear just after the start of the PBX and they were not there before the problems.

 

Should I change the level of logging?

Link to comment
Share on other sites

This is what get:

 

# host -t NAPTR ssw3.brussels.weepee.org
# host -t SRV _sips._tcp.ssw3.brussels.weepee.org
Host _sips._tcp.ssw3.brussels.weepee.org not found: 3(NXDOMAIN)
# host -t SRV _sip._tcp.ssw3.brussels.weepee.org
Host _sip._tcp.ssw3.brussels.weepee.org not found: 3(NXDOMAIN)
# host -t SRV _sip._udp.ssw3.brussels.weepee.org
Host _sip._udp.ssw3.brussels.weepee.org not found: 3(NXDOMAIN)
# host -t AAAA ssw3.brussels.weepee.org
# host -t A ssw3.brussels.weepee.org
ssw3.brussels.weepee.org has address 91.208.12.133

 

The record expires in approx. one hour, that all looks fine. The only problem that I would see with DNS is that you are using the router DNS server which does not support NAPTR or SRV or AAAA records, we have seen cases where this screwed up the DNS lookup. However because the first lookup is okay, this is probably not the problem.

 

You should also check if the router has some SIP awareness which might also screw it up.

 

if it all does not help, my recommendation would be to install a tool like Wireshark and run it when the PBX fails. You should see the DNS queries, the SIP queries and that should then help us to find out where the problem is.

Link to comment
Share on other sites

I am pretty sure that the problem has to do with your network setup, most probably with the router. If you have the chance to run the PBX behind another router, you should try this. Otherwise, you have to "prove" that the problem is with the network, and Wireshark is a good tool to do that.

Link to comment
Share on other sites

  • 3 weeks later...

Okay, at least we know that DNS is the problem here. If they change the IP address, you'll know pretty fast... Hopefully you remember that the neccessary change is the IP address.

 

Of couse it would be interesting to know why the DNS does not properly. IMHO it should not be a problem of the PBX, probably some problems with the interop of the next DNS relay server. We have to keep this in mind and if other people report similar problems, we have to see if we can change anything on the product side...

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.

×
×
  • Create New...