Attended Transfer Issue - Received a REFER without a parseable Refer-To

I manage PBX systems behind an SBC. We are having an issue with attended transfer. Example, 3 phones are registered, 101, 102, and 103.

101 calls 102 - good
102 initiates attender transfer to 103 - good
103 answers 102’s call and is now ready for the transfer - good
102 presses the final transfer button to complete the att. transfer - This is where it breaks.

We have done MANY packet capture with both PBX and SBC support and they can’t figure it out but I have narrowed down to a specific Asterisk error message.

We are seeing this error in the asterisk debug
“Received a REFER without a parseable Refer-To”
I have tried using latest versions asterisk 16, 18, and 19. and the problem persists.

I can provide more information on any part of the system if needed, just let me know what might be needed to troubleshoot this. Any help is appreciated!

At the very least, we need the Refer-To header from the received REFER, although the more logging the better.

On Monday 18 March 2024 at 22:04:47, RyuValkyrie via Asterisk Community wrote:

We are seeing this error in the asterisk debug
“Received a REFER without a parseable Refer-To”

Please show us the actual packet capture of this REFER.

Antony.


Never write it in Perl if you can do it in Awk.
Never do it in Awk if sed can handle it.
Never use sed when tr can do the job.
Never invoke tr when cat is sufficient.
Avoid using cat whenever possible.

                                               Please reply to the list;
                                                     please *don't* CC me.

Of course, not sure how much of the conversation you need, but this is the call leg that contains the refer-to issue. I don’t seem to be able to upload it directly. Here is a link to where I can put it, if this is not proper procedure here, let me know and I will change it.

https://drive.google.com/file/d/1Siw9zNc8ezmSUi5WvNpwteKs2Y6Mp70D/view?usp=sharing

In this example, 172.16.3.254 is my PBX, 172.16.0.4 is my SBC.

Refer-To: <sip:103@172.16.3.254:5060?Replaces=0217F2960D814000000246CF@INTERNAL_TS%3Bto-tag%3D4d7d4acf-38ff-4784-985c-6146c11467b3%3Bfrom-tag%3DD23A303033303330A0FDB101>

Nothing obviously wrong, although I would have preferred to see it in the Asterisk logs, together with Asterisk full logging.

Note that the OP’s system seems to be FreePBX, although, except for noisy logs, it shouldn’t make a difference here.

Yes, it is a FreePBX system. Sorry, forgot to mention that.

I enabled debugging at level 3 and just redirected the output of /etc/asterisk/full to another log while making the calls. If you need it pull from another source, or with more verbosity. Please let me know.

https://drive.google.com/file/d/1sGYC7XF49BRXjLc4DllnVVfQZ23Knkc7/view?usp=sharing

There doesn’t seem to be any REFER request in the latest log.

I just double checked it. I’m seeing the REFER on line 5288.

The issue is that the endpoint is not properly encoding the “@” symbol to “%40”. So instead of:

Refer-To: <sip:103@172.16.3.254:5060?Replaces=02180F6E8981400000006C58@INTERNAL_TS%3Bto-tag%3D94049985-9977-4d41-a403-2e66eab4378b%3Bfrom-tag%3D6F8A303033303330343E5800>

It should be:

Refer-To: <sip:103@172.16.3.254:5060?Replaces=02180F6E8981400000006C58%40INTERNAL_TS%3Bto-tag%3D94049985-9977-4d41-a403-2e66eab4378b%3Bfrom-tag%3D6F8A303033303330343E5800>

Parsing occurs within the PJSIP stack itself according to the specs and standards, there’s no option in Asterisk to override that.

1 Like

This is VERY helpful. I suspected this about a month ago but official support for the SBC told me that wasn’t the issue. It was at that time I noticed it was %40 going into the SBC and @ coming out.

I am going to wait for a response from SBC support, but I think this is the answer.

This is the issue. SBC provider is not encoding properly. Working with them for a fix.