Call stealing issues using BLF

This started happening when we converted an old PBX to 12.7.6-2002-2.sng7 so I could believe this could be either the PBX or the older Yealink t38G phones, though it’s not consistently happening. What happens is that when one phone rings and they use the flashing BLF to steal the call it sometimes will connect the call without audio in either direction. It seems to happen maybe 10% of the time.

Here’s what I see in the asterisk log during one example

|[2020-08-19 13:31:43]|app_dial.c: SIP/110-00002b22 is ringing|
|---|---|
|[2020-08-19 13:31:48]|app_dial.c: SIP/116-00002b23 answered SIP/VI-Inbound_1-00002b20|
|[2020-08-19 13:31:48]|pbx.c: Executing [[email protected]:1] Set("SIP/116-00002b23", "__MACRO_RESULT=") in new stack|
|[2020-08-19 13:31:48]|pbx.c: Executing [[email protected]:2] Set("SIP/116-00002b23", "CFIGNORE=") in new stack|
|[2020-08-19 13:31:48]|pbx.c: Executing [[email protected]:3] Set("SIP/116-00002b23", "MASTER_CHANNEL(CFIGNORE)=") in new stack|
|[2020-08-19 13:31:48]|pbx.c: Executing [[email protected]:4] Set("SIP/116-00002b23", "FORWARD_CONTEXT=from-internal") in new stack|
|[2020-08-19 13:31:48]|pbx.c: Executing [[email protected]:5] Set("SIP/116-00002b23", "MASTER_CHANNEL(FORWARD_CONTEXT)=from-internal") in new stack|
|[2020-08-19 13:31:48]|pbx.c: Executing [[email protected]:6] Macro("SIP/116-00002b23", "blkvm-clr,") in new stack|
|[2020-08-19 13:31:48]|pbx.c: Executing [[email protected]:1] Set("SIP/116-00002b23", "SHARED(BLKVM,SIP/VI-Inbound_1-00002b20)=") in new stack|
|[2020-08-19 13:31:48]|pbx.c: Executing [[email protected]:2] Set("SIP/116-00002b23", "GOSUB_RETVAL=") in new stack|
|[2020-08-19 13:31:48]|pbx.c: Executing [[email protected]:3] MacroExit("SIP/116-00002b23", "") in new stack|
|[2020-08-19 13:31:48]|pbx.c: Executing [[email protected]:7] ExecIf("SIP/116-00002b23", "1?Set(MASTER_CHANNEL(CONNECTEDLINE(num))=110)") in new stack|
|[2020-08-19 13:31:48]|pbx.c: Executing [[email protected]:8] ExecIf("SIP/116-00002b23", "1?Set(MASTER_CHANNEL(CONNECTEDLINE(name))=Front Desk)") in new stack|
|[2020-08-19 13:31:48]|bridge_channel.c: Channel SIP/116-00002b23 joined 'simple_bridge' basic-bridge <cd240c75-25a2-4582-bf5a-96901b62c4a8>|
|[2020-08-19 13:31:48]|bridge_channel.c: Channel SIP/VI-Inbound_1-00002b20 joined 'simple_bridge' basic-bridge <cd240c75-25a2-4582-bf5a-96901b62c4a8>|
|[2020-08-19 13:31:56]|bridge_channel.c: Channel SIP/116-00002b23 left 'simple_bridge' basic-bridge <cd240c75-25a2-4582-bf5a-96901b62c4a8>|
|[2020-08-19 13:31:56]|bridge_channel.c: Channel SIP/VI-Inbound_1-00002b20 left 'simple_bridge' basic-bridge <cd240c75-25a2-4582-bf5a-96901b62c4a8>|
|[2020-08-19 13:31:56]|app_macro.c: Spawn extension (macro-dial, s, 23) exited non-zero on 'SIP/VI-Inbound_1-00002b20' in macro 'dial'|
|[2020-08-19 13:31:56]|pbx.c: Spawn extension (followme-sub, 110, 40) exited non-zero on 'SIP/VI-Inbound_1-00002b20'|
|[2020-08-19 13:31:56]|app_stack.c: SIP/VI-Inbound_1-00002b20 Internal Gosub(crm-hangup,s,1) start|

I don’t see anything remarkable here. x110 rings for 5 seconds, x116 takes the call, 8 seconds later the call ends.

I’ve tried using some Yealink t4x phones from another location and that seems to work. The next step is to loan them one to try out and see if it makes a difference unless someone here has an idea.

Thanks.

FreePBX 14.0.13.34
Asterisk 16.9.0

Maybe a wireshark would help see what’s happening with the RTP packets. Seems like the signaling is working. Are all the phones affected on the same subnet?

I could only reproduce it on two phones while I was there but the example above is another phone and the others say it happens sporadically to their phones. So yes, I think.

I’ll see about doing a capture from the router.

rtp set debug on

And see what happens.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.