Jump to content

Cross domain calling


CarlH
 Share

Recommended Posts

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

Link to comment
Share on other sites

  • Replies 51
  • Created
  • Last Reply

Top Posters In This Topic

  • 1 month later...

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 3 months later...
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.

Link to comment
Share on other sites

  • 1 month later...
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.

Link to comment
Share on other sites

  • 2 weeks later...
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

Link to comment
Share on other sites

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").

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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"

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

  • 2 months later...

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

Link to comment
Share on other sites

  • 2 months later...
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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

  • 6 months later...

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.

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.

Loading...
 Share




×
×
  • Create New...