SIP trunk between two Asterisk servers with same extensions

Asterisk Asterisk SIP
1

Hi,

I have set up a SIP trunk between two Asterisk servers, asterisk1 and asterisk2.
asterisk1 uses PJSIP and asterisk2 uses SIP. The trunk is set up without registration. Both Asterisk servers use the same extension number range, for example 11XX. I can successfully dial from one to another, the problem is when I dial from an extension on asterisk1 that is already present in the configuration of asterisk2 to an extension on asterisk2 I get an error.

2

This isn’t to do with the dialable extensions, I’m going to take it you have the endpoints named after the extensions they are mapped to? So 1111 is both an extension and endpoint? You’re running into it not authing the endpoints right. If 1111 on asterisk1 calls 1115 on asterisk2, asterisk2 is going to challenge 1111 for the INVITE and expect the response to match its 1111 endpoint not asterisk1’s 1111.

We would need to see an actual SIP trace to validate but I’m pretty sure that is what is going on.

3

Do one of:

  • change the endpoint names (which has security advantages, but makes dialplans more complex;

  • manipulate the caller IDs to include the routing digits; or

  • with PJSIP, I believe you can change the match priorities, so that IP address matches are preferred over name matches.

4

I made this work with 2 ways:

  1. On asterisk2 I set the extensions type to peer instead of friend.
    or
  2. On asterisk1 I manipulated the CallerID of the caller to include the routing digits.
Set(CALLERID(num)=8${CALLERID(num)})

I think the second method is more clean and functionable as the callee can dial back the caller.

5

I don’t think I fully understand your question, but possibly the switch => functionality in chan_iax2 might do exactly what you were looking for.

IAX2 tends to be a better protocol for trunking between Asterisk than SIP. Much easier to configure too.

6

he meant the same extension numbers, for unrelated devices, not so much as intentia design, but the de facto implementation, which means that, if you don’t manipulate caller ID, the From user matches the names of devices on the other machine, so, rather than assuming the call is coming from the trunk, it assumes it is coming from one of its local devices and tries to authenticate it as though it came from that device.

7

So if he used IAX2, he wouldn’t have that problem at all, and wouldn’t need to resort to a hacky workaround then.

8

Hacky is relative. It’s working perfectly fine for the individual now, and is a supported configuration.

9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.