Defining own extensions for inbound calls

Hello all,
I need bit of help.
I’d like to create my own extensions in cextensions_custom.conf thats should be the first to proceed when someone reach my PBX.

For now I have several trunks, but I has not define them for incoming calls.

Also I have several Inbound routes and they process my incoming calls to diferent ring groups or lines. And everything works fine. So every time when someone calls to my PBX, call is processed via from-trunk extension. I think it is default setting because I haven’t defined it anywhere. And I would like to implement my extension from extensions_custom.conf to process it first and after that going to from-trunk and else.
Or inplement my extension like Gosub in first steps of from-trunk.

So my question is:
How to change from-trunk etension to my own extension for all incoming calls to all inbound routes.

Or

How to add my extension to first steps in from-trunk extensions.

many thanks for advices!

Did you create an inbound route for the various DID and specify where the call should route?

In cases where you want to run your own dialplan on incoming trunk calls, easiest is to create a new unique context in extensions_custom.conf in such as:

[from-trunk-rumprcimprcampr]
exten _.,1,Noop(Entering user defined context from-trunk-rumprcimprcampr in extensions_custom.conf)
; exten _.,n,DumpChan   ; uncomment for debug
; additional lines as required
exten _.,n,Goto(from-trunk,${EXTEN},1)

Then change the context of the trunk to from-trunk-rumprcimprcampr in the GUI for the trunk config.

Hello,

Yea, It works fine, Inbound routes looks like (example):

DID             |       CID         |       Destination
8001            |     602252000     |     Ring Groups 1111
8002            |     702021169     |     Ring Groups 2222
591572870       |         Any       |     Ring Groups 3333                          

What I need is as a first step of incoming call process this:

[from-trunk-custom]
exten => _X. ,1 ,NoOp(incoming call into own extension)
same => n, Set(CALLERID(num)=${CALLERID(num):3})
same => n, NoOp(upravene Caller ID je $(CallerID(num)))
same => n, Goto(from-trunk,${EXTEN},1)

and I don’t know how to do that in freepbx

You can modify caller id information with the CID Superfecta module I do believe.

Yasss!
It works just I want to!
Thanks a lot.

My wrong assuming was that incoming call hit right to inbound route and no into Trunk.
And also I didn’t asume that tha change in outgoing peer details has required effect.

I had never heard about that. Have you got some easy brief to understand how it works? :slight_smile:

I would add this source and test it out.

Thank you Sorvani, I take a look on that and it’s for longer study so, hopely later :slight_smile:

Guys,
I have another fundamental question.
is it nessecary to define at least one trunk with filled SIP Setting -> Incoming?

Or filled only SIP settings -> outgoing is good enough for calling both ways?

I probably don’t understand why has trunk separated outgoing and incoming settings.

I find it difficult to understand this too. In most cases Asterisk only needs one definition, which for chan_sip should normally be a peer. I think there is even less need for chan_pjsip. Although I’m only answering from an Asterisk point of view, I think I’ve seen reports of people using only one definition for FreePBX, so I don’t think this is a FreePBX thing, even though the structure of the GUI hints that you need the inbound definition.

There are cases where, for example, there might be multiple source addresses that don’t match the URL needed for outgoing calls, but there you would probably need multiple inbound entries (and chan_pjsip can handle these with multiple match lines in an identify section).

I’m not certain of the original reason for incoming sections, but it is very clear that ITSPs provide sample configurations that are not properly researched. I think they often copy another provider’s configuration and fail to remove features they don’t need, as well.

They tend to use obsolete names for options and to enable unnecessary workarounds. They can also use options that are only relevant to the other section.

Having two can actually be risky, as I don’t think Asterisk formally defines which section, for the same host address, will match the provider’s IP address. I think a lot of them rely on undocumented behaviour.

Although you shouldn’t be starting with chan_sip nowadays, my advice would be to start from first principles, and ignore the provider’s suggestion, and try to use a type=peer outgoing section as the only definition of the trunk. Although you are less likely to get provider supplied chan_pjsip configurations, I have seen an example here of what looks like a bad, literal, translation of chan_sip one, and many people mechanically translate from poor quality chan_sip definitions, so I’d also say try to start from first principles for chan_pjsip and ignore provider ones and translations of chan_sip ones.

Generally when people define inbound sections a type=friend, it just opens a minor security hole, as the section name is not something that the provider sends, so there can never be a user match (type=friend, really a combination of type=peer and type=user, with the type=user match being preferred). The security hole is small because you shouldn’t allow incoming calls from your provider to initiate arbitrary toll calls.

The GUI labels are confusing, there is nothing specifically inbound or outbound about the peers being created. When defining a chan_sip trunk, it is sometimes necessary to have different SIP settings for inbound and outbound, so if that’s the case you can use the inbound tab to create a second peer. Usually you just need to define one peer on the outbound tab.

All is moot tho, chan_sip is deprecated. Strongly recommend you only use pjsip for everything now.

Thank you guys,
I have much much to think about. (Mostly about PJSIP :slight_smile: )

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.