[jitsi-dev] [jitsi] attended call transfer does leaves the initial caller on hold (#139)


#1

Consider the following scenario which seems to be caused by Jitsi.

We have experienced this issue on two different versions of asterisk (current one is 11.18.0).
We also do not have this issue with another softphone.

The Jitsi versions tested include 2.8.5426 on mac and 2.6.5390 on ubuntu linux.

- Customer calls agent A
- Agent A picks up the call
- Agent B wants to transfer the call to Agent B and puts Customer on hold
- Customer hears music on hold
- Agent A sets up a new call to Agent B
- Agent B picks up the call
- Agent A transfers Customer to Agent B

What happens next is that in about 50% of the cases:
- Customer remains to sit in on hold and hears music on hold
- Agent B does here Customer

When Agent B toggles the call on hold and takes it off hold again, two-way audio is established between Customer and Agent B.

PCAP traces can be provided if required.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/139


#2

Do you by chance have direct media enabled on your extensions in Asterisk? This sounds loosely related to a problem discussed on the [mailing list](http://lists.jitsi.org/pipermail/users/2015-June/009631.html).

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/139#issuecomment-128131626


#3

We had directmedia enabled initially, but I've also tried with directmedia disabled on the two agent extensions + the upstream SIP trunk to the SBC. Same result.

This was verified with 'sip show peer xxxx', which clearly marked the peer as 'Directmedia: no'

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/139#issuecomment-128133677


#4

Can you please upload the .pcaps somewhere? Also, how is your dialplan generated?

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/139#issuecomment-128279570


#5

We run FreePBX as the management interface on top of asterisk, so FreePBX is responsible for generating the dial plan. Any specific details from the dialplan you are after?

I will PM you on your @jitsi.org address where to get the PCAP tracefiles. As these will contain real telephone numbers, I don't want to make these publicly available.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/139#issuecomment-128308573


#6

Knowing that it's FreePBX is enough. We use Asterisk 11/FreePBX 11 at work as well and I haven't heard of such problems from our users. There used to be issues when encryption (media SRTP with SDES) was enabled, but these have long been fixed.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/139#issuecomment-128310449


#7

PM with PCAP location sent.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/139#issuecomment-128315887


#8

I looked through your logs, but I couldn't find anything suspicious. All call legs seem perfectly normal from the SIP traces. What strikes me as odd anyway is that "customer" still hears the MoH after the transfer has been completed. MoH comes from Asterisk and would need to be stopped there. I don't really want to blame Asterisk or FreePBX as you apparently don't have problems with other phones, but it sure looks like something goes wrong on that side.
Are you able to reproduce this with either plain Asterisk or with FreePBX 2.11? I did a couple of test calls/transfers with Asterisk 11.16/FreePBX 2.11/Jitsi 2.9.5456 and couldn't reproduce this at all.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/139#issuecomment-128964995


#9

Will run some more tests and revert back.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/139#issuecomment-130207703


#10

Further tests have proven that we do have similar issues with other (hard) phones, but only when directrtpsetup = yes

Disabling directrtpsetup makes the issue go away for hard phones.

Will continue to investigate.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/139#issuecomment-135159197


#11

I can only advise you not to use directrtpsetup. There's just too much that can go wrong with all the network elements involved, especially if NAT is in the game anywhere in the path. Additionally you can't use music on hold (as that would need to be coming from the phones, not Asterisk - see the referenced thread on the mailing list in my first comment).
But are you saying the issue persists in Jitsi even with directrtpsetup=no?

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/139#issuecomment-135174503


#12

I understand your point about directrtpsetup, but we understand this well and have been using it for +5y.
We operate in an environment separate from the internet, with no NAT at all and full IP connectivity between the phones, the PBX and the upstream SBC's.

The reason we highly prefer to use directrtpsetup, is that this allows us to keep the RTP streams away from the FreePBX'es instances, which we run as VM's.

Yes, with jitsi we experience the issue with no directrtpsetup enabled. Asterisk continues to set moh to jitisi in that case. Putting the call on hold and taking it back off hold provides a deterministic workaround.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/139#issuecomment-135867156


#13

Hello simplexify.
I have the same problem with the phones cisco 7940.
You have got to solve it?

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/139#issuecomment-150147063


#14

Hi mischenkovn

Not yet been able to make the time to further look into this, as we have a workaround in place which is sort of releasing the pressure off this.

Will try to report back soon with more feedback.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/139#issuecomment-150155216