hmcap Posted July 6, 2011 Report Share Posted July 6, 2011 I'll post my question here and also in 'general', but I pretty desperate and don't know where to start. It happens after upgrading to 4.2.1.4025. First I had some problems with the caller-ID and now all my inbound trunks are not working. I've a DID via DIDWW, which is mapped to a voipcheap-trunk with a failover to a voipbuster-trunk. Since two days, it is not possible anymore to call our office. A long silence is heard. I than down=graded to x.x.x.3981 and it looks like the snom one was working again. Just for a few minutes and the office was not reacheable again. How to solve this? I don't know where to start looking, but it has to work. Regards, Harry Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted July 6, 2011 Report Share Posted July 6, 2011 Do you see anything in the LOG? Try turning on the log messages and then make an inbound call. If you see nothing at all, this will be most probably a problem with the firewall. If you do see traffic, dive into the log messages, for example maybe the way the number is presented does not match your extension naming any more. Sometimes the providers change the number presentation, and you could have this problem as well. Quote Link to comment Share on other sites More sharing options...
hmcap Posted July 6, 2011 Author Report Share Posted July 6, 2011 [8] 2011/07/06 18:04:04: DNS: Add SRV _sips._tcp.sip.voipcheap.com (ttl=60) [4] 2011/07/06 18:04:04: Could not find packet with number 261 [5] 2011/07/06 18:04:05: SIP Rx udp:ip:5060: REGISTER sip:server SIP/2.0 Via: SIP/2.0/UDP ip:5060;branch=z9hG4bK2b9c042c28709b9362bd516c5663fae0;rport From: "name" <sip:371@ip>;tag=1400395483 To: "name" <sip:371@ip> Call-ID: 2611753284@ip4 CSeq: 5856 REGISTER Contact: <sip:371@ip:5060> Max-Forwards: 70 User-Agent: A580 IP022230000000 Expires: 3600 Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 [5] 2011/07/06 18:04:05: SIP Tx udp:ip4:5060: SIP/2.0 200 Ok Via: SIP/2.0/UDP 192.168.178.4:5060;branch=z9hG4bK2b9c042c28709b9362bd516c5663fae0;rport=5060 From: "name" <sip:371@ip>;tag=1400395483 To: "name" <sip:371@ip>;tag=3942b0d123 Call-ID: 2611753284@ip CSeq: 5856 REGISTER Contact: <sip:371@ip:5060>;expires=359 Content-Length: 0 [5] 2011/07/06 18:04:25: SIP Rx tls:ip:3807: REGISTER sip:localhost SIP/2.0 Via: SIP/2.0/TLS ip:3807;branch=z9hG4bK-uls8ndemvpej;rport From: "name" <sip:300@localhost>;tag=1x5hfgqrvu To: "namen" <sip:300@localhost> Call-ID: 3770263cf216-q3qcpm0hwu0x CSeq: 45861 REGISTER Max-Forwards: 70 Contact: <sip:300@IP:3807;transport=tls;line=6qt0xsxs>;reg-id=1;q=1.0;+sip.instance="<urn:uuid:9946764b-eb87-4c38-a93b-a00c98fa2a33>" User-Agent: snom870/8.4.31 Allow-Events: dialog X-Real-IP: Supported: path, gruu Proxy-Require: buttons Expires: 3600 Content-Length: 0 Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted July 6, 2011 Report Share Posted July 6, 2011 Well, there is no INVITE coming in at all... So it must be something with the firewall I guess. Firewalls and NAT continue to be a pain in the neck when it comes to SIP, sorry for that. Also, it seems that your service provider does not provide the convenience of a session border controller to keep the connection alive or support something like outbound (which automatically set up STUN as a refresh method). A easy way to fix this is to set the "Keepalive Time" in the trunk to 20 seconds. Quote Link to comment Share on other sites More sharing options...
hmcap Posted July 6, 2011 Author Report Share Posted July 6, 2011 Well, there is no INVITE coming in at all... So it must be something with the firewall I guess. Firewalls and NAT continue to be a pain in the neck when it comes to SIP, sorry for that. Also, it seems that your service provider does not provide the convenience of a session border controller to keep the connection alive or support something like outbound (which automatically set up STUN as a refresh method). A easy way to fix this is to set the "Keepalive Time" in the trunk to 20 seconds. I checked the firewall; all sip traffic is passed. I only have problems with voipcheap & voipbuster trunks. Our trunk from callvoip is working (set to only inbound). I read that version 4.2.1.4025 that 'A false 200 OK (Trunk registration issue) occurred as a result of a glitch in the DNS interaction.' has been solved. I downgraded to x.x.x.3981 (mac OS X) because of no connection. Do I have to upgrade again? And how do you check whether the trunk registration is real? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted July 6, 2011 Report Share Posted July 6, 2011 I would just try to keep the trunk alive by forcing the PBX to re-register every 20 seconds. From what I saw about the provider, they expect the PBX to keep the connection alive. Quote Link to comment Share on other sites More sharing options...
hmcap Posted July 6, 2011 Author Report Share Posted July 6, 2011 I would just try to keep the trunk alive by forcing the PBX to re-register every 20 seconds. From what I saw about the provider, they expect the PBX to keep the connection alive. I don't get it. The connection (our DID mapped to voipcheap > which is a trunk in pbxnsip) is answering calls again. I did set the keep-alive-time to 20 seconds. So, would it be safe to upgrade to 4.2.1.4025? I still have some issues with the caller-id. The trunks voipcheap & voipbuster are showing the ANI I put in the trunk and using RFC3325 (P-asserted-ID) and it shows the ANI I wanted to show. But another trunk from the same company with the same settings is showing 'Blocked' or 'Unknown" Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted July 6, 2011 Report Share Posted July 6, 2011 Most service providers use other service providers to terminate their traffic, and the routing can be really unpredictable. So they might not have it in their hands on how exactly the caller-ID is being presented. Especially if they dont use SBC (instead use SIP proxy model), it is practically impossible to keep this 100 % under control. Keep the 20 secs for some time until the dust settles. This is something that should not hurt, except for generating higher traffic. Later you can try to slow it down or seek other ways to keep the connection alive (e.g. put the trunk on a public IP address). Quote Link to comment Share on other sites More sharing options...
hmcap Posted July 6, 2011 Author Report Share Posted July 6, 2011 Most service providers use other service providers to terminate their traffic, and the routing can be really unpredictable. So they might not have it in their hands on how exactly the caller-ID is being presented. Especially if they dont use SBC (instead use SIP proxy model), it is practically impossible to keep this 100 % under control. Keep the 20 secs for some time until the dust settles. This is something that should not hurt, except for generating higher traffic. Later you can try to slow it down or seek other ways to keep the connection alive (e.g. put the trunk on a public IP address). OK. Thanks. I wait and see what happens. Remains one thing; yes or no upgrading to the latest version? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted July 6, 2011 Report Share Posted July 6, 2011 I would make a backup of the PBX directory and upgrade to the latest release at a time when there are not too many calls going on. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.