Hello all,
We are unable to view the visual pickup (on Yealink) correctly when using PJSIP.
What we currently see on the display:
We already tried modifying pjsip.endpoint_custom_post.conf by adding:
1000
notify_early_inuse_ringing=yes
notifycid=yes
1001
notify_early_inuse_ringing=yes
notifycid=yes
but it didn’t make any difference.
Thanks for your help!
Unfortunately this is still a limitation in PJSIP in that regards. It does not have the full XML body that contains all the settings for the phone to automatically append them to the ** so when you hit the BLF it’s displaying ** and waiting for you to tell it what extension you want to pick up.
This is one of the reasons I haven’t fully migrated to PJSIP on all my users. Some need one-touch directed call pickup and want full CID details for BLF. In those case I keep them on Chan_SIP because it works.
There is a patch for Asterisk to resolve this issue for PJSIP but I haven’t had the required time to spend applying to the Asterisk package Sangoma uses and test it. Though from what I’ve seen by other’s testing with straight up source code based Asterisk, it works.
Honestly, I’m hoping it ends up rolled into Asterisk 17. 
Hello Tom,
I was hoping you would reply on this post 
I saw your reply on a post on January 26 (55988) with someone having the same issue.
Before migrating all our many hundreds of users back to CHAN_SIP… can you please share the patch which could work? Do you already know if this patch has any negative side effects?
Since Asterisk 17 has no LTS, we will never upgrade to it :(.
I will also take this chance to advise all users not to migrate to PJSIP. In my point of view it’s still not mature enough to use in production environments.
It worries me PJSIP is already present for many years, and still these kind of issues are showing up.
As you already pointed out, there is also currently no way to use global endpoint settings for all extensions.
Thanks a lot for your reply!
Update: I found a reply on the Snom forum where someone submitted the following patch in February 2015 to the Asterisk team, but I don’t see any update on that.
Adding the line: ast_sip_presence_xml_create_attr(state_data->pool, dialog, “direction”, “recipient”);
after line 135 in the file res_pjsip_dialog_info_body_generator.c
Fingers crossed you found a better patch without recompiling Asterisk
That change was already merged. The fix for this is a separate change. It’s available on JIRA[1], it’s the latest patch. It hasn’t been merged as noone has put it up for code review and taken it through the process. Such a change does require recompiling Asterisk.
When / who from the Asterisk team will finally put the code for review and take it though the process then? This bug looks to be reported in Dec’14…
In our case we are using Yealink phones and not Snom. I assume the patch will also fix it on Yealink?
What will need to happen to have it fixed in Asterisk 13 without recompiling? We are using the Distro version which shouldn’t be altered for support reasons.
It’s impossible to fix it without recompiling.
Anyone who has signed a license agreement can put the change up for review and take it through the process. It is not dependent on the Asterisk team to do so, and generally we don’t (as we’re quite busy).
Once up for review we will then review it, provide feedback, and sometimes we do take it over at that point.
The reason for this is that we can’t do everything and we meet the community half way (or more) on it. If a person is interested and willing to get the code into Asterisk by putting it up for review then we’ll help get it in.
That’s really unfortunate to hear… We will migrate all our end-customers back to CHAN_SIP then.
Once it’s, any the other flaws, are finally fixed in Asterisk LTS, we move back to PJSIP.
@All Sangoma staff: Please stop pushing people towards PJSIP since it will break your working environment.
OK I get you’re bummed by this but before you start making blanketed demands you need to step back and take a breath.
First, how did you end up with hundreds of users on PJSIP only to then find out all the features you wanted to push into production where not working? Did you not test any of this before going to production?
Second, this is a very specific feature that is having an issue. Not everyone needs this. I have about 100 users that need it but for me that’s less than 10% of my user base.
Third, Chan_SIP is deprecated. It’s been deprecated since Aug 2014. All the updates/bug fixes in Chan_SIP since then have been community driven. In fact, as of Asterisk 17 Chan_SIP should be moving to “no-load” which means you have to enable it to use it. While the Sangoma package will most likely have it loaded that does mean something. Such as it’s on the road to being fully removed.
And finally
Yes, it will be a Standard release but you know what it will also have? All the new features and updates that will end up in 18 which will be LTS. That means someone like you, with many many 100’s of customers on their boxes, can actually spin up a lab and test all the new things that are in v17 (and thus v18) so that when v18 comes out next Oct you’re pretty much 90% there with your testing and knowing what works for you and what doesn’t.
There are many other functions/features in Asterisk than visual pickup… we really cannot test every single one of them before migrating unfortunately. As CHAN_SIP is deprecated and we are all pushed towards PJSIP for years, I trusted the Asterisk team. Also, it’s not our core-business to have a QA team for it.
As I understand we need to test every single feature before upgrading from now on… We will for sure not put resources on it migrating to non LTS versions.
I have yet suggested or said move your customers to a non-LTS. I said you can lab Asterisk v17 and you can test it. As for not testing features that you sell or market to your end users, that’s BS. I’ve been doing this for a very long time and pushing out features in a service that have not been tested just causes a bunch of unneeded support and could result in the fact the feature doesn’t work and you have to recall it. None of those scenarios make you look good so why even put yourself in that position?
You are either providing customers FreePBX because they requested it specifically. In that case you can just easily say this is a vendor limitation and yeah there could be issues. Or you are offering your customers voice services and are using FreePBX/Asterisk in order to do so. In that case the onus is 100% on you to make sure the features you are saying are supported by your service are, in fact, supported.
So yeah on the one hand I get where you are coming from. I still have to use Chan_SIP to support some features that some customers want/need. On the other hand, I also didn’t run into the issue of deploying them all on PJSIP to find out it doesn’t work by having those 100+ users opening support issues about their Call Pickup/BLF features being broken. I did that by testing everything first before making the decision.
Thanks for your help on this… but let’s close this thread for now.
We were forced to move to PJSIP since CHAN_SIP is not supported anymore.
So staying with CHAN_SIP is also not an option unfortunately.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.