Hello,
I'm trying to settting up a voip trunk.
I need one only extension is able to route out directly with this trunk without prepend something.
I'v tried to remove the extension from the other trunks and leave it only in the voip outbound route but I can't call.
Can someone help me please?
Thanks a lot!
Mattia
What kind of trunk -peer or register and to a provider or another PBX?
Hi Larry, it’s a register trunk to a provider.
And is the trunk registered? Can you receive a call from the trunk? Can you go to maintenance, troubleshooting and do a capture of when trying to make a call and send me the pcap file so it can be examined? Mask the private IP so that we can at least tell if if is private or public, but not completely as we need to be able to tell which they are so we can see the flow. My email is lneblett@n2techsolution.com
Hi Larry, the trunk is correctly registered and i'm able to recieve and make call.
I'v sent you the pcap file by mail!
The inbound calls work correctly, only extension 13 ring
The outbound calls dont use the Voip trunk but one of the 2 pstn.
Thanks for support!
Am confused, you initially stated-
"I'v tried to remove the extension from the other trunks and leave it only in the voip outbound route but I can't call."
Then in the last post you indicate -
"Hi Larry, the trunk is correctly registered and i'm able to recieve and make call"
So. if you can make and receive calls, what is the issue?
So, tell me what the issue is and what you wish it to do.
Sorry Larry, I probably expressed myself badly!
I have 3 trunk:
I've 3 groups of extensions / departments, I would need to call from each department with a pre-established line.
Example:
extension 12 (department 1) calls comes out with L555249
extension 13 (department 2) calls comes out with L1918005
extension 14 (department 3) calls comes out with L556924
Is it possible to set some outgoing call pattern based on origin extension?
Have you a solution for what i need to do?
Thanks a lot,
Mattia
Is this because you want the extensions to present a given callerID (CID)? Is it because of cost reasons? Do all trunks have the ability to serve the same destinations?
There are a number of options depending on the need.
It's not a cost reason, i'v the necessity to out with different CIDs because we have one office that host 3 company!
Generally all trunks serve the same destinations (national local and mobile call).
OK, depending on your locale, the POTS line may have their outbound CIDs set by the provider and if so, these will reflect the same number as the DID. Is this the case where you are located?
On the SIP line, you may have options. I am assuming that you will also want this line to represent the DID that associated to it by the provider? Some providers will require the number the CID to be the same as the DID, or at least a number that is associated to the account. Others will allow you to alter the number to suit your needs. However, and assuming they will allow a change, it all depends on the SIP header the provider uses to capture the CID as being sent from the PBX.
IF it were me, I would use the DOD settings and set the CID for each extension. Then proceed to get into the PBX and call control, outbound routes and create the rules that will allow an extension to dial out. You will need to create the rule for the SIP trunk and these may need take into account what the provider wants to see versus what your people are used to dialing.In other words, my provider in the US always wants to see 11 digits. However. when using a PSTN line, the folks are used to dialing a 7 digit number for a local call, 10 digits for a local call where, in a big city when 7 digits is not enough, and 11 digits for long distance, So I modify the dial plan to always prepend 1956 to the 7 digit number, a 1 to a 10 digit number and nothing to the 11 digit number. In this manner the folks do not have to alter their usual dialing habits as I have taken care of it for them. Yours may be different for your country and provider needs.
So, in my case, I would have 5 routes, 3 for the SIP trunk and 2 for the PSTN trunks. You will note that the routes can be moved up and down to set a priority of execution. This is important as the extensions using the analog trunks will use both their respective analog trunk as well as the SIP trunk. You should have the analog trunk routes set at the top of the route listings followed by the SIP trunk routes.
Then, in the extension settings in the PBX, set the outbound routes that the extensions can use. So, for extension 12, the trunks would be the SIP trunk, for extension 13 PSTN 1 and then SIP and for 14 PSTN 2 and then SIP. In this manner, the PSTN associated extensions can still use the SIP trunk if the analog trunks are busy as the SIP trunk can will act as a fail-over and the DOD settings will still reference the analog line CID (again, if the provider will allow). The extensions that need the SIP trunk will only have the rules set for the SIP trunk.
Once this is set, try it and see what happens. While I understand that you only need 1 extension to one trunk and it appears that your current extension count and trunk count match to the need, the above method will allow you to have the flexibility should you grow and add extensions without the need to necessarily add trunks. In fact, your SIP trunk alone could possibly handle the entire need by itself without the need for analog, but that something to consider later, after you see how flexible your SIP provider is.
THere are other ways to address this, but this is the more flexible. The questions we may have to answer are in what field does the provider look and does he allow you access to change the fields. My provider allows me to change at the trunk level so that I can select the header field - PAI, From, or RPID.
Try and let's go from there.
Do you check the CDR, that the call is made from the SIP trunk?
If yes, you might share the pcap log when you replicate the issue.
https://support.yeastar.com/hc/en-us/articles/360007739473-How-to-Get-PCAP-Dump-Capture
Hi Larry, I followed your valuable suggestions and I did various tests locally, remotely and with Linkus, everything works perfectly, thanks!
