I’ve been unable, after hours of research, to find the option that sets the username in the Request URI on the INVITE packet sent to the trunk when placing an outbound call.
System:
OS: FreePBX 15.0.17.68
Asterisk Version: 16.20.0
Endpoints: Various models of Yealink’s phones
Issue:
System registers and authenticates correctly to our provider’s chan_SIP trunk. Incoming calls work fine, however, outgoing calls returns “SIP/2.0 403 Forbidden: Registration Cache Entry Not Found”. Still unsure which value is set incorrectly on the INVITE Request that causes this issue, but we suspect is the username on the RURI, since our provider has stated in the documentation that: DID is not specified in the INVITE Request, it’s specified in the TO header. The INVITE request is always directed to the username
The provider should tell you what they want. There are sometimes subtle differences in the settings. We don’t know them and there is no global unique configuration that works for all connections.
That said, is there a reason why you are using an outdated channel driver? You should not use chan sip. Among other things, PJSIP can cope with far more situations and it could be that you need one of those features to make your connections work.
Hi @EkFudrek , thanks for the quick reply. Yes, I’ve requested the provider the exact settings, but they don’t have any documentation for FreePBX systems, in other words, they don’t support FreePBX installs… But looking at the info they provided, our best guess is that the error is because of the username not being what they expect in the Request URI. (See last two lines in the first post)
Also, In the email they sent an screenshot of an INVITE packet from another customer that have outgoing calls working succesfully, please tell me if uploading this screenshot might help with the settings needed to achieve the format they require or that they know that works.
Regarding the use of chan_SIP, mainly for two reasons, first, they told us they “only support chan_SIP” even though I’m aware both drivers end up being the indifferent to them on their side, and second, I want to, at least for now, have the system running with a known working setting, and with these settings, convert it to pjsip This I will need some help, since I haven’t done this before
So, they cannot technically describe their SIP settings, but say it works with chan_sip and not with pjsip?
Get some other provider. Given the information you posted, we can only guess here. You may want to enable SIP debugging and try to find some more hints about the things that are going wrong.
Yes, I do agree with you of getting another provider. Unfortunately, we don’t have many options in our country, and the other providers might give us the same experience if not, worst. The only way they give support, is by agreeing in a monthly fee for a managed device or by taking their cloud solution.
So, I’m up to the only option of bruteforcing/trying different settings until I hit the right one ( practically, what I had to do with the register string). Also, I do have been enjoying the learning experience and getting to know more in depth of the SIP protocol and how it works.
Back to the issue, from what I’ve seen from the debug logs, my best guess and what I would like to try next, is changing how the RURI (this → INVITE sip:3456789@provider.tld SIP/2.0) is being presented to the trunk and see if it makes any difference, if someone could help with this, I would greatly appreciate the support. If any other info is needed, I can try to provide it.
P.D. Provider’s trunk is being provided by an on-site SBC, which I guess, is the device with the IP of 10.254.xxx.xxx acting as an Outbound Proxy ( Just in case this info helps at all )
As said before, nobody can help you here. The provider must tell you what to expect in the request URI, etc.
To give you an idea what you have to consider you can read this:
There are actually a couple of more technical docs with more details, in case you would want to set up such a system.
The description of the German Telekom VoIP products won’t help you, but the text gives you some hints about what needs to be considered. I’ve seen fiber connections that were as easy to configure as a local endpoint, but that is no longer the rule nowadays.
Note that FreePBX isn’t supported here and FreePBX limits your options with Asterisk.
That’s such a serious violation of the expected use of SIP that I’d have to suggest you are being given bogus advice. FreePBX will have the assumption that 3456789 is the number you are calling very deeply embedded, and how do you expect the provider to know where to send the call if you don’t put it there.
There shouldn’t be a space after the : This may be a problem with how you posted this to the forum, although it is correct elsewhere.
I’m wondering if you have failed to register. Whilst registration is technically necessary, it is possible they only accept calls if you are registered. In any case, if you are getting authentication errors on an INVITE, I’d also expect them on the REGISTER.
The RURI may not say much about the called number; there’s still the To header. I know providers who require the user name of the account in the RURI and then the number as dialled by the caller shows up in the To field and a normalized number in the P-Called-Party-ID header (which is not really optional in this case).
One provider I’ve come across uses a base number as the account’s user name, which means that at least this base number can be reached in case a PBX lacks some features. One could say (using post-modern slang) that especially FreePBX is somewhat limited in the deconstruction of SIP headers. PJSIP/Asterisk is flexible enough.
Unfortunately, chan_pjsip sets both To URI and Request URI to the same value, so this misuse of the request URI is going to limit the OP to chan_sip, if the real request URI is in the To header.
I’d still say that using the request URI in this way is an abuse of SIP, and, if they are using the To header as the real destination, having that different from the request URI is a violation of a SHOULD level rule RFC 3261 - SIP: Session Initiation Protocol
This is incorrect. If I dial 505NXXXXXX from my phone and I need to route it out Flowroute (for example) who wants my tech prefix to prepend the dialed number, before I send it out the Flowroute trunk I’m going to do PJSIP/${TECHPREFIX}${EXTEN}@endpoint. So if my tech prefix is 45678* then the Request URI is going to be 45678*505NXXXXXX while the TO URI is holding the originally dialed numbers of 505NXXXXXX. Now when that call leaves my Asterisk box over that endpoint, the RURI and TURI are not the same, at all. Hell if I set the from_user and from_domain settings on the endpoint, if could have a completely different FURI then my phone presented.
As for the OPs issue. The error is pretty clear. Did anyone consider why on an INVITE they are rejecting the call for NO REGISTRATION CACHE. So that would lead me to one very important question, is the provider requiring this trunk to be REGISTERED?! If there is no active location then calls are rejected? That is a very important thing to know.
Also, using outbound proxies the outbound_proxy setting must be in this format: sip:10.254.xx.xx\;lr if it is not in that format it will be ignored and not used.
At this point we should see you pjsip.conf settings for all this.
I’ve never seen this message. I am wondering whether it could be that the service provider has a problem and their boxes are not properly configured. I don’t know, since we also do not know what is actually happening on the customer side.
Technically it can also be a name instead of a single IP and the resolution goes through the NAPTR/SRV cascade. We had that here about 3 years ago and the final question was what happens when the actual proxies rotate and the service provider does not maintain the state of the registration. I have an example, but that would be a bit off topic now.
That conflicts with what @jcolp has recently said on the subject:
Also, the only technology independent way it could be done, in your example, is for the channel driver to look at the value of EXTEN, but channel drivers are not in general aware of the the dialplan. It can’t copy the To header from a DAHDI channel, as there is no To header.
I have never seen that error before either. However, I have the ability to make that error. It is just the response and proxy/SBCs let you update that.
I look at things like registered contacts when an INVITE is sent. It will reject the call (if the option by the user is set) if the source doesnt match a registered contact. All I do is just send a generic 403 back. I could give a custom reason but I dont.
Well, as far as German Telekom SIP trunks are concerned, they use the user name, which happens to be a phone number. Everything enters here the dialplan and you have to manually evaluate the To (stupid) or the P-Called-Party-ID (clever) header and then jump into the usual processing. Likewise you have to do something similar for the outgoing calls in case you want to indicate the extension.
Given that scheme they could as well use account names like burrito or taco and things would still work.
Hello! Good night from this side of the world. Thanks to all of you guys for the input provided.
Taking in consideration all of the information, I must conclude to this:
So, discarding the idea of modifying the RURI and after a bit of talking with the provider, they have requested our INVITE to have a Remote-Party-ID with the following format:
How can I set USER_AUTH in the Remote-Party-ID header?
P.D. I’ve succesfully migrated the trunk to chan_pjsip, and just as before, registers and authenticates just fine, incoming calls also do work fine, but still having the same response from the trunk of 403 Forbidden for outbound calls.
Yes, the spaces were added by me, as I just created the account and still had the forum’s limit to how many hyperlinks I could have in a post, so I had to add some spaces to what the forum was considering as a link. Just after I posted the topic question, my account was “upgraded”"
Done, migrated to pjsip and added the Loose Router to the Outbound Proxy IP. But I still have the same 403 Forbidden issue.
Good call, so, I will try using No Authentication for outbound calls and update back on this. Hope this is all that was needed after all…
Remote party ID is used by the caller ID, so set the caller ID to the authentication user. There are rumoured to be broken ITSPs that will actually accept a caller ID in From and account in RPID, but that is back to front.
Although I don’t like setting fields that are normally controlled by Asterisk, you can also disable sending RPID and then add the header explicitly. Search for example on setting phones to auto-answer for how to add headers.
Logs (and configuration files) should be marked up as pre-formatted text, for the forum, in which case the forum will not recognize any of the content as being URIs. This can also be used to post a real URI, when you don’t have enough posting history. It should still frustrate link spam.