Jump to content

Calls Routing/Redirection


Kostya

Recommended Posts

Hi all

 

I have 5.0.10a (CentOS64);

I use the same ITSP, which provides two differend DID. One DID I setup for Auto Attendant, onether one is for specific extention for my boss.

 

I setup two trunks as SIP Gateway for different DID: one of them is routed to Auto Attendant account (Defa account); another one is routed to the boss extention.

 

The first trunk (with the first DID) is working well with Auto Attendant extention. However, when I enable the second trunk, the first one stops working and all the inbound calls are forwarded to the second extention.

 

Please explain me what is wrong and where can I learn how to setup two different DID (from the same ITSP),which have to be routed to different extentions.

 

Thank you.

Link to comment
Share on other sites

If you use two gateway trunks, the PBX somehow needs to figure out to which trunk incoming calls belong. If they are coming from the IP address, this will not help.

 

What helps is setting the account name of the trunk to what the provider sends when using the trunk. If there is a match, the PBX will find the right trunk even if there are several trunks that receive traffic from the same IP.

Link to comment
Share on other sites

  • 4 weeks later...

I'm having exactly the same problem. I'm using two SIP Registration trunks from the same ISP (Vitelity). Could you please elaborate on what you mean by the "account name of the trunk being what the provider sends when using the trunk"? If my SIP invite looks like below, exactly what field in the trunk configuration should contain exactly what value to make this work? (I've replaced some data with xxx.) The only value that differs when I call different numbers on the ISP is the xxxx431160 portion of the INVITE or the To: line, but putting xxxx431160 as the name for the trunk did not work.

 

INVITE sip:xxxx431160@24.xxx.24.238:5060 SIP/2.0
Via: SIP/2.0/UDP 66.241.99.28:5060;branch=z9hG4bK6684f64f;rport
From: "XXXX DALE" <sip:xxxx606310@66.241.99.28>;tag=as60252cef
To: <sip:xxxx431160@24.xxx.24.238:5060>
Contact: <sip:xxxx606310@66.241.99.28>
Call-ID: 552d1e4412f59c7d4d2787c417517bc4@66.241.99.28
CSeq: 102 INVITE
User-Agent: packetrino
Max-Forwards: 70
Date: Mon, 22 Jul 2013 17:38:26 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Content-Type: application/sdp
Content-Length: 334

Link to comment
Share on other sites

Just for the record, "packetrino" is not SIP complaint if it deliberately decides to throw away the line parameter that was present during the registration. But we know that such complaints are easily overheared by equipment manufacturers and don't help solving the problem :angry: .

 

As long if both trunks are in the same domain, does it matter which trunk the PBX will pick? Usually you can set up a rule for sending the call to the right destination that applies to both trunks and then you don't have to care. You can do this by giving accounts in the domain additional names that match the numbers that are being called.

Link to comment
Share on other sites

It does matter which trunk is selected because one trunk is for the main number that goes to the receptionist and the other is for the back office that goes to a different station. I can change the account names at Vitelity, but, sorry, I'm still a bit fuzzy regarding exactly what you mean by "giving accounts in the domain additional names that match the numbers being called." As you can see the incoming invite and To: show the number that was called, but how do I get the PBX to select the right trunk? What, exactly, would you recommend I put in which field of the trunk configuration to get the PBX to match the right trunk? That is, what rule can I configure to make this work? If you could give a specific example based on the INVITE message above that would be very helpful. Thanks.

Link to comment
Share on other sites

My point was: The PBX might confuse which trunk it actually is; but if you use the same rules for determining the destination based on the Request-URI or on the To-header, you can still route it to the right destination. Just make the routing dependent on the Request-URI, not dependent on the trunk. That implies that the routing rules for both trunks must be the same.

Link to comment
Share on other sites

I think I understand what you are saying, but, being new to SNOM ONE, I don't know how to implement what you suggest. How, in the SNOM ONE gui, do I create the rules in the PBX that will route to different extensions based on the Request-URI or To-header?

Link to comment
Share on other sites

In version 5 (5.1 just released today) it is actually quite simple.

  • If you are in the US/Canada, first of all set the country code in the domain settings to "1".
  • In the trunk select "Routing/Redirection", then "Destination for incoming calls". Then select on the trunks "send to 10-digit DID". Source for caller-ID just leave it to Request-URI.
  • Then make sure that your accounts have your DID names set up. For that, set the "Account number(s)" to something like "40 8123245445" if 8123245445 is the DID that should be linked with the extension 40. You can also add more than one, e.g. "40 8123245445 8123245446".
Link to comment
Share on other sites

  • 4 years later...

I have a similar problem to the one discussed above.

I need to differentiate between calls coming in on two trunks to the same provider (Twilio). One trunk as defined on the Twilio side enforces TLS at extra cost, but I don't want all incoming calls from Twilio to go via this trunk.

Is there a way that I can make the PBX route Invites like the two below to different trunks?

Invite version 1 (I want this to go to the first trunk):
 

Quote

 

INVITE sip:+4xxxxxxx1908@YY.ZZ.99.123 SIP/2.0
Record-Route: <sip:54.171.127.192:5060;lr;ftag=62103213_6772d868_bb1c95c2-3144-4e70-a476-d42f0f970ff7>
Max-Forwards: 17
From: <sip:+11234567890@imp.pstn.twilio.com>;tag=62103213_6772d868_bb1c95c2-3144-4e70-a476-d42f0f970ff7
To: <sip:+4xxxxxxx1908@YY.ZZ.99.123;user=phone>
CSeq: 102 INVITE
Date: Wed, 31 Jan 2018 06:00:58 GMT
P-Asserted-Identity: <sip:+11234567890@10.41.27.13;user=phone>
Diversion: <sip:+4xxxxxxx1908@public-vip.ie1.twilio.com>;reason=unconditional
Call-ID: 8e10d24703ba26d98b9b01f25b9b21af@0.0.0.0
Via: SIP/2.0/UDP 54.171.127.192:5060;branch=z9hG4bK46f8.0e6eb963.0
Via: SIP/2.0/UDP 172.18.200.223:5060;rport=5060;received=172.18.200.223;branch=z9hG4bKbb1c95c2-3144-4e70-a476-d42f0f970ff7_6772d868_239-2322326987040813616
Contact: <sip:+11234567890@172.18.200.223:5060;transport=udp>
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE
User-Agent: Twilio Gateway
X-Twilio-AccountSid: ACd686a3ed4302bdf2710a152470c1f784
Content-Type: application/sdp
X-Twilio-CallSid: CAd5607e4384a06de577a9287c7856b152
Content-Length: 234

 

 

Invite version 2 (I want this to go to the second trunk)

Quote


INVITE sip:+4xxxxxxx1890@YY.ZZ.99.123 SIP/2.0
Record-Route: <sip:54.171.127.193:5060;lr;ftag=41806496_6772d868_121fab86-2cd0-40e4-ac41-4e49a738a7af>
Max-Forwards: 17
From: <sip:+11234567890@imp2.pstn.twilio.com>;tag=41806496_6772d868_121fab86-2cd0-40e4-ac41-4e49a738a7af
To: <sip:+4xxxxxxx1890@YY.ZZ.99.123;user=phone>
CSeq: 102 INVITE
Date: Wed, 31 Jan 2018 05:59:15 GMT
P-Asserted-Identity: <sip:+11234567890@10.41.27.13;user=phone>
Diversion: <sip:+4xxxxxxx1890@public-vip.ie1.twilio.com>;reason=unconditional
Call-ID: 94fec472857dc4655684f999ea503326@0.0.0.0
Via: SIP/2.0/UDP 54.171.127.193:5060;branch=z9hG4bKaa2.5b5bc56.0
Via: SIP/2.0/UDP 172.18.198.129:5060;rport=5060;received=172.18.198.129;branch=z9hG4bK121fab86-2cd0-40e4-ac41-4e49a738a7af_6772d868_291-4899177849831067392
Contact: <sip:+11234567890@172.18.198.129:5060;transport=udp>
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE
User-Agent: Twilio Gateway
X-Twilio-AccountSid: ACd686a3ed4302bdf2710a152470c1f784
Content-Type: application/sdp
X-Twilio-CallSid: CA66db5e8d50d2417ebab867afa6408700
Content-Length: 238

 



  
Link to comment
Share on other sites

I think for incoming you can only accept the calls (there is no need to make a decision). For outbound, the dial plan determines what trunk should be used. The extended regular expressions are complex, but you should be able to handle all sorts of complex patterns with that and then send them to the right trunk.

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