[Home]

Summary:ASTERISK-26333: Problems with Blind Transfer, PJSIP (Aastra 6869i)
Reporter:Matthias Binder (mitterhuemer)Labels:
Date Opened:2016-09-02 04:18:57Date Closed:2017-06-01 09:50:21
Priority:MajorRegression?
Status:Closed/CompleteComponents:pjproject/pjsip
Versions:Frequency of
Occurrence
Constant
Related
Issues:
Environment:Attachments:( 0) asterisk_capture_+_6869i_syslog.zip
( 1) capture-asterisk-good-case-chansip.pcap
( 2) chan_pjsip.JPG
( 3) chan_pjsip2.JPG
( 4) chan_sip.JPG
( 5) patch-for-awesome-transfers.diff
( 6) syslog-good-cas-chansip.pcap
Description:Sangoma told me to open a issue in the asterisk tracker.

We cannot do PJSIP Blind Transfers on the Mitel 6869i Phone.

The Problem is already analysed by Mitel Support and they made a Statement about the problem and showed up a workaround for this problem.

The asterisk pjsip needs to be changed to solve the Problem.

http://community.freepbx.org/t/problems-with-blind-transfer-pjsip-aastra-6869i/34393/20

{quote}
HI there,

After having a look at the sip traces I have come to the following conclusion:

The Problem:

The channel drivers CHAN_SIP and CHAN_PJSIP seem to implement the REFER method differently.

-- CHAN_SIP responds the REFER with an "202 Accepted" followed by a "200 OK" in NOTIFY sip/frag body as soon as Asterisk knows that the user can be reached.
https://issues.asterisk.org/jira/secure/attachment/54361/chan_sip.JPG

-- On the other hand CHAN_PJSIP notifies all the progress details of the C user e.g. Trying, Ringing etc. It sends a "200 OK" ONLY if the called user answers the call.
https://issues.asterisk.org/jira/secure/attachment/54360/chan_pjsip.JPG
https://issues.asterisk.org/jira/secure/attachment/54362/chan_pjsip2.JPG

This leads to the stated issue because in case of Blind Transfer, Mitel Phones expect a "200 OK" after REFER has been accepted. Otherwise the line is kept busy. This is by-design with no intension to change it at the moment.
{quote}
Comments:By: Asterisk Team (asteriskteam) 2016-09-02 04:18:58.947-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

By: Rusty Newton (rnewton) 2016-09-07 13:41:09.827-0500

Howdy,

Any relevant details, images, traces and so on need to be posted or attached here. I appreciate the link to the other forum, but we need anything relevant or helpful here.

If you have a wireshark viewable trace showing the exact call behavior that is problematic with the phone then that would be really helpful.

By: Matthias Binder (mitterhuemer) 2016-09-07 14:03:10.284-0500

PJSIP Syslog from Phone and Wireshark TCPDUMP Capture of the Blind Transfer issue

By: Matthias Binder (mitterhuemer) 2016-09-07 14:15:00.631-0500

Syslog of the Chan_SIP Good Case

By: Matthias Binder (mitterhuemer) 2016-09-07 14:15:30.622-0500

Capture Asterisk Good Case chan_sip

By: Matthias Binder (mitterhuemer) 2016-09-07 14:17:48.939-0500

Okay, i attached the Screenshots from the Mitel Support.
I also attached the chan_sip good case captures where everything is working.

The .zip file asterisk capture + 6869i syslog.zip contains the not working blind transfer captures.

By: Rusty Newton (rnewton) 2016-09-07 14:58:37.855-0500

Thanks [~mitterhuemer] !

By: Matthias Binder (mitterhuemer) 2016-09-19 16:05:18.925-0500

Hi @rnewton
are there any news about that? Will this be fixed in a future release?

By: Joshua C. Colp (jcolp) 2016-09-19 16:08:57.592-0500

The issue has been accepted and is in queue. Any updates will be posted here but I have no timeframe.

By: Rusty Newton (rnewton) 2016-09-22 13:18:54.425-0500

Your patience is appreciated as a developer may work the issue when time and resources become available.

Asterisk is an open source project and community members work the issues on a voluntary basis. You are welcome to develop your own patches and submit them to the project.[1]

If you are not a programmer and you are in a hurry to see a patch provided then you might try rallying support on the Asterisk users mailing list or forums.[2] Another alternative is offering a bug bounty on the asterisk-dev mailing list.[3] Often a little incentive can go a long way.

[1]: https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process
[2]: http://www.asterisk.org/community/discuss
[3]: https://wiki.asterisk.org/wiki/display/AST/Asterisk+Bug+Bounties



By: Matthias Binder (mitterhuemer) 2016-10-06 13:08:00.866-0500

We came across that we have this issue also on our Snom M700 Station with M65 Handsets.

They told me that they have to wait until the call is answering on blind transfer before they can hangup the phone.

By: Ross Beer (rossbeer) 2016-10-26 09:16:17.932-0500

I believe this also causes issue on other Snom models too

By: Matthias Binder (mitterhuemer) 2017-03-22 20:31:01.630-0500

Mitel released a new Firmware some days ago.
They did not fix this bug.

I think we have to patch it on asterisk.

By: cmaj (cmaj) 2017-05-02 02:16:58.445-0500

Patch added for alternative dial plan solution to slow transfer problem that extends configs/basic-pbx examples for Super Awesome Company PBX.

By: cmaj (cmaj) 2017-05-04 16:01:14.306-0500

The patch takes stock of the SIPTRANSFER variable, which is set to "yes" on blind transfers in res_pjsip_refer.c

The one second silence Playback is what gets the SIP 200 OK response from Asterisk that the phones are looking for.

https://issues.asterisk.org/jira/secure/attachment/55434/patch-for-awesome-transfers.diff

By: Alexei Gradinari (alexei gradinari) 2017-05-08 16:12:22.094-0500

Patch for review https://gerrit.asterisk.org/#/c/5602/

This patch added a new PJSIP endpoint option "refer_blind_progress"
to turn off notifying the progress details on Blind Transfer.
If this option is not set then the chan_pjsip will send NOTIFY "200 OK" immediately after "202 Accepted".


By: Friendly Automation (friendly-automation) 2017-06-01 09:50:22.991-0500

Change 5602 merged by Jenkins2:
res_pjsip: New endpoint option "refer_blind_progress"

[https://gerrit.asterisk.org/5602|https://gerrit.asterisk.org/5602]

By: Friendly Automation (friendly-automation) 2017-06-01 09:54:31.159-0500

Change 5609 merged by Jenkins2:
res_pjsip: New endpoint option "refer_blind_progress"

[https://gerrit.asterisk.org/5609|https://gerrit.asterisk.org/5609]

By: Friendly Automation (friendly-automation) 2017-06-01 10:07:26.768-0500

Change 5610 merged by Jenkins2:
res_pjsip: New endpoint option "refer_blind_progress"

[https://gerrit.asterisk.org/5610|https://gerrit.asterisk.org/5610]

By: Friendly Automation (friendly-automation) 2017-06-02 16:33:50.113-0500

Change 5745 merged by Jenkins2:
pjsip/immediate_ok_notify: Add test for 'refer_blind_progress' option.

[https://gerrit.asterisk.org/5745|https://gerrit.asterisk.org/5745]