Hi, how can i create a trunk to send calls from my asterisk server to another server.
asterisk version 16.2
Thanks for your help
You can only send calls from clients to servers; the roles are dynamic.
The best way of creating them is to create them like IP authenticated trunks to an ITSP. You can do two way authentication with passwords, as well, if you like.
Basically take the second example in:
https://wiki.asterisk.org/wiki/display/AST/res_pjsip+Configuration+Examples
remove the parts relating to registration, and ether remove the authentication or add reciprocal inbound and outbound authentication.
If those descriptions are not obvious, you need to read the documentation to understand how the example works, rather than asking for an example to blindly copy.
1 Like
If you are connecting two Asterisk servers using a trunk, you probably want to look at IAX2:
What are the advantages of using IAX2 over SIP?
- Asterisk-native
- More firewall friendly (only need a single UDP port, that’s it)
- More bandwidth efficient
- Easier to configure
- Easy built-in authentication and encryption
Also see: Why IAX2? - Asterisk Project - Asterisk Project Wiki
Generally speaking, there are few things that can go wrong with IAX2. You set it up and it just works. Most debugging and hair pulling is on the SIP side of things. It’s not as nice or elegant a protocol to work with.
IAX2 is generally only used for trunking calls between Asterisk systems (don’t expect to use it in other scenarios), but it does a better job at that than other protocols do.
1 Like
Some disadvantages however:
- IAX2 sees considerably less usage
- While core supported we (Sangoma) don’t touch it and it’s not something we really push in any of our products, so I’ll probably try to make it community supported
- It does not support exchange of format attribute information, and newer codecs aren’t supported, there was actually a security vulnerability as a result of that
- There’s more overhead in bridging an IAX2 and SIP channel in Asterisk, because media has to flow through the core and have more work done to it
Ultimately you’re free to use it if you wish, but weigh both the pros and cons.
1 Like
- IAX2 sees considerably less usage
There are tens/hundreds of thousands of people using it, at least, it’s not like “nobody” uses it.
- While core supported we (Sangoma) don’t touch it and it’s not something we really push in any of our products, so I’ll probably try to make it community supported
Probably because IAX2 is remarkably stable and just doesn’t need any changes for the most part. It works and doesn’t need constant changes.
I’ll just contrast that with pjsip, which has more issues about crashes in JIRA than any other module I’ve seen. Obviously there are a lot of factors, but IAX2 is more stable.
- It does not support exchange of format attribute information, and newer codecs aren’t supported, there was actually a security vulnerability as a result of that
G.711 is what most people use anyways, the newer codecs all have other limitations. I only support G711 with PJSIP as well.
So unless someone is using an unsupported codec, this likely doesn’t have an impact.
- There’s more overhead in bridging an IAX2 and SIP channel in Asterisk, because media has to flow through the core and have more work done to it
If you’re referring to direct media, that’s kind of misleading: in my case, ALL calls flow through the core, regardless of technology, so IAX2 presents no additional overhead per se. Same would be true with a SIP to SIP call. It has to go through the core if you’re doing anything audio related, e.g. using audio/frame hooks, etc.
Ultimately you’re free to use it if you wish, but weigh both the pros and cons.
Of course.
I’m not referring to direct media. There is also optimizations in place for RTP to RTP that has to remain within Asterisk, it shortcircuits the core and flows through the RTP stack with considerably fewer memory allocations for the cases where other parts of Asterisk don’t need the media.
@InterLinked I’ve also been giving this some thought and I think ultimately the project has gone in a direction that is counter to what you want/believe. Perhaps even the industry as a whole. A considerable number of years ago things would have been different and further aligned, but these days things are just different and honestly from a project perspective my goal is to make the project for the majority of the users. This is reflected in what I suggest for people to use, how to do things, and how attention is given to changes.
Well, to some extent I think you are right. Where I differ is I prefer to use the technology that actually works best, as opposed to the technology that which is actively looked at or “used the most”. These are good indications, but they don’t tell a complete story.
As I’ve said before, IAX2 is in many respects a technically superior protocol to other channel drivers in Asterisk, which is why people to continue to use it - it works better for their use cases. The OP’s use case in this case to me resonates more with IAX2 than with PJSIP, that’s why I recommended it.
A large reason for the negative attitude towards IAX2 from Sangoma (from what I have noticed) is because the protocol never caught on outside of Asterisk, they decided it was a failure and focus on all the bad aspects of it rather than the good, and wanted people to stop using it to the point that it is never recommended anymore by employees and now it’s “PJSIP or bust” for everything. But the reality is that - in its little niche - it’s an excellent protocol and I don’t think its niche usage detracts from that at all. If people decide to use it aware of the compatibility issue with other systems then I believe they should have the option too.
I guess my perspective is that these can coexist just fine: nobody’s asking Sangoma to work on chan_iax2, the module is stable and works just fine as is, and it’s great that Sangoma is devoting its attention to other things that need work, but I personally steer people towards the best tool for the given use case, not necessarily the newest/shiniest one, and we can all acknowledge that no channel driver is perfect and different ones may make more sense for different use case.
So ultimately, I do “best for the specific use case” rather than “best for the majority of use cases”.
As far as making chan_iax2 community supported, my main issue with that would arise if that was the path towards deprecation, like the way chan_sip went. If it stays community supported forever, like many modules have, then maybe that makes sense in that case.
And I think that’s another aspect of things. You’re not an end user, you’re more of a developer user which means you approach and think about things differently. You have some of the skills, the desire, and the knowledge to use such things purely from a technical perspective. Not everyone has that luxury.
So I ask that in the future if you do push IAX2, then state cons as well.
The way I see it, if you have a setup consisting of SIP providers for external connectivity, then adding another technology, and protocol, you ALSO need to familiarize yourself with, makes things a lot more complex. Sure as a developer with more than 10+ years of experience with Asterisk, and telephony, IAX2 would not be that hard to figure out. However, my entire troubleshooting toolkit, has no clue about an Asterisk only protocol, which makes troubleshooting a pure SIP setup WAY easier, than having multiple protocols just because they were designed for that specifik purpose.
My setup consists of multiple Asterisk servers, all interconnecting with each other using SIP, we also have a couple of Kamailio servers in the mix as well, using pure SIP means that we only ever have to train new employees in ONE protocol, we only need ONE set of tools, and in general our setup is much easier to manage.
As for PJSIP crashing, you must be doing something wrong, I’ve never had PJSIP crash ONCE during the time we’ve used it, which is about the time when Asterisk 13 were the latest version. I’ve had crashes in the code of other modules, however, but if that was just by random chance, or caused by the actual module, were never investigated, we just upgraded to a newer version, and moved on.
If I don’t remember wrong (Didn’t bother to check) IAX2 is a binary protocol, and as such would require a specific tool, to gain the same level of visibility that ngrep or sngrep gives us with SIP. With many servers you need something that’s simple, where the tools are easily available for all OSes involved, and where you can easily train new people to maintain and troubleshoot the network.
If you have a lot of NAT involved, sure IAX2 might be great, however, most NAT devices today supports SIP just fine, and will only have a problem if you run SIP over TLS. But apart from that, what does IAX2 provide, that makes the higher support burden worth it?
Also I’m all for dropping IAX2 in Asterisk, if there’s something Asterisk REALLY needs, it’s fewer modules. There’s way too many to keep track of, which results in either spending a lot of time figuring out which modules you need, or wasting a lot of time compiling modules you will never use anyways.
IAX2 was a nice try, but makes little sense today. And if Sangoma wont even keep it updated, it could just be a matter of time, before the module no longer compiles, unless someone else is willing to invest the time required to keep it compatible. (Yeah, changing the API for channel modules might not happen every day, but there’s no reason why it would never happen)
In my opinion, a channel driver should also support all available features of Asterisk, that INCLUDES every codec.
Asking new users to figure out yet another protocol while they might be struggling to figure out SIP already, seems a bit too much to ask of them.
Sometimes it’s best to keep things simple, even if a better solution might exist. For most people efficiency of a protocol, in regards to memory, CPU and network bandwidth, is not really a problem, most people are able to just throw more resources at the problem.
Perhaps my perspective from a telco point of view is different than an end user, but my experience with end users is they prefer as few things to keep track of, and learn, as possible. While technicians like you and I might find it more for to connect multiple technologies, just for the fun of it.
The way I see it, if you have a setup consisting of SIP providers for external connectivity, then adding another technology, and protocol, you ALSO need to familiarize yourself with, makes things a lot more complex. Sure as a developer with more than 10+ years of experience with Asterisk, and telephony, IAX2 would not be that hard to figure out. However, my entire troubleshooting toolkit, has no clue about an Asterisk only protocol, which makes troubleshooting a pure SIP setup WAY easier, than having multiple protocols just because they were designed for that specifik purpose.
If you want to use a hammer for everything, go ahead.
Not every technology is best suited for everything.
My setup consists of multiple Asterisk servers, all interconnecting with each other using SIP, we also have a couple of Kamailio servers in the mix as well, using pure SIP means that we only ever have to train new employees in ONE protocol, we only need ONE set of tools, and in general our setup is much easier to manage.
Again, different strokes for different folks.
The great thing about choice is you can do what works best for your org, I can do what works best for mine.
As for PJSIP crashing, you must be doing something wrong, I’ve never had PJSIP crash ONCE during the time we’ve used it, which is about the time when Asterisk 13 were the latest version. I’ve had crashes in the code of other modules, however, but if that was just by random chance, or caused by the actual module, were never investigated, we just upgraded to a newer version, and moved on.
I suggest you look at the Asterisk issue tracker at some point.
There are a large number of PJSIP crash issues on there, issues with both PJSIP in Asterisk as well as the underlying pjproject.
Are these likely to happen? Probably not. But saying “you must do something wrong” just comes off as ignorant. Lots of users have had issues, and they do exist.
If I don’t remember wrong (Didn’t bother to check) IAX2 is a binary protocol, and as such would require a specific tool, to gain the same level of visibility that ngrep or sngrep gives us with SIP. With many servers you need something that’s simple, where the tools are easily available for all OSes involved, and where you can easily train new people to maintain and troubleshoot the network.
Maybe that’s one way to look at it.
If you have a lot of NAT involved, sure IAX2 might be great, however, most NAT devices today supports SIP just fine, and will only have a problem if you run SIP over TLS. But apart from that, what does IAX2 provide, that makes the higher support burden worth it?
I find IAX2 much easier to debug because there’s only a limited set of things that could go wrong, with authdebug=yes, the built-in IAX2 debugging tends to work quite well.
So for me, IAX2 presents a lower support burden. I could set up an IAX2 trunk in my sleep, PJSIP is all bets off until after I’ve had my breakfast.
Also I’m all for dropping IAX2 in Asterisk, if there’s something Asterisk REALLY needs, it’s fewer modules. There’s way too many to keep track of, which results in either spending a lot of time figuring out which modules you need, or wasting a lot of time compiling modules you will never use anyways.
Um, so don’t compile the modules you don’t use?
You should be using menuselect and makeopts to script your installs and only be compiling and loading the modules you use anyways. You shouldn’t be relying on the default compilation and loading options to run a production system. Projecting your requirements on the entire Asterisk community is just self-centered and doesn’t solve the problem.
IAX2 was a nice try, but makes little sense today.
Which is hindsight oriented again, it makes a lot of sense if it works for your usecase.
And if Sangoma wont even keep it updated, it could just be a matter of time, before the module no longer compiles, unless someone else is willing to invest the time required to keep it compatible. (Yeah, changing the API for channel modules might not happen every day, but there’s no reason why it would never happen)
There are lots of users using it and it’s alive and well. app_playtones hasn’t been updated in 6 years and it’s alive and well too. Modules that are mature don’t need regular attention.
If it became community supported, it would not be at any risk of falling out of date; I for one would be willing to set up as a maintainer, and I know many folks that would do the same.
In my opinion, a channel driver should also support all available features of Asterisk, that INCLUDES every codec.
Well, then maybe we should get rid of all the channel drivers, because there is some functionality that ALL of them don’t support.
PJSIP for example doesn’t support Advice of Charge, custom parameters, or ADSI.
DAHDI probably doesn’t support many IP-specific things.
SIP doesn’t support a lot of the things that MGCP does.
Your approach seems very generic and shortsighted. If the requirements were all the same, there would only be one channel driver in the first place: chan_asterisk.
People use a channel driver because of what they do support, and whether they support some codec nobody uses nobody could care about less.
Asking new users to figure out yet another protocol while they might be struggling to figure out SIP already, seems a bit too much to ask of them.
I have worked with many people over the years in educational environments with Asterisk.
SIP is always the hardest thing for people to figure out in Asterisk, across the board. chan_sip, chan_pjsip, you name it, a newbie to Asterisk is always going to struggle with it. It was hard enough with SIP and for most people it got even more complicated with PJSIP. Put somebody new in front of an Asterisk system and they’re not going anywhere fast without handholding.
Have I seen people struggle with IAX2? Yes. But almost always with issues that are easy for them to debug and solve and get resolved relatively quickly. Most people can RTFM and get something going very quickly.
Some SIP issues are so complicated for newcomers that they really do need outside help or consulting resources to come in. So I stand by my statement that IAX2 is a great channel driver for newbies. A lot of people love IAX2 because it’s simple to set up and configure and use.
Sometimes it’s best to keep things simple, even if a better solution might exist.
A bit ironic, since you said simple is better, and yet you complain about IAX2, one of the simplest channel drivers.
For most people efficiency of a protocol, in regards to memory, CPU and network bandwidth, is not really a problem, most people are able to just throw more resources at the problem.
That sounds like a terrible way to run a production system, especially one operating at any level of scale.
Many users care immensely about the resources their systems consume. Many people run Asterisk systems with 512 MB or 1 or 2 GB of RAM, maybe one or a couple CPUs: and IAX2 scales a lot better than PJSIP does if you’re doing a lot of trunking.
I prefer to have an efficient system, not throw more time, money, and computing into the void and hope it works out. That’s literally one of the worst philosophies one can hold in IT.
Perhaps my perspective from a telco point of view is different than an end user, but my experience with end users is they prefer as few things to keep track of, and learn, as possible. While technicians like you and I might find it more for to connect multiple technologies, just for the fun of it.
I don’t know what you mean by “telco point of view”, unless you mean more the “modern” way of doing telco. The Bell System cared immensely about engineering quality and high standards, and was able to do things nicely and efficiently on machines with low resources. I don’t find your perspective anything like what a traditional telco engineering perspective that strives for high reliability and durability, but we’re all entitled to our opinions.
He is a person that if you call him out he becomes irate and offensive, as he has with others,he does have the know how but is young and does not seem to realize that there are others who no more. Seems he is doing it here as well
Who are you referring to?
Interlinked
If only having a hammer in my toolbelt makes it easier to do my work, even if it means hamming in the occasional screw.
There’s crashes everywhere in the issue tracker, in just about every module in active development, I’ve even got an open bug posted some 10 or so years ago.
That does not mean it’s a general problem, I’ve not had crashes related to PJSIP, and I’ve been processing a lot of calls using it. That, to me, means there’s no big issues, that suggests to avoid PJSIP, whenever possible. I’ve had my share of problems with random crashes all over the place, if the modules where the crash happened were to believed, I’d have to avoid most of Asterisk.
Easier to debug on the network, or Asterisk level? What tools exists to visualize the entire signalling flow of the call? sngrep does a great job of visualizing the SIP flow, for PJSIP we also have the HEP module that can forward signalling to homer, for analysis, what exists for IAX2?
Sometimes you need a high level overview of a call flow, troubleshooting does not always start on the individual server used to process it. It hardly ever does, as you need to figure out where the problem originates, before deciding what server to look at.
I still need to make a decision in regards to EVERY single module, and whenever something is updated, modules might disappear or change name, and new modules may appear, that I then also needs to make a decision about.
Automation works fine, if things never change, but if going from asterisk 16 to 18 or 18 to 20 requires you to make new decisions, you’ll need to update the automation tools, and you’ll not gain much from automating the process, except for minor updates, that can also be handled with “patch” or by just checking out the code from git, then updating the local copy whenever a new version is out. This preserves the selections made with menuselect, and gives the latest version anyway.
You can also just open menuselect for the new and old versions, then make sure to check the same boxes in the latest version, it’s a little slower, but the few times I’ve needed that, it’s taken a little over 10 minutes.
That doesn’t change the fact though, that Asterisk has a LOT of modules you need to make individual decisions about.
Sounds like a good idea, to clean up, there’s too much choice already. 
In general though, a basic requirement, for IP channels, should be to support any codec, for analog channels, that’s not possible, same goes for ISDN channels. But a rule of thumb, if it goes from IP to IP, transcoding should not be a requirement.
Sure, in my situation, we allow nothing but G.711a, as that’s what all our interconnect links requires, and reducing transcoding is a good thing, and as such there’s more or less no good reason for a channel driver that uses an IP connection, to not support any codec available. To my knowledge, SIP for instance, supports whatever codec you manage to put in the SDP payload.
Funny, I’ve always seen IAX2 more like blackmagic, perhaps I just don’t understand it?
And still every telco in the world, seems to be moving to SIP. The LTE networks and beyond are, more or less entirely based on SIP and RTP for signalling and audio transmission.
My simple refers to the ENTIRE system, not just asterisk. Adding another protocol to the mix, makes the system as a whole, more complex, but it might make that tiny fraction of configuration, that’s communication between asterisk servers, a bit more simple on it’s own.
It’s not that I don’t care at all, but if given the choice of a little less resource usage, or making our day to day troubleshooting easier, I’d go for easier troubleshooting, rather than a marginal reduction in system usage.
I mean, from the perspective of running a lot of different phone services, that all interconnect with each other, and external providers. I can train someone in troubleshooting signalling a LOT faster using only ONE protocol, no matter what it may be, than using a lot of different protocols, just because “It’s more right to do”.
Kinda like that same reason people use things like node.js, or electron. It’s easier to write everything in ONE language, then writing background services in C/C++/Python, web backends in PHP and the web frontend in HTML/CSS/JS, native software for crossplatform use in Swift, C# and C++, depending on wether the target platform is MacOS, Windows or Linux.
The smaller the techstack is, the faster you can train a new employee in using it.
In our network, all interconnects are SIP, Kamailio that runs the core routing functions, uses SIP, why should I use IAX2 between Asterisk servers, when SIP is an option? If I need a complete picture of the signalling path, inside our network, I can just capture and analyse all the traffic using tools like sngrep, that’ll allow me to see the entire message diagram at once. If I used multiple protocols I’d have to either make a custom tool, or use different tools to visualize the signalling.
This post has not been written top down, so if things seems to be repeated or doesn’t make chronological sense, that’s why.
If only having a hammer in my toolbelt makes it easier to do my work, even if it means hamming in the occasional screw.
There’s crashes everywhere in the issue tracker, in just about every module in active development, I’ve even got an open bug posted some 10 or so years ago.
True, I was just observing PJSIP has a disproportionally higher number of crash reports than other modules, including chan_iax2. There has been one general segfault issue with chan_iax2 in the last couple years, which I discovered and Sangoma fixed. There have been many PJSIP/pjproject issues in that same time.
That does not mean it’s a general problem, I’ve not had crashes related to PJSIP, and I’ve been processing a lot of calls using it. That, to me, means there’s no big issues, that suggests to avoid PJSIP, whenever possible. I’ve had my share of problems with random crashes all over the place, if the modules where the crash happened were to believed, I’d have to avoid most of Asterisk.
I’m not saying avoid PJSIP merely on this account, but rather than depending on usage, it can potentially have a negative impact, to the point where some folks (not me) have decided they can’t use it in production due to its instability. Take a look at this issue, for example: ASTERISK-28689: res_pjsip: Crash when locking group lock when sending stateful response
It’s been duplicated a whopping 5 times, yet Sangoma is not even currently working on it, even though it’s core supported. This doesn’t exactly build confidence in the stability of PJSIP.
Some issues are also present in the underlying pjproject that have not been addressed.
So “core supported”, widely used, etc. honestly I don’t think make as much difference as how stable the module is and how willing folks are to fix issues with it. PJSIP is the future, but, like most things, it’s far from perfect. I continue to use PJSIP, even though in my experience it’s less stable than modules like chan_iax2.
Easier to debug on the network, or Asterisk level? What tools exists to visualize the entire signalling flow of the call? sngrep does a great job of visualizing the SIP flow, for PJSIP we also have the HEP module that can forward signalling to homer, for analysis, what exists for IAX2?
Sometimes you need a high level overview of a call flow, troubleshooting does not always start on the individual server used to process it. It hardly ever does, as you need to figure out where the problem originates, before deciding what server to look at.
Fair enough, in my case though it’s usually straightforward to figure out what servers are involved and then trace the issue from there. Every environment will be different.
I still need to make a decision in regards to EVERY single module, and whenever something is updated, modules might disappear or change name, and new modules may appear, that I then also needs to make a decision about.
Automation works fine, if things never change, but if going from asterisk 16 to 18 or 18 to 20 requires you to make new decisions, you’ll need to update the automation tools, and you’ll not gain much from automating the process, except for minor updates, that can also be handled with “patch” or by just checking out the code from git, then updating the local copy whenever a new version is out. This preserves the selections made with menuselect, and gives the latest version anyway.
You can also just open menuselect for the new and old versions, then make sure to check the same boxes in the latest version, it’s a little slower, but the few times I’ve needed that, it’s taken a little over 10 minutes.
I guess if you only install Asterisk once a year, it’s fine. I probably install Asterisk once a week or more, since I also do development, so being able to compile and install automatically for me is a must have. I do update the scripts slightly as things change.
That doesn’t change the fact though, that Asterisk has a LOT of modules you need to make individual decisions about.
Sounds like a good idea, to clean up, there’s too much choice already.
Well, on that front, I think you’ll get your way
A lot of channel drivers are deprecated as of 19 and will be removed as of 21, like Skinny, MGCP, etc.
In the case of those two in particular, there are much better third-party Asterisk channel drivers than the built-in ones so I guess those aren’t any particular loss.
In general though, a basic requirement, for IP channels, should be to support any codec, for analog channels, that’s not possible, same goes for ISDN channels. But a rule of thumb, if it goes from IP to IP, transcoding should not be a requirement.
Sure, in my situation, we allow nothing but G.711a, as that’s what all our interconnect links requires, and reducing transcoding is a good thing, and as such there’s more or less no good reason for a channel driver that uses an IP connection, to not support any codec available. To my knowledge, SIP for instance, supports whatever codec you manage to put in the SDP payload.
Right, in theory I agree with you, but in practice, I only use G.711a as well and so my checklist is a) does it support G.711a? b) Great! Let’s move on to the next thing now
Well, maybe alaw support as well, and G.722 as well, but I dropped G.722 support a while back so it’s really just a/ulaw for me. In fact, I disable most of the other codecs outright, such as gsm, ilbc, etc. since they’re not necessary.
Funny, I’ve always seen IAX2 more like blackmagic, perhaps I just don’t understand it?
I can see what you mean by that - it’s almost too simple that you kind of wonder how it actually manages to work
At its simplest, really, you can set up a trunk with just two lines:
[my-trunk]
context = from-my-trunk
Obviously, that is far from the recommend way of doing anything, but this is a lot less “boilerplate” than needed with SIP (let alone PJSIP) to get something going. A more thoughtful trunk might look like:
[my-trunk]
context = from-my-trunk
secret=abcdefghijklmnop
auth = md5
encryption = yes
And still every telco in the world, seems to be moving to SIP. The LTE networks and beyond are, more or less entirely based on SIP and RTP for signalling and audio transmission.
Yup, I think you might say IAX2 won a specific battle, but SIP has won the war. It’s the “fax effect” in play - there can only be one major standard for doing this type of thing, and as IAX2 is Asterisk-specific really, it never had a chance. So depending on how important that one battle was, IAX2 may or may not be relevant to specific folks.
I use SIP for all my endpoints and some of my PSTN trunking, IAX2 for some of my PSTN trunking and all inter-Asterisk trunking (tie lines, etc.).
My simple refers to the ENTIRE system, not just asterisk. Adding another protocol to the mix, makes the system as a whole, more complex, but it might make that tiny fraction of configuration, that’s communication between asterisk servers, a bit more simple on it’s own.
I see your point. I think you’re more concerned about the social/people aspect of all this all - the team managing all this - and I’m more concerned about the actual technical properties of the system. Just different priorities. (Although for me, in terms of Asterisk interconnection, my experience is again that IAX2 is easier for us to set up - for a team already familiar with SIP and not other protocols, a different story likely).
It’s not that I don’t care at all, but if given the choice of a little less resource usage, or making our day to day troubleshooting easier, I’d go for easier troubleshooting, rather than a marginal reduction in system usage.
Sure - I guess in your case, SIP is easier to troubleshoot in your environment, and for me, IAX2 is. And there are other folks for whom DAHDI is probably easier, so pick your poision
I’ve run into resource problems with Asterisk in the past, and so I tend to run it on leaner systems which makes any resource issues (e.g. memory leaks) more obvious, so they can get fixed, which then benefits systems run at any scale. It’s a lot easier to notice and fix problems this way then just throwing more resources at something which tends to mask the problem. This is probably more of a development thing though.
I mean, from the perspective of running a lot of different phone services, that all interconnect with each other, and external providers. I can train someone in troubleshooting signalling a LOT faster using only ONE protocol, no matter what it may be, than using a lot of different protocols, just because “It’s more right to do”.
Kinda like that same reason people use things like node.js, or electron. It’s easier to write everything in ONE language, then writing background services in C/C++/Python, web backends in PHP and the web frontend in HTML/CSS/JS, native software for crossplatform use in Swift, C# and C++, depending on wether the target platform is MacOS, Windows or Linux.The smaller the techstack is, the faster you can train a new employee in using it.
Yeah, I think it’s just different people mindsets here.
For example, it can depend on specific environments - some Asterisk systems have no SIP running at all, since they have DAHDI for all the local endpoints and perhaps IAX2 for branch trunking. In that case, adding SIP to the picture does add something new in that implementation.
And FWIW, I will definitely do PHP in the backend and JS only in the frontend, only when necessary. I find I’m more productive this way since I can be more productive with PHP and only use JS when needed, as opposed to trying to use a single least-common denominator tool for everything. (As an analogy, you might need a car to arrive at a particular building, but it’s sure a lot slower to drive across the country in a car all the way there, then to take a plane or a train most of the way there, and then a car for the “last mile”).
So that’s at least generally how I tend to approach things: PHP and IAX2 for the long “back haul”, and then JS and SIP for the “last mile” when there’s no other option. But that’s just what works for me.
In our network, all interconnects are SIP, Kamailio that runs the core routing functions, uses SIP, why should I use IAX2 between Asterisk servers, when SIP is an option? If I need a complete picture of the signalling path, inside our network, I can just capture and analyse all the traffic using tools like sngrep, that’ll allow me to see the entire message diagram at once. If I used multiple protocols I’d have to either make a custom tool, or use different tools to visualize the signalling.
This post has not been written top down, so if things seems to be repeated or doesn’t make chronological sense, that’s why.
Not sure what you mean by chronological - it makes sense enough to me though. Different ecosystems and approaches to management. I don’t find SIP easier for me to work with, but the great thing about Asterisk is that we can each use the tools and resources available to the extent that makes the most sense for each of us. Lots of ways to skin a cat… or make a phone call.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.