Asterisk 16 Certified 16.8 And MagicJack Incoming Calls
I upgraded our Asterisk 13 LTS to Asterisk 16 Certified 16.8 yesterday and converted form SIP to PJSIP using the python script as a start and then mofiying from there. I ran into an issue when testing that incoming calls from MagicJack would go silent after about 10 seconds. This happened while in the automated attendant area. This problem did not occur with Asterisk 13
LTS. I reverted PJSIP back to SIP and the problem still occurred, so that was not it.
We connect to Flowroute for our SIP provider. I added “force_avp = yes” to the Flowroute endpoint section in the pjsip.conf and the problem appeared to be solved after I tested it a dozen times. However, this morning this issue has reappeared. Any thoughts on what might be causing this?
My Flowroute pjsip.conf config:
[transport-udp]
type = transport protocol = udp bind = 0.0.0.0
tos = cs3
[reg_us-west-wa.sip.flowroute.com]
type = registration retry_interval = 20
expiration = 120
transport = transport-udp outbound_auth = auth_reg_us-west-wa.sip.flowroute.com client_uri = sip:12345678@us-west-wa.sip.flowroute.com server_uri = sip:us-west-wa.sip.flowroute.com
[auth_reg_us-west-wa.sip.flowroute.com]
type = auth password = XXZZXXZZXXZZ
username = 12345678
[reg_us-west-or.sip.flowroute.com]
type = registration retry_interval = 20
expiration = 120
transport = transport-udp outbound_auth = auth_reg_us-west-or.sip.flowroute.com client_uri = sip:12345678@us-west-or.sip.flowroute.com server_uri = sip:us-west-or.sip.flowroute.com
[auth_reg_us-west-or.sip.flowroute.com]
type = auth password = XXZZXXZZXXZZ
username = 12345678
[reg_us-east-nj.sip.flowroute.com]
type = registration retry_interval = 20
expiration = 120
transport = transport-udp outbound_auth = auth_reg_us-east-nj.sip.flowroute.com client_uri = sip:12345678@us-east-nj.sip.flowroute.com server_uri = sip:us-east-nj.sip.flowroute.com
[auth_reg_us-east-nj.sip.flowroute.com]
type = auth password = XXZZXXZZXXZZ
username = 12345678
[reg_us-east-va.sip.flowroute.com]
type = registration retry_interval = 20
expiration = 120
transport = transport-udp outbound_auth = auth_reg_us-east-va.sip.flowroute.com client_uri = sip:12345678@us-east-va.sip.flowroute.com server_uri = sip:us-east-va.sip.flowroute.com
[auth_reg_us-east-va.sip.flowroute.com]
type = auth password = XXZZXXZZXXZZ
username = 12345678
[flowroute]
type = aor contact = sip:12345678@us-west-wa.sip.flowroute.com
[flowroute]
type = identify endpoint = flowroute match = 147.75.60.160/28, 34.210.91.112/28, 34.226.36.32/28, 147.75.65.192/28
[flowroute]
type = auth username = 12345678
password = XXZZXXZZXXZZ
[flowroute]
type = endpoint context = from-trunk dtmf_mode = rfc4733
allow = !all,ulaw direct_media = no from_domain = us-west-wa.sip.flowroute.com tos_audio = ef tos_video = af41
; Note: “force_avp = yes” fixes issues with calls coming from MagicJack with no audio after a few seconds. force_avp = yes auth = flowroute outbound_auth = flowroute aors = flowroute t38_udptl = yes t38_udptl_ec = fec
[anonymous]
type=endpoint context = anonymous allow = !all,ulaw
One thought on - Asterisk 16 Certified 16.8 And MagicJack Incoming Calls
It seems that if there is a pause in the auto attendant longer than a second this problem occurs. I have this for an extension in my extensions.conf file:
exten => 2799,1,GotoIf($[“${CALLERID(num)}” = “${EXTEN}”]?500)
exten => 2799,2,Dial(PJSIP/${EXTEN},14,tr)
exten => 2799,3,Dial(PJSIP/${EXTEN},1,tr)
exten => 2799,4,BackGround(abandon-all-hope)
exten => 2799,5,BackGround(dial-here-often)
exten => 2799,6,Wait(2)
exten => 2799,7,BackGround(gambling-drunk)
exten => 2799,8,BackGround(you-seem-impatient)
exten => 2799,9,BackGround(nobody-but-chickens)
exten => 2799,10,BackGround(tt-somethingwrong)
exten => 2799,11,BackGround(tt-weasels)
exten => 2799,12,Voicemail(${EXTEN},ug(15))
exten => 2799,13,Voicemail(${EXTEN},bg(15))
exten => 2799,14,Hangup exten => 2799,500,VoicemailMain(${CALLERID(num)})
If I change the Wait to 1 the MagicJack will hear everything. If I change it to 2, nothing is heard from that point on.
Chris