Blind Transfer - Drops call - No reinvite after refer

[Brandon B]

Hi Everyone - we are having an extremely rare but problematic issue with blind transfers that we just can't seem to get a lock on.  Here is to hoping that someone else out there has seen it and might have some advice! We only get notice of it happening from one client...but they are pretty high volume, and the receptionist is REALLY fast at pushing buttons (maybe that is it?) and does a lot of blind transfers. Essentially what is happening is:

1. Call comes in (device = Polycom VVX 410).  (normal invite, all looks correct)

2. Receptionist hits transfer, (we see the invite to hold that looks very normal)

3. Hits blind, dials the user's extension.  (we see the refer and all looks good)  

4. We see the normal signaling (202 accepted, the BYE, the 481 Call Leg does not exist, 200 OK)

5. The caller goes on hold and gets stuck there.  

6. The referred party never receives the call at all.

We NEVER see the new invite from the caller to the new extension after the refer.  It just never shows up at all.  

What is even more confounding is it works a good 90% of the time.  Ruled out firewall issues we think, because the refer is there - we just don't see the re-invite.  Ruled out phone config issues, because 90% it works.  comparing one that does work for the same client literally is identical, the one that works just has a following reinvite.  

Any thoughts?  I've got logs ready to rock if anyone is up for looking - just didn't want to clutter the question if it scares everyone away. :D

[J. Erickson]

I don't have a solution for you, just wanted to let you know you're not going crazy. I have seen this same issue with a customer that is fairly high volume on inbound calls. Their receptionist is also is very quick on her phone (and also has a VVX 410!) and transfers most of the inbound calls she receives to other users or to ring-groups (they are a construction supply wholesaler so they have too many departments and specialists to make an IVR tree that wouldn't irritate callers, she transfers calls based on a short Q&A session with the caller). Callers occasionally get permanently stuck in a hold state after being "transferred" and the transferees phone, or the ring group, never rings. My evidence is the same as yours. Successful REFER with no follow-up INVITE to the transferee. They are on a high quality router (Adtran 4305 2nd Gen) and internet connection. Industrial-grade (not UBNT crap) point-to-point wireless link to an ISP PoP with a fiber loop straight to the datacenter where our Kazoo cluster is hosted - ping-time from Adtran to the whapps server is a consistent 1.5-2 ms even though they are 25 miles away from the DC and the last 20 miles to CPE is wireless. No SIP ALG or NAT funny-business.

I thought maybe it was a dropped packet situation, but their connection has persistently passed muster under daily load testing conditions (100% ping response with 100,000 100-byte packets sent at 100 ms intervals while maxing their download rate), and besides that, the SIP UDP packets are sent 3 times each. Regardless, I'm loathe to blame their internet connection. It's a $10,000 piece of wireless equipment and it has been triple checked by a wireless engineer that I trust working in tandem with their ISP. Their signal quality is prime. They never even have complaints about call quality and all my capture analyses for their calls came back with the highest possible MOS scores for g.711 (4.41).

This was occurring as recently as 3.20 and 3.21, although I haven't had a recent report from them (currently running 3.22 in production). I'm not sure if it was inadvertently fixed due to Erlang code/Kamailio config overhauls related to transferring, or if the customer just decided to stop reporting them. I'm planning on asking next time they contact me with a callflow change request (fairly frequent for them).

Which version of the Kazoo code are you running? Kamailio? If you are running older code I would try upgrading (if your situation allows for it).

[Brandon B]

Mr. Erickson!  Thanks so much for the reply on this, and I've got the paperwork in to get checked out of the asylum. ;)  We did a bunch of testing on this yesterday also and no real help.  5-10% of the time on blind transfer OR on a Park it will do this.  FSW shows the call there, but no BLF notifies sent, and they just go on hold with no hold music.  The Ladder diagram, refer and invite SDP are literally identical when it does work vs. doesn't work.  We will give the update a shot as I believe we are running 3.21 currently and hopefully that helps.  Thanks again for the reply!

[Luis Azedo]

Hi,

what freeswitch version/release are you guys runnning ? 

--
You received this message because you are subscribed to the Google Groups "2600hz-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to 2600hz-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brandon B]

Hey Luis - good to hear from ya! freeswitch: 1.4.15-3 and our kazoo is 3.21-34.  Plan tonight is to upgrade fsw to 1.4.26-0 and kazoo to 3.22-14

[Scott Burlovich]

Please keep us in the loop about the upgrade, I am also having this same issue intermittently on 3.21...