Clarify Telephony Terms? Trunk vs. Ext vs. Chan. vs. Route

Asterisk Asterisk Support
1

I read several chapters in TFOT. Several times.

I examined the Asterisk Glossary (for which thank you btw, although it’s missing 90% :^) asterisk.org/glossary).

I try to keep it poked in under my skull long enough to take a peek at the .conf files to see if I can match what I see there with concepts in the book.

Most of the HowTos I’ve read concentrate on three of them: sip.conf, extensions.conf, and voicemail.conf, so so do I.

But it’s like a spell gets cast when I open the files and my brain jellifies. Terms fly around like Indian clubs and medicine balls.

Compounding the effect is my ATA (I think), a Linksys SPA-3102, which has a lot of these same terms flying around inside its web configuration, but most of which have been dumbed out so it can pass the stuff on for Asterisk to do the heavy lifting.

So Most of the stuff in the SPA I should ignore but ~Some~ of the fields entered in the SPA Must correspond EXACTLY with fields in the Asterisk confs, and–with the jargon soup–a newbie is soon reduced to flailing around.

Could some kind soul, compare and contrast the following terms for me, as you would for a sixth grader, some of whom I daresay have already had better luck at this? :^)
Q. What’s a trunk? Do I really need one?
Q. What’s a route? Do I have to have one of those?
Q. What’s an extension? When do I need more than one? Any?
Q. What’s a channel? (I think I know this one: I might call it a “conversation” and say it’s the thing that happens when the Caller finally gets connected to someone or something.)

What would be most useful would be a sentence or two to create a picture in my head.

For example, (have to be careful here or people will google the wrong answer for a millennium):

I hope someone can imagine how far this could go to setting up the room for new users to arrange the rest of the furniture as they continue to read and study.

I could always return to my little shibboleth to force the concepts back into their proper relationships.

If no help, I’d happily enjoy sympathy.

2

first… thanks for the laugh, your post was quite humurous :smile:

TRUNK - The term “trunk” has varying meanings depending on the technology being used. A lot of VoIP (SIP) carriers will throw around the term “trunk” to refer to how many concurrent calls they will allow your account to concurrently transport. If you have 1000 SIP “trunks” you could have 1000 calls going out (or in) from the PSTN at once. A “trunk” could also be what you were referring to with an analog POTS line.

ROUTE - I am not 100% sure what “route” specifically means in this context. When I think of “route” in terms of SIP calls, I generally think of the actual IP path the SIP messages are taking to reach their endpoint. I don’t think this is the context you are referring to though.

EXTENSION - Has two distinct meanings in asterisk:
Most commonly people are referring to a SIP/IAX phone, or a softphone client. When people say a call comes in to extension XXXX, that generally means that asterisk has taken an inbound call and subsequently dialed an ‘extension’ to connect the call to an individual. An “extension” is generally configured in sip.conf or iax.conf as a peer or friend.

The other half of this definition is the extension part of the dial plan. Each node of the dial plan is made up of CONTEXT/EXTENSION/PRIORITY.

CHANNEL - A channel can be in the form of many different protocols (SIP, IAX, H323, ZAP, etc). Each channel needs a channel driver which takes care of the low level implementation of the protocol. Basically it’s an abstraction away from the protocol so that asterisk users can make things function the same regardless of what type of channel is being processed. This is probably the most powerful feature of the asterisk platform. Technically a ‘channel’ is a single leg of a call.

That’s all for now… either I will have shed some light for you, or you will be 100% more confused now :smile:

3

Well, if my post was humorous, yours will go down in history as a Boon to Newbydom, while ~I~ nevertheless take modest pride in being the mosquito what provoked the Great Post!

Embarrassed after reading my own post, I curled up with Chapter 5 of Asterisk: The Future of Telephony, “Dialplans: can’t live with 'em; can’t shoot 'em!” on my thumb drive. No mean feat in itself.

I made some progress.

I’m beginning to see what’s throwing me is a kind of “chicken and egg” thing going on. You need to tell Asterisk that calls “coming in over here” are to be handled “in this context” and then quick-like-a-bunny jump over to the dialplan and define what that “context” is, and its steps (sorry, extension). And then get the “thing over there” to “tell the
same story” that Asterisk did.

But in the HowTos these instructions often come well before the Noob (rhymes with?) has any inkling of what a “context” is.

And in another place in the book I ran into something I’d puzzled over once before: it mentions the sad lack of consistency between what Asterisk calls “the unique identifier” in sip.conf and the variety of things it may be called in the hardware you’re trying to identify to Asterisk. It’s a little more understandable after having now actually having scraped my nose on the Very Problem without even recognizing THAT’s what I had read about!

Did I mention I’m doing this in a Virtual Machine?

Yes, because day-in and day-out, I just don’t get near enough PAIN!

I also didn’t mention that of the four tutes I studied (freepbx’s, zultron’s, mcbsys’s, and poormantech’s), I stumblebummed into a setup that lets me dial out through my SPA-3102 via the Asterisk server running in a VM on a Linux box on the same network.

I went back to see if I could sift through the .conf files to see why it wouldn’t ANSWER the phone and, well, I just lost it… My lower lip started quivering at the sheer complexity of it all. So I posted. :^)

I ~do~ suspect after more reading about Dialplans that it’s because
I haven’t:

  • defined some kind of incoming SIP (from the SPA)
  • didn’t define the context correctly for it
  • don’t have a ‘s’ extension in the context to do something in cases
    where no extension is provided

I forget that the Caller can’t provide an Extension to Asterisk until Asterisk has answered the phone which it can’t do if it’s required to know an Extension for everything. I’m allatime forget.

An I’m allatime inovermahead.

But, like the folks on their way to Oz, “I’ve got something they haven’t got!” A mad plan…

4

Terminlogy aside, I propose to post this “header” at the top of my dialplan (extensions.conf) file as a reminder. Corrections esp. welcome.

; Workflow
; 1. define channels in the necessary .conf files for
; your hardware (zap*.conf, iax*.conf, sip*.conf, etc.)
; 2. explain in those same technology files the Context under which
; calls originating in those files are to enter the dialplan
; 3. define those contexts in the dialplan (extensions.conf) and
; create and refine the steps to process calls under each context
; (HERE is where the CREATIVITY blooms mostly)
; 4. note that “dialing out” any of the channels is defined as
; a step under a Context in the extensions.conf file rather than
; by an entry in the .conf file

5

that looks good to me…

6

I’d add one more note to myself.

The "technology"s to be concerned about are those that the Asterisk server sees.

In my case, I have a Linksys SPA-3102, which has four ports: one “Ethernet”, one “Internet”, one “Line” and one “Phone.”

For the technically adept, these translate to:
LAN, WAN, FXO and FXS.

Because I’ve got a “real (analog) phone” and I plugged it into a the FXS (phone) port, I was temporarily lulled into imagining that I needed to configure a “zapata/zaptel” port!

However, I asked myself, “How is Asterisk talking to the phone?” and I finally realized that the only connection between the Asterisk server and the SPA-3102 being a Network Cable, my connections were SIP!

That is huge for a newby. This weekend I’ve been progressing by seven-league strides at least in understanding.

Tomorrow I’ll get to test the Mad Plan against that.