Outbound calls fail depending on carrier

Hello,

When I place a call to a cell phone using Verizon or AT&T the call goes through. However, when the cell phone is on T-Mobile or Google Fi (effectively T-Mobile), the call fails immediately with SIP response 486 “Busy Here.” In those cases, the target phone doesn’t ring or get a missed call notification.

I’m extremely new to Asterisk, so I’m out of ideas about how to investigate and fix this issue. Any help is appreciated :slightly_smiling_face:

Dialplan:

[outbound_twilio]
exten => _[1-9]XXXXXXXXX,1,NoOp(outbound_twilio)
  same => n,Dial(SIP/outbound_twilio/+1${EXTEN},20)

CLI call log for a failed call, T-Mobile:

== Using SIP RTP CoS mark 5
     > 0x7f1d7401e250 -- Strict RTP learning after remote address set to: 10.10.1.125:3000
  -- Executing [<phone_number>@default:1] NoOp("SIP/0101-00000014", "outbound_twilio") in new stack
  -- Executing [<phone_number>@default:2] Dial("SIP/0101-00000014", "SIP/outbound_twilio/+1<phone_number>,20") in new stack
== Using SIP RTP CoS mark 5
  -- Called SIP/outbound_twilio/+1<phone_number>
  -- Got SIP response 486 "Busy Here" back from 54.172.60.3:5060
  -- SIP/outbound_twilio-00000015 is busy
== Everyone is busy/congested at this time (1:1/0/0)
  -- Auto fallthrough, channel 'SIP/0101-00000014' status is 'BUSY'

CLI call log for a successful call, AT&T:

== Using SIP RTP CoS mark 5
     > 0x7f1d7401f760 -- Strict RTP learning after remote address set to: 10.10.1.125:3000
  -- Executing [<phone_number>@default:1] NoOp("SIP/0101-0000000a", "outbound_twilio") in new stack
  -- Executing [<phone_number>@default:2] Dial("SIP/0101-0000000a", "SIP/outbound_twilio/+1<phone_number>,20") in new stack
== Using SIP RTP CoS mark 5
  -- Called SIP/outbound_twilio/+1<phone_number>
     > 0x7f1de40074c0 -- Strict RTP learning after remote address set to: 34.203.251.243:19834
  -- SIP/outbound_twilio-0000000b is making progress passing it to SIP/0101-0000000a
  -- SIP/outbound_twilio-0000000b is ringing
WARNING[26652][C-00000006]: channel.c:4661 indicate_data_internal: Unable to handle indication 3 for 'SIP/0101-0000000a'
  -- Nobody picked up in 20000 ms
  -- Auto fallthrough, channel 'SIP/0101-0000000a' status is 'NOANSWER'
== Using SIP RTP CoS mark 5
     > 0x7f1d7401e250 -- Strict RTP learning after remote address set to: 10.10.1.125:3000
  -- Executing [<phone_number>@default:1] NoOp("SIP/0101-0000000c", "outbound_twilio") in new stack
  -- Executing [<phone_number>@default:2] Dial("SIP/0101-0000000c", "SIP/outbound_twilio/+1<phone_number>,20") in new stack
== Using SIP RTP CoS mark 5
  -- Called SIP/outbound_twilio/+1<phone_number>
     > 0x7f1dd0007fb0 -- Strict RTP learning after remote address set to: 34.203.250.227:16828
  -- SIP/outbound_twilio-0000000d is making progress passing it to SIP/0101-0000000c
  -- SIP/outbound_twilio-0000000d answered SIP/0101-0000000c
  -- Channel SIP/outbound_twilio-0000000d joined 'simple_bridge' basic-bridge <d855d624-2196-497d-8e2d-8871a96a0bfd>
  -- Channel SIP/0101-0000000c joined 'simple_bridge' basic-bridge <d855d624-2196-497d-8e2d-8871a96a0bfd>
     > Bridge d855d624-2196-497d-8e2d-8871a96a0bfd: switching from simple_bridge technology to native_rtp
     > Remotely bridged 'SIP/0101-0000000c' and 'SIP/outbound_twilio-0000000d' - media will flow directly between them
     > 0x7f1dd0007fb0 -- Strict RTP learning after remote address set to: 34.203.250.227:16828
     > 0x7f1d7401e250 -- Strict RTP learning after remote address set to: 10.10.1.125:3000
  -- Channel SIP/outbound_twilio-0000000d left 'native_rtp' basic-bridge <d855d624-2196-497d-8e2d-8871a96a0bfd>
  -- Channel SIP/0101-0000000c left 'native_rtp' basic-bridge <d855d624-2196-497d-8e2d-8871a96a0bfd>
== Spawn extension (default, <phone_number>, 2) exited non-zero on 'SIP/0101-0000000c'  

The problem seems to be being introduced by Twilio, not Asterisk.

Not sure what the issue is on the on the Twilio side (I’m new to everything there too).

I found that setting CALLERID(number) in extensions.conf or cid_number in sip.conf to one of my business’s numbers instead of leaving it as the phone’s extension seems to have fixed the issue.