Kostya Posted June 29, 2013 Report Share Posted June 29, 2013 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. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted June 29, 2013 Report Share Posted June 29, 2013 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. Quote Link to comment Share on other sites More sharing options...
Kostya Posted June 29, 2013 Author Report Share Posted June 29, 2013 Thank you. Quote Link to comment Share on other sites More sharing options...
Dale Posted July 22, 2013 Report Share Posted July 22, 2013 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.0Via: SIP/2.0/UDP 66.241.99.28:5060;branch=z9hG4bK6684f64f;rportFrom: "XXXX DALE" <sip:xxxx606310@66.241.99.28>;tag=as60252cefTo: <sip:xxxx431160@24.xxx.24.238:5060>Contact: <sip:xxxx606310@66.241.99.28>Call-ID: 552d1e4412f59c7d4d2787c417517bc4@66.241.99.28CSeq: 102 INVITEUser-Agent: packetrinoMax-Forwards: 70Date: Mon, 22 Jul 2013 17:38:26 GMTAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFOSupported: replacesContent-Type: application/sdpContent-Length: 334 Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted July 22, 2013 Report Share Posted July 22, 2013 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 . 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. Quote Link to comment Share on other sites More sharing options...
Dale Posted July 22, 2013 Report Share Posted July 22, 2013 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. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted July 23, 2013 Report Share Posted July 23, 2013 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. Quote Link to comment Share on other sites More sharing options...
Dale Posted July 23, 2013 Report Share Posted July 23, 2013 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? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted July 23, 2013 Report Share Posted July 23, 2013 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". Quote Link to comment Share on other sites More sharing options...
Dale Posted July 23, 2013 Report Share Posted July 23, 2013 Unfortunately, I'm not using 5.1. I'm using a SNOM ONE MINI running 4.5.1.1107. How do I do it with this release? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted July 23, 2013 Report Share Posted July 23, 2013 In the old versions, you have to use the extended regular expressions (the Javascript is just sitting on top of that). See http://wiki.snomone.com/index.php?title=Inbound_Calls for some examples. "!([0-9]{10})$!\1!u!700" should be close (if 700 is your default and you are looking at the request-URI header). Quote Link to comment Share on other sites More sharing options...
Dale Posted July 23, 2013 Report Share Posted July 23, 2013 Thanks. I was able to make it work by setting up DID names on the accounts and leaving the "route to extension" blank in the trunk configuration. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted July 24, 2013 Report Share Posted July 24, 2013 Thanks. I was able to make it work by setting up DID names on the accounts and leaving the "route to extension" blank in the trunk configuration. That also works. Quote Link to comment Share on other sites More sharing options...
cwernstedt Posted January 31, 2018 Report Share Posted January 31, 2018 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.0Record-Route: <sip:54.171.127.193:5060;lr;ftag=41806496_6772d868_121fab86-2cd0-40e4-ac41-4e49a738a7af>Max-Forwards: 17From: <sip:+11234567890@imp2.pstn.twilio.com>;tag=41806496_6772d868_121fab86-2cd0-40e4-ac41-4e49a738a7afTo: <sip:+4xxxxxxx1890@YY.ZZ.99.123;user=phone>CSeq: 102 INVITEDate: Wed, 31 Jan 2018 05:59:15 GMTP-Asserted-Identity: <sip:+11234567890@10.41.27.13;user=phone>Diversion: <sip:+4xxxxxxx1890@public-vip.ie1.twilio.com>;reason=unconditionalCall-ID: 94fec472857dc4655684f999ea503326@0.0.0.0Via: SIP/2.0/UDP 54.171.127.193:5060;branch=z9hG4bKaa2.5b5bc56.0Via: SIP/2.0/UDP 172.18.198.129:5060;rport=5060;received=172.18.198.129;branch=z9hG4bK121fab86-2cd0-40e4-ac41-4e49a738a7af_6772d868_291-4899177849831067392Contact: <sip:+11234567890@172.18.198.129:5060;transport=udp>Allow: INVITE,ACK,CANCEL,OPTIONS,BYEUser-Agent: Twilio GatewayX-Twilio-AccountSid: ACd686a3ed4302bdf2710a152470c1f784Content-Type: application/sdpX-Twilio-CallSid: CA66db5e8d50d2417ebab867afa6408700Content-Length: 238 Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted February 1, 2018 Report Share Posted February 1, 2018 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. 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.