Jump to content

interdomain calls


ndemou

Recommended Posts

I have a pbxnsip server with a trunk to an opensips server that routes outgoing calls. My problem is with calls from an extension of domain #A to a DDI of another domain. I know that using the "try loopback" option is discouraged for big installations so I've asked the admin of the opensips server to return such calls back to the PBX (based on the DDI). He tried two diferent methods but both fail:

 

Method #1: when ever an INVITE was send to the opensips server it was sending an INVITE back (with the same callid).

The pbx was rejecting such calls with a 404 message and the logs were showing something like this:

[8] 20131120114754: Call from a loopback trunk
[8] 20131120114754: To is "+30...413" <sip:+30...413@OPENSIPS_IP>, user 0, domain 0
[8] 20131120114754: Loopback: Set the To domain to
[2] 20131120114754: Call Reject: Could not identify domain for the call 268
[8] 20131120114754: call port 268: state code from 0 to 404

 

 

Method #2: when ever an INVITE was send to the opensips server it was sending back a "sip 300 Redirect" like this:

SIP/2.0 302 Redirect.
Via: SIP/2.0/UDP PBX_IP:5060;received=PBX_IP;branch=z9hG4bK-8bf3d340064f61553b7fee6dcb923aa8;rport=5060.
From: "Nick Dimou" <sip:...008@CALLER_DOMAIN;user=phone>;tag=21467714.
To: <sip:30...413@OPENSIPS_IP>;tag=f3f1ee7ec5dd7a1cc344ff92df241132.1ea1.
Call-ID: 5979c504@pbx.
CSeq: 23611 INVITE.
Contact: <sip:+30...413@PBX_IP:5060>, <sip:+302113114413@PBX_IP:5060>.
Server: OPENSIPS Proxy.
Content-Length: 0.

 

 

The pbx is ACKing this Redirects but then does something strange: The caller sees his extension on the display and the logs seem to suggest that the pbx is trying to call CallerExtension@PbxIp. See bellow (8 is the extension number of the caller)

 

[5] 20131120194231: INVITE Response 302 Redirect: Terminate 946bc46e@pbx
[8] 20131120194231: Clearing call port 28, SIP call id 946bc46e@pbx
...

[8] 20131120194231: Hangup: Call 28 not found

[8] 20131120194231: Clearing call port 27, SIP call id 1006061914@10.1.11.40
[8] 20131120194231: Remove leg 254771: call port 27, SIP call id 1006061914@10.1.11.40

[8] 20131120194232: Allocating for call port 29, SIP call id 1006061914@10.1.11.40
[8] 20131120194232: Could not find a trunk (41 trunks)
[8] 20131120194232: Using outbound proxy sip:85.74.237.7:40394;transport=udp because UDP packet source did not match the via header
[8] 20131120194232: Tagging request with existing tag
[7] 20131120194232: Set packet length to 20
[6] 20131120194232: Call-leg 29: Sending RTP for 1006061914@10.1.11.40 to 10.1.11.40:11782, codec not set yet
[8] 20131120194232: Incoming call: Request URI sip:8@PBX_IP:5060, To is <sip:8@PBX_IP:5060>
[8] 20131120194232: Call from an user 8
[8] 20131120194232: To is <sip:8@PBX_IP:5060>, user 0, domain 335
[8] 20131120194232: From user 8
[8] 20131120194232: Set the To domain based on From user 8@CALLER-DOMAIN
[8] 20131120194232: Call state for call object 115753: idle
[7] 20131120194232: Call port 29: set_codecs for 1006061914@10.1.11.40 codecs "", codec_preference count 7
[5] 20131120194232: Dialplan g_Default_CT: 8@PBX_IP is not allowed
[5] 20131120194232: Destination is forbidden

 

Any ideas about what should a working setup be like? I'll need to make this work in both versions 4 and 5.

 

Nick

Link to comment
Share on other sites

First if all make sure that you have the loopback detection turned off (admin/SIP settings). Then the PBX can accept calls with the same Call-ID and uses the tags in the From/To-header to differentiate between the calls.

 

The PBX needs a clear indication in which domain the calls should happen. Ideally, the SIP URI contains the phone number to be called in the domain starting with a + and then at least 6 digits. It must also contain the domain name.

 

Redirect is a bad idea. This is ending in a SIP RFC massacre that has interesting challenges, but just just costing us all a lot of time for troubleshooting tricky problems.

Link to comment
Share on other sites

Thanks for the prompt reply!

Yes, loopback detection is indeed turned off.

Regarding this point

The PBX needs a clear indication in which domain the calls should happen. Ideally, the SIP URI contains the phone number to be called in the domain starting with a + and then at least 6 digits. It must also contain the domain name.

 

 

The SIP URI is like this (1.2.3.4 is the IP of the pbx -- there is no reference to the callee domain as it is not known to either the caller or the opensips server):

INVITE sip:+30123456789@1.2.3.4 SIP/2.0.

I will make more tests and come back to you with a trace

Link to comment
Share on other sites

Alternatively you can use a trunk and make sure that it is a global trunk (allowed to send calls into every domain). Then the PBX will look for the +30123456789 in all domains.

 

That's how we do it.

 

PS

I'm waiting for the opensips admin to try and configure it so that it's sending the call back with a different from tag as per your suggestion and will report if that fixes my problem

Link to comment
Share on other sites

Hello,

 

I am a collegue of Nick. We want those kind of calls to be handled by the Snomone only (with the "loopback detection" option turned off). We don't want the calls to be routed to a sip proxy.. Is this possible? Can you please suggest a configuration (for instance a new dial plan)?

 

To be more specific: extension 120 from the domain 112310.z3.vpbx.gr is trying to call the DID +302109558300. This DID is assigned to extension 340, which is at the domain 115396.z3.vpbx.gr. Can you please suggest a dial plan rule for this interdomain call?

 

John.

Link to comment
Share on other sites

...the PBX can accept calls with the same Call-ID and uses the tags in the From/To-header to differentiate between the calls...

 

 

... I'm waiting for the opensips admin to try and configure it so that it's sending the call back with a different from tag as per your suggestion...

 

Τhe opensips admin told as that returning an INVITE with diferent From/To tags is possible but requires extensive changes so if you have any other ideas that might be easier to implement we'll be glad to read them

Link to comment
Share on other sites

You don't need to change anything with opensips. The PBX sends out a request with the from-header tag when receives it sets it own to-tag, so that it can determine which calls is being addressed.

 

The dial plan should just use a gateway trunk pointing to the SIP proxy. This trunk must be a global trunk. In the dial plan don't use the try loopback, just use that global trunk.

Link to comment
Share on other sites

The setup your're describing is what we've tried first. I'm sorry if I wasn't clear enough before. I'll try to be more detailed this time (excuse me if I'm too detailed :-)

 

THE BASICS OF OUR SETUP

 

We have two domains dom1 and dom2.

We have an extension "extA@dom1" and an extension "extB@dom2".

extB@dom2 has DDI +30222222

We have a trunk "trnkOS". It is connecting the PBX to OpenSips and it's both for incoming and outgoing calls.

We have a global dial plan "dialplanOS" that sends calls via trnkOS

 

WHAT WORKS

 

Calls from the outside world to +30222222 reach OpenSips and are successfully connected via trnkOS to extB@dom2

Calls from extA@dom1 to the outside world are send from dialplanOS to trnkOS and are also successfully connected.

 

WHAT DOESN'T WORK

 

Calls from extA@dom1 to +30222222 fail. Details regarding the failure follow:

 

Suppose that extA@dom1 is dialing 30222222. dialplanOS sends this call to trnkOS so an INVITE for sip:+30222222@OPENSIPS-IP is send to OpenSips. This INVITE seems OK (it has proper From, To and the correct SIP URI in INVITE). OpenSips knows that +30222222 is to be found at the PBX so it sends an INVITE back to the PBX with a SIP URI +30222222@PBX-IP. Note that this INVITE has the same From,To and CallID headers. The PBX is rejecting that last INVITE with a 404 message and the logs are showing something like this:

 

[8] 20131120114754: Call from a loopback trunk

[8] 20131120114754: To is "+30222222" <sip:+30222222@OPENSIPS_IP>, user 0, domain 0
[8] 20131120114754: Loopback: Set the To domain to
[2] 20131120114754: Call Reject: Could not identify domain for the call 268
[8] 20131120114754: call port 268: state code from 0 to 404

 

Finally we do have the loopback detection turned off at admin/SIP settings.

Link to comment
Share on other sites

  • 4 weeks later...

Ndemou, John.

 

Indeed, there are some serious issues with inter-domain calling in 5.1.2 / 5.1.3

 

We don't have any issues with 5.1.1 (loopback works fine), but we could not make it work in the latest releases (with exactly the same config)

 

My recommendation is to try with 5.1.1.

 

Vodia guys don't like to accept the idea that they broke something recently.

Link to comment
Share on other sites

Let me clarify something that might is causing some confusion.

 

When you choose "try loopback" in the dial plan and the PBX has a number that matches the destination, it will send the request on the loopback interface of the system (typically 127.0.0.1 or ::1). In this case you still need to have a inbound trunk that takes traffic from 127.0.0.1 or ::1 (explicitly specify the address in the trunk).

 

The loopback detection is about detecting calls that have the same call-ID. It does not matter if the "loop" goes through the loopback interface of the PBX or through an external proxy. If you are using an external proxy you can use a gateway trunk to tell the PBX that the traffic from the proxy IP address should be landing on the trunk.

 

It is right now difficult for me (Christmas travelling) to try the loopback trunk setup. We probably have to do this after the holidays. 5.1.3 does change a couple of things in the routing. I would not say it broke something; it probably fixed a bug that was previously allowing calls to happen that should not happen -_- .

Link to comment
Share on other sites

  • 3 weeks later...

Okay, we have tested a loopback call in 5.1.3. It worked... In any case, we needed to have the country code set to make sure that all numbers internally start with +. And loopback detection was set to "off".

 

When the test setup was using "try loopback" in the dial plan, it worked right out of the box.

 

When using a trunk (which we looped back through 127.0.0.1 because we did not have an external proxy) we needed to make sure that the number was presented in the +-format. Then it also worked.

Link to comment
Share on other sites

  • 3 weeks later...

Hi,

 

I am trying to replicate this scenario, because I also need to do some inter domain calling but I am getting the "Temporarily Unavailable" error message,

 

In order not to affect current active users, I set two "test" domains, each with only one extension with a 10 digit DID,

 

Following what I understood from this thread, the following is my checklist:

 

1) Loop back detection is set to off in sip settings

2) Both domains have a Sip Gateway trunk with the proxy address of 127.0.0.1. In both cases, the trunk is Global and set to send calls to the Request Address in the URI

3) Both domains have a dial plan where Try Loopback is the highest priority trunk with "*" in both fields

4) Both domains have the country code set

 

In the log file, I can see that the system does find the right extension (thanks to the DID) and it seems to be sent through 127.0.0.1, However, I only get the Temporarily Unavailable message.

 

What am I missing?

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