Juan Manuel Acevedo Posted August 6, 2009 Report Share Posted August 6, 2009 The best solution for large system is to use a SIP proxy to route the calls between the domains and the other destinations. The dial plan will then become pretty simple--just send everything to the proxy. The proxy then has to make the decision if the call should be routed to a PBX or to the PSTN gateway (whatever that is). In this setup, you need to turn off loopback detection; because it is perfectly legal that one domain calls another on the same system. Hi: I had the same problem and I have found that the best way to do inter-domain calls is: 1. Define all dial planas as "global" 3. Insert in such dial plans one entry, as the first of the table, with the option "Try Loopback" and * as Pattern and Replacement (both) 4. Set OFF the option "Loopback detection" as a global set. All calls between domains will occur. Juan Acevedo consultorit@umi.com.co Quote Link to comment Share on other sites More sharing options...
pbxuser911 Posted August 7, 2009 Report Share Posted August 7, 2009 lets say you call a DID in another domain and then reach someones endpoint (phone), what does the other person you call see who is calling them? your ANI or your EXTention number? Quote Link to comment Share on other sites More sharing options...
maslym Posted August 10, 2009 Report Share Posted August 10, 2009 lets say you call a DID in another domain and then reach someones endpoint (phone), what does the other person you call see who is calling them? your ANI or your EXTention number? The other person I call sees my ANI. Quote Link to comment Share on other sites More sharing options...
olecoot Posted October 1, 2009 Report Share Posted October 1, 2009 The problems with cross domain or inter-domain dialing seems to still (at least for me) be in version 3.4.0.3201 (Linux). My scenario: We host multiple domains on our servers. Each domain has it's own set of trunks, some with many trunks, some with few. None of the dial plans are global. Loopback detection is set to off. I have followed the suggestions in the forums and in the knowledge base to use "Try Loopback" in the dial plan. They don't seem to work in my case. Is there anyone who has a scenario close to what we have that is able to call from domain to domain on the same physical server? If you have, does someone care to enlighten me on how it's done? Thanks in advance Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted October 2, 2009 Report Share Posted October 2, 2009 The best way to deal with this is still to use an external (stateless) proxy or gateway that receives all traffic, no matter if it later will terminate in the PSTN or on the same server. That is a "idiot proof" way of dealing with the problem. The loopback is a hack that tries to get installations going where something external is not an option. Loopback still has issues with the ANI presentation. Quote Link to comment Share on other sites More sharing options...
pbxuser911 Posted October 2, 2009 Report Share Posted October 2, 2009 can you post some exact instructions on how to set this up? im sure it is much better to keep the traffic within the server rather then terminating with another carrier Quote Link to comment Share on other sites More sharing options...
olecoot Posted October 2, 2009 Report Share Posted October 2, 2009 The best way to deal with this is still to use an external (stateless) proxy or gateway that receives all traffic, no matter if it later will terminate in the PSTN or on the same server. That is a "idiot proof" way of dealing with the problem. The loopback is a hack that tries to get installations going where something external is not an option. Loopback still has issues with the ANI presentation. We use that very scenario, a stateless proxy where all calls go. It is when the proxy sends the INVITE back to the originating PBX to a domain on the same PBX the call does not complete. From PBXnSIP logs when making a domain-to-domain call on same server: [9] 20091002073424: UDP: Opening socket on 0.0.0.0:53238 [9] 20091002073424: UDP: Opening socket on 0.0.0.0:53239 [8] 20091002073424: Could not find a trunk (4 trunks) [9] 20091002073424: Resolve 8664: aaaa udp 10.1.1.110 5060 [9] 20091002073424: Resolve 8664: a udp 10.1.1.110 5060 [9] 20091002073424: Resolve 8664: udp 10.1.1.110 5060 [6] 20091002073424: Sending RTP for 61ffb548-b9af7923-fe7b9e36@10.1.1.110#7170d387ad to 10.1.1.110:2264 [9] 20091002073424: Resolve 8665: url sip:300@10.1.1.110:5060 [9] 20091002073424: Resolve 8665: udp 10.1.1.110 5060 [9] 20091002073424: Resolve 8666: url sip:501@10.1.1.204:5060 [9] 20091002073424: Resolve 8666: udp 10.1.1.204 5060 [8] 20091002073424: Play audio_moh/noise.wav [9] 20091002073424: UDP: Opening socket on 0.0.0.0:51858 [9] 20091002073424: UDP: Opening socket on 0.0.0.0:51859 [9] 20091002073424: Resolve 8667: url sip:<PROXY_DOMAIN_NAME> [9] 20091002073424: Resolve 8667: naptr <PROXY_DOMAIN_NAME> [9] 20091002073424: Resolve 8667: srv udp _sip._udp.<PROXY_DOMAIN_NAME> [9] 20091002073424: Resolve 8667: a udp s-cscf-1.<PROXY_DOMAIN_NAME> 5060 [9] 20091002073424: Resolve 8667: udp <PROXY_IP_ADDRESS> 5060 [5] 20091002073424: UDP: recvfrom returns EAGAIN [6] 20091002073424: Send codec pcmu/8000 [9] 20091002073424: Resolve 8668: aaaa udp 10.1.1.110 5060 [9] 20091002073424: Resolve 8668: a udp 10.1.1.110 5060 [9] 20091002073424: Resolve 8668: udp 10.1.1.110 5060 [8] 20091002073424: Answer challenge with username <CALLING_NUMBER> [9] 20091002073424: Resolve 8669: udp <PROXY_IP_ADDRESS> 5060 udp:1 [9] 20091002073424: Resolve 8670: udp <PROXY_IP_ADDRESS> 5060 udp:1 [9] 20091002073424: Message repetition, packet dropped [5] 20091002073424: Received loopback request without tag [9] 20091002073424: UDP: Opening socket on 0.0.0.0:60038 [9] 20091002073424: UDP: Opening socket on 0.0.0.0:60039 [9] 20091002073424: Resolve 8671: aaaa udp <PROXY_IP_ADDRESS> 5060 [9] 20091002073424: Resolve 8671: a udp <PROXY_IP_ADDRESS> 5060 [9] 20091002073424: Resolve 8671: udp <PROXY_IP_ADDRESS> 5060 [6] 20091002073424: Sending RTP for 14bd5521@pbx#6b2fc5212a to <PBX_IP_ADDRESS>:51858 [5] 20091002073424: Received incoming call without trunk information and user has not been found [9] 20091002073424: Resolve 8672: aaaa udp <PROXY_IP_ADDRESS> 5060 [9] 20091002073424: Resolve 8672: a udp <PROXY_IP_ADDRESS> 5060 [9] 20091002073424: Resolve 8672: udp <PROXY_IP_ADDRESS> 5060 [9] 20091002073424: Resolve 8673: aaaa udp <PROXY_IP_ADDRESS> 5060 [9] 20091002073424: Resolve 8673: a udp <PROXY_IP_ADDRESS> 5060 [9] 20091002073424: Resolve 8673: udp <PROXY_IP_ADDRESS> 5060 [7] 20091002073424: Other Ports: 2 [7] 20091002073424: Call Port: 14bd5521@pbx#138323889 [7] 20091002073424: Call Port: 61ffb548-b9af7923-fe7b9e36@10.1.1.110#7170d387ad [7] 20091002073424: Call 14bd5521@pbx#138323889: Clear last INVITE [9] 20091002073424: Resolve 8674: url sip:<PROXY_DOMAIN_NAME> [9] 20091002073424: Resolve 8674: naptr <PROXY_DOMAIN_NAME> [9] 20091002073424: Resolve 8674: srv udp _sip._udp.<PROXY_DOMAIN_NAME> [9] 20091002073424: Resolve 8674: a udp s-cscf-2.<PROXY_DOMAIN_NAME> 5060 [9] 20091002073424: Resolve 8674: udp <PROXY_IP_ADDRESS> 5060 [5] 20091002073424: INVITE Response 404 Not Found: Terminate 14bd5521@pbx [7] 20091002073424: Other Ports: 1 [7] 20091002073424: Call Port: 61ffb548-b9af7923-fe7b9e36@10.1.1.110#7170d387ad [9] 20091002073424: Message repetition, packet dropped [9] 20091002073424: Resolve 8675: aaaa udp 10.1.1.110 5060 [9] 20091002073424: Resolve 8675: a udp 10.1.1.110 5060 [9] 20091002073424: Resolve 8675: udp 10.1.1.110 5060 [9] 20091002073424: Resolve 8676: url sip:300@10.1.1.110:5060 [9] 20091002073424: Resolve 8676: udp 10.1.1.110 5060 [9] 20091002073424: Resolve 8677: url sip:501@10.1.1.204:5060 [9] 20091002073424: Resolve 8677: udp 10.1.1.204 5060 [9] 20091002073424: Resolve 8678: aaaa udp 10.1.1.110 5060 [9] 20091002073424: Resolve 8678: a udp 10.1.1.110 5060 [9] 20091002073424: Resolve 8678: udp 10.1.1.110 5060 Quote Link to comment Share on other sites More sharing options...
olecoot Posted January 14, 2010 Report Share Posted January 14, 2010 can you post some exact instructions on how to set this up?im sure it is much better to keep the traffic within the server rather then terminating with another carrier To PBXnSIP: To resurrect an old issue .... Has there been an advancement in this scenario? The issue is still not fixed. We have just installed version 3.5 (Linux) and we use a stateless soft switch and cannot dial domain to domain on the same server. Our soft switches do not manipulate packets to or from the PBX. They are true proxies. Step-by-step detailed instructions would be much appreciated. Again, our situation is a hosted environment, where we have servers with MANY domains and MANY trunks per domain on the same machine. Every build after 3.1 has had the issue. It is becoming very frustrating! We are a large provider using your product. Many of our customers make calls between themselves and we have reached a point where we are beginning to move customer domains to other servers so that our customers can call each other. Obviously this is not a scalable solution. This has to be addressed in the 3.5 branch. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted February 23, 2010 Report Share Posted February 23, 2010 I quickly tested this loopback scenario again (using the latest and greatest 4.0.1.3424, let me know if you need a build/OS). The PBX blocks the loop request if the "detect loopback" is on, once it is turned off it is working as it should. Quote Link to comment Share on other sites More sharing options...
olecoot Posted February 23, 2010 Report Share Posted February 23, 2010 I quickly tested this loopback scenario again (using the latest and greatest 4.0.1.3424, let me know if you need a build/OS). The PBX blocks the loop request if the "detect loopback" is on, once it is turned off it is working as it should. So continuing development on 3.x is not happening? We would prefer a fix be included in 3.x development strain. Is this at all possible? When do you expect 4.x to go GA? For the sake of testing, please provide the link to a CentOS 5 version of 4.x. We will provide critical feedback. Quote Link to comment Share on other sites More sharing options...
maslym Posted March 9, 2010 Report Share Posted March 9, 2010 I quickly tested this loopback scenario again (using the latest and greatest 4.0.1.3424, let me know if you need a build/OS). The PBX blocks the loop request if the "detect loopback" is on, once it is turned off it is working as it should. I tried the latest 4.0.1.3433 on CentOS 5.3 and still got the same problem on cross domain calling. I tried to turn the "detect loopback" on and off and it didn't make any difference. I still got following error message as found in version 3.x. [5] 2010/03/08 16:09:52: Received loopback request without tag [5] 2010/03/08 16:09:52: Received incoming call without trunk information and user has not been found [5] 2010/03/08 16:09:57: Call 2ab08296@pbx#625927210: Last request not finished [5] 2010/03/08 16:09:57: BYE Response: Terminate 2ab08296@pbx Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted March 9, 2010 Report Share Posted March 9, 2010 Well, that's your problem now: "Received incoming call without trunk information and user has not been found". That means you must have a trunk that accepts traffic from 127.0.0.1 (or ::1 in IPv6). In V4, you can explicitly put the 127.0.0.1 into the trunk now (at the bottom, "Explicitly list addresses for inbound traffic"). Quote Link to comment Share on other sites More sharing options...
maslym Posted March 9, 2010 Report Share Posted March 9, 2010 Well, that's your problem now: "Received incoming call without trunk information and user has not been found". That means you must have a trunk that accepts traffic from 127.0.0.1 (or ::1 in IPv6). In V4, you can explicitly put the 127.0.0.1 into the trunk now (at the bottom, "Explicitly list addresses for inbound traffic"). Okay, I did that by putting 127.0.0.1 into the trunk and it didn't make any difference. I still got the same error messages in the logfile and the call still didn't go through. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted March 9, 2010 Report Share Posted March 9, 2010 Is that a trunk that is either inbound or inbound/outbound? When you are using the outbound proxy and don't use the field "Explicitly list addresses for inbound traffic" then the transport layer does matter. The best would be if you put "127.0.0.1" into the "Explicitly list addresses for inbound traffic" setting of the trunk and make it "inbound". Of course, use 127.0.0.1 only of the packet is actually received over the loopback device. Maybe just add the IP address of the server there as well, e.g. "127.0.0.1 10.1.1.110" if "10.1.1.110" if the IP address of the PBX which is used for sending the request out. If you are using a SIP proxy, put the address of the SIP proxy there. Whereever the looped request is coming from" Quote Link to comment Share on other sites More sharing options...
maslym Posted March 9, 2010 Report Share Posted March 9, 2010 Is that a trunk that is either inbound or inbound/outbound? When you are using the outbound proxy and don't use the field "Explicitly list addresses for inbound traffic" then the transport layer does matter. The best would be if you put "127.0.0.1" into the "Explicitly list addresses for inbound traffic" setting of the trunk and make it "inbound". Of course, use 127.0.0.1 only of the packet is actually received over the loopback device. Maybe just add the IP address of the server there as well, e.g. "127.0.0.1 10.1.1.110" if "10.1.1.110" if the IP address of the PBX which is used for sending the request out. If you are using a SIP proxy, put the address of the SIP proxy there. Whereever the looped request is coming from" Here is the test setup. I set up two domains on one server running 4.0.1.3433 on CentOS 5.3. Each domain has a SIP Registration trunk and is registering to the SIP Proxy server. Since the server is behind the router, so the trunk is registering to the SIP proxy server through the outbound proxy. I tried to set up the trunk as Inbound only and put all the IP addresses related into the trunk such as 127.0.0.1, the private IP of the server, the public IP of the router, the IP of the SIP proxy server and the IP of the outbound proxy. Still the cross domain calling doesn't work. It was working before on version 2.x and stopped working since version 3.x. Quote Link to comment Share on other sites More sharing options...
pbx support Posted March 10, 2010 Report Share Posted March 10, 2010 Here is the test setup.I set up two domains on one server running 4.0.1.3433 on CentOS 5.3. Each domain has a SIP Registration trunk and is registering to the SIP Proxy server. Since the server is behind the router, so the trunk is registering to the SIP proxy server through the outbound proxy. I tried to set up the trunk as Inbound only and put all the IP addresses related into the trunk such as 127.0.0.1, the private IP of the server, the public IP of the router, the IP of the SIP proxy server and the IP of the outbound proxy. Still the cross domain calling doesn't work. It was working before on version 2.x and stopped working since version 3.x. Can we see the screen shot of the trunk? Quote Link to comment Share on other sites More sharing options...
maslym Posted March 10, 2010 Report Share Posted March 10, 2010 Can we see the screen shot of the trunk? Here is the screen shot of the trunk settings. Trunk_settings.pdf Quote Link to comment Share on other sites More sharing options...
maslym Posted May 14, 2010 Report Share Posted May 14, 2010 Hi pbxnsip support, Any update on this issue? I tried 4.0.1.3499 and still the call couldn't go through. And I got following error messages. [5] 2010/05/14 14:01:18: Received loopback request without tag [2] 2010/05/14 14:01:18: Call Reject: Could identify call domain Quote Link to comment Share on other sites More sharing options...
olecoot Posted August 13, 2010 Report Share Posted August 13, 2010 Hi pbxnsip support, Any update on this issue? I tried 4.0.1.3499 and still the call couldn't go through. And I got following error messages. [5] 2010/05/14 14:01:18: Received loopback request without tag [2] 2010/05/14 14:01:18: Call Reject: Could identify call domain Has there been a step-by-step write up of the procedure for getting inter-domain dialing to work properly in version 4.x? It would prove to be a lot less frustrating to set up. We've been battling the same issue since the release of 3.x. We currently host multiple domains with each domain having multiple trunks on a many servers. We really need to get this to work. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted August 15, 2010 Report Share Posted August 15, 2010 I think you definitevely have to use a newer version that 4.0.1. There were some problems with the loopback trunk that have been fixed meanwhile. Quote Link to comment Share on other sites More sharing options...
olecoot Posted August 16, 2010 Report Share Posted August 16, 2010 I think you definitevely have to use a newer version that 4.0.1. There were some problems with the loopback trunk that have been fixed meanwhile. I'm using what is available on the web site. Perhaps those links could be updated? Can you provide the link for a newer CentOS build? Quote Link to comment Share on other sites More sharing options...
maslym Posted February 23, 2011 Report Share Posted February 23, 2011 Hi Snom one/PBXnSIP support: New PBXnSIP release 4.2.0.3981 is supposed to fix this problem. But it doesn't. This time the error message is "No dial plan available". Hopefully someone from Snom one/PBXnSIP support can help us with it? Quote Link to comment Share on other sites More sharing options...
pbx support Posted February 23, 2011 Report Share Posted February 23, 2011 If the error is "No dial plan available", then check the account that is making the call to see if it really has a dial plan assigned. Quote Link to comment Share on other sites More sharing options...
maslym Posted February 24, 2011 Report Share Posted February 24, 2011 If the error is "No dial plan available", then check the account that is making the call to see if it really has a dial plan assigned. The account has the dial plan assigned and it could make outbound calls. It just couldn't call any DID in another domain on the same PBXnSIP server. Thank you. Quote Link to comment Share on other sites More sharing options...
pbx support Posted February 24, 2011 Report Share Posted February 24, 2011 That is strange. If the extension has a dial plan, we should not have seen that error message. Even if did not have a dialplan, then domain default dial plan should have kicked in. Anyways, can you PM the log (with log level 9 & SIP logging turned ON) for just 1 such call? 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.