Troubles with Attended Transfer

General Help
1

I’m doing some research on this one but I thought I’d post here as well.

I have a customer with a FreePBX deployment, which is the same as 20 other customers. FreePBX is hosted in our colocation, and phones exist at the customers premises. Using Polycom IP450 handsets - again, identical setup to our other customers, same firmware and configurations etc. I also have the same “lab” next to me on my desk.

The customer is unable to do an attended transfer, however can do blind transfers just fine.

I believe I found the problem with a packet capture, but not sure where to go to from here.

Here is part of the SIP dialog that shows what I believe is the problem (the REFER and NOTIFY);

U 111.144.1.54:49152 -> 111.22.126.20:5060
REFER sip:[email protected]:5060 SIP/2.0.
Via: SIP/2.0/UDP 111.144.1.54:49152;branch=z9hG4bKd404118dA614A389.
From: "Grant" <sip:[email protected]:49152>;tag=B72C21C9-CD2C6D8D.
To: "61755123456" <sip:[email protected]>;tag=as2cbbd003.
CSeq: 4 REFER.
Call-ID: [email protected]:5060.
Contact: <sip:[email protected]:49152>.
User-Agent: PolycomSoundPointIP-SPIP_450-UA/4.0.8.1608.
Accept-Language: en.
Refer-To: <sip:[email protected]:5060;user=phone?Replaces=84bf3f8d-9d9589-abe99dcd%4010.1.1.43%3Bto-tag%3Das1fdaa66e%3Bfrom-tag%3DF744D4CD-474D4C49>.
Referred-By: <sip:[email protected]>.
Max-Forwards: 70.
Content-Length: 0.
.

#
U 111.22.126.20:5060 -> 111.144.1.54:49152
SIP/2.0 202 Accepted.
Via: SIP/2.0/UDP 111.144.1.54:49152;branch=z9hG4bKd404118dA614A389;received=111.144.1.54;rport=49152.
From: "Grant" <sip:[email protected]:49152>;tag=B72C21C9-CD2C6D8D.
To: "61755123456" <sip:[email protected]>;tag=as2cbbd003.
Call-ID: [email protected]:5060.
CSeq: 4 REFER.
Server: FPBX-AsteriskNOW-2.11.0(11.14.2).
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
Contact: <sip:[email protected]:5060>.
Content-Length: 0.
.

#
U 111.22.126.20:5060 -> 111.144.1.54:49152
NOTIFY sip:[email protected]:49152 SIP/2.0.
Via: SIP/2.0/UDP 111.22.126.20:5060;branch=z9hG4bK52fc6dfd;rport.
Max-Forwards: 70.
From: "61755123456" <sip:[email protected]>;tag=as2cbbd003.
To: "Grant" <sip:[email protected]:49152>;tag=B72C21C9-CD2C6D8D.
Contact: <sip:[email protected]:5060>.
Call-ID: [email protected]:5060.
CSeq: 105 NOTIFY.
User-Agent: FPBX-AsteriskNOW-2.11.0(11.14.2).
Event: refer;id=4.
Subscription-state: terminated;reason=noresource.
Content-Type: message/sipfrag;version=2.0.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
Content-Length: 49.
.
SIP/2.0 481 Call leg/transaction does not exist.

#
U 111.144.1.54:49152 -> 111.22.126.20:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 111.22.126.20:5060;branch=z9hG4bK52fc6dfd;rport.
From: "61755123456" <sip:[email protected]>;tag=as2cbbd003.
To: "Grant" <sip:[email protected]:49152>;tag=B72C21C9-CD2C6D8D.
CSeq: 105 NOTIFY.
Call-ID: [email protected]:5060.
Contact: <sip:[email protected]:49152>.
Event: refer;id=4.
User-Agent: PolycomSoundPointIP-SPIP_450-UA/4.0.8.1608.
Accept-Language: en.
Content-Length: 0.

.54 - Customer’s site (phones are NAT’ed behind this IP)
.20 - FreePBX, no NAT.

So, I figured that the NOTIFY contained that 481 error sipfrag message because the third party is unable to INVITE the SIP dialog URI reference in the Refer-To field in the REFER message?

If so, I’m not sure how I would start to troubleshoot this - this would mean that one of the dialogs disappears mid transfer? Also wondering if NAT (at the customer end) could be a cause of an issue here too - I notice that the Refer-To URI contains a private address, but, the phone should be able to connect to this over the local area network - is there any reason why it wouldn’t? Direct Media perhaps?

All the worse, I can’t replicate this issue on my lab setup which is pretty much identical. I am going to go through and confirm identical phone configs and etc. The NOTIFY in my lab contains the sipfrag message “SIP/2.0 200 OK”, everything else in the SDP’s is pretty similar (apart from addresses) and it all works as normal.

Thanks in advance,

Update Edit: So, doing some testing now. I registered some phones here at the office, to the customers FreePBX install. I can’t replicate the issue, on the same PBX, with the same handsets/config/firmware - whether it be an attended transfer between internal extensions or an attended transfer with a call coming in over the trunk, it always works. This leaves me to suspect equipment at the customer end - I’m going to now point the finger at NAT on their router.

2

Well I don’t know how much trouble youwant to go through to fix this, but to be certain all is in your lab as it is at customers place, you can take a backup of FPBX and their phones. Setup a replica of their system, FPBX (In virtual?), with a set of routers you have that are setup the same way to duplicate NAT, and then hook a polycom that has been “restored” using a real backup from their phones. If it work ok, then you can wag and point that finger at their equipement, otherwise maybe it’s some silly setting on the phone (Try factory reset with basic SIP acct info, and work up from there.)

Just my thoughts though.

3

Hi Marc,

Thanks for the reply - I’ve pretty much done this already. Their handsets are configured via HTTP with templates sitting on their PBX, we use OSS EPM for this. I’ve registered the same model handsets here, using the same configuration template so that should be identical - and it’s all using the same FPBX instance as the customer. The only thing I can’t replicate is their router, they supplied the router themselves (a Netgear) and we don’t stock this model.

We are going to send out one of working lab handsets to the customer as a test, to ensure it definitely ISN’T the handset or, some gremlins lurking in an existing config, I think the customer bought second-hand handsets and not sure if they were factory defaulted.

I’m pretty sure it’s not a PBX or handset configuration thing, and I am still focussing on configuration in the router.

I guess, what I want to know is the URI after Replaces= in Refer-To what the third party will try and Invite into? In which case, there is an IP address in that URI, which I assume is a local IP address of one of the other handsets, and does it indeed use this address?

In testing, my (working) packet captures are the same in reference to the URI in Refer-To -> I see the local address of the handset, and the transfer completes. One difference is that I see the local handset address in the Via: field, and I wonder if that address comes into play during the transfer, instead of what’s in Replaces?

As above, the customers public address is in the Via: field during their transfer. That’s about the only difference I can discern from the packet capture. Asterisk logs show up nothing, and using them you’d think the transfer completed.