Interesting as their source code online does not have these patches which is in violation of the GPL of asterisk. This has come up over and over with them. They keep hiding their patches and source changes and playing games with Digoum and Sangoma. If you are reselling the product you open yourself up for liability since you are distributing a product to a customer that you do not have the proper source code for. Of course Yeastar is also liable but as a chinense company their is not much you or us can do to them. Another reason not to do business with companies like yeastar.
They have a US office in Dallas, TX.
We are very aware of their offices and Corp structures. Doesn’t change the whole Chinese company in the end but we are looking at all of our options on the table against them and others doing the same thing.
Like this year, 2018? Or the “AstriCon Year” ala Oct 2019?
And thank you for all feedback i didnt want the thread to be this long. I do agree with sangoma support you cant fix somthing you dont know is broken,
I have to build a phone system for a hospital which is 24/7 open and i have to make sure everything works on the way suppose to. I pick sangoma because they are working hard to provide us with a phone system which is very affordable and good system, I have deployed 3 PBXact and i will keep switching customers from different platform to sangome and sipstation.
Thank you team
We are trying to replicate this. Can you tell us what version of Asterisk and are you able to replicate this still with updsted asterisk.
Not sure about the BLFs, but we have about 100 extensions (Sangoma S300, S400, S705s, and a few Yealinks) running PJSIP. The main issue that I’ve come across has been CallerID on what I call a warm transfer. The person hits transfer, dials an extension, wait for it to ring, and then hangs up. If the other end is using chan_sip, the CallerID updates to the transferred call. If you use PJSIP, it doesn’t update. I opened a ticket with Sangoma (Ticket # 840804). This is an Asterisk issue and waiting to see when that will be resolved. This is an issue with our facility, as people see an incoming call from what appears to be a local extension and get surprised that it is an outside call, since the caller ID doesn’t update.
In regards to lights on the keys themselves, I do have issues with some Yealink phones that we’ve started using. With the T41S and T46S (running V81 firmware), it sometimes takes a while for the lights to work with the Parking app. And on the Yealinks, the Phone apps never show “green” or available. They usually turn Red when they are busy, but that has been inconsistent.
Again, the last comment is that both the SIPstation module and Vega Gateway modules require you to use chan_sip extensions or chan_sip, in case of SIPstation. If the goal is to move everyone to PJSIP, then I figured those would begin switching over to PJSIP as well.
SIPStatuon does not require you to use chansip. In advanced settings you can pick what it uses and in a update soon it will default to pjsip instead of chansip. I will check into Vega module as that should also use PJSIP by default.
Ah, I see the “experimental” mode under Advanced settings. I’ll have to test that out and see about switching over. It took me a little bit to get SIPstation to works, with some NAT settings on or Sonicwall (ie, switching 5060 -> 5160 and vice versa).
It happened in 13.22.0 and the Equivalent in 15.
We redistributed customers between 2 different servers and switched them all back to chan_sip so we are not setup to replicate on the original server/s. Cannot run a live test with already pissed off customers either.
Do you guys have a way to register hundreds of fake VOIP phones to a server with BLF’s and Voicemail? We may have a backup hiding somewhere and we have a spare server. I might be able to recreate the problem and give you full access to a server doing it, would have to double check if I can spend time on this if your able/willing to try that.
You are clearly using FreePBX as a ITSP/VoIP service provider solution. That’s problem #1. The other issue is that there has been an ongoing conversation in the #asterisk IRC room with others using Asterisk for their ITSP/VoIP services and I’ll be honest, every single one of them ran into your issue.
This was for a two-fold reason. 1) No one has actually benchmark tested PJSIP in an environment with high end 100’s to 1000’s of endpoints let alone the amount of contacts that could end up on the endpoint. 2) They all pretty much did the same thing. They converted production systems to PJSIP without actually testing anything on another system.
As @tm1000 pointed out PJSIP does not have the same settings or configs as Chan_SIP and you need to make sure you have the right ones in place and that the conversion was completed properly. So when people are saying things like “X doesn’t work on PJSIP” it is probably because they actually haven’t read up on what the options are and how PJSIP handles X now.
Like I said, you’re using FreePBX as an ITSP/VoIP provider solution to host multiple customers on the system. There have been no real modifications to the system to support this type of deployment based on your output. FreePBX is not setup for this type of deployment and using PJSIP within FreePBX limits you to how FreePBX does PJSIP so unlike Chan_SIP you can’t just throw in a bunch of settings or “override” them because that’s not how PJSIP works.
Another part of the issue, you’re using FreePBX/Asterisk alone which in your type of setup is just bad, bad, bad. Look, I use FreePBX to do what you are doing but my boxes have been heavily modified and have a lot of custom things done to them to support the fact I’m using it in a “non-PBX” method. Additionally, I have SIP Proxy/Switches that handle things like Registration/Location services and handle dealing with the NOTIFY/SUBSCRIBEs between Asterisk and the end users. This takes a lot of the load off Asterisk with the Proxy dealing with most things between it and the devices before they get sent to Asterisk.
It also limits the amount of dialplan and “outbound routes” that Asterisk has to process because all of the digit manipulation is handled at the Proxy so when it hits Asterisk the call just routes out without having Asterisk do the processing on a lot of the call.
For sure we have the ability to register thousands of phones and BLFs and simulate it all. its all part of the load testing and testing suite we do. We have scheduled for R&D to try and replicate this in the past we have not been able to see the issues you are reporting but its being looked at again.
Also, I would love to know how this happened. I use Polycoms as my primary phone for end users. I also have them on PJSIP with BLF’s. Plus if it “registered” 27K times then you have a serious issue.
I am very curious about your setup now because you are making claims that no only PJSIP seem weird but SIP in general because 27K different “subscribes” from one user is a serious issue with the SIP dialog/transactions themselves.
You quoted how I did that. While on PJSIP asterisk allowed that polycom phone to register to a BLF hint indefinitely. Did not happen with chan_sip. As long as the phone was connected it ticked up the counter every second or so. Is it difficult for you to replicate?
Besides a custom firewall, which ends up going to from-internal for all allowed situations, preventing the phone from calling certain extensions there is not that much different about the extension compared to the defaults.
That’s how it works. The device will send a new REGISTER or SUBSCRIBE when their Expire timer is reached. A SUBSCRIBE starts a “dialog” which every NOTIFY and new SUBSCRIBE from the device is a part of. I’m not sure what counter is ticked up outside of the amount of Watchers a hint has.
If you’re referring to the CSeq: header, that should always tick up +1 during the auth process. The first SUBSCRIBE will be CSeq: 1 (if a fresh reboot) the PBX will challenge it and it will send another SUBSCRIBE with CSeq: 2. This will continue to happen with each new SUBSCRIBE. So the next one will be 3 then when challenged 4, and so on and so on.
OK so in that do you make sure all their hints are separated? Voicemail access? Etc, etc etc. The logic of the PBX is that all users are able to communicate with each other. There are numerous things that are shared across all users and things that all users can access.
You’re also just restricting where the “users” can call. What about all the other things for calls? Everything is in the general dialplan so when calls are routed to extensions they check the ext-findmefollow and ext-local, etc, etc which means any call (in or out) that get pushed through certain contexts and flow still have a change to hit your other customers extensions or hints or anything…
If you are trying to make this a “Multi-Tenant” system then you basically need to give all your “tenants” their own dialplan flow. You can dip and call on existing apps, functions, etc but you need to do more than change “from-internal” to “from-customer” and just limit where the user can dial.
There are a lot of ways even your “restricted” users can end up on dialplan flow that gives them access to all the other users.
OK so there are 7K watchers in that output and this was from the PJSIP setup?
Is there any related PCAPs or traces showing the SUBSCRIBEs to either of those hints? These would show why this is happening or at least what is occurring during the process. Without those, there’s no way to actually tell what the issue is/was.
Also, when you did the conversion did you let PJSIP take over the port Chan_SIP was listening on or did you have PJSIP on a different port?
Users don’t touch their own phones very much at all and most of the don’t want to. They just want their phones to work. Separating hints is theoretically good but in practice a butcher isn’t going to try to access a flower shop’s hints or even care when all they do is press buttons on a phone and never log into the phone GUI. A person in the 1XX range doesn’t want to accidentally call someone in the 2XX range. They don’t touch the admin GUI either and don’t want to.
Not been a problem. We setup their call flow they don’t set it up.
Customers cannot call one another and cannot jump between call flows. The call flow isolates them from inbound-routes and we isolate IVR’s with direct dial directories. They cannot call one another. This has worked well.
Correct it was on PJSIP.
I was able to replicate it on a test Polycom 550 right away when I tried it before. PCAP from the Polycom or from asterisk? If from asterisk how?
Chan_SIP = 5060
PJSIP = 5062
PJSIP = 5060
CHAN_SIP = 5062
Also tried removing Chan_SIP but that didn’t help.
Asterisk, if you please. You can do:
pjsip set logger on
Let some subscribe’s roll by and get the dialog interactions for them. Should be able just to post it here.
A little late to the party, but I’m looking into this on the Asterisk side of things. Got an environment set up with a large number of PJSIP endpoints, hints, subscriptions, etc. Stress tested the system and get slightly choppy audio at around 200 calls run via sipp (REGISTER, multiple SUBSCRIBES, followed by an INVITE), which will happen under large call loads. Is that similar to your issue? Also, can you specify the difference between 20-30 calls and the 400-500 mark for PJSIP you mentioned in your earlier comment? That would help narrow down what the problem could be.