attended transfer failed: 481 Call Leg/Transaction Does Not Exist/INVITE

[bit101]

Hi togehter:

unfortunately we´ve from time to time sporadically issues with transfer external calls to another internal extensions. This time a staff member (Extn. 62) got a call (ID: 8553) which he has transfered to a collegue (Extn.21). We can see the "replace event" but after that the originally call (ID: 8553) is away. We can only see "481 Call Leg/Transaction Does Not Exist/INVITE".
We got no "BYE" event before that! Why the call is suddenly away? I cannot understand that! Here is the logfile:

10.05.2021 10:34:48 - Leg L:8553.11[Extn:21] is terminated: Cause: 481 Call Leg/Transaction Does Not Exist/INVITE from 127.0.0.1:5080
10.05.2021 10:34:48 - [CM505003]: Provider:[Easybell] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [] PBX contact: [sip:00*****64987080@116.***.180.***:5060]
10.05.2021 10:34:48 - L:8553.1[Line:10000<<****9821041] failed to reach Extn:21, reason Reason Unknown
10.05.2021 10:34:48 - Call to T:Extn:21@[Dev:sip:[email protected]:58974;line=nuj7wxwe] from L:8553.1[Line:10000<<****9821041] failed, cause: Cause: 481 Call Leg/Transaction Does Not Exist/INVITE from 127.0.0.1:5080
// Here the call is suddenly away, why?!
10.05.2021 10:34:48 - [CM503003]: Call(C:8553): Call to "**Staff Member" <sip:21@***-***.my3cx.de:0> has failed; Cause: 481 Call Leg/Transaction Does Not Exist/INVITE from 127.0.0.1:5080
10.05.2021 10:34:47 - [CM503025]: Call(C:8553): Calling T:Extn:21@[Dev:sip:[email protected]:58974;line=nuj7wxwe] for L:8553.1[Line:10000<<****9821041]
10.05.2021 10:34:47 - Leg L:8554.3[Extn:21] is terminated: Cause: BYE from local
10.05.2021 10:34:47 - [CM503008]: Call(C:8554): Call is terminated
10.05.2021 10:34:47 - Leg L:8554.1[Extn:62] is terminated: Cause: BYE from 127.0.0.1:5080
10.05.2021 10:34:47 - [CM505003]: Provider:[Easybell] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [] PBX contact: [sip:*****[email protected]:5060]
10.05.2021 10:34:47 - Call(C:8553): Replaces: L:8554.3[Extn:21] // We have the replace event
10.05.2021 10:34:47 - [Flow] Refer: RefTo=<sip:21@**-****.my3cx.de:5060>; was call from=<sip:62@**-****.my3cx.de:0> to=<sip:*****[email protected]:5060>
10.05.2021 10:34:44 - Currently active calls - 2: [8553,8554] // Here we have 2 active calls
10.05.2021 10:34:36 - Leg L:8554.2[Extn:21] is terminated: Cause: 487 Request Terminated/INVITE from 127.0.0.1:5080
10.05.2021 10:34:36 - [CM503003]: Call(C:8554): Call to <sip:21@**-****.my3cx.de:0> has failed; Cause: 487 Request Terminated/INVITE from 127.0.0.1:5080
10.05.2021 10:34:36 - [CM503007]: Call(C:8554): Extn:21 has joined, contact <sip:[email protected]:58974/UDP>
10.05.2021 10:34:36 - [CM503007]: Call(C:8554): Extn:62 has joined, contact <sip:[email protected]:5060/UDP>
10.05.2021 10:34:36 - L:8554.3[Extn:21] has joined to L:8554.1[Extn:62]

 

[NickD_3CX]

In your Easybell SIP Trunk settings in the 3CX Management Console, could you please check in the "Options" tab if options "Supports Re-Invite" and "Support Replaces" are checked?
If they are, please uncheck them.

Also make sure option "PBX Delivers Audio" is enabled.

 

[bit101]

Hi,

the options "Supports Re-Invite" and "Support Replaces" are disable. The option "PBX Delivers Audio" is enable:
(only in the extentions setting the option "Supports Re-Invite" is enabled):



Against my statement we can see above that the call 8553 is still active (ID 10.05.2021 10:35:14 - Currently active calls - 3: [8553,8555,8556]

 

[YiannisH_3CX]

Hi @beon

What version PBX do you have and also what devices are you using for your extensions? Are you using IP phones or mobile clients etc?
To be able to better troubleshoot the issue I would recommend enabling verbose logging so you can actually see the SIP messages and better identify why this happens.

 

[bit101]

Hi Yiannish,

it is the 3CX pro version 16.0.9. The 3CX pbx is in a datacenter, locally we have a SBC on Windows 10 pro installed. The customer use Snom M70 DECT phones with the newest firmware installed (BS520B1).
As i said the issue sadly appears sporadically only.

The call with ID 8553 was not away. We can see that this call has been terminated later. Customer said that after try to transfer the call to Extn 21, the originally caller was coming back to Extn. 62.
So what means that the attended transfer "487 Does Not Exist/INVITE" and "L:8553.1[Line:10000<<****9821041] failed to reach Extn:21, reason Reason Unknown" ?
It is also confusing because the Extn 21 was reachable of course, they have spoken 3 seconds before. So could this be a bug in 3CX?

Do you already faced with this issue? I will switch over to verbose logging but i cannot said when this mistake will happen again.

regards,
beon

 

[YiannisH_3CX]

Hi @beon and thank you for the additional info.

We tried to replicate your scenario but we couldn't so it is hard to know what is causing this. We will need the verbose logs to get more details and find the cause. Since this requires additional troubleshooting you could also create a ticket with our support department.

 

[bit101]

Hi Yannish,

thanks for that. I have switch over to verbose loggin now and also create a support ticket. I send the support also this forum thread here to get a faster solution for that. Our customer is a little bit annoyed about this...

 

[bit101]

Hi @YiannisH_3CX

the support team wants to have the PCAP Traces from the 3XC server but the problem is that this issue appears sporadically after 1 or 2 Weeks. This is to long to have an open webbrowser session. Is there another way to run the PCAP traces for example in Linux bash?

Other info is also that our customer has 2 telephones per extension provisioned, a Snom M70 DECT and a SNOM D385 deskphone. He use also the 3CX Windows desktop client in CTI mode with the d385. But he uses only the M70 for attended and blind transfers. Unfortunately i dont know how i can reproduce the issue. Some test attended transfers are working fine from Ext. 62 to Ext. 21

 

[YiannisH_3CX]

You can run tshark which can capture packets continuously without eating away at all your resources. Ask our support department for details on how to run that as the commands vary depending on the situation.