I had an account with a SIP provider with a single phone number. I had it registered as a SIP trunk, and used the username (thats used in SIP registration) in the ‘Inbound Routes’ section too. And all this worked fine.
Now I’ve added a second phone number on the same account, and I don’t see the point in registering again - just need to add another ‘Inbound Route’ right?
Only thing is the ‘Inbound Route’ should be the phone number not the SIP username so that the system can identify which was dialled for different routing. However the ‘Inbound Routes’ only answers a call if I put the SIP username in there, not the number dialled. In other words it seems it’s obversing the INVITE field and not the To: field as below…
You could ask your provider to be a bit Asterisk friendly and provide the additional DIDs in a way that Asterisk ‘naturally’ likes it as many providers do. You can consider another provider. Or you can have a look at the following documentation and pull the number out yourself:
I have already asked VoIP.co.uk about this and they don’t see it as a flaw with themselves as many of their users use asterisk and ‘watch’ for the To: field. I did mention to them the “FROM_DID” variable but I think that is a FreePBX thing and it must calculate it from the INVITE field - can you confirm that?
They are a friendly bunch, so if you can be more specific on how they can be more Asterisk or FreePBX friendly I can pass it on, even guide them to this post and they can speak for themselves.
Edit: Oops, I didn’t notice that p_lindheimer had already posted that link above. Did you read that and try anything mentioned there?
Edit 2: To be really specific, what you need to do is this. In the trunk setup for that provider, change the context=from-trunk statement to read context=custom-get-did-from-sip and then add these two lines to /etc/asterisk/extensions_custom.conf:
Don’t commit your changes (that is, don’t click the orange bar) until you’ve made both of the changes (in the trunk setup and in extensions_custom.conf), because FreePBX won’t “see” the changes in /etc/asterisk/extensions_custom.conf until you do a reload.
this subject comes up often amongst carries who say they are correct. And the answer is they are not incorrect. The crux of the situation is whether or not they want to make their service easier for users to consume.
Asterisk will translate the invite field to an extension automatically. (It has nothing to do with the FROM_DID, we use that for internal purposes after-the-fact.)
In order to get the DID from any other field you have to extract it, per some of the examples shown in the referenced documentation. That is more work for the user. So the point is - do they force every one of their users to do more work, or do they handle it on their end?
There have been suggestions of extending some of the capabilities in the “Zap Channel DIDs” section to handle other types of DID’s such as these. That is being reviewed. However, one would think that carriers would want to make life easier on their customers, vs. standing behind the argument that they are right when there are hundreds of thousands of FreePBX installs out there, dozens (probably hundreds) of carriers who acknowledge that they need to cater to how the installed base is expecting to receive information, and not standing behind an argument that they may be correct (when there is no “correct”).
If they want to consult with someone, they can contact paid support to get the help. However, I suspect being a carrier, they can review the information listed above and have enough understanding of Asterisk and SIP to figure it out. (I would want that in any carrier I was doing business with).
I edited my previous post to show a specific example that should work for you. But p_lindheimer is right, this does seem to be a common problem, especially where customers are getting multiple DID’s from the same provider that are coming in via the same trunk. Sometimes the only thing that tells you which number the customer actually dialed is the sip To: header (or something more obscure, such as the port number sent in the sip Via: header).
I’m not trying to be difficult, the information is there. It’s simply a matter of not enough time in the day. They should be able to see from that information what they need to do, and from what you said they told you, it sounds like they already know.
Look, I will grant that your supplier could perhaps be more helpful, but I’ve told you explicitly how to fix the problem. If you are going to use Asterisk and FreePBX there are times when you are going to have to roll up your sleeves (so to speak) and do a little work on your own, simply because not everyone you deal with is going to move on your timetable. You can literally take under three minutes and fix the problem yourself, or you can hope your supplier will get it right.
But here is what you apparently want to tell them, based on what’s been written so far:
“I want you to send the DID that the caller actually dialed in the SIP INVITE field.”
But having said that, I’m not entirely convinced that would not cause other problems (such as your system not recognizing that the call is coming in on a valid trunk) - I don’t know enough about the internals of Asterisk to comment on that.
Me, I’d take the three-minute fix, rather than losing any sleep over the matter.
Simply put then, if VoIP.co.uk sent the DDI in the INVITE field (because so far no one has said that is where FreePBX is expecting to get until wiseoldowls post a moment ago) then this is as you say…
‘[the] way that Asterisk ‘naturally’ likes it’
And thus my problem is solved.
If they can’t do that then I’ll do the custom context trick.
All I’m asking is what exactly I should be telling my provider… what they should be providing - I don’t want to leave them guessing on what to provide.
that’s what you mentioned in the top of your message, I thought you already knew that:-)
they can, they may choose not to, it may be too much work for them. For your own sake, it’ll probably be less work / less painful to do it yourself.
there’s nothing to guess, do a search, they have encountered this before. It is generous of you to be trying to help them, being that you are paying for their service. It’s something one would expect that they would be doing on their own, as part of what you are paying them to do. You should be able to point them to this thread and that should be enough help to set them on the right course.
Basically it seems that from-sip-external has a GotoIf that checks which trunk a calls coming in on and then sends it on to from-trunk… to me changing the context in the PEER section to from-trunk-fixddi (for example, I renamed it :P) instead of from-trunk doesn’t seem to do anything as it never gets ran.
Thanks Philippe, the suggestion of it ‘observing the INVITE’ field right at the beginning was just a guess on my part - and I just wanted some confirmation of that is how the FROM_DID variable is calculated (which gets filled with the username like the bit before the @ in the INVITE field).
if it’s hitting from-sip-external then you have a configuration issue, likely because of a lack of info provided by your provider. They are probably not sending the calls to you from the IP address they provided, so it hit’s the ‘default’ sip context.
The provider is going to have to provide the information you need in the configuration. Alternatively, you are going to have to either re-define the from-sip-external context so that your changes are included in it, or just change the default setting, which is normally set in sip_general_additional.conf but can be re-defined in sip_general_custom.conf.
Sorted it, the hostname I was using the register with wasn’t the same as the domain they are coming from… so now they’re both the same it doesn’t hit from-sip-external.
Incidentally I found this wiki page on their site all about how bad asterisk is and they are right and asterisk is wrong.
Not that I’m saying they’re right or wrong! Just thought I’d point it out
I haven’t read the link but it’s a familiar story and given how they are sending your DIDs not surprising. I’ve seen this lots of places in the industry, “they are wrong, we are right” when in the end it is an un-productive attitude.
Whether they are right or not, “it’s the hand that is feeding you.” It is reasonable to entertain discussions and drive change towards convergence going forward, but in the meantime you make it work with what your customers are going to have.
I’ve seen this attitude with claims of “Sonus is not following the standards, they are evil we are right” and in the end the argument may be completely correct. The difference is, they are out there and installed and the more you “attack” them the more defensive the other guy is going to get in trying to address the problem. It’s not a productive approach to change. Try calling the phone company when installing a PRI (here in the US) and telling them immediately they are wrong and see how much help you get out of them… It’s all in the approach and attitude.
So, using the To header is completely incorrect due to the fact there is no guarantee the To header will match the targeted number (see http://wiki.voip.co.uk/sip/matching_using_to_header for a brief run down on it)
I’m sitting, right now, at IETF 74 in San Francisco where how to deliver target URIs (i.e, the “target number”) has been an agenda item. We thought we worked out a solution at IETF 73 in Minneapolis 4 months ago (using History-Info), but there seems to be some discontent about that solution as SIPForum (which we’re also involved in) have chosen a totally different method for SIPConnect 1.1. So far it still looks like RFC 4244 will be the solution (at least in it’s -bis form), but that could change.
The problem is not as simple as it looks on the face of it (due to multiple targets, forking, redirects, etc), but we (voip.co.uk) appreciate that right now there is no defined solution, so for now, the To header user-part will always contain the most recently targeted URI (where “target” is a telephone number or most of our customers) in dialstirng format. However, this will change over the long term (in terms of lots of months, if not years :)), as we get closer to removing all the SBCs and B2BUAs from out network and have HI support and will in the next few months be adding a bunch of choices for URI delivery as it becomes more clear the direction the IETF and SIPConnect are going.
This thread was pointed out to me by someone and i don’t normally monitor it - but if anyone has any problems with our SIP services (at a protocol level), or indeed any IETF SIP related things not related to VoIP.co.uk, then feel free to email me directly ([email protected]) and i’ll be more than happy to chat.
